Agent —— 核心范式与行动机制

如果说 LLM 是 Agent 的”大脑”，那么范式（Paradigm）就是大脑的”思维方式”，工具调用机制就是”手”。本篇覆盖 Agent 决策和行动的核心设计模式。

一、五种基础编排模式

Anthropic 在 《Building Effective Agents》 中总结了五种基础编排模式，这是比具体框架更底层的设计原语，所有框架都在这五种模式的基础上组合构建。

1.1 Prompt Chaining（链式调用）

结构：将复杂任务拆解为多个步骤，每个步骤的输出作为下一个步骤的输入。

用户需求 → [步骤1: 提取关键信息] → [步骤2: 搜索相关资料] → [步骤3: 生成报告] → 输出

适用场景：任务有明确的线性步骤，每步结果可验证（加入检查点）。例如：文档翻译 → 质量检验 → 格式化输出。

优点：流程清晰，每步可独立测试；出错时容易定位。
缺点：不灵活，无法处理步骤之间需要动态决策的情况。

1.2 Routing（路由分发）

结构：先对输入进行分类，再路由到对应的专门化子流程。

用户输入 → [分类器 LLM] → 判断类型
                           ├─ 技术问题 → 技术支持 Agent
                           ├─ 退款请求 → 财务 Agent
                           └─ 通用咨询 → 通用 Agent

适用场景：不同类型的任务需要不同的处理逻辑或专业知识。例如：客服系统按问题类型路由，代码库按语言路由到不同的代码 Agent。

优点：每条路径可以针对性优化；各路径互相隔离，易于维护。
缺点：分类准确率直接决定整体效果；需要维护多条路径。

1.3 Parallelization（并行聚合）

结构：将任务的多个子任务同时执行，再聚合结果。

                    ├─ [子任务 A] ─┐
用户需求 → [拆解] ─ ├─ [子任务 B] ─┤ → [聚合] → 输出
                    └─ [子任务 C] ─┘

两种变体：

• 分段并行：同一任务由多个 Agent 独立处理，取最优或多数投票（提升准确率）
• 任务并行：互相独立的子任务同时执行（降低总延迟）

适用场景：子任务之间无依赖关系；对响应速度有要求；需要通过多次独立评估提升准确率。

1.4 Orchestrator-Subagents（主控-子 Agent）

结构：一个 Orchestrator Agent 负责规划和任务分配，多个 Subagent 负责专门的执行工作。

用户需求 → [Orchestrator]
               ├─ 分配给 [搜索 Agent]
               ├─ 分配给 [代码执行 Agent]
               └─ 分配给 [文件操作 Agent]
               ↑─────── 收集结果，决定下一步 ──────┘

适用场景：需要动态规划的复杂任务，子任务在执行前无法完全预知。例如：自主软件工程 Agent（Devin 的模式），复杂研究任务。

特点：Orchestrator 是”项目经理”，Subagent 是”专业执行者”。Orchestrator 的质量直接决定整体效果。

1.5 Evaluator-Optimizer（生成-评估循环）

结构：一个 LLM 生成输出，另一个 LLM 评估并给出改进建议，循环迭代直到质量达标。

[生成 Agent] → 输出草稿 → [评估 Agent] → 满意? → 是 → 最终输出
     ↑                          │
     └─────── 改进建议 ──────────┘ 否

适用场景：输出质量有明确标准；单次生成质量不稳定；可以接受额外的延迟和成本换取更高质量。代表场景：代码生成后自动测试、文章写作后风格评审。

本质：用 LLM 的判断能力来弥补生成能力的不稳定性，类似于”写-改-审”的人类写作流程。

---

二、三大经典 Agent 范式

在五种基础模式之上，形成了三个经典的 Agent 范式，是目前工程实践中使用最广的决策架构。

2.1 ReAct：推理与行动交织

来源：Yao et al. 2022，论文标题即 “Synergizing Reasoning and Acting in Language Models”。

核心思想：将推理（Reasoning）和行动（Acting）交替进行，而不是先规划所有步骤再执行。每次行动后的观察结果立即影响下一步推理。

