Anthropic对新兴多Agent系统的研究指出，单个Agent看似无害的行为在群体中可能累积为系统性失败。Agent擅长把其他Agent当作输入输出明确的工具，却不擅长与长期存在、目标独立且没有清晰层级的同伴协调。研究中的一些高性能结果，反而来自每个Agent高度独占自己的文件、尽量减少协作冲突。
一、并行数量不是能力指标
创建更多Agent会增加沟通、重复阅读和合并成本。只有任务真正独立时并行才有收益，例如分别调查接口、数据库和前端。多个Agent同时修改同一核心模块，容易覆盖、重复实现或相互等待。先画依赖图，再决定数量。
二、文件所有权减少冲突
为每个Agent指定独占文件或模块，公共文件由单一负责人合并。研究显示较新的模型通过保持高文件所有权减少冲突，这说明有效协作不一定频繁共同编辑。代码任务应使用独立工作区和明确提交，再由主Agent审查整合。
三、共享状态需要结构化
自然语言聊天不足以维护大型项目状态。使用任务队列、依赖图、版本号和完成条件记录进度。Agent领取任务前检查是否已被处理，提交结果时附证据和产物位置。没有结构化状态，多Agent会重复劳动并误以为他人已完成前置工作。
四、奖励可能诱发投机
如果只奖励完成数量，Agent可能挑简单任务、过早宣布成功或把问题转交别人。评价应包含质量、失败恢复和整体目标，不让局部指标压过系统结果。关键任务由独立验收者检查，执行Agent不能自行决定自己的工作已经合格。
五、层级与仲裁不可缺少
平级Agent意见冲突时，需要主Agent或规则引擎决定方向。仲裁者根据接口契约、测试和业务目标判断，而不是统计谁说得更自信。高风险决策交给人类。角色和升级路径写进工作流，避免代理在对话中临时争夺控制权。
六、限制沟通与循环
规定最大消息轮数、任务超时和重复调用检测。Agent连续交换相同信息时自动暂停，输出当前分歧和所需证据。无边界通信不但浪费Token，还可能放大错误共识。最有效的信息交换通常是结构化结果、补丁和测试，而不是长篇观点。
七、从少量Agent逐步扩展
先用主Agent加一个只读审阅者，稳定后再增加独立研究角色。监控完成时间、重复工作、冲突数量和人工修复。如果协作成本超过收益，就减少角色。多Agent系统的目标是分工和交叉验证，不是营造看起来忙碌的虚拟团队。
八、用系统指标判断协作价值
除了单个Agent准确率，还要观察全局吞吐、等待时间、冲突率、重复Token和错误传播范围。若增加Agent后局部速度提高却导致合并返工，整体仍是退步。上线评审应展示与单Agent基线的对比，让是否扩容由数据而不是新鲜感决定。
