Agent 是当前 AI 工程领域最热的方向之一。它不只是一个"会调工具的 LLM"，而是一套完整的决策-执行-反馈循环系统。本文从架构角度系统梳理 Agent 的核心模式、关键组件和工程挑战。
什么是 Agent
最简单的定义：Agent = LLM + 工具 + 循环。
传统 LLM 应用是单次请求-响应，用户输入 → 模型输出 → 结束。Agent 的核心差异在于引入了循环：模型可以根据上一步的结果决定下一步做什么，直到任务完成。
这个循环带来了质变：Agent 可以处理需要多步推理、动态决策、与外部系统交互的复杂任务，而这些是单次调用无法完成的。
核心架构模式
ReAct 模式
ReAct（Reasoning + Acting）是最基础也最常用的 Agent 模式，由 Google 在 2022 年提出。
核心思路是让模型交替输出三种内容：
- Thought：当前的推理过程，分析情况、制定计划
- Action：调用某个工具执行操作
- Observation：工具返回的结果
这个 Thought → Action → Observation 的循环不断重复，直到模型判断任务完成并输出最终答案。
Thought: 用户问的是今天北京的天气，我需要调用天气 API。
Action: get_weather(city="北京", date="today")
Observation: {"temp": 18, "weather": "晴", "wind": "东南风3级"}
Thought: 已经拿到天气数据，可以回答了。
Answer: 今天北京天气晴，气温 18°C，东南风 3 级。
ReAct 的优点是简单直观，模型的推理过程完全透明可追踪。缺点是每一步都依赖上一步的结果，无法并行，长任务容易在中途迷失方向。
Plan-and-Execute 模式
Plan-and-Execute 将任务分成两个阶段：先规划，再执行。
规划阶段：用一个 Planner LLM 把复杂任务拆解成有序的子任务列表。
执行阶段：用一个 Executor LLM 逐步执行子任务，每步完成后更新计划状态。
任务：帮我调研竞品并生成分析报告
Plan:
1. 搜索主要竞品列表
2. 分别抓取各竞品官网信息
3. 对比核心功能差异
4. 生成 Markdown 格式报告
Execute:
Step 1 → 搜索结果：[竞品A, 竞品B, 竞品C]
Step 2 → 抓取完成，数据已存储
Step 3 → 差异分析完成
Step 4 → 报告生成完毕
与 ReAct 相比，Plan-and-Execute 更适合长任务。规划和执行解耦，可以在执行中途重新规划（Re-plan），也更容易实现子任务并行。
Reflection 模式
Reflection 让 Agent 具备自我评估和纠错能力。执行完一个步骤后，引入一个独立的 Critic 角色对结果进行审查，发现问题则触发重试或修正。
这个模式有两种变体：
Self-Reflection：同一个模型对自己的输出进行反思，prompt 中明确要求模型找出潜在问题。
外部 Critic：用独立的模型或专门微调的模型做评审，与执行模型分离，避免自我确认偏差。Claude Code 里的验证专家 Agent 就是典型的外部 Critic 模式，且在 prompt 中明确告知 Critic："你自己也容易犯错，不要轻易放行。"
多 Agent 协作模式
当任务足够复杂，单个 Agent 的 context 窗口和能力都会成为瓶颈。多 Agent 架构将任务分配给多个专门化的 Agent 并行处理。常见的拓扑结构有三种：
Orchestrator-Worker：一个主 Agent 负责任务分解和结果汇总，多个 Worker Agent 负责执行具体子任务。主 Agent 不直接操作工具，只做调度。
Pipeline：Agent 串行排列，上一个 Agent 的输出是下一个的输入。适合有明确阶段划分的流程，如"提取 → 分析 → 生成报告"。
Peer-to-Peer：Agent 之间平等协作，通过消息传递共享信息。适合需要多个专家角色讨论的场景，但协调复杂度较高。
核心组件
工具系统
工具是 Agent 与外部世界交互的唯一接口，工具的设计直接决定 Agent 的能力边界。一个好的工具定义需要包含名称、详细描述、参数 Schema 和返回值说明。
{
"name": "search_web",
"description": "搜索互联网获取最新信息。适用于需要实时数据或知识截止日期之后的信息。不适用于本地文件操作。",
"parameters": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "搜索关键词，建议使用精确的关键词而非长句"
},
"num_results": {
"type": "integer",
"description": "返回结果数量，默认 5，最大 20",
"default": 5
}
},
"required": ["query"]
}
}
工具数量不是越多越好。工具过多会稀释模型的注意力，导致选择错误。实践中建议单次请求的工具数量控制在 20 个以内，并通过懒加载机制按需注入。
Memory 系统
Agent 的 Memory 分为四个层次：
- In-context Memory：当前 context 窗口里的对话历史和工具调用记录。最直接但容量有限，超出后需要截断或压缩。
- External Memory：向量数据库、文档存储等外部存储。Agent 通过检索工具按需读取，理论上无上限，但检索质量决定了可用性。
- Episodic Memory：历史任务的执行摘要。Agent 完成一个任务后，将关键信息提炼存储，供后续任务参考。
- Procedural Memory：固化在 system prompt 或工具定义里的行为规范。这是最稳定的 memory，但更新成本高。
Context 管理
Context 窗口是 Agent 最核心的资源，管理不当会导致性能下降甚至任务失败。常见策略：
- 滑动窗口：只保留最近 N 轮对话，实现简单，但可能丢失关键信息。
- 摘要压缩：定期让模型对历史对话生成摘要，用摘要替换原始记录，保留语义信息。
- 重要性过滤：标记关键信息，压缩时优先保留用户核心需求和重要中间结果。
- 分层缓存：将 context 分为静态部分（system prompt、工具定义）和动态部分（对话历史），分别管理缓存策略。
可靠性设计
错误处理与重试
Agent 在执行过程中面临多种错误：工具调用失败、模型输出格式错误、任务陷入死循环等。基本原则：
- 工具错误：将错误信息作为 Observation 返回给模型，让模型决定是重试还是换策略
- 格式错误：设置 output parser，解析失败时触发重新生成，最多重试 3 次
- 死循环检测：设置最大步骤数（max_steps），超出后强制中止并返回当前状态
- 超时控制：每个工具调用设置独立超时，避免单个慢工具阻塞整个流程
幂等性与副作用控制
Agent 执行的操作分为只读操作（搜索、读文件）和写操作（修改文件、发送消息、调用 API）。写操作需要特别谨慎：设计工具时尽量让操作幂等，对不可逆操作增加确认步骤，记录所有写操作的日志支持回滚。
人机协作
完全自主的 Agent 在生产环境中风险较高。实践中通常采用 Human-in-the-loop 设计：
- 审批节点：在关键操作前暂停，等待人工确认后继续。
- 置信度阈值：Agent 对自己的决策不确定时，主动请求人工介入而非盲目执行。
- 操作沙箱：Agent 默认在受限环境中运行，只有明确授权的操作才能影响生产系统。
工程实践
Prompt 工程
Agent 的 system prompt 是整个系统最重要的配置，需要明确定义角色定位、任务边界、行为规范和输出格式。一个常见的误区是 system prompt 写得太短，期望模型自己推断行为规范。实践证明，越详细的 prompt 往往带来越稳定的行为。
可观测性
Agent 的调试比普通程序难得多，因为执行路径是动态的。好的可观测性设计需要：
- 完整的 trace：记录每一步的输入、输出、耗时、token 消耗
- 工具调用日志：每次工具调用的参数和返回值
- 决策追踪：模型的 Thought 过程，理解为什么做出某个决策
- 成本监控：按任务统计 token 消耗和 API 费用，识别异常
评估与测试
Agent 的测试比传统软件更复杂，因为输出存在随机性。常用的评估方法：
- 轨迹评估：评估 Agent 的执行路径是否合理，而非只看最终结果
- 对比测试：同一任务跑多次，统计成功率和平均步骤数
- 边界测试：构造极端输入（空输入、超长输入、恶意输入），验证 Agent 的鲁棒性
- 回归测试集：收集历史上出现过问题的 case，每次更新 prompt 或工具后自动回归
主流框架对比
目前生产环境中常用的 Agent 框架：
- LangGraph：基于图的状态机模型，适合复杂的多 Agent 工作流，状态管理清晰
- AutoGen：微软出品，多 Agent 对话框架，支持 Human-in-the-loop，上手简单
- CrewAI：角色扮演式多 Agent，适合需要明确分工的团队协作场景
- OpenAI Swarm：轻量级多 Agent 框架，核心概念只有 Agent 和 Handoff，极简
- Claude Code SDK：Anthropic 官方 Agent SDK，深度集成 Claude 的工具调用和子 Agent 机制
选择框架的核心原则：简单任务不需要框架，直接调用 API；复杂任务优先选择概念简单、可观测性好的框架，避免过度抽象带来的调试困难。
总结
Agent 架构的核心是循环 + 工具 + 记忆，在这个基础上演化出了 ReAct、Plan-and-Execute、Reflection、多 Agent 协作等不同模式，各有适用场景。
工程实践上，可靠性设计比功能设计更重要。一个能稳定完成 80% 任务的 Agent，比一个偶尔能完成 100% 但经常失败的 Agent 更有价值。错误处理、幂等性、Human-in-the-loop、可观测性，这些"非功能性"设计往往决定了 Agent 能否真正落地。
最后，Agent 不是银弹。并非所有任务都适合用 Agent 解决——如果一个任务可以用简单的 prompt 或确定性代码完成，就不要引入 Agent 的复杂性。