近期必读！Devin VS Anthropic 的多智能体构建方法论

昨天最热的的两篇文章是关于多智能体系统构建的讨论。

先是 Anthropic 发布了他们在深度搜索多智能体构建过程中的一些经验，具体：包括多智能体系统的优势、架构概览、提示工程与评估、智能体的有效评估等方面。

另外一边 Devin 的开发商 Cognition 的一个负责人 Walden 发布文章告诫大家不要构建多智能体，指出一些常见但实际效果不佳的方法，特别是多智能体架构的弊端。

这篇文章主要就是结合两篇文章看一下 Cognition 提到的多智能体架构弊端和 Anthropic 给出的解决方案。同时后面也会有两篇文章非常详细的总结。

 什么是多智能体 

多智能体系统由多个智能体（大型语言模型 [LLM] 自主地循环使用工具）协同工作组成。

在这种系统中，一个主智能体（或协调器）会根据用户查询规划研究过程，然后使用工具创建并行操作的子智能体，这些子智能体同时搜索信息。这种架构允许主智能体协调整个过程，同时将任务委托给专门的子智能体。

所以具体的步骤一般为：

1. 1. 将工作分解为多个部分
2. 2. 启动子智能体处理这些部分
3. 3. 最终合并这些结果

 多智能体存在哪些问题？如何解决 

总的来说 Anthropic 也承认 Cognition 提到的多智能体问题的存在，但是他们也做了很多约束和措施来解决这些问题。

首先是领域选择: 他们将多智能体系统应用于他们认为特别适合并行化和开放式探索的领域——研究任务，而不是普遍适用于所有任务（例如他们承认编码任务就不太适合，Cognition 就是做的编程智能体）。

然后是严格的架构和设计: 采用协调者-工作者模式，并通过详细的提示工程来明确子智能体的任务和职责，以最大程度地减少误解和冲突

最后引入高级上下文管理: 引入记忆机制和通过文件系统传递输出等方式，来解决上下文窗口限制和信息流失的问题。

我们来看看具体的对比。

1. 关于多智能体架构的“脆弱性”与“可靠性”问题

Cognition的观点: 多智能体架构非常脆弱，关键的失败点在于子智能体可能误解任务并产生不一致的结果，导致最终的智能体难以整合这些误解。智能体需要长期运行并保持连贯对话时，可靠性至关重要，而上下文工程是核心。多智能体系统会导致“决策过于分散，上下文无法充分共享”，从而产生“脆弱的系统”

Anthropic的观点: Anthropic承认多智能体系统确实会带来“智能体协调、评估和可靠性方面的新挑战”。他们也指出，“代理系统中的微小变化会级联为大的行为变化”，这使得为复杂的、需要维护状态的智能体编写代码变得非常困难。代理系统中的错误复合性质意味着，对于传统软件来说的次要问题可能会完全扰乱智能体。早期的智能体确实存在协调问题，例如“为简单查询生成50个子代理”、“无休止地搜索不存在的来源”以及“过度更新互相干扰”。

2. 关于上下文共享和冲突决策

Cognition的观点: 子智能体即使共享原始任务上下文，也可能因为无法看到其他子智能体正在做什么而导致工作不一致，因为它们的行动基于相互冲突的未预设假设。他们强调原则1是“共享完整上下文和完整的智能体追踪，而不仅仅是单独的消息”，原则2是“行动带有隐含决策，冲突的决策会导致糟糕的结果”。

Anthropic 首先也承认了这些限制：“有些领域需要所有智能体共享相同上下文，或者涉及智能体之间许多依赖关系，目前不适合多智能体系统”。他们特别提到，“大多数编码任务涉及的真正可并行化任务比研究任务少，而且LLM智能体目前还不擅长实时协调和委派给其他智能体”。这与《Don’t Build Multi-Agents》中提到的Claude Code子智能体不并行写代码以及“编辑应用模型”中小型模型误解指令的问题形成了呼应。

然后我们来看一下 Anthropic 是如何克服这些限制的：