Thought:     我需要知道 X 才能回答用户的问题，调用工具 A 查询 X。
Action:      tool_A(query="X")
Observation: X 的值是 42。
Thought:     知道了 X=42，现在需要用 X 计算 Y，调用工具 B。
Action:      tool_B(x=42)
Observation: Y = 84。
Thought:     有了所有信息，可以给出答案了。
Action:      Finish["答案是 84"]

优点：

• 行动后立即利用观察结果，不会在错误方向上走太远
• 推理步骤可见，便于调试和理解
• 适合信息未知但工具齐全的探索性任务

局限：

• 容易陷入循环（工具调用失败→重试→再失败）
• 对工具的依赖性强，工具不可用时无法应对
• 没有全局规划，可能在局部优化上浪费步骤

2.2 Plan-and-Solve：先规划再执行

核心思想：将任务分解为两个阶段——先制定完整计划（Planning），再按计划执行（Executing）。

阶段一（规划）:
Thought: 用户任务是"分析竞品并生成报告"
Plan:    1. 搜索竞品列表
         2. 逐一搜索各竞品详情
         3. 分析对比各竞品的优缺点
         4. 生成结构化报告

阶段二（执行）:
执行步骤 1 → 执行步骤 2 → ... → 生成最终报告

与 ReAct 的对比：

维度	ReAct	Plan-and-Solve
规划时机	边走边决策	先制定全局计划
灵活性	高，能随时调整	低，计划变更成本高
效率	可能走弯路	路径更优，但计划本身可能有缺陷
适用场景	探索性任务，步骤未知	结构化任务，步骤可预知

适用场景：任务的步骤在开始前大体可知，且步骤之间有明确依赖关系。例如：生成技术报告、执行一套完整的数据分析流程。

2.3 Reflection：自我批评与迭代改进

来源：Shinn et al. 2023，Reflexion 论文系列。

核心思想：Agent 在执行后对自己的输出进行评估和反思，将反思结果存入记忆，在下一次尝试时避免同样的错误。

第一次尝试:
  执行任务 → 输出结果

Reflection:
  评估输出 → 发现问题: "代码跑通了，但边界条件没有处理"
  将反思存入记忆: "需要考虑 N=0 和负数的情况"

第二次尝试（带反思记忆）:
  执行任务（参考记忆中的反思）→ 更好的输出

两种形式：

• 自我反思：Agent 用自己来评估自己（节省成本，但可能有盲区）
• 外部反思：用独立的 Evaluator LLM 或外部工具（如测试框架）来评估

成本-收益分析：Reflection 机制会增加 2-3 倍的 Token 消耗和延迟，适合质量要求高于速度要求的场景（代码生成、复杂分析）。对于简单任务，单次 ReAct 已经够用。

---

三、进阶推理范式

在三大经典范式之上，学术界和工程界还发展出若干更专门化的推理范式，了解它们有助于在复杂场景下做出更合适的设计选择。

3.1 Tree of Thoughts（ToT）：树状搜索推理

来源：Yao et al. 2023，Princeton / Google DeepMind

核心思想：将推理过程建模为树状搜索。每个节点是一个中间思维（Thought），每次从当前节点扩展多个候选后续思维，通过评估函数剪枝，保留最有希望的路径继续探索。

问题
├─ 思路 A
│   ├─ A-1 → 评估: 差 ✗（剪枝）
│   └─ A-2 → 评估: 好 ✓
│         └─ A-2-1 → 最终答案 ✓
├─ 思路 B → 评估: 差 ✗（剪枝）
└─ 思路 C → 评估: 中等
      └─ C-1 → ...

搜索策略可以是 BFS（广度优先，找最优解）或 DFS（深度优先，快速找可行解）。

与 ReAct 的区别：ReAct 是线性”思考→行动→观察”，ToT 在每步维护多个候选，支持回溯，适合需要”试错”的任务。

适用场景：数学证明、创意写作、策略规划等需要回溯的复杂推理。

代价：调用次数是 ReAct 的 5-20 倍，成本高，不适合简单任务。

---

3.2 Self-Consistency：多路采样投票

来源：Wang et al. 2022

