有两篇关于多智能体的文章在这两天引起了热议。
第一篇是 Anthropic 的《How we built our multi-agent research system》，以多个 Claude Agents 的配合为案例，分享了期间遇到的工程挑战和经验。
第二篇是 Cognition（AI 程序员 Devin 母公司）的《Don’t Build Multi-Agents》，看起来和 Anthropic 针锋相对，但其实是分享了他们在 AI Coding 领域的多智能体落地实践。
细读就会发现，Anthropic 多智能体的成功，很多依赖于「低依赖、可并行的任务」；而 Devin 的 Coding，很多是「高依赖、紧耦合」。就连 Anthropic 自己都说，
「某些场景目前还不太适合多智能体系统，比如需要所有智能体共享同一个上下文的任务，或者智能体之间存在大量依赖关系的情况。……多智能体系统最适合那些价值高、需要大量并行处理、信息量超出单个上下文窗口、需要与多个复杂工具交互的任务。」
也就是说，当下的 AI Coding，暂时还没办法用多智能体，但不代表之后不能。看似观点不同，但其实说的还是一件事。
两篇放在一起看，基本上是今天设计Multi-Agent的必读文章了，有教程和设计原则，还有踩坑实践。
文章转载自「锦秋集」和「思考机器」的翻译版本，略有删减。
TLDR:
-
对于超出单个智能体能力的任务，多智能体架构能有效扩展 token 的使用。
-
智能体使用的 token 通常是普通聊天的 4 倍左右，而多智能体系统更是达到了 15 倍。
-
大部分编码任务的可并行部分比研究任务少得多，而且 LLM 智能体目前还不太擅长实时协调和分配任务给其他智能体。
-
长上下文很重要，只是今天 Anthropic 用拆分任务的方式解决了，未来会有更好的方式。
-
对于多智能体来说，提示词很重要。提示词不只是沟通语言，更是调度逻辑、任务协议、格式规范的集中承载体。
-
调试很重要，对于多智能体来说，微小的改动会引发连锁反应，会累加。要预设失败是常态，系统需要有重试的能力。
-
2025 年，对于编程等强依赖上下文的任务来说，运行多个 Agents 协作只会导致系统脆弱。决策过程过于分散，agents 之间无法充分共享上下文。
超 6000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。
-
最新、最值得关注的 AI 新品资讯；
-
不定期赠送热门新品的邀请码、会员码；
-
最精准的AI产品曝光渠道
Claude 现在具备了强大的研究能力——它能搜索网络、Google Workspace 以及各种集成系统，完成复杂的研究任务。
将这个多智能体系统从原型打造成生产级产品的过程，让我们在系统架构、工具设计和提示工程方面收获了许多关键经验。所谓多智能体系统，就是让多个智能体协同工作——每个智能体本质上都是能够自主调用工具的大语言模型。我们的研究功能是这样运作的：先由一个主智能体根据用户需求制定研究计划，然后创建多个并行工作的子智能体去搜索信息。当系统中有多个智能体同时运作时，如何协调它们、评估效果、保证可靠性——这些都是全新的挑战。
01
性能提升 90%，
但目前也不是都适用
研究工作本质上是探索开放性问题，我们很难预先设定好每一步该做什么。探索复杂主题时不可能预设固定路径，因为整个过程充满变数，每一步的发现都会影响下一步的方向。人类做研究时，会根据新发现不断调整策略，追踪调查中冒出的新线索。
这种不可预测性恰恰说明了为什么 AI 智能体特别适合研究任务。研究需要根据发现灵活调整方向，探索相关联系。模型必须能够自主运行很多轮次，基于中间发现来决定下一步探索什么。简单的线性流程根本无法胜任这类任务。
搜索的本质是提炼——从海量信息中萃取关键洞察。子智能体通过并行工作实现了这种提炼：它们各自拥有独立的上下文窗口，可以同时探索问题的不同维度，然后把最重要的信息汇总给主研究智能体。每个子智能体还实现了关注点分离——使用不同的工具、提示和探索路径，这减少了路径依赖，让调查更加全面深入。
当智能水平达到一定程度后，多智能体系统就成了提升性能的关键方式。这就像人类社会的演进：虽然个体人类在过去 10 万年里变得更聪明了，但信息时代的人类社会凭借集体智慧和协作能力实现了能力的指数级增长。即便是通用智能体，单打独斗也有其局限；而智能体团队能完成远超个体的任务。
我们的内部评估显示，多智能体研究系统在处理需要同时探索多个方向的广度型查询时表现尤为出色。测试结果令人振奋：以 Claude Opus 4 为主智能体、Claude Sonnet 4 为子智能体的多智能体系统，比单独使用 Claude Opus 4 的性能提升了 90.2%。
举个实际例子：当要求找出信息技术类标普 500 公司的所有董事会成员时，多智能体系统通过任务分解，让各个子智能体分头搜索，成功找到了答案；而单智能体系统只能一个个慢慢搜索，最终没能完成任务。
多智能体系统之所以有效，主要原因是它们能够投入足够的计算资源（token）来解决问题。通过分析 BrowseComp 评估（测试浏览智能体查找难觅信息的能力），我们发现三个因素解释了 95%的性能差异。
其中，仅 token 使用量这一项就解释了 80%的差异，另外两个因素是工具调用次数和模型选择。这个发现验证了我们的架构设计：通过给不同智能体分配独立的上下文窗口来增加并行推理能力。
最新的 Claude 模型在 token 使用效率上有巨大提升——升级到 Claude Sonnet 4 带来的性能提升，比在 Claude Sonnet 3.7 上加倍 token 预算还要显著。对于超出单个智能体能力的任务，多智能体架构能有效扩展 token 的使用。
当然，凡事都有代价：实际使用中，这些架构消耗 token 的速度非常快。根据我们的数据，智能体使用的 token 通常是普通聊天的 4 倍左右，而多智能体系统更是达到了 15 倍。
要让多智能体系统在经济上可行，任务本身必须有足够的价值来支撑这种性能提升的成本。
另外，某些场景目前还不太适合多智能体系统，比如需要所有智能体共享同一个上下文的任务，或者智能体之间存在大量依赖关系的情况。
举例来说，大部分编码任务的可并行部分比研究任务少得多，而且 LLM 智能体目前还不太擅长实时协调和分配任务给其他智能体。我们发现，多智能体系统最适合那些价值高、需要大量并行处理、信息量超出单个上下文窗口、需要与多个复杂工具交互的任务。
02
多智能体架构设计
我们的研究系统采用了编排器-工作器模式的多智能体架构：一个主智能体负责协调整个过程，同时指挥多个专门的子智能体并行工作。
多智能体架构实际运行示意：用户查询首先到达主智能体，主智能体分析后创建多个专门的子智能体，让它们并行搜索不同方面的信息。
用户提交查询后，主智能体会分析需求、制定策略，然后生成多个子智能体同时探索不同维度。如上图所示，子智能体就像智能过滤器，通过反复调用搜索工具收集信息（本例中是搜索 2025 年的 AI 智能体公司），然后将整理好的公司列表返回给主智能体，供其编写最终答案。
传统的检索增强生成（RAG）方法采用静态检索——找出与查询最相似的文本块，然后基于这些文本生成回答。相比之下，我们的架构采用多步动态搜索，能够灵活地寻找相关信息，根据新发现调整策略，通过深入分析得出高质量答案。
上图展示了多智能体研究系统的完整工作流程。用户提交查询后，系统会创建一个主研究员（LeadResearcher）智能体，开始迭代式的研究过程。
主研究员首先思考研究方案，并将计划保存到内存中——这很重要，因为当上下文超过 20 万个 token 时会被截断，必须保留研究计划。接着，它会创建多个专门的子智能体（图中显示了两个，但实际可以是任意数量），给每个子智能体分配特定的研究任务。
每个子智能体独立工作：执行网络搜索，通过交错思考来评估工具返回的结果，然后将发现汇报给主研究员。主研究员综合这些结果，判断是否需要继续研究——如果需要，它可以创建更多子智能体或调整策略。
收集到足够信息后，系统退出研究循环，将所有发现传递给引用智能体（CitationAgent）。引用智能体会处理文档和研究报告，为每个论述找到具体的引用位置，确保所有观点都有据可查。最后，完整的研究结果连同引用一起返回给用户。
03
多智能体的提示词原则
多智能体系统与单智能体系统有关键差异，包括协调复杂性的快速增长。早期的智能体犯了一些错误，比如为简单查询生成 50 个子智能体，无休止地搜索不存在的来源，以及用过多的更新分散彼此的注意力。由于每个智能体都由提示引导，提示工程是我们改进这些行为的主要杠杆。以下是我们学到的一些提示智能体的原则：
像你的智能体一样思考。要迭代提示，你必须了解它们的效果。为了帮助我们做到这一点，我们使用我们的控制台构建了模拟，使用系统中的确切提示和工具，然后逐步观察智能体工作。这立即揭示了失败模式：智能体在已经有足够结果时还继续工作，使用过于冗长的搜索查询，或选择不正确的工具。有效的提示依赖于开发智能体的准确心理模型，这可以使最有影响力的更改变得明显。
教会编排器如何分配任务。在我们的系统中，主智能体需要把查询拆解成子任务，然后清楚地向子智能体说明任务要求。每个子智能体都需要明确的目标、输出格式、工具使用指南和任务边界。如果任务描述不够详细，子智能体就会出现重复劳动、遗漏关键信息或找不到必要资料的情况。
起初，我们让主智能体只给出简短指令，比如「研究半导体短缺」，但发现这种模糊指令经常被误解——子智能体要么理解偏差，要么做着完全相同的搜索。比如有一次，一个子智能体在研究 2021 年的汽车芯片危机，另外两个却在重复调查 2025 年的供应链现状，完全没有合理分工。
根据查询复杂度调整资源投入。智能体很难判断不同任务需要多少努力，所以我们在提示中直接给出了资源分配规则。
简单的事实查询只需 1 个智能体执行 3-10 次工具调用；对比类任务可能需要 2-4 个子智能体，每个执行 10-15 次调用；复杂研究则可能需要 10 个以上职责明确的子智能体。这些明确的指导帮助主智能体高效分配资源，避免了早期版本中常见的「小题大做」问题。
工具设计和选择至关重要。智能体与工具的接口设计和人机界面一样重要。使用对的工具不仅高效，往往还是成功的前提。比如，如果需要的信息只存在于 Slack 中，而智能体却在网上搜索，那从一开始就注定会失败。
当使用 MCP 服务器给模型提供外部工具访问时，这个问题变得更加复杂——智能体会遇到各种质量参差不齐的陌生工具。
我们给智能体设定了明确的选择策略：先浏览所有可用工具，根据用户意图选择合适的工具，需要广泛外部信息时搜索网络，优先使用专门工具而非通用工具。糟糕的工具描述会把智能体引向歧途，所以每个工具都必须有独特明确的用途和清晰的说明。
让智能体学会自我提升。我们发现 Claude 4 模型本身就是出色的提示工程师。给它一个提示和失败案例，它就能诊断失败原因并提出改进建议。我们甚至创建了一个专门的工具测试智能体——给它一个有问题的 MCP 工具，它会尝试使用并重写工具描述来避免错误。
通过几十次测试，这个智能体发现了许多关键细节和 bug。经过这样优化的工具描述，让后续使用的智能体任务完成时间缩短了 40%，因为它们避开了大部分常见错误。
先广后精的搜索策略。搜索策略应该模仿专家研究者的做法：先纵览全局，再深入细节。智能体往往倾向于使用过长、过于具体的查询词，结果返回的信息很少。我们通过提示引导智能体从简短、宽泛的查询开始，评估搜索结果的整体情况，然后逐步聚焦到具体内容。
引导思考过程。扩展思考模式让 Claude 输出额外的思考过程 token，这就像一个可控的思维草稿本。主智能体利用这个功能来规划研究方案：评估哪些工具适合当前任务、判断查询的复杂程度和需要的子智能体数量、明确每个子智能体的职责。
我们的测试表明，扩展思考显著改善了指令遵循、推理质量和执行效率。子智能体也会先做规划，然后在获得工具结果后使用交错思考来评估信息质量、识别缺失内容、优化下一步查询。这让子智能体在应对各种任务时都更加灵活有效。
并行工具调用带来速度和性能的飞跃。复杂的研究任务天然需要探索多个信息源。我们早期的智能体按顺序执行搜索，速度慢得让人难以忍受。为了提速，我们引入了两层并行化：（1）主智能体同时启动 3-5 个子智能体，而不是一个接一个；（2）每个子智能体并行使用 3 个以上的工具。
这些改变让复杂查询的研究时间缩短了高达 90%，使研究功能能在几分钟内完成原本需要几小时的工作，同时覆盖的信息量也远超其他系统。
我们的提示策略核心是培养良好的思维习惯，而非制定死板的规则。我们研究了人类专家如何进行研究，并将这些策略编码到提示中：把复杂问题分解成小任务、仔细评估信息源的质量、根据新发现灵活调整搜索方向、准确判断何时该深挖细节何时该广泛探索。同时，我们也设置了明确的防护措施，防止智能体失控。最终，通过建立快速迭代、可观察、有测试用例的开发流程，我们打造出了可靠的系统。
04
智能体的评估需要更灵活
优秀的评估体系是构建可靠 AI 应用的基石，智能体系统也不例外。但评估多智能体系统面临着独特挑战。
传统评估通常假设：给定输入 X，系统应该按照路径 Y 产生输出 Z。但多智能体系统不是这样运作的。即使起点完全相同，智能体也可能选择截然不同但同样有效的路径来达成目标。
一个智能体可能搜索三个信息源，另一个可能搜索十个；它们可能用不同的工具找到相同的答案。由于我们往往无法预知「正确」的步骤，所以不能简单地检查智能体是否遵循了预设路径。我们需要更灵活的评估方法，既要判断智能体是否达成了正确结果，也要评估其过程是否合理。
从小规模测试立即开始。 在智能体开发早期，每个改动都可能带来巨大影响，因为有大量容易改进的地方。一个提示调整就可能把成功率从 30%提升到 80%。效果如此显著，只需几个测试用例就能看出变化。
我们从大约 20 个代表真实使用场景的查询开始，测试这些查询通常就能清楚看到改动的效果。我们经常听到 AI 开发团队推迟创建评估系统，因为他们认为只有包含数百个测试用例的大型评估才有价值。但实际上，与其等待构建完善的评估系统，不如立即用几个例子开始小规模测试。
用 LLM 做评判可以实现规模化。 研究输出很难用程序化方式评估，因为它们是自由格式的文本，很少有唯一正确答案。LLM 天然适合为这类输出打分。
我们使用 LLM 评判者根据评分标准来评估每个输出：事实准确性（论述是否与资料相符？）、引用准确性（引用的资料是否支撑论点？）、完整性（是否涵盖了所有要求？）、资料质量（是否优先使用了一手资料而非质量较低的二手资料？）、工具效率（是否合理地使用了正确的工具？) .
我们尝试过用多个评判者分别评估各个维度，但发现使用单个 LLM 调用、单个提示、输出 0.0-1.0 的分数和通过/失败判定的方式最稳定，也最符合人类判断。
当测试用例有明确答案时，这种方法特别有效——我们可以让 LLM 评判者直接检查答案是否正确（比如是否准确列出了研发预算最高的三家制药公司）。使用 LLM 作为评判者让我们能够规模化地评估数百个输出。
人工评估发现自动化遗漏的问题。 人工测试智能体时总能发现自动评估遗漏的边缘情况，比如在特殊查询上的幻觉回答、系统故障或微妙的信息源选择偏差。
在我们的案例中，测试人员发现早期智能体总是选择 SEO 优化过的内容农场，而忽视了权威但搜索排名较低的学术 PDF 或个人博客。在提示中加入信息源质量的判断标准后，这个问题得到了解决。即使在自动化评估的时代，人工测试依然不可或缺。
多智能体系统会表现出涌现行为——这些行为并非刻意编程而自然产生。比如，对主智能体的微小调整可能会意想不到地改变子智能体的行为模式。要想成功，必须理解智能体间的交互模式，而不仅仅是单个智能体的行为。
因此，这些智能体的最佳提示不应是死板的指令集，而应是协作框架——定义好分工方式、解决问题的方法和资源预算。要做好这一点，需要精心的提示和工具设计、可靠的经验法则、良好的可观察性以及紧密的反馈循环。您可以在我们的 Cookbook 中查看系统使用的开源提示示例。
05
多智能体的调试需要新思路
在传统软件中，bug 可能导致功能失效、性能下降或服务中断。但在智能体系统中，微小的改动会引发连锁反应，造成行为的巨大变化。这使得为需要长时间维护状态的复杂智能体编写代码变得异常困难。
智能体有状态，错误会累积。 智能体可能运行很长时间，在多次工具调用中保持状态。这要求我们持久化执行代码并妥善处理错误。如果没有有效的应对措施，小小的系统故障对智能体来说都可能是灾难性的。
出错时，我们不能简单地从头重启——重启既昂贵又让用户沮丧。相反，我们构建了能从错误发生点恢复的系统。
我们还利用模型的智能来优雅地处理问题：比如，告诉智能体某个工具出现故障并让它自行调整，效果出奇地好。我们将基于 Claude 的 AI 智能体的适应能力与确定性保障（如重试逻辑和定期检查点）相结合。
调试需要新思路。 智能体会动态决策，即使用相同提示，每次运行结果也不尽相同，这让调试变得更加困难。比如，用户反馈智能体「找不到明显的信息」，但我们看不出原因。是搜索词不当？选错了信息源？还是工具出了故障？增加完整的生产环境追踪功能后，我们才能诊断失败原因并系统性地修复问题。
除了标准的可观察性指标，我们还监控智能体的决策模式和交互结构——这一切都不涉及具体对话内容，以保护用户隐私。这种高层次的可观察性帮助我们诊断根本原因、发现意外行为并修复常见故障。
部署需要精心协调。 智能体系统是由提示、工具和执行逻辑组成的高度状态化网络，几乎持续运行。这意味着每次部署更新时，智能体可能正处于执行过程的任何阶段。我们必须确保善意的代码更改不会破坏正在运行的智能体。
我们不能同时把所有智能体更新到新版本，而是采用彩虹部署策略——在保持新旧版本同时运行的情况下，逐步将流量从旧版本迁移到新版本，避免中断运行中的智能体。
同步执行造成瓶颈。 目前，我们的主智能体同步执行子智能体，必须等待每批子智能体完成后才能继续。这简化了协调工作，但也在智能体间的信息流动中制造了瓶颈。
比如，主智能体无法实时指导子智能体，子智能体之间也无法相互协调，而且当某个子智能体搜索时间过长时，整个系统都会被阻塞。异步执行将带来更多并行性：智能体可以同时工作，按需创建新的子智能体。
但异步化也会在结果协调、状态一致性和错误传播等方面带来新挑战。随着模型能够处理更长更复杂的研究任务，我们相信性能提升将证明这种复杂性是值得的。
06
一些额外的建议
以下是关于多智能体系统的一些额外建议。
面向多轮对话中会持续修改状态的智能体，采用「最终状态评估」方法。在评估那些会在多轮对话中持续修改持久状态的智能体时，我们会遇到独特的挑战。与只读型的研究任务不同，此类智能体的每一步操作都会改变随后步骤所处的环境，产生传统评估方法难以处理的依赖关系。
我们的实践表明，聚焦「最终状态评估」而非逐步分析会更加有效。与其检验智能体是否按照某一特定流程操作，不如直接评估它是否达成了正确的最终状态。这种做法承认智能体可能通过不同路径实现同一目标，同时也能确保其输出符合预期。对于复杂的工作流，可将评估拆分为若干离散的检查点，在每个关键节点上确认预期状态变化是否发生，而不是尝试验证所有中间步骤。
长时间对话的管理策略。 生产环境的智能体经常要进行跨越数百轮的对话，这需要精心的上下文管理策略。随着对话延长，标准的上下文窗口会变得不够用，需要智能的压缩和记忆机制。
我们实现了这样的模式：智能体在进入新任务前，会总结已完成的工作阶段并将关键信息存储在外部内存中。当接近上下文限制时，智能体可以生成具有全新上下文的子智能体，同时通过精心设计的交接保持连续性。
此外，它们可以从内存中检索存储的上下文（如研究计划），而不是在达到上下文限制时丢失之前的工作。这种分布式方法既防止了上下文溢出，又在长时间交互中保持了对话的连贯性。
子智能体直接输出到文件系统，减少「传话游戏」。 对于某些类型的结果，让子智能体的输出绕过主协调器可以提高保真度和性能。与其要求子智能体通过主智能体传递所有内容，不如实现工件系统，让专门的智能体创建独立持久的输出。
子智能体调用工具将工作存储在外部系统中，然后只将轻量级引用传回协调器。这防止了多阶段处理中的信息损失，并减少了在对话历史中复制大量输出的 token 开销。这种模式特别适合结构化输出，如代码、报告或数据可视化，因为子智能体的专门提示能产生比通过通用协调器过滤更好的结果。
07
挑战很多，
但成果也很显著
构建 AI 智能体时，最后一英里往往会变成大部分旅程。在开发机上运行良好的代码，要成为可靠的生产系统还需要大量工程工作。
智能体系统中错误的复合效应意味着，传统软件中的小问题可能彻底搞垮智能体。一个步骤的失败就可能让智能体走上完全不同的轨迹，导致难以预料的结果。基于本文所述的种种原因，从原型到生产的距离往往比预期的要远得多。
尽管挑战重重，多智能体系统在开放式研究任务上已经证明了其价值。用户反馈说，Claude 帮助他们发现了从未考虑过的商机、理清了复杂的医疗选择、解决了棘手的技术难题，通过发现他们独自无法找到的研究关联，节省了数天的工作时间。
通过精心的工程设计、全面的测试、细致的提示和工具设计、稳健的运维实践，以及深谙当前智能体能力的研究、产品和工程团队的紧密协作，多智能体研究系统能够大规模可靠运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。
上图是 Clio 嵌入图，展示了用户目前使用研究功能的主要方式。排名前几的使用场景包括：开发跨专业领域的软件系统（10%）、开发和优化专业技术内容（8%）、制定业务增长和收入策略（8%）、协助学术研究和教材开发（7%）、研究和验证关于人员、地点或组织的信息（5%）。
08
AI Coding 的多智能体实践
此文章由 Cognition（Devin 母公司） 于 6 月 12 日在其官方 Blog 发布，作者为 Cognition 联合创始人 Walden Yan。
LLM Agents 框架的表现令人意外地令人失望。我想基于我们自己的试错经验，提供一些构建 agents 的原则，并解释为什么一些诱人的想法在实践中实际上相当糟糕。
8.1 构建长期运行 agents 的理论
让我们从可靠性开始。当 agents 需要在长时间运行中保持可靠并维持连贯的对话时，你必须采取一些措施来控制错误累积的可能性。否则，如果不小心，事情很快就会崩溃。可靠性的核心在于上下文工程。
2025 年，模型将变得极其智能。但即使是最聪明的人类，如果没有被要求执行任务的具体上下文，也无法有效地完成工作。「提示工程」这一术语被创造出来，指的是需要以理想格式为 LLM 聊天机器人编写任务的努力。「上下文工程」则是这一概念的进阶。它关乎在动态系统中自动完成这一过程。这需要更多的细致考量，实际上成为了构建 AI agents 的工程师们的首要任务。
以一个常见类型的 agent 为例。这个 agent
-
将其工作分解为多个部分
-
启动子 agents 来处理这些部分
-
最终将这些结果结合起来
这是一个诱人的架构，尤其是在处理具有多个并行组件的任务领域时。然而，它非常脆弱。关键失败点在于：
假设你的任务是「构建一个 Flappy Bird 克隆版」。这被分解为子任务 1「构建一个带有绿色管道和碰撞盒的移动游戏背景」和子任务 2「构建一个可以上下移动的鸟」。 结果子 agent 1 误解了你的子任务，开始构建一个看起来像《超级马里奥兄弟》的背景。子 agent 2 为你制作了一只鸟，但它看起来不像游戏资源，动作也完全不像《Flappy Bird》中的那只。现在，最终 agent 不得不承担起将这两个误解结合起来的棘手任务。
这看似有些牵强，但现实世界中的大多数任务都包含许多细微差别，每一层都有可能被误解。你可能会认为，一个简单的解决方案是将原始任务作为上下文直接复制给子 agents。这样，它们就不会误解自己的子任务。但请记住，在实际的生产系统中，对话很可能是多轮次的，agent 可能需要进行一些工具调用来决定如何分解任务，而任何细节都可能对任务的解释产生影响。
原则一 共享上下文，并共享完整的 agent 轨迹，而不仅仅是单独的消息
让我们再次审视我们的 agent，这次确保每个 agent 都拥有之前 agents 的上下文。
不幸的是，我们还没有完全摆脱困境。当你给你的 agent 同样的 Flappy Bird 克隆任务时，这次，你可能会得到一个鸟和背景视觉风格完全不同的结果。子 agent 1 和子 agent 2 无法看到对方的操作，因此它们的工作最终彼此不一致。
子 agent 1 采取的行动和子 agent 2 采取的行动是基于事先未规定的相互矛盾的假设。
原则二 行动包含隐含的决策，而冲突的决策会带来不良后果
我认为原则一和原则二非常关键，且很少值得违反，因此你应该默认排除任何不遵守这两条原则的 agent 架构。你可能会觉得这很受限，但实际上你仍然可以探索许多不同的 agent 架构。
遵循这些原则的最简单方法就是使用单线程的线性 agent：
这里，上下文是连续的。然而，对于包含许多子部分的非常大型任务，你可能会遇到上下文窗口开始溢出的问题。
说实话，简单的架构已经能带你走很远，但对于那些真正需要长时间任务且愿意付出努力的人来说，你可以做得更好。有几种方法可以解决这个问题，但今天我只介绍其中一种：
在这个世界中，我们引入了一种新的 LLM 模型，其主要目的是将一系列动作和对话的历史压缩成关键细节、事件和决策。这很难做到准确。需要投入精力去确定哪些信息是关键的，并创建一个擅长此任务的系统。根据不同领域，你甚至可以考虑微调一个较小的模型（这实际上是我们在 Cognition 所做的事情）。
你获得的好处是一个在较长上下文中依然有效的 agent。不过，你最终仍会遇到限制。对于热衷阅读的读者，我鼓励你思考更好的方法来管理任意长度的上下文。
8.2 多 Agent 的落地案例
如果你是一个 agent 构建者，确保你的 agent 的每一个动作都基于系统其他部分所做的所有相关决策的上下文。理想情况下，每个动作都能看到所有其他信息。不幸的是，由于上下文窗口的限制和实际权衡，这并不总是可能的，你可能需要决定为了达到你期望的可靠性水平，愿意承担多大的复杂度。
当你考虑设计你的 agents 以避免决策冲突时，以下是一些值得思考的现实案例：
Claude Code 子 agents
截至 2025 年 6 月，Claude Code 是一个会生成子任务的 agent 示例。然而，它从不与子任务 agent 并行工作，且子任务 agent 通常只负责回答问题，而不编写任何代码。为什么？因为子任务 agent 缺乏主 agent 所拥有的上下文，它无法完成除回答明确定义的问题之外的任何工作。如果它们运行多个并行的子 agents，可能会给出相互矛盾的回答，从而导致我们在前面的 agents 示例中看到的可靠性问题。在这种情况下，拥有子 agent 的好处是，子 agent 的所有调查工作都无需保留在主 agent 的历史记录中，这样就可以在超出上下文之前进行更长时间的跟踪。Claude Code 的设计者采取了一个有意为之的简单方法。
编辑应用模型
在 2024 年，许多模型在编辑代码方面表现非常差。编码 agents、集成开发环境（IDE）、应用构建器等（包括 Devin）中常见的做法是使用「编辑应用模型」。其核心思想是，给一个小模型提供你想要更改的说明（以 markdown 格式），让它重写整个文件，比让一个大模型输出格式正确的 diff 更可靠。因此，构建者让大模型输出代码编辑的 markdown 说明，然后将这些说明交给小模型去实际重写文件。然而，这些系统仍然存在很多缺陷。例如，小模型经常会因为说明中的细微歧义而误解大模型的指令，导致错误的编辑。如今，编辑的决策和应用更常由单个模型一次性完成。
8.3 多 Agents 需要更长上下文的支持
如果我们真的想从系统中获得并行性，你可能会认为让决策者彼此「交流」并协同解决问题。
这就是我们人类在意见不合时的做法（在理想情况下）。如果工程师 A 的代码与工程师 B 的代码产生了合并冲突，正确的做法是通过沟通解决分歧并达成共识。然而，现在的 agents 还无法进行这种长上下文主动对话，其可靠性远不如单个 agent。人类在传递最重要的信息时非常高效，但这种高效需要非凡的智慧。
自从 ChatGPT 发布不久后，人们就开始探索多个 agents 相互交互以实现目标的想法。虽然我对 agents 相互协作的长期可能性持乐观态度，但显而易见的是，在 2025 年，运行多个 agents 协作只会导致系统脆弱。决策过程过于分散，agents 之间无法充分共享上下文。目前，我还没有看到有人专门致力于解决这一困难的跨 agent 上下文传递问题。我个人认为，随着我们让单线程 agents 更擅长与人类沟通，这个问题将自然而然地得到解决。届时，将释放出更大规模的并行性和效率。
原文：
https://www.anthropic.com/engineering/built-multi-agent-research-system
https://cognition.ai/blog/dont-build-multi-agents
（文：Founder Park）