# 多智能体协作与 Subagents

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

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

## 一、直觉

单 agent 像一个通才：

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

多 agent 像一个小团队：

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

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

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

| 术语 | 直觉解释 | 最小例子 |
| --- | --- | --- |
| 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 做错了。
- 成本、延迟或工具调用次数已经是主要瓶颈。

一个实用判断：

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

## 三、常见协作模式

### 1. Orchestrator / Workers

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

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

适合：

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

关键要求：

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

### 2. Handoff

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

例子：

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

适合：

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

Handoff 的关键是交接包：

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

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

### 3. Agents as Tools

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

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

适合：

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

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

### 4. 并行评审

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

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

适合：

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

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

### 5. Pipeline

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

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

适合：

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

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

### 6. Critic / Verifier

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

```text
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 更清楚，因为它通常看不到完整上下文。

推荐结构：

```text
# 角色
你是 [具体职责] 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 最容易出问题的地方是共享状态。

危险例子：

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

解决方法：

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

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

## 九、结果合成

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

合成 agent 要做：

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

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

合成模板：

```text
请基于多个 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 都必须服从同样或更严格的权限和审批规则。

## 十二、理解检查

请你试着回答：

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

## 十三、下一步

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