核心思想：以高 temperature 采样生成多条独立的推理路径，对最终答案进行多数投票，取胜出答案作为输出。

问题
├─ 推理路径 1 → 答案: A
├─ 推理路径 2 → 答案: A  ← 多数
├─ 推理路径 3 → 答案: B
└─ 推理路径 4 → 答案: A
最终答案：A（3/4 票）

特点：不需要额外工具和外部环境，代价是 N 倍 token 消耗；通常与 CoT 结合使用。

与 ToT 的区别：Self-Consistency 各路径完全独立，最后投票；ToT 在生成过程中持续评估并剪枝。

适用场景：高精度推理任务，对延迟不敏感，可接受多倍成本换取准确率提升。

---

3.3 Self-Refine：同模型自迭代改进

来源：Madaan et al. 2023

核心思想：同一个模型承担生成者和批评者两个角色，生成输出 → 自我批评 → 基于批评修改，循环直到满意或达到最大迭代次数。

生成 → 输出 v1
        ↓
自我批评: "边界条件未处理"
        ↓
修改 → 输出 v2
        ↓
自我批评: "基本满足要求"  → 终止，输出 v2

与 Reflection（Reflexion）的核心区别：

维度	Self-Refine	Reflexion
评估来源	自身 LLM	外部执行结果（如代码运行）
记忆	无持久记忆	反思写入持久记忆
依赖	无需外部环境	需要可运行的外部环境

适用场景：代码风格改进、文章润色、答案优化；不适合需要外部验证的场景。

---

3.4 Self-Ask：显式子问题分解

来源：Press et al. 2022

核心思想：LLM 主动将复杂问题分解为若干更简单的子问题，依次回答，最后综合得出最终答案。可以配合搜索工具，每个子问题独立检索。

问题："苹果公司的创始人出生在哪个城市？"

Follow-up: 苹果公司的创始人是谁？
Intermediate: 史蒂夫·乔布斯

Follow-up: 史蒂夫·乔布斯出生在哪里？
Intermediate: 旧金山（搜索工具返回）

Final Answer: 旧金山

与 ReAct 的区别：Self-Ask 先显式列出所有子问题再依次回答；ReAct 边行动边决策下一步，分解是隐式的。

适用场景：多跳知识问答、Multi-hop RAG 的前置查询分解。

---

3.5 MRKL：模块化路由推理

来源：Karpas et al. 2022, AI21 Labs
全称：Modular Reasoning, Knowledge and Language

核心思想：LLM 作为路由器，识别问题的类型，将子任务分发给对应的专家模块（计算器、数据库、搜索引擎、代码解释器等）处理，自己负责组织最终答案。

问题："$1000 投资年化 8%，10 年后是多少？"

LLM 判断：需要精确计算 → 路由给计算器
calculator("1000 * (1.08)^10") → 2158.93

LLM 组织回答："10 年后约 $2158.93"

核心洞察：LLM 在事实记忆和精确计算上不可靠，应交给专门模块处理，LLM 只负责理解和路由。

历史地位：MRKL 是 2022 年的早期工作，其核心思想已被现代 Function Calling 完全吸收——现在的 Agent 都是”LLM 路由 + 工具执行”的 MRKL 变体。理解 MRKL 有助于理解 Function Calling 设计的根本动机。

---

四、工具调用机制

工具是 Agent 连接外部世界的接口，也是从”只能说”到”能做”的关键跨越。

3.1 Tool 范式的演进

文本输出        →  Agent 用自然语言描述要做什么，人类执行
Structured Output → Agent 输出 JSON，系统自动解析执行
Function Calling  → LLM 原生支持工具调用，参数有 Schema 约束
Computer Use      → Agent 直接操控浏览器/桌面的 GUI 界面
Agent-to-Agent    → Agent 调用另一个 Agent 作为工具（MCP/A2A 协议）

每一步都在扩大 Agent 的行动边界，但也带来新的安全和可靠性挑战。

3.2 Function Calling 的工程机制

Function Calling 是目前最主流的工具调用方式，工作机制如下：

1. 工具定义（JSON Schema）：

