Devin 的开发商 Cognition 的一个负责人 Walden 也发了一篇关于多智能体的文章 告诫大家不要构建多智能体 指出一些常见但实际效果不佳的方法，特别是多智能体架构的弊端 于是对比了一下这两个公司是如何面对和解决多智能体的问题的

文章在这里：

关于上下文共享和冲突决策 Cognition的观点: 子智能体即使共享原始任务上下文，也可能因为无法看到其他子智能体正在做什么而导致工作不一致，因为它们的行动基于相互冲突的未预设假设。他们强调原则1是“共享完整上下文和完整的智能体追踪，而不仅仅是单独的消息”，原则2是“行动带有隐含决策，冲突的决策会导致糟糕的结果”。 Anthropic 首先也承认了这些限制： “有些领域需要所有智能体共享相同上下文，或者涉及智能体之间许多依赖关系，目前不适合多智能体系统”。他们特别提到，“大多数编码任务涉及的真正可并行化任务比研究任务少，而且LLM智能体目前还不擅长实时协调和委派给其他智能体”。这与《Don’t Build Multi-Agents》中提到的Claude Code子智能体不并行写代码以及“编辑应用模型”中小型模型误解指令的问题形成了呼应。 然后我们来看一下 Anthropic 是如何克服这些限制的： 协调模式: Anthropic的系统采用“协调者-工作者”模式，由一个主智能体协调整个过程，并委派任务给并行的专业子智能体。主智能体分析查询，制定策略，并生成子智能体同时探索不同的方面。子智能体将结果返回给主智能体进行综合。 明确委托: 他们强调“教导协调者如何委托”，即主智能体需要为子智能体提供详细的任务描述，包括目标、输出格式、使用的工具和来源指南，以及明确的任务边界，以避免工作重复、遗漏或任务误解。例如，如果没有详细描述，子智能体可能会重复执行相同的搜索，或者对任务进行不同的解释。 上下文管理: 对于长期运行的任务和上下文窗口溢出问题，Anthropic的解决方案是主智能体将计划保存到“内存”中，以持久化上下文，防止上下文窗口过大时被截断。他们还实现了智能体在完成工作阶段后总结关键信息并存储到外部记忆中，并在上下文接近限制时生成新的子智能体，通过仔细交接保持连续性。 最小化“电话游戏”: 他们通过让子智能体将输出直接保存到文件系统来“最小化‘电话游戏’（game of telephone）”，而不是所有信息都通过主协调器传递。这有助于提高保真度和性能，并减少通过对话历史复制大量输出所需的token开销，从而避免信息丢失。

关于单线程线性智能体与多智能体并行性 Cognition的观点: 推荐最简单的遵循原则的方法是使用“单线程线性智能体”，其中上下文是连续的。他们认为目前的智能体在长上下文、主动的交流方面不如人类可靠，因此多智能体协作只会导致脆弱的系统。 Anthropic的观点: Anthropic则积极拥抱多智能体并行性，认为它是“扩展性能的关键方式”。 他们认为，对于像研究这样开放式、不可预测的问题，多智能体系统特别适用，因为它提供了灵活性，能够根据发现调整方法，并允许子智能体并行操作，从而实现“压缩”和“关注点分离”。他们通过内部评估发现，多智能体研究系统在广度优先的查询上，性能比单智能体系统提高了90.2%。 速度提升: Anthropic通过引入两种并行化方式大幅提升了研究时间：主智能体并行启动3-5个子智能体，子智能体并行使用3个以上工具，从而将复杂查询的研究时间缩短了90%。 Token消耗: 不过，Anthropic也承认这是一个“缺点”：“这些架构在实践中会快速消耗token”，多智能体系统通常比聊天互动多用约15倍的token。因此，多智能体系统只适用于“任务价值足够高以支付增加的性能”的场景。 协调瓶颈: Anthropic目前的主智能体是“同步执行子智能体”，即等待每组子智能体完成后再继续，这简化了协调，但会在信息流中造成瓶颈。他们提到异步执行将实现更大的并行性，但会增加结果协调、状态一致性和错误传播的挑战，并期望未来模型能处理更长的复杂研究任务时，性能提升将证明其复杂性是值得的。