一个月前写了单 Agent 设计（《AI Agent 系统设计》），那篇讲的是"怎么做一个 Agent"。这篇讲"怎么做多个 Agent 协作"。
这不是为了炫技。当系统复杂到一定程度，单 Agent 模式会出现几个硬伤：
1. 上下文窗口不够放
工具描述 + 角色定义 + 对话历史 + 检索结果
→ 一个 Agent 承载太多，上下文被稀释
2. 职责不清
同一个 Agent 既要做意图分类、又要做工具选择、又要做回答生成
→ 优化一个能力可能影响其他能力
3. 扩展性差
新增一个能力路径，可能需要修改整个 System Prompt
→ 牵一发动全身
Multi-Agent 不是目标，是一个解决复杂问题的手段。
四种主流架构模式
模式 1：Supervisor（监督者模式）
┌─────────────┐
│ Supervisor │
│ (路由/分配) │
└──────┬──────┘
│
┌────────┼────────┐
▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐
│Agent │ │Agent │ │Agent │
│ 查询 │ │ 报表 │ │ 操作 │
└──────┘ └──────┘ └──────┘
Supervisor 负责听懂用户意图，分发给对应的子 Agent。子 Agent 专注完成自己的任务。
特点：
- Supervisor 不做具体工作，只做路由
- 子 Agent 之间不直接通信
- 适合：客服助手、企业内部门户
一个实际问题：Supervisor 的路由准确率决定系统上限。如果 Supervisor 把查询路由到操作 Agent，用户就会收到奇怪的回复。实践中用轻量 LLM（如 Haiku 或 Flash）做路由可以节省成本，但准确率会下降一些。需要根据业务容忍度权衡。
模式 2：Pipeline（流水线模式）
输入 → Agent A → Agent B → Agent C → 输出
(分步) (执行) (质量检查)
Agent 按固定顺序执行，前一个的输出是后一个的输入。
特点：
- 流程固定，易于理解
- 每个 Agent 的职责清晰
- 适合：内容生成、文档处理、审核流程
经典场景——内容起草流水线：
Research Agent → Outline Agent → Writer Agent → Reviewer Agent → Editor Agent
(调研) (大纲) (写作) (审查) (编辑)
Pipeline 模式的风险是单点故障——中间任何一个 Agent 输出质量差，后面的 Agent 全受影响。Reviewer 的存在就是为了拦截低质量输出，但如果 Reviewer 本身也不稳定，可能发生"Agent 在审查烂内容，然后批准了"的情况。
模式 3：Debate（辩论模式）
Agent A (观点1) ─┬─ 综合 → 输出
Agent B (观点2) ─┼─ 综合 → 输出
Agent C (观点3) ─┘
多个 Agent 从不同角度分析同一个问题，由汇总 Agent 综合各方意见。
特点：
- 质量高（多方验证）
- 计算成本高（多个 Agent 独立运行）
- 适合：代码 Review、争议处理、决策支持
辩论模式在代码审查中的实践：
Agent A（安全视角）：审查 SQL 注入、XSS、权限问题
Agent B（性能视角）：审查慢查询、冗余计算、未优化代码
Agent C（可维护性视角）：审查命名、架构耦合、测试覆盖
汇总 Agent：综合三个视角的发现，生成最终的 Review 报告
模式 4：Tool 分发模式（Tool Distribution）
把工具按领域分组，每组由一个 Agent 管理，Supervisor 按需路由。
User Query
│
▼
┌──────────────┐
│ Supervisor │
│ (意图分析) │
└──────┬───────┘
│
┌───┼───┬───┐
▼ ▼ ▼ ▼
D1 D2 D3 D4
│ │ │ │
│ │ │ └── Agent 设备管理
│ │ │
│ │ └────── Agent 数据分析
│ │
│ └─────────── Agent 客户管理
│
└─────────────── Agent 知识库
这其实就是我做的 IssuePilot 的架构理念：每个 Agent 只管理与自己职责相关的工具，工具按领域分组，不交叉。
实践中的关键：Tool 分发 + 分层。第一层只给 Supervisor 一个"路由到哪个领域的工具"的能力，第二层才把具体工具暴露出来。这样工具定义不会占用过多的上下文窗口。
四种模式的混合使用
实际项目中，很少只用一种模式。
场景：企业内部智能助手
┌────────────────────────────────────────────┐
│ Gateway Agent │
│ 意图分类 + 用户身份验证 │
└────────────────┬───────────────────────────┘
│
┌────────────┼────────────┬───────────────┐
▼ ▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────────┐
│ 查询 Agent │ │ 报表 Agent ││ 操作 Agent│ │ 闲聊 Agent │
│(Supervisor│ │(Pipeline) ││(Debate) │ │(单 Agent) │
│ + Tools) │ │ R→A→R→V ││安×性×审 │ │ 简单对话 │
│ │ │ 四步流水线 ││ 三路辩论 │ │ │
└─────┬─────┘ └──────────┘ └──────────┘ └──────────────┘
│
┌───┴───┬───┐
▼ ▼ ▼
D1 D2 D3
不同场景用不同模式：
- 查询：Supervisor → 工具分发（简单、快速）
- 报表：Pipeline（复杂、需要多步骤、有顺序依赖）
- 操作：Debate（安全敏感、需要多方确认）
- 闲聊：单 Agent（不需要复杂编排）
通信与共享状态
Multi-Agent 系统面临的最大工程挑战：Agent 之间怎么通信、怎么共享状态。
方案 1：上下文传递
最简单的方案——前一个 Agent 的输出直接作为后一个 Agent 的输入。
Agent A 输出：{"summary": "...", "key_findings": [...]}
Agent B 输入：[System Prompt + Agent A 的输出 + 用户原始问题]
优点：简单，没有额外的存储依赖。 缺点：上下文会越来越大；Agent B 要处理不属于它关心的信息。
方案 2：共享状态存储
所有 Agent 读写同一个状态存储（通常是数据库或分布式缓存）。
Agent A 写入状态：
db.set("task_123", {"status": "researched", "findings": [...]})
Agent B 读取状态：
task = db.get("task_123")
# 处理 findings
db.set("task_123", {"status": "drafted", ...})
优点：状态结构化；Agent 只读取自己需要的信息。 缺点：需要额外的存储和并发控制（如果两个 Agent 同时写同一个 key）。
方案 3：事件总线
Agent 通过事件（Event）通信，松耦合。
Agent A 完成调研后发布事件：
event_bus.publish("task.researched", { task_id: "123", findings: [...] })
订阅了 "task.researched" 事件的 Agent B 自动启动：
Agent B 收到事件 → 处理 findings → 发布 "task.drafted"
优点：松耦合；可以独立扩展单个 Agent。 缺点：调试困难（事件流不易追踪）；非确定性执行顺序可能带来问题。
编制 vs 编排（Orchestration vs Choreography）
编制（Orchestration）：
有一个中央控制器（Supervisor），统一调度所有 Agent
流程由 Supervisor 定义和驱动
优点：可控、可审计
缺点：Supervisor 是单点
编排（Choreography）：
没有中央控制器，Agent 之间通过事件自发协作
每个 Agent 知道自己该做什么
优点：松耦合、可扩展
缺点：不可预测的行为
哪个更好？取决于场景。
需要流程确定性、审计追踪 → 用编制（Orchestration）
如：金融交易处理、订单流程
需要高扩展性、灵活性 → 用编排（Choreography）
如：客服对话、自动化运维
实践中，大部分生产系统是混合的——核心流程用编制，外围流程用编排。
Multi-Agent 系统的陷阱
陷阱 1：不必要的拆分
一个 Agent 能做的事，拆成三个 Agent。结果：
以前（单 Agent）：
上下文：4000 tokens
延迟：2 秒
现在（三个 Agent）：
路由 Agent：500 tokens + 0.5 秒
执行 Agent：4000 tokens + 2 秒
验证 Agent：2000 tokens + 1 秒
总延迟：3.5 秒
+ Agent 间通信开销
+ 反序列化和状态传递
成本增加了 3 倍，延迟增加了 2 倍——如果质量没有显著提升，这个拆分就是失败的。
陷阱 2：幻觉传递
前一个 Agent 产生了幻觉，后一个 Agent 基于幻觉继续推理：
Agent A（意图识别）：
"用户想要删除数据库" ← 错误（实际上用户想查数据）
Agent B（执行）：
"正在生成删除表结构的 SQL" ← 基于 Agent A 的错误输出继续扩大
这是一个级联错误。每一个后续 Agent 都增加了错误的置信度。
防御方式：
- 每个 Agent 在关键决策点输出置信度（confidence score）
- 低置信度的结果标记给人类审核
- 关键路径上的结果需要多个 Agent 交叉验证
陷阱 3：成本失控
Multi-Agent 的 token 消耗可能比单 Agent 高 3-6 倍。如果每个 Agent 都用最强模型，成本可能高得离谱。
成本优化策略：
低价模型（Haiku / Flash）做路由和分类
中价模型（Sonnet / V4）做核心推理
高价模型（Opus / Pro）只做最关键的综合和验证
从单 Agent 到多 Agent 的演进路径
阶段 1：单 Agent（1-2 个月）
✓ 跑通核心功能
✓ 发现 Agent 的能力瓶颈在哪里
阶段 2：Supervisor + 子 Agent（3-4 个月）
✓ 拆出第一个专用 Agent
✓ 验证拆分带来了质量提升
阶段 3：专业化（6-9 个月）
✓ 根据数据确定哪些场景需要专业 Agent
✓ 逐步添加安全 Agent、审查 Agent
阶段 4：标准化通信（12 个月+）
✓ MCP 标准化工具
✓ A2A 标准化 Agent 间通信
✓ 持续优化成本结构
不要跳过阶段 1。在没有数据证明单 Agent 不够之前，不要进入阶段 2。
总结
Multi-Agent 架构的核心不是"多个 Agent"，而是让每个 Agent 专注做一件事并做好。拆分的信号不是"我觉得可以拆"，而是"数据证明不拆不行"。
如果你的系统：
- Agent 上下文窗口经常打满
- 修改一个功能会影响其他功能
- 某个 Agent 的工具太多（> 15 个）
- 需要在不同场景用不同模型（成本优化）
→ 考虑拆成多 Agent，按 Supervisor + 子 Agent 模式起步
如果你的系统没有这些问题 → 别拆
2026 年的 Multi-Agent 趋势是标准化通信（MCP + A2A）和工具分发而非 Agent 拆分。工具分发让每个 Agent 管理自己领域内的工具，效果好、成本低，比不分青红皂白地拆 Agent 更实用。
评论