{
  "name": "get_weather",
  "description": "查询指定城市的实时天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "城市名称，如'北京'"
      }
    },
    "required": ["city"]
  }
}

工具描述的质量直接影响 Agent 是否能正确选择和调用工具。description 字段对 LLM 的工具选择影响最大，含糊的描述会导致工具调用错误。

2. 并行 vs 串行工具调用：

• 串行：顺序调用，第 N 个工具的结果可能影响第 N+1 个工具的参数
• 并行：当多个工具调用互不依赖时，同时发出，节省总延迟

现代 LLM API（OpenAI、Anthropic）都支持在单次响应中返回多个工具调用，框架负责并行执行。

3. Tool Hallucination（工具幻觉）：
LLM 可能调用不存在的工具，或传入不合法的参数。防护措施：

• 严格校验工具名称是否在注册表中
• 用 JSON Schema 验证参数格式
• 对参数做语义层的合理性检查

3.3 Structured Output：可靠性的基础

问题：自由文本输出无法被程序稳定解析，”大约是 JSON 格式”的输出会导致生产事故。

解决方案：

• JSON Mode：强制要求 LLM 输出合法 JSON，但不能约束 JSON 的具体结构
• JSON Schema 约束：指定输出必须符合特定 Schema，拒绝不合规的输出（最严格）
• Instructor 库：用 Pydantic 定义输出 Schema，自动重试直到格式正确
• Outlines 库：通过约束采样（Constrained Sampling），从 Logit 层面保证输出符合语法

为什么 Structured Output 是生产可靠性的基础：Agent 的工具调用参数、状态更新、最终输出都需要程序处理，非结构化输出意味着每次都需要脆弱的字符串解析，一旦格式偏差就可能导致整个流程失败。

---

五、范式选择的判断框架

任务结构是否清晰？
├── 是 → 步骤是否在开始前可知？
│         ├── 是 → Plan-and-Solve
│         └── 否 → ReAct
└── 否 → 质量要求是否高于速度？
          ├── 是 → Reflection（+ ReAct 或 Plan-and-Solve）
          └── 否 → ReAct（快速迭代）

任务是否可以并行？
├── 是 → Parallelization
└── 否 → 继续上面的判断树

输入类型是否多样？
└── 是 → Routing + 上面的判断树

精度 vs 成本的额外判断维度：

能接受 N 倍成本换精度？
├─ 是 → 推理路径多样性重要？ → Self-Consistency（投票）
│       需要空间探索回溯？   → Tree of Thoughts
└─ 否 → 继续上面的判断树

需要多跳知识推理？
└─ 是 → Self-Ask + 搜索工具

使用外部专家模块（计算器/数据库）？
└─ 是 → MRKL 思想（即现代 Function Calling）

在实际工程中，复杂系统往往是多种范式的组合：Routing 先分类，Plan-and-Solve 做高层规划，ReAct 执行具体步骤，Reflection 在关键输出上做质量验证，Self-Consistency 在高精度决策节点投票确认。

---

六、总结

概念	核心要点
Prompt Chaining	线性步骤串联，每步输出是下步输入
Routing	先分类再路由到专门处理流程
Parallelization	独立子任务并行执行，汇总结果
Orchestrator-Subagents	主控 Agent 分配任务，专业子 Agent 执行
Evaluator-Optimizer	生成-评估-改进循环，以质量换速度
ReAct	推理与行动交替，边做边学，适合探索性任务
Plan-and-Solve	先规划再执行，适合结构清晰的任务
Reflection	自我评估与迭代，质量优先时使用
Tree of Thoughts	树状搜索多条推理路径，支持回溯，成本高
Self-Consistency	多路采样投票，无需工具，以 N 倍成本换准确率
Self-Refine	同模型自我批评迭代，轻量，无需外部环境
Self-Ask	显式分解子问题，适合多跳推理
MRKL	路由到专家模块，Function Calling 的思想前身
Function Calling	工具调用的标准机制，Schema 定义工具接口
Structured Output	约束 LLM 输出格式，生产可靠性的基础

下一篇：框架生态全景——从低代码平台到重框架，六层分类图谱与选型判断逻辑。