多智能体系统：协作的幻觉与真实的分工
多智能体系统最大的风险不是技术不可行，而是把「像团队一样开会」误当成协作。给出判断何时该拆多 Agent 的工程判据。
从单 Agent 到多 Agent：问题出在哪一步
单个智能体（Agent）能处理「接一个目标、调一串工具、交付一个结果」的任务。当任务规模超出单个上下文窗口、或需要并行处理、或需要截然不同的工具集时，自然的想法是多智能体系统（Multi-Agent System）：让多个 Agent 分工协作。
业界常见的失败路径是反过来的：先画一张模仿人类组织架构的图——经理 Agent、研究员 Agent、评审 Agent，让它们互发消息「讨论」，然后发现系统在空转。原因不玄：每一次 Agent 间通信都是一次有损压缩。A 把它看到的东西总结给 B，B 理解并执行后再汇报给 C，每一跳都丢失细节、引入偏差，还会放大幻觉——一个 Agent 编造的事实会被下游当成既定前提。人类团队的沟通成本定律（沟通信道数随人数平方增长）在多 Agent 系统里只会更严苛，因为机器的信噪比更低。
真实分工的三个判据
多 Agent 什么时候是真需求？我们用三个判据筛选：
上下文隔离。 单个 Agent 的上下文装不下全部信息：比如代码库评审要通读几十个文件，一个上下文塞满后前面的分析质量会明显衰减。拆成多个子 Agent 各自读各自的部分、只向编排者汇报结论，等于用「分工」换「上下文容量」。
并行性。 任务可以拆成互不依赖的子任务同时跑：同时对二十个候选方案做独立评估、对多个数据源并行检索。多 Agent 在这里买的不是「更聪明」，而是「更快」和「互不污染」。
工具与权限边界。 不同环节需要不同工具集甚至不同安全等级：执行写入操作的 Agent 和只读分析的 Agent 分开，故障半径小、审计也清晰。这与其说是智能设计，不如说是权限工程。
三个判据一条都不沾的，就不该拆。多智能体的收益来自上下文管理、并行与隔离，而不是来自「它们开会讨论出了结论」——后者几乎总是编排的幻觉。
编排者-执行者：当前最稳的形态
形态繁多的多 Agent 架构里，工程上最稳的是编排者-执行者（Orchestrator-Worker）模式：一个编排 Agent 负责任务拆解、结果汇总与质量把关，若干执行 Agent 各领一个边界清晰的子任务，彼此不直接对话。它把自由协作的风险收敛成了一张确定的通信拓扑，调试时每条信息来去可查。
配套的工程纪律比架构选型更决定成败：子任务的输入输出要有明确契约（这正是 Skills 模块的用武之地，参见《如何设计一个好 Skill》）；执行结果要有可程序化校验的验收标准，而不是让编排者「看着还行」。
观点：单 Agent 优先
本篇观点：默认单 Agent，拆分是例外而非常态。每次想上多 Agent 之前，先用三个判据过一遍；过不掉，就把省下的复杂度投给上下文工程与工具质量——一条更长的上下文、一组更好的工具，往往胜过三个互相转述的 Agent。多智能体不是组织架构的数字化复刻，它是一种用复杂度换容量与隔离的架构手段，付费之前先确认真的需要买。
小结
- Agent 间通信是有损压缩，自由「讨论」式协作会放大偏差与幻觉。
- 拆多 Agent 的三个真判据：上下文隔离、并行性、工具与权限边界。
- 编排者-执行者 + 明确契约 + 程序化验收，是当前最稳的工程组合。
- 默认单 Agent；多智能体的收益来自上下文管理，不来自拟人化的协作叙事。