多 Agent 不是"人多力量大"
把任务分给多个 Agent（各管一段 ✔）看起来很自然 ✔，但协作成本会随数量上升 ✗：
状态同步、重复劳动、互相覆盖、责任不清 ✔。
多数场景下，2~3 个 Agent 的分工已经够用 ✔；再多往往收益递减 ✗。
一、什么时候值得多 Agent
- 子任务真独立（互不依赖，输出可合并 ✔）；
- 需要不同工具/权限（一个只读、一个可写 ✔）；
- 可并行且能合并（例如同时检索多个来源再汇总 ✔）。
不值得：只是"把一件事拆成步骤" ✗ → 单 Agent + 工具链更简单可控 ✔（见工具设计那篇 ✔）。
二、四种常见"打架"
| 现象 | 原因 | 对策 |
|---|---|---|
| 重复劳动 | 分工边界不清 ✔ | 明确"每个 Agent 负责什么、不负责什么" ✔ |
| 互相覆盖 | 共享同一份状态/文件 ✔ | 单一写入者（write owner ✔）或加锁/版本号 ✔ |
| 结论冲突 | 各自看到不同证据 ✔ | 汇总层负责呈现冲突而不是强行统一 ✔（见证据表 ✔） |
| 责任不清 | 出问题不知怪谁 ✔ | 每个输出带 agent id 与 trace ✔ |
"单一写入者"是最有用的规则 ✗→✔：共享状态只有一个 Agent 能写 ✔，其它只能读或提议 ✔。
三、汇总层是关键（也最容易做薄）
- 去重（同一事实只留一条 ✔）；
- 保留冲突（明确写"来源 A 说 X，来源 B 说 Y" ✔）；
- 标注来源（每条结论对应哪个 Agent ✔）；
- 给置信（几方一致 vs 单方主张 ✔）。
忌讳：汇总层让模型"融合"所有结论 ✗ → 会把冲突抹平，产生看似确定的错误答案 ✔。
四、该观测什么
- 重复率（多少内容被两个 Agent 同时产出 ✔）；
- 冲突率与冲突处理方式 ✔；
- 端到端成功率与成本（多 Agent 通常成本翻倍 ✔）；
- 失败归因分布（哪个 Agent 最常出问题 ✔）。
五、一个务实起点
① 先用单 Agent + 工具做完（多数任务够 ✔）
② 只有当出现"确实需要并行且可合并"的子任务时，才引出第 2 个 Agent
③ 定好"单一写入者"与汇总规则 ✔
④ 用指标确认多 Agent 真的比单 Agent 好（常见结论：差不多但更贵 ✗）
一条判据
如果把多 Agent 换成单 Agent 串行调用同样工具 ✔，成功率与成本会差多少 ✔？
如果差不多，就别引入多 Agent 的复杂度 ✗。