什么是 AI Agent

在讨论设计模式之前，我们先厘清一个基本问题：什么才算是一个 AI Agent，而不仅仅是一次 LLM 调用？

一次普通的 LLM 调用遵循”输入-输出”的静态模式：用户提问，模型回答。而 AI Agent 则拥有一个持续运行的自主循环：

1
感知（Perceive）→ 推理（Reason）→ 行动（Act）→ 观察（Observe）→ 回到感知

Agent 与普通 LLM 调用的关键区别在于：

维度 LLM 调用 AI Agent
执行模式 单次、无状态 多轮、有状态
与环境交互 仅文本输入 可以调用工具、访问外部数据
目标导向 完成当前问答 朝着一个目标持续努力
自主性 低（被动响应） 高（主动规划并执行）
错误处理 输出可能出错即终止 检测错误、自我修正、重试

这个自主循环是所有 Agent 架构的根本出发点。不同的设计模式，本质上是对这个循环的增强、变体和优化。

核心设计模式

ReAct：推理与行动的交织

ReAct（Reasoning + Acting）是当前使用最广泛的 Agent 模式。它的核心思想是将思考与行动交替进行——不像传统 pipeline 那样先一次性想清楚再执行，而是在执行中不断调整思路。

1
2
3
4
5
Thought: 我需要知道北京的天气才能回答这个问题
Action: 调用 get_weather(city="北京")
Observation: 北京：晴，25°C
Thought: 获得了北京的天气信息，可以给出回答
Answer: 北京今天天气晴朗，气温 25°C

ReAct 的优势在于：

  • 可解释性：每一步的 Thought 都暴露了模型的推理过程，便于调试和审计。
  • 容错性：错误的中间步骤可以被后续的 Thought 检测并修正。
  • 工具友好：Thought-Action-Observation 的三段式结构与工具调用天然契合。

几乎所有现代 Agent 框架（LangChain Agent、LangGraph、AutoGen）都在不同程度上实现了 ReAct 模式。它的主要局限是：当任务需要更前瞻性的规划时，逐步推理的效率较低。

Plan-and-Execute：规划先行

Plan-and-Execute 模式将任务分为两个阶段：

  1. 规划阶段：Agent 收到任务后，先生成一个完整的执行计划（步骤清单）。
  2. 执行阶段：Agent 按计划逐步执行，执行过程中可以根据进度更新计划。
1
2
3
4
5
6
7
8
9
10
11
用户：分析新能源汽车市场趋势并撰写报告

Plan:
1. 收集 2025-2026 年新能源汽车销量数据
2. 分析主要品牌的市场份额变化
3. 研究核心技术的进展（电池、自动驾驶）
4. 评估政策环境的影响
5. 撰写综合分析报告

Execute:
Step 1 → 获得数据 → Step 2 → 获得分析 → ... → Step 5 → 完成

这种模式特别适合步骤可提前枚举的复杂任务，如研究报告撰写、代码项目开发、多步骤的文档生成。它的核心优势是全局视野——在动手之前先看清全局，避免在细节中迷失方向。

在实际实现中，可以结合 ReAct：规划器生成宏观计划，每个步骤内的执行使用 ReAct 循环。这就是所谓的分层 Agent 架构。

Reflexion：从经验中学习

Reflexion 模式引入了一个自我反思的环节，让 Agent 在执行失败后能够分析原因、改进策略：

1
2
3
4
5
6
7
8
9
执行失败：工具调用返回错误
↓
Reflexion：我调用 API 时使用了错误的参数格式
          → 应该先查看工具文档，了解正确的调用方式
↓
重试：先调用 help(tool_name) 获取文档
     → 使用正确的参数格式重新调用
↓
成功

Reflexion 的核心组件包括：

  • Actor：执行任务的 Agent。
  • Evaluator：评估执行结果，判断成功或失败。
  • Self-Reflection：失败时分析根本原因，产生”经验教训”。
  • Memory：将经验存储为长期记忆，供未来的类似场景使用。