• 协调模式: Anthropic的系统采用“协调者-工作者”模式，由一个主智能体协调整个过程，并委派任务给并行的专业子智能体。主智能体分析查询，制定策略，并生成子智能体同时探索不同的方面。子智能体将结果返回给主智能体进行综合。
• 明确委托: 他们强调“教导协调者如何委托”，即主智能体需要为子智能体提供详细的任务描述，包括目标、输出格式、使用的工具和来源指南，以及明确的任务边界，以避免工作重复、遗漏或任务误解。例如，如果没有详细描述，子智能体可能会重复执行相同的搜索，或者对任务进行不同的解释。
• 上下文管理: 对于长期运行的任务和上下文窗口溢出问题，Anthropic的解决方案是主智能体将计划保存到“内存”中，以持久化上下文，防止上下文窗口过大时被截断。他们还实现了智能体在完成工作阶段后总结关键信息并存储到外部记忆中，并在上下文接近限制时生成新的子智能体，通过仔细交接保持连续性。
• 最小化“电话游戏”: 他们通过让子智能体将输出直接保存到文件系统来“最小化‘电话游戏’（game of telephone）”，而不是所有信息都通过主协调器传递。这有助于提高保真度和性能，并减少通过对话历史复制大量输出所需的token开销，从而避免信息丢失。

3. 关于单线程线性智能体与多智能体并行性

Cognition的观点: 推荐最简单的遵循原则的方法是使用“单线程线性智能体”，其中上下文是连续的。他们认为目前的智能体在长上下文、主动的交流方面不如人类可靠，因此多智能体协作只会导致脆弱的系统。

Anthropic的观点: Anthropic则积极拥抱多智能体并行性，认为它是“扩展性能的关键方式”。

他们认为，对于像研究这样开放式、不可预测的问题，多智能体系统特别适用，因为它提供了灵活性，能够根据发现调整方法，并允许子智能体并行操作，从而实现“压缩”和“关注点分离”。他们通过内部评估发现，多智能体研究系统在广度优先的查询上，性能比单智能体系统提高了90.2%。

• 速度提升: Anthropic通过引入两种并行化方式大幅提升了研究时间：主智能体并行启动3-5个子智能体，子智能体并行使用3个以上工具，从而将复杂查询的研究时间缩短了90%。
• Token消耗: 不过，Anthropic也承认这是一个“缺点”：“这些架构在实践中会快速消耗token”，多智能体系统通常比聊天互动多用约15倍的token。因此，多智能体系统只适用于“任务价值足够高以支付增加的性能”的场景。
• 协调瓶颈: Anthropic目前的主智能体是“同步执行子智能体”，即等待每组子智能体完成后再继续，这简化了协调，但会在信息流中造成瓶颈。他们提到异步执行将实现更大的并行性，但会增加结果协调、状态一致性和错误传播的挑战，并期望未来模型能处理更长的复杂研究任务时，性能提升将证明其复杂性是值得的。 

 Cognition - Don’t Build Multi-Agents 总结 

文章主要围绕以下两项上下文工程（Context Engineering）原则展开：

1. 1. 共享上下文: 智能体应共享完整的上下文，包括完整的智能体追踪（agent traces），而不仅仅是单独的消息。
2. 2. 行动隐含决策: 智能体的行动带有隐含的决策，冲突的决策会导致糟糕的结果。

构建长期运行智能体的理论与挑战 文章指出，LLM智能体框架的表现令人失望，目前还没有单一的构建方法成为标准。特别是在构建严肃的生产级应用时，可靠性至关重要，而上下文工程是实现可靠性的核心。上下文工程旨在动态、自动化地为LLM提供完成任务所需的理想格式信息。

文章以一个常见的将任务分解为多个部分的智能体为例，说明了多智能体架构的脆弱性。

