一、什么是 AI Agent
2023 年，Lilian Weng 在博客中给出了一个定义：Agent 是以 LLM 为核心控制器，通过规划、记忆、工具三大组件感知环境并自主执行任务的系统。 这个框架影响了此后两年的大多数 Agent 研究。
2024 年，Google 技术白皮书进一步做了更清晰的阐释：Agent 是一个扩展了大模型出厂能力的应用程序——大模型本身只会说话，而 Agent 能真正"动手"，通过调用外部工具在现实世界中获取信息、完成任务。Anthropic 则进一步区分了两个概念：
- Workflow（工作流）：LLM 和工具通过预定义的代码路径被编排执行，适合可预测的固定任务。
- Agent（智能体）：LLM 动态指挥自己的行为和工具使用，自己决定如何一步步达成目标，适合开放性、步骤数无法预知的复杂任务。
二者的核心区别在于控制权的归属——工作流由开发者预设路径，Agent 由模型驱动决策。
构建 LLM 应用时，应该先用最简单的方案。Agent 带来更强的灵活性，但同时也是更高的延迟、更高的成本，以及更难以预测的行为。能用单次 LLM 调用解决的问题，就不要引入 Agent。
二、Agent 的核心组件
从系统层面剖析一个 Agent，它由三个核心组件构成：规划（Planning）、记忆（Memory）和工具（Tool Use）。
2.1 规划
复杂任务往往需要多个步骤。Agent 必须能够将任务拆解为可管理的子目标，并在执行过程中不断反思、调整策略。
任务分解是最基础的规划能力。CoT（Chain of Thought，思维链）通过提示模型显式输出推理步骤来增强复杂任务表现——让模型在回答前先展示"思考过程"。Tree of Thoughts（ToT）则更进一层：在每个步骤同时探索多条可能的推理路径，形成树状结构，通过 BFS 或 DFS 搜索配合投票或分类器，找到最优解。
任务分解有三种实现方式：由 LLM 通过简单提示词自动分解（如"请列出完成 X 的步骤"）；使用任务专用的指令模板；以及由用户在界面上手动输入分解结果（这一方式在实际产品中较少见，但在需要精确控制时确实存在）。
自我反思是 Agent 区别于普通 LLM 调用的关键能力。Reflexion 框架引入了动态记忆和自我反思机制：每次行动后，Agent 计算一个启发式得分，判断当前轨迹是否低效或存在幻觉（如连续相同动作导致相同结果），并在必要时选择重置环境重新尝试。反思内容通过 few-shot 示例注入到上下文中，供后续决策参考。
2.2 记忆
Agent 的记忆分为两层：短期记忆和长期记忆。
短期记忆本质上是 LLM 的上下文窗口——一切在当前对话中通过 in-context learning 学到的信息，都是短期记忆。它快且可靠，但受限于有限的上下文长度。
长期记忆则让 Agent 能够在更长的时间跨度内保留和检索信息，通常通过外部向量数据库 + 快速相似度检索实现。Generative Agents 论文（Park et al., 2023）展示了一个典型设计：记忆流以自然语言形式持久化记录 Agent 的经验；检索模型根据相关性、近期性和重要性三个维度打分，为当前决策提供最有价值的上下文。
不过向量检索的表示能力不如全注意力机制。当 Agent 需要从大量历史经验中找到真正相关的那一条时，简单的语义相似度往往不够——还需要结合时间和重要性等多维度信号。
2.3 工具使用
工具的使用，是人类区别于动物的标志，也是 Agent 区别于大模型的标志。 这是 Google 白皮书中最为精炼的一句话。
MRKL（Modular Reasoning, Knowledge and Language）系统最早提出了"神经符号"架构的 Agent 概念：多个专业模块（可以是神经网络或符号系统如计算器、天气 API）由 LLM 作为路由器动态调用。Toolformer（TALM 的后续工作）则证明可以通过微调让 LLM 自学使用外部工具 API。
Anthropic 在工程实践中总结了三个原则：给模型足够的 token 思考再行动；格式贴近互联网上的自然文本；避免格式开销（如让模型自己数代码行数或转义 JSON）。在构建 SWE-bench Agent 时他们发现，优化工具定义本身比优化 Prompt 更有价值——把相对路径改为绝对路径后，模型的工具调用错误率大幅下降。
Google 白皮书将工具分为三类。Extensions 直接调用预定义 API 端点，比如让 Agent 查询航班信息；Functions 让模型输出结构化参数，由客户端执行实际调用，适合需要控制权限或保留审计日志的场景；Data Storage 则作为 Agent 的知识检索后端，支持动态更新的信息。Anthropic 更关注工具的文档质量——认为 ACI（Agent-Computer Interface）需要像 HCI（人机交互）一样被认真对待。
三、经典 Agent 范式
3.1 ReAct
ReAct（Synergizing Reasoning and Acting in Language Models）是目前影响最广泛的 Agent 范式，由 Yao et al. 在 ICLR 2023 提出。其核心思想是：将推理（Reasoning）和执行（Acting）融合在同一个 LLM 调用序列中。
ReAct 的标准格式是：
Thought: 我需要做什么
Action: 调用某个工具
Observation: 工具返回了什么
...（循环）
Thought 让模型分析当前状态并决定下一步；Action 执行工具调用；Observation 将结果反馈给模型，进入下一轮推理。ReAct 的关键发现是：在知识密集型任务（如 HotpotQA 问答）和决策型任务（如 ALFWorld 环境导航）中，同时使用 Thought + Action 的效果优于纯 Action（Act-only）或纯推理方法。
3.2 Reflexion
Reflexion 在 ReAct 基础上引入了更结构化的自我反思机制。它维护一个启发式函数，判断轨迹是否低效或包含幻觉（连续相同动作），并在必要时主动重置环境。反思结果以语言形式存入工作记忆（最多 3 条），在后续决策中作为上下文参考。
与 ReAct 的 Observation 不同，Reflexion 的反思是主动的自我评估：不是被动等待环境反馈，而是主动判断当前策略的质量。Datawhale 的教程将其与 Plan-and-Solve 并列为经典范式。
3.3 Plan-and-Solve
Plan-and-Solve 的思路更直接：先让模型制定完整计划，再按计划执行。Google 白皮书中描述的"先规划步骤，再逐步推理"即为此类。它的优势在于计划本身可以被检查和调整，适合步骤明确但执行路径需要一定灵活性的任务。
四、生产级 Agent 设计模式
Anthropic 基于与数十个团队的合作经验，提炼出了七种生产级 Agent 设计模式。这些模式在 Google 白皮书中也能找到对应，二者的共识远大于分歧。
1. Augment LLM（增强版 LLM）：所有模式的基础。LLM 配备检索、工具和记忆能力，可以主动生成搜索查询、选择工具、判断保留哪些信息。
2. Prompt Chaining（提示链）：将任务分解为顺序执行的多个子步骤，每个 LLM 调用处理前一个的输出，在中间步骤加入程序化检查（gate）确保过程在正确轨道上。适合任务可被干净分解为固定子任务、可以用延迟换精度的场景。典型例子：先写大纲→检查大纲是否符合要求→根据大纲写正文。
3. Routing（路由）：对输入进行分类后导向不同的下游处理路径。适合有明确类别区分、且不同类别需要不同处理方式的复杂任务。例如将客服问题分流到退款流程、技术支持或普通问答。Router 可以是 LLM 也可以是传统分类模型。
4. Parallelization（并行化）：LLM 同时处理多个子任务后聚合成最终结果。两种形式：Sectioning（任务分割并行，如同时分析代码的不同部分）和 Voting（同一任务多次执行取最优或投票）。并行化适合子任务相互独立、或需要多视角才能做出可靠判断的场景。
5. Orchestrator-Workers（编排器-工作者）：中心 LLM 动态分解任务、委派给子 LLM、汇总结果。区别于并行化的关键在于：子任务不是预定义的，而是根据输入动态确定的。适合代码修改（需修改哪些文件取决于任务本身）和多源信息搜索等场景。
6. Evaluator-Optimizer（评估器-优化器）：一个 LLM 生成响应，另一个 LLM 提供评估和反馈，循环迭代直到质量达标。适合有明确评估标准、迭代反馈能带来可衡量提升的场景，如文学翻译和复杂多轮搜索任务。
7. Agents（自主 Agent）：上述所有模式的终点。Agent 接收任务后自主规划步骤、通过环境反馈评估进度、在检查点暂停等待人类确认或遇到障碍时主动求助。Anthropic 强调 Agent 的实现通常出奇地简单——往往就是 LLM 在循环中依据环境反馈调用工具。复杂性在于工具集和文档的设计。
五、Tool 设计：被低估的关键环节
Anthropic 在 Appendix 2 中记录了一个发现：构建 Agent 时，优化工具定义往往比优化 Prompt 更有价值。
他们在 SWE-bench 任务中发现，模型在使用相对路径的工具时频繁出错——因为 Agent 会切换工作目录。改为强制使用绝对路径后，错误消失了。这个教训用一句话总结就是：让工具的参数设计使错误更难发生。
Google 白皮书则从另一个角度强调工具设计：Extensions、Functions、Data Storage 三类工具各有适用场景，需要根据任务的实时性要求、执行确定性要求和模型能力来选择。
Datawhale 的教程补充了一个实践视角：在低代码平台（Coze、Dify、n8n）和代码框架（LangGraph、AutoGen）之间做出选择时，前者适合快速验证想法，后者适合需要深度定制的生产场景。
六、多智能体协作
当单个 Agent 的能力无法覆盖任务所需的全领域知识时，多智能体协作成为自然的选择。
Ginonotes 翻译的《智能体设计模式》第七章系统梳理了多智能体协作的核心模式：通过组织一组专长型 Agent 相互协作，将复杂任务拆解为可独立处理的子问题，实现超越单一 Agent 的协同效应。
Anthropic 的 Orchestrator-Workers 模式本质上是一种简化的多智能体协作：Orchestrator 负责任务分解和结果汇总，各 Worker 执行具体子任务。在更复杂的多智能体系统中，还会出现 Agent 间的协议通信、能力互补、结果验证等更高级的协作形态。
Agent 间的通信协议是 2025 年的一个重要方向。MCP（Model Context Protocol）和 A2A（Agent-to-Agent）等协议正在逐步标准化，为不同来源的 Agent 提供互操作基础。
七、典型应用场景
Coding Agent 是目前最成熟、生产部署最广泛的 Agent 类型之一。Anthropic 在 SWE-bench Verified 基准测试中，Agent 能够根据 GitHub Issue 描述独立完成 Pull Request 的修复，展示了接近人类的代码理解和修改能力。代码解决的可验证性（通过自动化测试）是 Coding Agent 成功的关键——明确的成功标准让 Agent 能够可靠地判断任务是否完成。
Computer Use 是另一个前沿方向：Agent 直接控制操作系统界面（鼠标、键盘、屏幕），在真实计算机环境中完成任务。Anthropic 在 Computer Use 参考实现中展示了这方面的探索。这比调用 API 更通用，但同时也面临更高的复杂性和安全挑战。
Customer Support 是 Anthropic 观察到的另一个高价值场景：对话流程天然适合 Agent 架构，工具集成（查用户数据、下订单、退款）可以大幅提升自动化水平，部分公司已采用按成功解决数计费的商业模式。
八、挑战与局限
Agent 目前仍面临几个根本性挑战。
有限的上下文长度始终是瓶颈。Agent 需要在有限的 context 窗口内塞入历史信息、详细指令、API 调用上下文和响应，这限制了可以处理的任务复杂度。虽然向量存储和检索提供了访问更大知识库的途径，但其表示能力不如全注意力机制。
长期规划和任务分解仍是难题。LLM 在面对意外错误时调整计划的能力弱于人类，而自我反思机制虽然有帮助，但也依赖足够长的上下文来存储有价值的反思内容。
自然语言接口的可靠性是实际工程中的痛点。LLM 可能产生格式错误，偶尔还会表现出对抗性行为（拒绝执行指令）。因此大量 Agent Demo 代码实际上是在做"解析"工作——确保模型输出能被程序正确理解和执行。Anthropic 的建议是：把ACI（Agent-Computer Interface）设计得和 HCI（人机交互）一样精细。
结语
2025 年被称为"Agent 元年"，技术焦点正从训练更大的基础模型，转向构建更聪明、更可靠的 Agent 应用。
回过头来看这条演进路径：规划能力让 Agent 知道"做什么"，工具使用让它能够"动手"，记忆让它在长程任务中不会丢上下文，而多智能体协作则把单个 Agent 的边界再往外推了一层。每一个环节都有独立的设计决策空间——这些决策组合得好不好，决定了 Agent 是在原地打转，还是真正能完成复杂的开放任务。
主要参考资料