这种模式模拟了人类”从错误中学习”的能力，让 Agent 在多次执行中逐步改善表现。

Self-Refine：迭代改进

Self-Refine 与 Reflexion 类似，但侧重点不同：Reflexion 关注的是行为策略的改进（如何更好地调用工具），而 Self-Refine 关注的是输出质量的改进（如何生成更好的内容）。

1
2
3
4
5
6
7
8
9
10
11
初始输出：一个只有基本结构的报告

Feedback：报告缺少数据支撑，论证不够充分
↓
改进：添加具体数据，强化论证逻辑

Feedback：语言风格过于学术化，目标读者可能难以理解
↓
改进：调整语言风格，增加案例说明

最终输出：数据扎实、论证有力、易于理解的报告

Self-Refine 在内容创作、代码生成、翻译润色等场景中特别有效。它可以用”同一模型既生成又评估”的简单形式实现，也可以引入专门的 Evaluator 模型。

工具使用模式

工具是 Agent 能力的放大器。好的工具设计遵循以下原则：

工具的设计哲学

  1. 单一职责：每个工具只做一件事，并且做好。与其设计一个”万能数据分析工具”，不如将查询、图表、统计分别独立为工具。
  2. 自描述接口：工具的函数名、docstring、参数类型注解至关重要——这是模型理解工具能力的唯一途径。写作清晰的道具说明是 prompt engineering 的重要部分。
  3. 结构化输出：工具返回结构化的、易于被 LLM 理解和引用的结果。JSON 格式优于自然语言描述。
  4. 幂等性：同一个工具用相同参数调用多次，结果应该一致（或至少安全）。这避免了 Agent 因重试而产生副作用。

推理与行动的交织模式

在工具调用中，常见的执行模式有两种：

顺序工具链：Agent 按固定顺序调用工具——“先查数据，再分析，再生成图表”。适合步骤明确的标准化流程。

动态工具选择：Agent 根据当前状态自主决定下一个工具——“我现在需要查什么才能回答用户的问题？”。这是 Agent 自主性的核心体现。

在实践中，大多数系统混合使用这两种模式：将标准流程编码为可选的”SOP”（标准作业程序），同时允许 Agent 根据实际情况灵活偏离。

记忆模式

记忆是 Agent 区别于无状态脚本的关键能力。三种记忆模式分别服务于不同的时间尺度：

短期记忆（Working Memory）

存储当前任务执行过程中的信息：对话历史、中间计算、工具调用结果。通常实现为简单的消息列表或字典，生命周期与当前任务一致。

长期记忆（Long-term Memory）

跨越多次会话的持久化知识：用户偏好、已完成的项目、学到的经验。通常使用向量数据库（Chroma、Pinecone、Milvus）实现，通过语义搜索检索相关内容：

1
2
3
4
5
6
7
8
9
10
11
12
# 存入长期记忆
vector_store.add(
    texts=["用户偏好简洁的回答风格，不喜欢冗长的解释"],
    metadata={"type": "user_preference", "user_id": "user_123"}
)

# 检索相关记忆
relevant_memories = vector_store.similarity_search(
    "用户的回复偏好",
    k=3
)
# → 在构建 Agent Prompt 时，将 relevant_memories 注入系统消息

情景记忆（Episodic Memory）

记录完整的任务执行历程：成功案例、失败教训、决策过程。这是 Reflexion 模式的基础——Agent 通过回顾过去的经历来改善将来的行为。实现上，情景记忆通常存储结构化的事件日志，支持按任务类型、时间范围、结果状态等维度检索。

规划模式

任务分解（Task Decomposition）

将复杂任务分解为子任务，是提升 Agent 成功率的最有效手段之一。两种分解策略：

  • 自上而下：先定义顶层目标，逐层分解到可执行的原子步骤。适合结构化任务，如”开发一个用户管理系统”。
  • 自下而上：从最具体的需求出发，逐步组合成更大的方案。适合探索性任务，如”分析为什么用户流失率上升”。

