多 Agent 协作的边界：什么时候会互相打架

多 Agent 的协作成本随数量上升。本文给出值得多 Agent 的三种情况、四种常见冲突与对策（重点是「单一写入者」）、汇总层该怎么写、该观测的指标与一个务实起点。

多 Agent 不是"人多力量大"

把任务分给多个 Agent（各管一段 ✔）看起来很自然 ✔，但**协作成本会随数量上升** ✗：

状态同步、重复劳动、互相覆盖、责任不清 ✔。

**多数场景下，2~3 个 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 的复杂度 ✗。