• 任务分解的脆弱性: 假设一个智能体被要求“构建一个《飞扬的小鸟》克隆”，并将其分解为子任务：“构建带绿管子和碰撞盒的移动游戏背景”和“构建一个可以上下移动的小鸟”7。如果子智能体1误解了任务，构建了《超级马里奥兄弟》风格的背景，而子智能体2构建的小鸟与《飞扬的小鸟》不符，那么最终的智能体将面临结合这些误解的困难。
• 上下文共享不足: 即使将原始任务作为上下文复制给子智能体，也可能导致问题。在多轮对话的真实生产系统中，智能体可能需要进行工具调用来分解任务，任何细节都可能影响任务的解释。
• 行动冲突: 即使每个子智能体都能看到之前智能体的上下文，如果它们没有看到彼此在做什么，它们的工作最终也可能不一致。例如，可能出现不同视觉风格的小鸟和背景。这是因为子智能体1和子智能体2的行动基于相互冲突的未预设的假设。文章强调，原则1和原则2是如此关键，以至于默认应该排除任何不遵守它们的多智能体架构。

Cognition 推荐的架构

最简单的遵循这些原则的方法是使用单线程线性智能体。在这种架构中，上下文是连续的。然而，对于包含许多子部分的超大任务，可能会出现上下文窗口溢出问题。对于真正长期运行的任务，文章提出了一种更高级的方法：引入一个新的LLM模型，其主要目的是将历史行动和对话压缩成关键细节、事件和决策。这需要大量投入来确定什么是关键信息并构建一个擅长此任务的系统。

原则的应用与实际案例

• Claude Code子智能体: 截至2025年6月，Claude Code是一个会生成子任务的智能体，但它从不与子任务智能体并行工作，并且子任务智能体通常只负责回答问题，不编写代码。这是因为子任务智能体缺乏主智能体所需的上下文来执行除回答明确定义的问题之外的任何操作。如果并行运行多个子智能体，它们可能会给出冲突的响应，导致可靠性问题。在这种情况下，使用子智能体的好处是，子智能体的调查工作不需要保留在主智能体的历史记录中，从而允许在上下文耗尽之前进行更长的追踪。
• 编辑应用模型（Edit Apply Models）: 在2024年，许多模型在编辑代码方面表现不佳。常见的做法是让大型模型输出代码编辑的Markdown解释，然后将这些解释提供给小型模型来实际重写文件。然而，这些系统仍然存在缺陷，小型模型经常会因为指令中的微小歧义而误解大型模型的指令并进行不正确的编辑。如今，编辑决策和应用通常由单个模型在一个行动中完成。

多智能体协作的局限性

Cognition 文章指出，虽然让决策者之间“对话”以解决问题看似合理，就像人类在分歧时会沟通一样，但到2025年，智能体尚不能以比单个智能体更可靠的方式进行这种长上下文、主动的交流。

人类在高效地传达重要知识方面非常高效，但这种效率需要非凡的智能。 自ChatGPT推出后不久，人们一直在探索多个智能体相互协作以实现目标。尽管作者对未来智能体之间协作的可能性持乐观态度，但目前来看，运行多个智能体协作只会导致脆弱的系统。决策变得过于分散，并且智能体之间无法充分共享上下文。

跨智能体上下文传递的难题目前没有人投入专门的精力去解决，并预测当单线程智能体在与人类沟通方面变得更好时，这个问题将“免费”得到解决，从而解锁更大的并行性和效率。

 Anthropic - How we built our multi-agent research system 总结 

Anthropic 的多智能体研究系统是一个利用多个 Claude 智能体协同工作来更有效地探索复杂主题的系统。该系统旨在通过其研究功能，使 Claude 能够跨网络、Google Workspace 和任何集成进行搜索，以完成复杂的任务。

多智能体系统的优势

研究工作涉及开放性问题，很难预先预测所需的步骤，因为研究过程本质上是动态且路径依赖的。多智能体系统特别适合研究任务，因为它要求具备灵活性，以便在调查过程中根据发现进行调整或探索切线联系。

多智能体系统能够通过以下方式提升性能：