层次化规划（Hierarchical Planning）

在复杂任务中，单一层次的规划是不够的：

1
2
3
Level 1（战略层）：完成用户管理模块
    Level 2（战术层）：实现用户注册功能
        Level 3（操作层）：创建数据表 → 编写 API → 实现前端表单 → 编写测试

层次化规划让 Agent 能够在不同抽象层次上思考和行动——在战略层做决策时不会被低级细节淹没，在操作层执行时又有清晰的上下文。

多 Agent 协作模式

当单个 Agent 的能力不足以覆盖任务的全部维度时，多 Agent 协作就成为了选择。常见的协作模式包括：

辩论模式（Debate）

多个 Agent 独立生成答案，然后互相评审、质疑，通过多轮”辩论”达成共识或选出最优解。适用于需要严谨推理的场景，如数学证明、法律分析、安全风险评估。

投票模式（Voting）

多个 Agent 独立工作，最终通过多数投票决定输出。适用于容错性要求高的场景——即使个别 Agent 出错，整体结果依然可靠。这是一种简单的集成学习策略。

专长角色（Specialized Roles）

每个 Agent 被赋予一个明确的角色和领域知识：研究员负责收集信息，分析师负责解读数据，写手负责产出文本，审核员负责质量把关。这是目前生产环境中应用最广泛的模式，也是 LangGraph 等框架重点支持的场景。

错误恢复模式

在生产环境中，Agent 不可避免地会出错。可靠的错误恢复策略包括：

  1. 重试（Retry）：最简单的策略。对瞬态错误（API 超时、速率限制）有效。应结合实际采用指数退避，避免对后端系统造成冲击。
  2. 降级（Fallback）：当首选方案失败时，使用次优但可靠的备选方案。例如，精确搜索无结果时，回退到模糊搜索。
  3. 人工升级（Human Escalation）：当 Agent 遇到超出能力边界的问题时，将任务转交给人工处理。LangGraph 的 interrupt 机制为此提供了原生支持。
  4. 自我修正（Self-Correction）：Agent 检测到自己的输出不符合预期后，自动触发修正流程——这是 Reflexion 和 Self-Refine 模式的核心。

评估 Agent 架构

选择架构时，需要权衡以下维度：

维度 需要考虑的问题
延迟 用户的等待容忍度是多少？多 Agent 系统通常更慢。
可靠性 任务的容错要求有多高？投票和辩论模式提高可靠性，但增加成本。
成本 每次推理消耗的 token 数量和模型单价。越是复杂的模式，通常消耗越大。
可解释性 是否需要 audit trail？ReAct 模式天然提供推理链。
维护性 系统的复杂度是否能被团队持续维护？

实用的决策框架：

  • 简单任务（单步查询、翻译、摘要）：直接 LLM 调用或简单的 ReAct Agent。
  • 中等任务（多步推理、需要工具）：ReAct Agent + 基础的记忆系统。
  • 复杂任务（多维度分析、长文档生成）：Plan-and-Execute + Reflexion。
  • 超复杂任务（多领域专家协作）：多 Agent 的 Supervisor 模式，配合完善的错误恢复。

结语

AI Agent 的设计模式仍在快速演进中。ReAct、Plan-and-Execute、Reflexion 这些经典模式奠定了 Agent 开发的工程基础，而随着 LangGraph 等新工具的出现，我们正在见证多 Agent 协作、人机协同等更复杂模式的成熟。

不管模式如何演化，核心原则始终不变：保持架构的简单性、确保状态的可追踪性、为失败设计容错机制。一个设计良好的 Agent 系统，不应该试图用复杂的模式掩盖模型本身的不确定性，而应该通过清晰的架构将不确定性限制在可控范围内。