多智能体协作与 Subagents

多智能体协作不是“多叫几个 AI 一起干活”这么简单。它是一种把复杂任务拆给多个有边界的 agent，再由一个协调者整合、验证和交付结果的工程方法。

如果单个 agent 已经能稳定完成任务，就不应该为了“高级感”强行上多智能体。多智能体真正有价值的地方在于：任务可以并行、需要不同专业视角、需要隔离上下文、需要不同工具权限、需要独立复核，或者单个上下文承载不了全部材料。

一、直觉

单 agent 像一个通才：

用户目标 -> 一个 agent 阅读、计划、调用工具、输出结果

多 agent 像一个小团队：

用户目标
-> 协调 agent 拆任务
-> 多个 subagents 分别研究 / 执行 / 复核
-> 汇总结果
-> 冲突处理
-> 最终验证
-> 输出

多 agent 的核心不是“数量”，而是“分工、交接、权限、验证和停止条件”。

本讲常见术语先按下面理解，详细定义和更多例子见 00.5-术语词典与最小用例。

术语	直觉解释	最小例子
Orchestrator	负责拆任务、分配、整合的协调 agent	主 agent 同时派 3 个 worker 调研方案
Worker	负责一个子任务的执行 agent	只分析一个代码模块或一个资料来源
Handoff	把任务控制权交给更合适的 agent	客服 agent 转给退款 agent
Agent as tool	主 agent 把另一个 agent 当工具调用	调用“安全审查 agent”返回风险清单
Verifier	独立复核结果的 agent 或流程	检查引用是否真实、测试是否通过
Shared state	多 agent 共享的任务状态	已完成动作、待确认问题、关键证据

二、什么时候应该用多智能体

适合使用多智能体的场景：

任务可以并行探索，例如调研多个技术方案、多个供应商、多个代码模块。
任务需要不同专业视角，例如产品、工程、安全、法务、财务分别审查。
任务需要上下文隔离，例如让一个 agent 读大量资料，只返回结论和证据，避免污染主上下文。
任务需要独立复核，例如一个 agent 写方案，另一个 agent 找漏洞。
任务需要不同工具权限，例如研究 agent 只读，执行 agent 才能写入。
任务需要长流程分段，例如检索、分析、生成、复核、发布分别处理。

不适合使用多智能体的场景：

任务很短，单个 prompt 就能完成。
任务强依赖同一个连续上下文，拆开后沟通成本更高。
多个 agent 会同时修改同一批文件、同一条数据库记录或同一份状态。
没有明确输出契约，最终只会得到一堆互相重复的回答。
没有评估和审计，无法判断哪个 agent 做错了。
成本、延迟或工具调用次数已经是主要瓶颈。

一个实用判断：

如果拆分不能带来并行、专业化、隔离、复核或权限控制，就先不要拆。

三、常见协作模式

1. Orchestrator / Workers

协调者负责理解目标、拆分任务、分配给 worker、整合结果。

Orchestrator
  -> Worker A：调研方案 1
  -> Worker B：调研方案 2
  -> Worker C：调研方案 3
  -> Synthesizer：汇总比较

适合：

多路线调研。
多文件代码审查。
多来源资料整理。
批量任务处理。

关键要求：

每个 worker 任务边界清楚。
worker 输出格式一致。
orchestrator 必须做冲突处理，不是简单拼接。

2. Handoff

Handoff 是把任务控制权交给更合适的 agent。

例子：

客服 agent 识别到用户问题是退款
-> handoff 给退款 agent
-> 退款 agent 继续对话并处理退款规则

适合：

任务类别明显切换。
专业 agent 拥有更合适的工具或规则。
用户需要和某个专业 agent 持续交互。

Handoff 的关键是交接包：

当前目标：
已知事实：
用户约束：
已完成动作：
下一步建议：
不能做什么：
需要确认什么：

没有交接包，handoff 很容易让下一个 agent 丢上下文或重复工作。

3. Agents as Tools

主 agent 不把控制权交出去，而是把其他 agent 当成工具调用。

主 agent
-> 调用“安全审查 agent”
-> 调用“文档总结 agent”
-> 调用“SQL 生成 agent”
-> 主 agent 保持最终控制权

适合：

子任务结果只是辅助信息。
主 agent 必须控制最终答案。
子 agent 不应该直接操作用户或外部系统。

这个模式比 handoff 更可控，因为主 agent 仍然负责最终合成和验证。

4. 并行评审

多个 agent 独立评审同一个产物，然后由协调者汇总。

草案
-> 正确性审查 agent
-> 安全审查 agent
-> 可读性审查 agent
-> 成本审查 agent
-> 协调者合并修改建议

适合：

代码审查。
方案评审。
高风险文档复核。
上线前检查。

并行评审的价值是独立视角，不是让多个 agent 互相附和。

5. Pipeline

任务按阶段流转，每个 agent 负责一个阶段。

资料收集 -> 信息抽取 -> 分析 -> 草案生成 -> 质量复核 -> 最终输出

适合：

格式固定的生产流程。
文档处理。
数据报告。
客服工单处理。

Pipeline 的优势是可控，缺点是灵活性较低。

6. Critic / Verifier

一个 agent 生成结果，另一个 agent 专门找问题。

Builder agent：产出方案
Verifier agent：检查遗漏、矛盾、无依据结论、安全风险
Coordinator：决定是否修改或通过

适合：

高风险总结。
工程方案。
RAG 回答。
工具调用结果解释。

Verifier 不应该只是“评价一下”，它要有明确检查清单。

四、Handoff 和 Subagent 的区别

