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

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

一、五种基础编排模式

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

1.1 Prompt Chaining（链式调用）

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

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

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

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

1.2 Routing（路由分发）

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

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

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

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

1.3 Parallelization（并行聚合）

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

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

两种变体：

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

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

1.4 Orchestrator-Subagents（主控-子 Agent）

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

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

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

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

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

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

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

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

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

二、三大经典 Agent 范式

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

2.1 ReAct：推理与行动交织

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

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

1
2
3
4
5
6
7
8
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）。

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

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

与 ReAct 的对比：

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

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

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

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

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

1
2
3
4
5
6
7
8
9
第一次尝试:
  执行任务 → 输出结果

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

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

两种形式：

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

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

三、工具调用机制

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

3.1 Tool 范式的演进

1
2
3
4
5
文本输出        →  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）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
  "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 的工具调用参数、状态更新、最终输出都需要程序处理，非结构化输出意味着每次都需要脆弱的字符串解析，一旦格式偏差就可能导致整个流程失败。

四、范式选择的判断框架

1
2
3
4
5
6
7
8
9
10
11
12
13
14
任务结构是否清晰？
├── 是 → 步骤是否在开始前可知？
│         ├── 是 → Plan-and-Solve
│         └── 否 → ReAct
└── 否 → 质量要求是否高于速度？
          ├── 是 → Reflection（+ ReAct 或 Plan-and-Solve）
          └── 否 → ReAct（快速迭代）

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

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

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

五、总结

概念 核心要点
Prompt Chaining 线性步骤串联，每步输出是下步输入
Routing 先分类再路由到专门处理流程
Parallelization 独立子任务并行执行，汇总结果
Orchestrator-Subagents 主控 Agent 分配任务，专业子 Agent 执行
Evaluator-Optimizer 生成-评估-改进循环，以质量换速度
ReAct 推理与行动交替，边做边学，适合探索性任务
Plan-and-Solve 先规划再执行，适合结构清晰的任务
Reflection 自我评估与迭代，质量优先时使用
Function Calling 工具调用的标准机制，Schema 定义工具接口
Structured Output 约束 LLM 输出格式，生产可靠性的基础

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

Prev
#Agent
Next