• 并行操作和信息压缩：子智能体能够通过自己的上下文窗口并行运行，同时探索问题的不同方面，然后将最重要的信息提炼给主研究智能体。
• 关注点分离：每个子智能体提供关注点分离——不同的工具、提示和探索轨迹——这减少了路径依赖，并实现了彻底、独立的调查。
• 扩展性能：一旦智能达到某个阈值，多智能体系统就成为扩展性能的重要方式，就像人类社会通过集体智能和协调能力实现了指数级发展一样。
• 卓越的广度优先查询能力：内部评估显示，多智能体研究系统在涉及同时追求多个独立方向的广度优先查询方面表现出色。例如，当被要求识别信息技术 S&P 500 公司所有董事会成员时，多智能体系统通过将此任务分解为子智能体的任务找到了正确答案，而单个智能体系统则未能通过缓慢的顺序搜索找到答案。
• 高效的 token 使用：多智能体系统能够消耗足够的 token 来解决问题。分析表明，token 使用本身解释了 BrowseComp 评估中 80% 的性能差异，而工具调用次数和模型选择是另外两个解释因素。多智能体架构通过将工作分配给具有独立上下文窗口的智能体来增加并行推理的能力，从而有效地扩展了 token 使用量。

然而，多智能体系统也有其缺点：它们通常会快速消耗大量 token。在 Anthropic 的数据中，智能体通常比聊天交互多使用约 4 倍的 token，而多智能体系统则比聊天多使用约 15 倍的 token。因此，多智能体系统需要任务的价值足够高，以支付其增加的性能成本，从而实现经济可行性。此外，一些需要所有智能体共享相同上下文或涉及许多智能体之间依赖关系的领域，目前不适合多智能体系统，例如大多数编码任务。

架构概览

Anthropic 的研究系统采用协调器-工作器（orchestrator-worker）模式的多智能体架构，其中一个主智能体协调整个过程，同时将任务委托给专门的并行操作的子智能体。

其工作流程如下：

1. 1. 用户提交查询后，主智能体（LeadResearcher）会分析查询，制定策略，并生成子智能体来同时探索不同的方面。
2. 2. LeadResearcher 首先思考其方法，并将计划保存到内存中以保留上下文，以防上下文窗口超过 200,000 个 token 被截断。
3. 3. 然后，它会创建专门的子智能体（Subagents），并分配具体的任务。
4. 4. 每个子智能体独立执行网络搜索，使用交错思考（interleaved thinking）评估工具结果，并将发现结果返回给 LeadResearcher。
5. 5. LeadResearcher 综合这些结果，并决定是否需要更多研究——如果需要，它可以创建额外的子智能体或调整其策略。
6. 6. 一旦收集到足够的信息，系统就会退出研究循环，并将所有发现结果传递给一个 CitationAgent（引用智能体），该智能体处理文档和研究报告以识别具体的引用位置，确保所有声明都正确归因于其来源。
7. 7. 最终的研究结果（包含引用）随后返回给用户。

与传统使用检索增强生成（RAG）的方法不同，Anthropic 的架构使用多步骤搜索，动态查找相关信息，适应新发现，并分析结果以形成高质量的答案。

提示工程与评估

多智能体系统与单智能体系统存在关键差异，包括协调复杂性的快速增长。提示工程是 Anthropic 改进智能体行为的主要手段。

学到的提示原则包括：

1. 1. 像你的智能体一样思考：理解提示的效果，通过模拟观察智能体一步步工作，从而发现故障模式。
2. 2. 教导协调器如何委派任务：主智能体需要将查询分解为子任务，并向子智能体描述它们。每个子智能体都需要明确的目标、输出格式、工具和来源的使用指导以及清晰的任务边界，以避免重复工作或遗漏信息。
3. 3. 根据查询复杂性调整工作量：在提示中嵌入扩展规则，以帮助主智能体高效分配资源并防止在简单查询上过度投入。简单的查证可能只需要 1 个智能体和 3-10 次工具调用，而复杂的研究可能需要 10 个以上的子智能体。
4. 4. 工具设计和选择至关重要：智能体-工具接口与人机接口同样重要。确保每个工具都有明确的目的和清晰的描述，并向智能体提供明确的启发式规则（例如，优先使用专用工具而非通用工具）。
5. 5. 让智能体自我改进：Claude 4 模型可以作为优秀的提示工程师，当给定提示和失败模式时，它们能够诊断失败原因并提出改进建议。Anthropic 甚至创建了一个工具测试智能体，能够测试有缺陷的工具并重写其描述以避免失败。
6. 6. 先广后深：搜索策略应模仿人类专家研究：先探索概况，再深入细节。通过提示智能体从简短、宽泛的查询开始，评估可用信息，然后逐步缩小焦点。
7. 7. 引导思考过程：扩展思考模式（Extended thinking mode）作为可控的草稿本，使 Claude 输出额外的 token，用于规划、评估工具适用性、确定查询复杂度和子智能体数量，并定义每个子智能体的角色。
8. 8. 并行工具调用提升速度和性能：通过让主智能体并行启动子智能体，以及子智能体并行使用多个工具，将复杂查询的研究时间缩短了高达 90%。

