Agent 架构模式

不只一种 Agent

到目前为止，我们讨论的都是最简单的 Agent 形态：一个模型 + 一组工具，在一个循环里解决问题。

但现实中的任务复杂度差异巨大。一个"帮我查天气"和"帮我把这个单体应用拆成微服务"显然需要不同的架构。

本章我们来看几种常见的 Agent 架构模式，以及它们各自适合什么场景。

模式一：单 Agent

最简单的架构，也是前几章一直在讲的：

用户请求 → [Agent: LLM + 工具集] → 最终结果
                ↻ 推理循环

一个模型承担所有工作——理解意图、规划步骤、调用工具、综合结果。

适用场景：

• 任务范围明确、工具数量有限（10 个以内）
• 不需要特别深的专业知识
• Claude Code 处理单个编程任务就是这个模式

局限：

• 工具太多时，模型选择工具的准确率会下降
• 模型需要同时扮演"规划者"和"执行者"，对推理能力要求高
• 上下文窗口可能不够用

模式二：路由（Router）

当你有多个不同领域的能力时，可以用一个路由层先判断任务类型，再分发给专门的处理模块：

用户请求 → [路由 Agent]
              ├→ 代码问题 → [编程 Agent + 编程工具]
              ├→ 数据分析 → [分析 Agent + 数据工具]
              └→ 文档问题 → [文档 Agent + 搜索工具]

路由 Agent 通常很轻量——它不解决问题，只负责分类和转发。

适用场景：

• 客服系统（不同类型的问题由不同专家处理）
• 多功能助手（一个入口，多个专业能力）

优势：

• 每个子 Agent 只需要关注自己领域的工具，降低复杂度
• 可以为不同领域使用不同的模型（简单分类用小模型，复杂推理用大模型）

注意： 路由判断本身可能出错。一个被错误分类的请求会得到完全不相关的处理。

模式三：编排者-执行者（Orchestrator-Worker）

一个"大脑"负责拆解任务和协调，多个"手脚"负责执行具体步骤：

用户请求 → [编排者 Agent]
              ├→ 分配子任务 1 → [执行者 A] → 结果
              ├→ 分配子任务 2 → [执行者 B] → 结果
              └→ 分配子任务 3 → [执行者 C] → 结果
                    ↓
           [编排者 Agent 综合结果] → 最终输出

编排者负责：

• 把复杂任务拆解为可独立执行的子任务
• 分配子任务给合适的执行者
• 收集结果并综合
• 如果某个子任务失败，决定是重试还是调整计划

执行者只需要专注完成分配给它的具体任务。

适用场景：

• 可并行的大任务（同时分析多个文件、同时调研多个方向）
• 需要不同专业能力的组合任务

实际例子： 你让 AI 做一个代码审查。编排者可能拆解为：执行者 A 检查代码风格，执行者 B 检查安全漏洞，执行者 C 检查性能问题。三个并行执行，最后汇总。

模式四：多 Agent 协作

多个 Agent 有不同的角色和视角，通过交互来完成任务：

[产品经理 Agent] ←→ [开发者 Agent] ←→ [测试 Agent]
      ↓                    ↓                  ↓
  定义需求            编写代码            编写测试
      ↓                    ↓                  ↓
  审查实现 ←————————→ 修改代码 ←————————→ 报告问题

和编排者-执行者模式的区别在于：这里没有一个中心控制者，Agent 之间是对等协作。

每个 Agent 有自己的系统提示、工具集和视角。它们通过消息传递来协调工作。

适用场景：

• 需要对抗性思考（一个提方案，一个挑毛病）
• 模拟团队协作流程
• 需要多视角审查的任务

注意： 这是最复杂的模式。Agent 之间的通信可能失控——消息越来越多，偏离主题，或者陷入无意义的来回。需要仔细设计通信协议和终止条件。

模式五：人机协同（Human-in-the-Loop）

不是所有决策都应该交给 AI。人机协同模式在关键节点引入人类判断：

Agent 执行 → 遇到关键决策点
              ├→ 低风险: 自动继续
              └→ 高风险: 暂停，请求人类确认
                          ├→ 人类批准 → 继续执行
                          └→ 人类拒绝 → 调整方案

典型的需要人类确认的节点：

• 删除文件或数据
• 发送外部请求（邮件、API 调用）
• 花费超过阈值的操作
• 修改生产环境配置
• 任何不可逆的操作

Claude Code 就是这个模式的典型代表。 它在读文件、搜索代码时自主进行，但在写文件、执行命令前会请求你的确认。

优势：

• 安全性大幅提高
• 用户保持控制感
• 在 Agent 能力不足时有兜底

代价： 打断了 Agent 的自主性，需要人类保持在场。

如何选择模式

一个实用的原则：从最简单的模式开始，只在遇到瓶颈时才升级。

单 Agent 解决不了的问题，先试试加路由。路由不够再考虑编排者-执行者。多 Agent 协作是最后的选择——它强大但也最难控制。

人机协同不是一个独立的选择，而是一个叠加在任何模式上的安全层。几乎所有生产环境的 Agent 都应该有某种形式的人类监督。

要点总结

1. 单 Agent 是起点，适合范围明确的任务。工具太多或任务太复杂时需要升级。
2. 路由模式用一个轻量分类器分发任务，降低每个子 Agent 的复杂度。
3. 编排者-执行者模式适合可并行的大任务，一个大脑协调多个执行者。
4. 多 Agent 协作最强大也最复杂，需要仔细设计通信和终止条件。
5. 人机协同是安全层，不是独立模式——在关键节点引入人类判断，几乎所有生产 Agent 都需要。
6. 从简单开始，按需升级。 架构的复杂度应该匹配任务的复杂度。