多智能体协作：让 Agent 像软件团队一样工作

多 Agent 系统最吸引人的叙事，是让研究员、工程师、测试员和审查员一样的智能体组成团队。但如果每个 Agent 都由相似模型驱动，把一个问题复制给十个实例，得到的往往不是组织智能，而是十份相似答案和十倍账单。

所以真正的问题不是“如何让更多 Agent 工作”，而是：什么时候任务中存在值得分离的认知边界，分离后获得的并行性和上下文容量，是否大于协调成本？

What：什么才算多智能体系统

多智能体系统由多个具有独立上下文和决策过程的 Agent 组成，它们通过消息、共享产物或环境状态协作。关键不在角色名称，而在每个 Agent 是否拥有相对独立的观察、任务和行动空间。

如果所有步骤仍由中央代码固定编排，只是分别调用几次模型，它更接近并行 Workflow。若主 Agent 能根据研究进展创建子任务、子 Agent 能自主探索并返回结构化结果，系统才体现出多 Agent 的动态性。

常见拓扑包括中心编排、流水线和对等网络。中心编排最容易控制：Lead Agent 拆任务、分配、汇总；流水线适合产物逐步加工；对等网络允许自由协商，却最难保证收敛和责任归属。

第一个限制是上下文。复杂调研可能涉及多个互不相关的方向，一个 Agent 把全部搜索过程塞进同一窗口，会让证据、试错和结论互相污染。子 Agent 可以在独立上下文中深入探索，只把压缩后的高价值结果交给主 Agent。

第二个限制是并行性。多个彼此独立的检索方向可以同时推进，减少墙上时间。Anthropic 的研究系统报告，多 Agent 在内部研究评估中优于单 Agent，但它的收益主要出现在广度优先、可并行搜索的问题上。

第三个限制是认知角色冲突。生成方案与批判方案需要不同目标。让同一个上下文中的模型先投入实现、再完全中立地审查自己，容易受到已有路径影响。独立 Reviewer 可以降低这种锚定，但并不能消除共同模型偏差。

“你是资深后端工程师”不能构成有效委派。子任务契约至少要说明目标、输入边界、允许的工具、不可改变的约束、期望产物和验收方式。

返回结果也不能只有“已完成”。主 Agent 需要知道使用了哪些证据、做了哪些假设、修改了哪些状态、运行了什么验证，以及仍有哪些不确定性。否则主 Agent 必须重新调查，分工带来的收益被抵消。

可以把 Agent 间通信看作 API 设计：输入含糊会导致范围漂移，输出无结构会增加集成成本，错误没有类型会导致错误重试。自然语言提供灵活性，但关键状态仍应结构化。

多个 Agent 同时修改同一代码库、数据库或云资源，会遇到分布式系统里熟悉的问题：竞争、覆盖、脏读和部分失败。

最简单的策略是按文件、模块或资源划定所有权，让任务尽量独立。需要合并时，通过补丁、提交或明确产物进行，而不是让所有 Agent 在同一工作目录自由写入。

共享记忆也不能成为公共垃圾场。未经验证的中间推测如果写入共享区，会被其他 Agent 当作事实，形成群体错误。更稳妥的做法是区分“候选发现”和“已验证事实”，并保存来源。

第一类失败是过度分解。任务本身高度耦合，却被切成多个孤立子问题，子 Agent 各自优化局部目标，最后无法组合。

第二类失败是通信损耗。子 Agent 在压缩结果时会丢细节，主 Agent 又根据摘要做二次推断。层级越深，语义漂移越大。

第三类失败是重复探索。没有共享搜索范围和已知事实时，不同 Agent 会访问相同来源、犯相同错误。

第四类失败是错误共识。多个同源模型给出一致结论，不代表结论正确；相似训练数据和提示会产生相关性错误，不能把“投票多数”简单当作独立证据。

最后是成本。Anthropic 报告其多 Agent 研究系统的 Token 使用可达到普通聊天的约十五倍。只有高价值、强并行、超出单上下文容量的任务，才可能证明这笔成本合理。

可以先问四个问题：任务能否拆成相互独立的方向？每个方向是否需要大量独立上下文？结果能否通过清晰接口合并？额外质量是否值得成本和延迟？

如果任务是修改一个高度耦合的核心模块，单 Agent 保持完整上下文可能更好；如果任务是同时调研十个市场、检索多类证据或生成多个候选再独立评估，多 Agent 更有优势。

当前系统更擅长把其他 Agent 当成“高级工具”：给出输入，等待输出。真正对等、长期、动态依赖的协作仍然困难。Agent 如何建立共同计划、发现依赖变化、协商冲突和分配信用，尚无稳定范式。

规模扩大后还会出现系统性行为。单个 Agent 的轻微偏差可能通过互动被放大，局部合理策略可能产生全局拥塞、串谋或责任扩散。这些问题与传统多智能体研究、机制设计和分布式系统开始交汇。

只比较最终正确率会掩盖成本。评估至少要同时记录任务成功率、总 Token、墙上时间、重复工具调用、通信量和人工介入次数，并与同预算的单 Agent 基线比较。

还要设计需要真实协作的任务。如果十个子问题完全独立，多 Agent 的优势只是并行执行；如果任务包含动态依赖，则可以观察 Agent 是否及时传播接口变化、发现冲突并重新分配工作。

消融实验同样重要：移除 Reviewer、减少子 Agent、共享或隔离上下文，分别观察质量变化。只有某个角色带来可测增益，它才是架构组件，而不是角色扮演。

多 Agent 的“团队感”很容易影响人的主观判断，因此越像组织，越需要冷静的系统指标。

从工程实践看，应先实现单 Agent 基线，再根据失败证据增加角色。如果瓶颈是搜索宽度，就并行研究；如果瓶颈是自我审查，就引入独立评价；如果没有可测瓶颈，就没有理由增加组织层级。

多 Agent 的核心收益不是模拟人类公司，而是获得上下文隔离、并行搜索和独立验证。组织结构应从任务的信息结构中生长出来，而不是先创造十个角色再寻找工作。

真正成熟的多智能体系统，会对每次委派回答三个问题：为什么必须分开、如何证明可以独立、由谁对合并后的结果负责。