Anthropic 的提示策略侧重于灌输良好的启发式规则而非僵硬的规则，通过研究人类专家如何进行研究并将其策略编码到提示中，如将难题分解为小任务、评估来源质量、根据新信息调整搜索方法以及识别何时应注重深度或广度。

智能体的有效评估

评估多智能体系统面临独特的挑战，因为即使起点相同，智能体也可能采取完全不同的有效路径来达到目标12。评估方法需要灵活，既要判断智能体是否达到了正确的结果，也要判断其过程是否合理。

关键评估方法包括：

• 立即开始小样本评估：在早期开发阶段，即使是少数测试用例也能揭示巨大的影响，因为效果规模往往很大。
• LLM 作为裁判的评估：研究输出通常是自由形式文本，没有单一正确答案，LLM 适合作为评分裁判。Anthropic 使用 LLM 裁判根据事实准确性、引用准确性、完整性、来源质量和工具效率等标准来评估输出。
• 人工评估发现自动化遗漏的问题：人工测试人员能够发现自动化评估可能遗漏的边缘情况，例如异常查询上的幻觉答案、系统故障或微妙的来源选择偏差。
• 多智能体系统具有涌现行为，其行为并非通过特定编程产生。理解交互模式至关重要，最好的提示不是严格的指令，而是定义分工、问题解决方法和工作量预算的协作框架。

生产可靠性和工程挑战

将智能体系统从原型转化为可靠的生产系统面临显著的工程挑战，因为代理系统中的错误具有复合性质。

主要挑战包括：

• 智能体有状态且错误会累积：智能体可以长时间运行并跨多个工具调用保持状态。次要系统故障可能对智能体造成灾难性影响。Anthropic 构建了能够从错误发生的地方恢复的系统，并利用模型的智能来优雅地处理问题，例如在工具失败时通知智能体并让其适应。
• 调试需要新方法：智能体做出动态决策，并且在运行之间是非确定性的，即使提示相同也如此，这使得调试更加困难。通过添加完整的生产追踪，Anthropic 能够诊断智能体失败的原因并系统地修复问题。
• 部署需要仔细协调：智能体系统是高度有状态的提示、工具和执行逻辑的网络，几乎连续运行。Anthropic 使用彩虹部署（rainbow deployments），通过逐步将流量从旧版本转移到新版本，同时保持两者同时运行，从而避免中断正在运行的智能体。
• 同步执行造成瓶颈：目前，Anthropic 的主智能体同步执行子智能体，等待每组子智能体完成后再继续。这简化了协调，但在智能体之间的信息流中造成了瓶颈，例如主智能体无法引导子智能体，整个系统可能被阻塞。异步执行将实现额外的并行性，但会增加结果协调、状态一致性和错误传播的挑战。

结论与价值

尽管面临这些挑战，多智能体系统已被证明对开放式研究任务非常有价值。

用户反馈称，Claude 帮助他们发现了未曾考虑的商业机会，导航复杂的医疗保健选项，解决了棘手的技术错误，并节省了数天的工作时间，因为发现了他们独自无法找到的研究联系。

通过精心的工程设计、全面的测试、注重细节的提示和工具设计、强大的操作实践以及研究、产品和工程团队之间的紧密协作，多智能体研究系统能够可靠地大规模运行。

目前，研究功能最常见的使用案例包括：开发专业领域软件系统（10%）、开发和优化专业技术内容（8%）、开发业务增长和收入生成策略（8%）、协助学术研究和教育材料开发（7%），以及研究和验证人员、地点或组织信息（5%）。

整理和翻译不易，觉得有用的话可以给个三连，感谢?‍