概念	谁控制最终流程	适合场景
Handoff	交给下一个 agent	用户任务转入另一个专业域
Subagent	主 agent 委派子任务	子任务结果供主 agent 使用
Agent as tool	主 agent 调用专业 agent	主 agent 保持最终控制
Parallel agents	协调者并行收集结果	独立探索或独立评审

简单说：

Handoff 是“这个任务现在你接手”。
Subagent 是“你帮我完成这部分，结果给我”。
Agent as tool 是“我调用你的能力，但最终由我决定”。

五、Subagent 任务说明怎么写

Subagent 的任务说明必须比普通 prompt 更清楚，因为它通常看不到完整上下文。

推荐结构：

# 角色
你是 [具体职责] subagent。

# 任务
[只写这个 subagent 要完成的子任务]

# 输入
[提供必要材料，不要假设它能看到主上下文]

# 边界
1. 只处理本任务，不要扩展范围。
2. 不要调用未授权工具。
3. 不要修改共享状态。
4. 不确定时标注，而不是猜测。

# 输出格式
{
  "summary": "",
  "findings": [],
  "evidence": [],
  "risks": [],
  "open_questions": [],
  "confidence": "high | medium | low"
}

# 停止条件
[完成什么就停止]

Subagent 输出要短、结构化、可合成。不要让每个 subagent 都输出长篇散文。

六、上下文隔离

多智能体最重要的收益之一是上下文隔离。

主 agent 不需要读取所有资料，只需要：

给 subagent 明确任务。
让 subagent 读取相关材料。
收回结构化结果、证据和不确定项。
在主上下文里合成。

这样可以减少：

主上下文过长。
无关材料干扰。
外部提示注入污染主流程。
多个任务互相挤占注意力。

但隔离也有代价：

subagent 可能缺少全局背景。
输出可能不一致。
需要额外合成和验证。
trace 更复杂。

所以要给 subagent 足够背景，但不要给它不需要的全部上下文。

七、权限设计

不同 agent 应该有不同权限。

示例：

Agent	权限
Research agent	只读搜索、文件读取
Code review agent	只读代码、运行静态检查
Code edit agent	可编辑指定文件、运行测试
Release agent	发布前必须人工确认
Security agent	只读审查，不执行写操作

不要让所有 agent 都拥有全部工具。多 agent 系统里，权限过宽会放大风险。

关键原则：

最小权限。
读写分离。
高风险操作确认。
共享状态加锁或明确 ownership。
每个 agent 的工具调用可审计。

八、共享状态与冲突

多 agent 最容易出问题的地方是共享状态。

危险例子：

Agent A 修改文件 X
Agent B 同时修改文件 X
Coordinator 没有合并策略
最终结果互相覆盖

解决方法：

明确文件或资源 ownership。
并行 agent 尽量只读。
写操作集中到一个执行 agent。
每个 agent 输出 patch proposal，而不是直接写。
协调者统一合并。
对数据库、权限、发布等操作设置人工确认。

如果多个 agent 会写同一个资源，默认不要并行。

九、结果合成

多 agent 的最终质量取决于合成，不取决于答案数量。

合成 agent 要做：

去重。
找冲突。
比较证据。
标注不确定项。
按用户目标重新组织。
删除无关内容。
给出最终结论。

不要把多个 subagent 输出简单拼接。那只是“多人聊天记录”，不是最终答案。

合成模板：

请基于多个 subagent 的结果生成最终答案。

规则：
1. 不要简单拼接。
2. 合并重复结论。
3. 对冲突结论列出冲突来源和判断依据。
4. 没有证据支持的结论不要写成事实。
5. 保留重要不确定项和待确认问题。

十、Eval 怎么评多智能体

多智能体 Eval 要看最终结果，也要看过程。

检查维度：

拆分是否合理。
是否选对 subagent。
每个 subagent 是否拿到足够上下文。
工具权限是否符合最小权限。
是否出现重复劳动。
是否正确处理冲突。
合成是否忠实于 subagent 证据。
是否有未授权写操作。
是否按停止条件结束。
成本和延迟是否可接受。

最小测试集：

单 agent 就能完成的任务，系统应避免过度拆分。
需要并行调研的任务。
需要 handoff 的任务。
subagent 输出互相冲突的任务。
某个 subagent 工具失败的任务。
外部资料包含提示注入的任务。
多个 agent 可能写同一资源的任务。

十一、常见误区

误区 1：agent 越多越强

不对。agent 越多，协调成本、延迟、成本和故障点都增加。只有拆分带来明确收益时才值得。

误区 2：让多个 agent 辩论就一定更准

不一定。没有证据、评分标准和合成规则的“辩论”容易变成重复观点或互相迎合。

误区 3：subagent 输出可以直接当最终答案

不应默认如此。subagent 只负责局部任务，最终答案需要协调者整合、去重、验证和对齐用户目标。

误区 4：每个 agent 都给全量上下文最保险

不对。全量上下文会增加成本、延迟和污染风险。应该给最小必要上下文。

误区 5：多 agent 可以绕过安全边界

绝对不行。subagent、handoff agent 和工具 agent 都必须服从同样或更严格的权限和审批规则。

十二、理解检查

请你试着回答：

什么情况下应该坚持单 agent，而不是拆成多 agent？
Handoff 和 subagent 的区别是什么？
为什么多 agent 系统要做上下文隔离？
为什么并行 agent 默认应该只读？
多 agent 的最终合成为什么不能只是拼接各个输出？

十三、下一步

下一步可以补成本与延迟优化：Prompt caching、上下文裁剪、模型分层、批处理、工具调用预算和生产监控。这一块能把前面的 prompt、RAG、Agent、Eval 连接到真实生产成本。