要不要搞多智能体，两家科技公司吵起来了！

Anthropic 刚发布了一篇博客，详细介绍他们如何用多智能体系统构建Claude的Research功能。

结果Cognition立马发文章反驳：「别搞多智能体，那是个坑！」

两家顶级AI 公司公开对线，实在太精彩了。

（双方原文见附录一、附录二）

Anthropic：多智能体真香

Anthropic在博客中分享了他们构建多智能体研究系统的经验。他们的架构是这样的：用户提交查询后，主智能体会分析任务，制定策略，然后生成多个子智能体同时探索不同方向。

他们的理由很直接：研究工作本质上就是开放性的。

你永远无法预测需要哪些步骤，必须根据发现不断调整方向。这种动态性让单一智能体很难胜任。

更重要的是，他们用数据说话：多智能体系统（Claude Opus 4作为主智能体，Claude Sonnet 4作为子智能体）比单智能体Claude Opus 4的性能提升了90.2%。

举个例子，当你让它找出标普500信息技术板块所有公司的董事会成员时，多智能体系统能把任务分解给子智能体并行处理，而单智能体只能慢吞吞地串行搜索。

但Anthropic也承认了代价：多智能体系统的token消耗是普通聊天的15倍。

所以他们强调，这种架构适合「高价值、可并行、信息量超过单个上下文窗口」的任务。

Cognition：你错了！

Cognition的@walden_yan直接发文声称：多智能体架构根本不可靠！

他们的核心观点是：上下文共享和决策一致性才是关键。

Walden举了个例子：假设你要做一个Flappy Bird克隆游戏。主智能体把任务分解成两部分：子智能体1负责「构建带绿色管道的游戏背景」，子智能体2负责「构建可上下移动的小鸟」。

结果呢？

子智能体1理解错了，做了个超级马里奥的背景。子智能体2做的小鸟看起来根本不像游戏素材，移动方式也完全不对。

最后主智能体面对这两个错误的结果，根本无法组合成正常的游戏。

问题出在哪？

子智能体之间看不到彼此在做什么，各自基于不完整的信息做决策，最终导致结果相互冲突。

Cognition提出了两个核心原则：

1. 共享上下文：要共享完整的智能体轨迹，而不仅仅是单个消息
2. 行动携带隐含决策：冲突的决策会导致糟糕的结果

他们的解决方案呢？答案是——

单线程线性智能体：

社区热议

这场一线大PK 在社区引发了激烈讨论。

Amp的@thorstenball站Anthropic这边：

在我的博客中提到，之前的子智能体确实不行。但Sonnet 4改变了游戏规则。我们看到用户说「请使用子智能体并行处理」，模型就用了10个子智能体，而且效果很好！

他还晒出了同事用子智能体完成Svelte迁移的截图，称其「完美运行」。

@_ChrisCovington的实践经验却支持Cognition：

我最好的子智能体使用方式是让主线程找到所有涉及的文件，然后分配子智能体分析每个文件需要的修改，最后由主线程编译实施计划。但让它们并行编辑文件？那会以壮观的方式失败。

他进一步解释：

子智能体不继承上下文，它们写的东西可能完全不同。有时能用，但更多时候你会得到无法编译的代码，因为子智能体对同一个东西用了不同的命名。

@guohao_li认为问题是可以解决的：

上下文共享确实是多智能体系统崩溃的主要原因。我们在@CamelAIOrg正在开发一个多智能体工作系统，专门解决上下文共享和扩展问题。

All Hands AI(@allhands_ai)也站队Cognition：

好文章！我们几个月前也发表了类似观点：https://www.all-hands.dev/blog/dont-sleep-on-single-Agent-systems

@biglootpig点出了一个关键问题：

不让LLM写上下文传递也很重要。否则你的智能体会慢得要死。还有很多优化空间……

@jabol_aso分享了自己的痛苦经历：

这是真的，我经历过。我创建了多个智能体并行运行，当智能体1和智能体2需要协作或智能体2依赖智能体1时，就引入了瓶颈。这是这种模式的常见问题。虽然能工作，但相比顺序执行不够可靠。

技术细节的争论

@__morse提出了一个有趣的技术点：

另一个要点：子智能体允许你使用并行工具调用来并行化文件编辑。你可以添加一个工具，接收修改描述而不是完整代码编辑，然后生成一个新请求给相同模型、相同上下文来实际编辑。

但他也承认：

这让你能并行进行多个编辑而不损失准确性。@zeddotdev现在就这么做（但对推理模型效果不好，因为它们启动太慢）。

@nickbaumann_追问@thorstenball：

你们在Sonnet 4之前用子智能体的结果如何？

@thorstenball坦诚回答：

它们没怎么被采用。很难看到好处。

@arafatkatze对并行任务的适用性提出了深刻见解：

从你发布的子智能体示例来看，这些似乎是可并行的任务，有某种互斥性（文件名不同）。而且它们似乎共享上下文，或至少在对话的某个上游点上下文完全相同。你是否认为子智能体可能更适合某些类型的问题？

更多尖锐的批评

@yourboiilevi直接质疑Cognition：

Devin 2.0不就是关于生成并行工作的子智能体吗？？

@damdandusmus也指出：

但你们自己的产品就有多智能体？记得#multidevin吗

@imad_taieb 破解了流量的密码：

标题有误导性；你应该说「别搞并行多智能体系统」。但现在点击率就是一切。

@z_malloc提出了更深层的思考：

当然，如果你不做任何依赖管理，肯定会有问题。如果你没有紧密耦合，并且栈的依赖有文档记录，并行推理是非常可行的。

一些有趣的反应

@MasoudMaani开了个玩笑：

但Demis说这是正确的方式，这个希腊矮子又撒谎了吗？

@nibzard的比喻很形象：

新模型就像给打地鼠游戏换了个更大的橡胶锤。

@rblalock想听更多人的意见：

我很想听听@AmpCode对此的看法……这个很有意思。

@Dpwritezz关心实际应用：

精彩的工作！多智能体系统显然是可扩展AI研究的未来。好奇你们如何实时处理智能体之间的协调和冲突解决？

@BennettBuhner提出了自己的解决方案：

这个理论说明了为什么多智能体框架会快速崩溃。不仅可以在多个智能体之间共享上下文，它们还可以相互通信，通过引用给定通用待办事项列表的目标来保持任务，以及主智能体的指导和任务分配。

背后的真相

仔细分析两家公司的产品定位，你会发现这场争论并非偶然。

Anthropic的Research功能天然适合多智能体：

• 探索性任务需要多路径并行
• 信息聚合容忍一定不一致性
• 部分子任务失败不影响整体价值

Cognition的Devin则需要极高的一致性：

• 代码必须能运行
• 文件结构必须一致
• 任何不一致都可能导致系统崩溃

而有意思的是，即使都在做coding agent，Claude Code和Devin的架构也完全不同。Claude Code的子智能体只负责回答问题，不写代码。而Devin坚持所有代码修改都在同一个上下文中完成。

@navin_sg总结得很好：

这真的做得很好。协调器+并行子智能体的设置反映了人类研究人员的协作方式。虽然，并非每个任务都能从并行智能体中受益。复杂的交叉依赖会破坏一致性。

@shan则中肯评价：

我们正处于智能体基础设施的狂野西部时代。

@elimach01保持乐观：

一个非常有意义的设计原则。目前多智能体确实有很多问题。我仍然期待它的发展。这不仅是技术问题，它可以更好地映射到真实活动，更有创造力。

如@jamesladd说的：

你应该能够构建多智能体而不出问题——就这么简单。

但现实远比理想复杂，在我看来——

技术没有绝对的对错，只有适合与否。

【附录一】Anthropic | 我们如何构建多智能体研究系统

原文链接：https://www.anthropic.com/engineering/built-multi-agent-research-system

Claude现在具备了研究能力^[1]，能够在网络、Google Workspace和任何集成中搜索，以完成复杂任务。

这个多智能体系统从原型到生产的历程，教会了我们关于系统架构、工具设计和提示工程的重要经验。多智能体系统由多个智能体（LLM在循环中自主使用工具）协同工作组成。我们的研究功能涉及一个根据用户查询规划研究过程的智能体，然后使用工具创建并行智能体同时搜索信息。具有多个智能体的系统在智能体协调、评估和可靠性方面引入了新的挑战。

本文分解了对我们有效的原则——我们希望您在构建自己的多智能体系统时会发现它们很有用。

多智能体系统的优势

研究工作涉及开放性问题，很难提前预测所需的步骤。您无法为探索复杂主题硬编码固定路径，因为这个过程本质上是动态且路径依赖的。当人们进行研究时，他们倾向于根据发现持续更新方法，跟踪调查过程中出现的线索。

这种不可预测性使AI智能体特别适合研究任务。研究需要在调查展开时转向或探索切线连接的灵活性。模型必须自主运行许多轮次，根据中间发现做出追求哪些方向的决定。线性的一次性管道无法处理这些任务。

搜索的本质是压缩：从庞大的语料库中提炼洞察。子智能体通过在各自的上下文窗口中并行操作来促进压缩，同时探索问题的不同方面，然后为主要研究智能体压缩最重要的令牌。每个子智能体也提供关注点分离——不同的工具、提示和探索轨迹——这减少了路径依赖性并实现了彻底的独立调查。

一旦智能达到阈值，多智能体系统就成为扩展性能的重要方式。例如，虽然个体人类在过去10万年中变得更加智能，但人类社会在信息时代变得指数级更有能力，这是因为我们的集体智能和协调能力。即使是通用智能的智能体在作为个体运行时也面临限制；智能体群体可以完成更多工作。

我们的内部评估显示，多智能体研究系统在涉及同时追求多个独立方向的广度优先查询中表现尤其出色。我们发现，以Claude Opus 4为主智能体、Claude Sonnet 4为子智能体的多智能体系统，在我们的内部研究评估中比单智能体Claude Opus 4的表现高出90.2%。例如，当被要求识别信息技术S&P 500中所有公司的董事会成员时，多智能体系统通过将其分解为子智能体任务找到了正确答案，而单智能体系统在缓慢的顺序搜索中未能找到答案。

多智能体系统之所以有效，主要是因为它们帮助花费足够的令牌来解决问题。在我们的分析中，三个因素解释了BrowseComp^[2]评估（测试浏览智能体定位难以找到信息的能力）中95%的性能方差。我们发现，令牌使用本身解释了80%的方差，工具调用次数和模型选择是另外两个解释因素。这个发现验证了我们的架构，该架构将工作分布在具有独立上下文窗口的智能体之间，为并行推理增加更多容量。最新的Claude模型在令牌使用上充当大型效率倍增器，因为升级到Claude Sonnet 4比在Claude Sonnet 3.7上将令牌预算翻倍带来更大的性能提升。多智能体架构有效地扩展了超出单一智能体限制的任务的令牌使用。

有一个缺点：在实践中，这些架构会快速消耗令牌。在我们的数据中，智能体通常使用比聊天交互多约4倍的令牌，而多智能体系统使用比聊天多约15倍的令牌。为了经济可行性，多智能体系统需要任务价值足够高以支付增加的性能成本。此外，一些需要所有智能体共享相同上下文或涉及智能体之间许多依赖关系的领域目前不太适合多智能体系统。例如，大多数编码任务涉及的真正可并行化任务比研究少，而LLM智能体在实时协调和委派给其他智能体方面还不够出色。我们发现多智能体系统在涉及大量并行化、超出单一上下文窗口的信息以及与众多复杂工具接口的有价值任务中表现出色。

研究系统的架构概述

我们的研究系统使用带有编排器-工作者模式的多智能体架构，其中主智能体协调过程，同时委派给并行运行的专业子智能体。

多智能体架构实战：用户查询通过主智能体流动，主智能体创建专业子智能体并行搜索不同方面。

当用户提交查询时，主智能体分析它，制定策略，并生成子智能体同时探索不同方面。如上图所示，子智能体通过迭代使用搜索工具收集信息来充当智能过滤器，在这种情况下关于2025年的AI智能体公司，然后将公司列表返回给主智能体，以便它可以编制最终答案。

使用检索增强生成（RAG）的传统方法使用静态检索。也就是说，它们获取与输入查询最相似的一些块，并使用这些块生成响应。相比之下，我们的架构使用多步搜索，动态找到相关信息，适应新发现，并分析结果以制定高质量答案。

显示我们多智能体研究系统完整工作流程的流程图。当用户提交查询时，系统创建一个进入迭代研究过程的LeadResearcher智能体。LeadResearcher首先思考方法并将其计划保存到内存中以保持上下文，因为如果上下文窗口超过200,000个令牌，它将被截断，保留计划很重要。然后它创建具有特定研究任务的专业子智能体（这里显示了两个，但可以是任何数量）。每个子智能体独立执行网络搜索，使用交错思考评估工具结果，并将发现返回给LeadResearcher。LeadResearcher综合这些结果并决定是否需要更多研究——如果需要，它可以创建额外的子智能体或改进其策略。一旦收集到足够的信息，系统退出研究循环并将所有发现传递给CitationAgent，后者处理文档和研究报告以识别引用的特定位置。这确保所有声明都正确归属于其来源。最终的研究结果，完整的引用，然后返回给用户。

研究智能体的提示工程和评估

多智能体系统与单智能体系统的关键区别包括协调复杂性的快速增长。早期智能体犯了诸如为简单查询生成50个子智能体、无休止地搜索网络寻找不存在的来源、以及过度更新相互分散注意力等错误。由于每个智能体都由提示引导，提示工程是我们改善这些行为的主要杠杆。以下是我们学到的一些智能体提示原则：

1. 像你的智能体一样思考。 要迭代提示，您必须了解它们的效果。为了帮助我们做到这一点，我们使用我们的控制台^[3]构建了具有与我们系统完全相同的提示和工具的模拟，然后逐步观察智能体的工作。这立即揭示了失败模式：智能体在已经有足够结果时继续工作，使用过于冗长的搜索查询，或选择错误的工具。有效的提示依赖于对智能体建立准确的心理模型，这可以使最有影响力的变化变得显而易见。

2. 教编排器如何委派。 在我们的系统中，主智能体将查询分解为子任务并将其描述给子智能体。每个子智能体需要一个目标、输出格式、关于使用工具和来源的指导，以及明确的任务边界。没有详细的任务描述，智能体会重复工作、留下空白或未能找到必要信息。我们开始允许主智能体给出简单、简短的指令，如"研究半导体短缺"，但发现这些指令经常模糊到子智能体误解任务或执行与其他智能体完全相同的搜索。例如，一个子智能体探索2021年汽车芯片危机，而另外2个重复工作调查当前2025年供应链，没有有效的分工。

3. 根据查询复杂性调整努力程度。 智能体难以判断不同任务的适当努力程度，所以我们在提示中嵌入了扩展规则。简单的事实查找只需要1个智能体进行3-10次工具调用，直接比较可能需要2-4个子智能体每个进行10-15次调用，复杂研究可能使用超过10个具有明确分工责任的子智能体。这些显式指导帮助主智能体有效分配资源并防止对简单查询的过度投资，这是我们早期版本中的常见失败模式。

4. 工具设计和选择至关重要。 智能体-工具接口与人机界面一样重要。使用正确的工具是高效的——通常，这是严格必要的。例如，智能体在网络上搜索仅存在于Slack中的上下文注定从一开始就失败。使用给模型访问外部工具的MCP服务器^[4]，这个问题变得复杂，因为智能体遇到质量参差不齐的描述的未见工具。我们给我们的智能体明确的启发式：例如，首先检查所有可用工具，将工具使用与用户意图匹配，在网络上搜索广泛的外部探索，或偏爱专用工具而不是通用工具。糟糕的工具描述可能会将智能体引向完全错误的路径，因此每个工具都需要明确的目的和清晰的描述。

5. 让智能体改进自己。 我们发现Claude 4模型可以是出色的提示工程师。当给出提示和失败模式时，它们能够诊断智能体失败的原因并建议改进。我们甚至创建了一个工具测试智能体——当给出有缺陷的MCP工具时，它尝试使用该工具，然后重写工具描述以避免失败。通过测试工具数十次，这个智能体发现了关键的细微差别和错误。这个改善工具人体工程学的过程使未来使用新描述的智能体的任务完成时间减少了40%，因为它们能够避免大多数错误。

6. 先宽后窄。 搜索策略应该模仿专家人类研究：在深入具体内容之前探索全局。智能体经常默认使用过长、具体的查询，返回很少结果。我们通过提示智能体从短而广泛的查询开始，评估可用内容，然后逐步缩小焦点来对抗这种倾向。

7. 引导思考过程。 扩展思考模式^[5]，引导Claude在可见思考过程中输出额外令牌，可以作为可控制的草稿本。主智能体使用思考来规划其方法，评估哪些工具适合任务，确定查询复杂性和子智能体数量，并定义每个子智能体的角色。我们的测试显示扩展思考改善了指令遵循、推理和效率。子智能体也进行规划，然后在工具结果后使用交错思考^[6]来评估质量，识别差距，并改进它们的下一个查询。这使子智能体在适应任何任务时更加有效。

8. 并行工具调用改变速度和性能。 复杂的研究任务自然涉及探索许多来源。我们早期的智能体执行顺序搜索，这是痛苦缓慢的。为了速度，我们引入了两种并行化：（1）主智能体并行而不是串行地启动3-5个子智能体；（2）子智能体并行使用3+工具。这些变化将复杂查询的研究时间减少了高达90%，允许研究在几分钟而不是几小时内做更多工作，同时覆盖比其他系统更多的信息。

我们的提示策略专注于灌输良好的启发式而不是严格的规则。我们研究了熟练的人类如何处理研究任务，并在我们的提示中编码这些策略——如将困难问题分解为较小任务、仔细评估来源质量、根据新信息调整搜索方法，以及识别何时关注深度（详细调查一个主题）与广度（并行探索许多主题）的策略。我们还通过设置明确的护栏来防止智能体失控，主动缓解意外副作用。最后，我们专注于具有可观察性和测试用例的快速迭代循环。

智能体的有效评估

良好的评估对于构建可靠的AI应用程序至关重要，智能体也不例外。然而，评估多智能体系统呈现独特挑战。传统评估通常假设AI每次遵循相同步骤：给定输入X，系统应该遵循路径Y产生输出Z。但多智能体系统不是这样工作的。即使具有相同的起点，智能体可能采取完全不同的有效路径来达到目标。一个智能体可能搜索三个来源，而另一个搜索十个，或者它们可能使用不同工具找到相同答案。因为我们不总是知道正确的步骤是什么，我们通常不能只检查智能体是否遵循了我们预先规定的"正确"步骤。相反，我们需要灵活的评估方法，判断智能体是否实现了正确的结果，同时也遵循了合理的过程。

立即开始用小样本评估。在早期智能体开发中，变化往往有戏剧性影响，因为有丰富的低垂果实。提示调整可能将成功率从30%提升到80%。有了这么大的效应大小，您可以用几个测试用例发现变化。我们从大约20个代表真实使用模式的查询集开始。测试这些查询通常允许我们清楚地看到变化的影响。我们经常听到AI开发者团队延迟创建评估，因为他们认为只有具有数百个测试用例的大型评估才有用。然而，最好立即开始小规模测试，用几个例子，而不是延迟直到您可以构建更彻底的评估。

LLM作为裁判评估在做得好时可扩展。研究输出很难以编程方式评估，因为它们是自由形式文本，很少有单一正确答案。LLM是评分输出的自然选择。我们使用LLM裁判根据标准评估每个输出：事实准确性（声明是否与来源匹配？）、引用准确性（引用的来源是否与声明匹配？）、完整性（是否涵盖所有请求的方面？）、来源质量（是否使用主要来源而不是较低质量的次要来源？）和工具效率（是否合理次数使用正确工具？）。我们尝试了多个裁判来评估每个组件，但发现单个LLM调用，单个提示输出0.0-1.0分数和通过-失败等级是最一致的，与人类判断最一致。当评估测试用例确实有明确答案时，这种方法特别有效，我们可以使用LLM裁判简单地检查答案是否正确（即它是否准确列出了R&D预算最大的前3家制药公司？）。使用LLM作为裁判使我们能够可扩展地评估数百个输出。

人类评估捕获自动化错过的内容。测试智能体的人们发现评估错过的边缘案例。这些包括对不寻常查询的幻觉答案、系统故障或微妙的来源选择偏见。在我们的案例中，人类测试者注意到我们早期的智能体一致选择SEO优化的内容农场而不是权威但排名较低的来源，如学术PDF或个人博客。在我们的提示中添加来源质量启发式帮助解决了这个问题。即使在自动化评估的世界中，手动测试仍然至关重要。

多智能体系统具有紧急行为，这些行为在没有特定编程的情况下出现。例如，对主智能体的小改变可能不可预测地改变子智能体的行为方式。成功需要理解交互模式，而不仅仅是个体智能体行为。因此，这些智能体的最佳提示不仅仅是严格指令，而是定义分工、问题解决方法和努力预算的协作框架。正确做到这一点依赖于仔细的提示和工具设计、可靠的启发式、可观察性和紧密的反馈循环。查看我们Cookbook中的开源提示^[7]获取我们系统的示例提示。

生产可靠性和工程挑战

在传统软件中，错误可能破坏功能、降低性能或导致中断。在智能体系统中，微小变化级联成大的行为变化，这使得为必须在长时间运行过程中维护状态的复杂智能体编写代码变得极其困难。

智能体是有状态的，错误会复合。智能体可以长时间运行，在许多工具调用中维护状态。这意味着我们需要持久执行代码并沿途处理错误。没有有效的缓解措施，轻微的系统故障对智能体可能是灾难性的。当错误发生时，我们不能只是从头开始重启：重启是昂贵的且对用户令人沮丧。相反，我们构建了可以从智能体发生错误时恢复的系统。我们还使用模型的智能来优雅地处理问题：例如，让智能体知道工具何时失败并让它适应效果出奇地好。我们将基于Claude构建的AI智能体的适应性与重试逻辑和定期检查点等确定性保障相结合。

调试受益于新方法。智能体做出动态决策，在运行之间是非确定性的，即使具有相同的提示。这使调试更加困难。例如，用户会报告智能体"没有找到明显信息"，但我们看不出原因。智能体是使用糟糕的搜索查询吗？选择差的来源？遇到工具故障？添加完整的生产跟踪让我们诊断智能体为什么失败并系统地修复问题。除了标准可观察性，我们监控智能体决策模式和交互结构——所有这些都不监控个人对话内容，以维护用户隐私。这种高级可观察性帮助我们诊断根本原因，发现意外行为，并修复常见故障。

部署需要仔细协调。智能体系统是几乎连续运行的提示、工具和执行逻辑的高度有状态网络。这意味着每当我们部署更新时，智能体可能在其过程中的任何地方。因此，我们需要防止我们善意的代码更改破坏现有智能体。我们不能同时将每个智能体更新到新版本。相反，我们使用彩虹部署^[8]来避免破坏运行中的智能体，通过在保持两者同时运行的同时逐渐将流量从旧版本转移到新版本。

同步执行创建瓶颈。目前，我们的主智能体同步执行子智能体，等待每组子智能体完成后再继续。这简化了协调，但在智能体之间的信息流中创建了瓶颈。例如，主智能体不能引导子智能体，子智能体不能协调，整个系统可能在等待单个子智能体完成搜索时被阻塞。异步执行将实现额外的并行性：智能体并发工作并在需要时创建新的子智能体。但这种异步性在结果协调、状态一致性和跨子智能体的错误传播方面增加了挑战。随着模型能够处理更长更复杂的研究任务，我们预期性能收益将证明复杂性的合理性。

结论

在构建AI智能体时，最后一英里经常成为大部分旅程。在开发者机器上工作的代码库需要大量工程才能成为可靠的生产系统。智能体系统中错误的复合性质意味着传统软件的轻微问题可能完全破坏智能体。一个步骤失败可能导致智能体探索完全不同的轨迹，导致不可预测的结果。由于本文描述的所有原因，原型和生产之间的差距往往比预期更宽。

尽管有这些挑战，多智能体系统已被证明对开放式研究任务有价值。用户说Claude帮助他们找到他们没有考虑过的商业机会，导航复杂的医疗选择，解决棘手的技术错误，并通过发现他们单独不会找到的研究连接节省高达数天的工作。多智能体研究系统可以通过仔细的工程、全面的测试、面向细节的提示和工具设计、强大的运营实践，以及对当前智能体能力有深入理解的研究、产品和工程团队之间的紧密协作，在规模上可靠运行。我们已经看到这些系统改变了人们解决复杂问题的方式。

一个Clio^[9]嵌入图，显示人们今天使用研究功能的最常见方式。最主要的用例类别是跨专业领域开发软件系统（10%），开发和优化专业和技术内容（8%），开发业务增长和收入生成策略（8%），协助学术研究和教育材料开发（7%），以及研究和验证关于人员、地点或组织的信息（5%）。

致谢

由Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox和Daniel Ford撰写。这项工作反映了Anthropic几个团队的集体努力，他们使研究功能成为可能。特别感谢Anthropic应用工程团队，他们的奉献将这个复杂的多智能体系统带到了生产环境。我们也感谢我们的早期用户提供的出色反馈。

附录

以下是多智能体系统的一些额外杂项技巧。

在多轮对话中改变状态的智能体的终态评估。评估在多轮对话中修改持久状态的智能体呈现独特挑战。与只读研究任务不同，每个动作都可以改变后续步骤的环境，创建传统评估方法难以处理的依赖关系。我们发现专注于终态评估而不是逐轮分析是成功的。与其判断智能体是否遵循特定过程，不如评估它是否实现了正确的最终状态。这种方法承认智能体可能找到同一目标的替代路径，同时仍确保它们交付预期结果。对于复杂工作流程，将评估分解为应该发生特定状态变化的离散检查点，而不是尝试验证每个中间步骤。

长期对话管理。生产智能体经常参与跨越数百轮的对话，需要仔细的上下文管理策略。随着对话延长，标准上下文窗口变得不足，需要智能压缩和内存机制。我们实施了智能体总结完成的工作阶段并在继续新任务之前将基本信息存储在外部内存中的模式。当上下文限制接近时，智能体可以生成具有干净上下文的新子智能体，同时通过仔细的交接维护连续性。此外，它们可以从内存中检索存储的上下文（如研究计划），而不是在达到上下文限制时丢失先前的工作。这种分布式方法防止了上下文溢出，同时在扩展交互中保持对话连贯性。

子智能体输出到文件系统以最小化"传话游戏"。直接的子智能体输出可以绕过主协调器处理某些类型的结果，提高保真度和性能。与其要求子智能体通过主智能体传达一切，不如实施工件系统，其中专业智能体可以创建独立持久的输出。子智能体调用工具将其工作存储在外部系统中，然后将轻量级引用传回协调器。这防止了多阶段处理期间的信息丢失，并减少了通过对话历史复制大型输出的令牌开销。该模式对结构化输出（如代码、报告或数据可视化）特别有效，其中子智能体的专业提示产生比通过通用协调器过滤更好的结果。

【附录二】Cognition | 不要构建多智能体系统

原文链接：https://cognition.ai/blog/dont-build-multi-agents

上下文工程的原则

我们将逐步构建以下原则：

1. 共享上下文
2. 行动承载隐含决策

为什么要思考原则？

HTML 于 1993 年推出。2013 年，Facebook 向世界发布了 React。现在是 2025 年，React（及其衍生品）主导着开发者构建网站和应用的方式。为什么？因为 React 不仅仅是编写代码的脚手架。它是一种哲学。通过使用 React，你拥抱了一种反应性和模块化的应用构建模式，人们现在认为这是标准要求，但这对早期的 Web 开发者来说并不总是显而易见的。

在 LLM 和构建 AI 智能体的时代，感觉我们仍在使用原始的 HTML 和 CSS，并试图弄清楚如何将它们组合在一起以创造良好的体验。除了一些绝对基础的内容外，还没有单一的构建智能体的方法成为标准。

在某些情况下，诸如 OpenAI 的 https://github.com/openai/swarm^[10] 和微软的 https://github.com/microsoft/autogen^[11] 等库积极推广我认为是错误的构建智能体方式的概念。即使用多智能体架构，我会解释原因。

话虽如此，如果你是智能体构建的新手，有很多关于如何设置基本脚手架的资源 [1^[12]] [2^[13]]。但当涉及构建严肃的生产应用时，情况就不同了。

构建长期运行智能体的理论

让我们从可靠性开始。当智能体必须在长时间运行时真正可靠并保持连贯对话时，你必须做某些事情来控制复合错误的潜在性。否则，如果你不小心，事情会很快崩塌。可靠性的核心是上下文工程。

上下文工程

在 2025 年，现有的模型极其智能。但即使是最聪明的人，如果没有他们被要求做什么的上下文，也无法有效地完成工作。"提示工程"被创造为一个术语，用于描述为 LLM 聊天机器人以理想格式编写任务所需的努力。"上下文工程"是这一概念的下一个层次。它涉及在动态系统中自动完成这项工作。它需要更多的细致入微，实际上是构建 AI 智能体的工程师的第一要务。

以一种常见的智能体类型为例。这个智能体：

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

这是一个诱人的架构，特别是如果你在一个有多个并行组件的任务领域工作。然而，它非常脆弱。关键的失败点是：

假设你的任务是"构建一个 Flappy Bird 克隆"。这被分为子任务 1"构建一个带有绿色管道和碰撞箱的移动游戏背景"和子任务 2"构建一只可以上下移动的鸟"。 结果子智能体 1 实际上误解了你的子任务，开始构建一个看起来像超级马里奥兄弟的背景。子智能体 2 为你构建了一只鸟，但它看起来不像游戏资产，移动起来也不像 Flappy Bird 中的那只。现在最终智能体面临着组合这两个误解的不良任务。

这可能看起来人为，但大多数现实世界的任务都有许多层次的细微差别，所有这些都有被误解的潜在性。你可能认为一个简单的解决方案是将原始任务作为上下文复制给子智能体。这样，它们就不会误解它们的子任务。但请记住，在真正的生产系统中，对话很可能是多轮的，智能体可能必须进行一些工具调用来决定如何分解任务，任何数量的细节都可能对任务解释产生后果。

原则 1

共享上下文，并共享完整的智能体轨迹，而不仅仅是单个消息

让我们重新审视我们的智能体，这次确保每个智能体都有之前智能体的上下文。

不幸的是，我们还没有完全脱离困境。当你给智能体相同的 Flappy Bird 克隆任务时，这次你可能会得到一只鸟和背景，它们具有完全不同的视觉风格。子智能体 1 和子智能体 2 无法看到对方在做什么，所以它们的工作最终彼此不一致。

子智能体 1 采取的行动和子智能体 2 采取的行动基于预先未规定的冲突假设。

原则 2

行动承载隐含决策，冲突的决策带来糟糕的结果

我认为原则 1 和 2 是如此关键，如此很少值得违反，以至于你应该默认排除任何不遵守它们的智能体架构。你可能认为这很约束，但实际上你仍然可以为你的智能体探索很广的不同架构空间。

遵循这些原则的最简单方法是使用单线程线性智能体：

在这里，上下文是连续的。然而，对于有太多子部分以至于上下文窗口开始溢出的非常大的任务，你可能会遇到问题。

说实话，简单的架构会让你走得很远，但对于那些有真正长期任务并愿意付出努力的人，你可以做得更好。有几种方法可以解决这个问题，但今天我只会介绍一种：

在这个世界中，我们引入了一个新的 LLM 模型，其关键目的是将行动和对话的历史压缩为关键细节、事件和决策。这_很难做对_。它需要投资找出什么最终成为关键信息并创建一个擅长此事的系统。根据领域，你甚至可能考虑微调一个较小的模型（这实际上是我们在 Cognition 做过的事情）。

你得到的好处是一个在更长上下文中有效的智能体。不过你仍然会最终达到极限。对于热心的读者，我鼓励你思考管理任意长上下文的更好方法。这实际上是一个相当深的兔子洞！

应用原则

如果你是智能体构建者，确保你的智能体的每个行动都基于系统其他部分做出的所有相关决策的上下文。理想情况下，每个行动都应该看到其他一切。不幸的是，由于有限的上下文窗口和实际权衡，这并不总是可能的，你可能需要决定你愿意为你目标的可靠性水平承担什么复杂性水平。

当你思考如何架构你的智能体以避免冲突的决策制定时，这里有一些现实世界的例子需要思考：

Claude Code 子智能体 截至 2025 年 6 月，Claude Code 是一个生成子任务的智能体例子。然而，它从不与子任务智能体并行工作，子任务智能体通常只被分配回答问题，而不是编写任何代码。为什么？子任务智能体缺乏来自主智能体的上下文，否则这些上下文将需要做任何超出回答明确定义问题的事情。如果他们要运行多个并行子智能体，它们可能会给出冲突的响应，导致我们在早期智能体例子中看到的可靠性问题。在这种情况下，拥有子智能体的好处是，所有子智能体的调查工作都不需要保留在主智能体的历史中，允许在耗尽上下文之前有更长的轨迹。Claude Code 的设计者采取了一种有意简单的方法。

编辑应用模型

在 2024 年，许多模型在编辑代码方面真的很糟糕。编码智能体、IDE、应用构建器等（包括 Devin）的常见做法是使用"编辑应用模型"。关键思想是，实际上让一个小模型根据你想要的更改的 markdown 解释重写你的整个文件，比让一个大模型输出正确格式的差异更可靠。因此，构建者让大模型输出代码编辑的 markdown 解释，然后将这些 markdown 解释提供给小模型以实际重写文件。然而，这些系统仍然会非常有问题。例如，小模型经常会误解大模型的指令，并由于指令中最细微的歧义而进行错误的编辑。今天，编辑决策制定和应用更经常由单个模型在一个行动中完成。

多智能体

如果我们真的想从我们的系统中获得并行性，你可能会想让决策制定者相互"交谈"并解决问题。

这是我们人类在不同意时所做的（在理想世界中）。如果工程师 A 的代码与工程师 B 的代码发生合并冲突，正确的协议是讨论分歧并达成共识。然而，今天的智能体还不能够进行这种长上下文主动话语的风格，其可靠性比你使用单个智能体得到的要高得多。人类在相互传达我们最重要的知识方面非常高效，但这种效率需要相当大的智能。

自 ChatGPT 推出后不久，人们一直在探索多个智能体相互交互以实现目标的想法 [3^[14]][4^[15]]。虽然我对智能体相互协作的长期可能性持乐观态度，但很明显，在 2025 年，运行多个智能体协作只会导致脆弱的系统。决策制定最终过于分散，上下文无法在智能体之间充分共享。目前，我没有看到任何人专门致力于解决这个困难的跨智能体上下文传递问题。我个人认为，当我们让单线程智能体在与人类交流方面变得更好时，这将免费获得。当这一天到来时，它将解锁更大程度的并行性和效率。

朝向更一般的理论

这些关于上下文工程的观察只是我们有朝一日可能考虑构建智能体标准原则的开始。还有许多这里没有讨论的挑战和技术。在 Cognition，智能体构建是我们思考的关键前沿。我们围绕这些我们反复发现自己重新学习的原则构建我们的内部工具和框架，作为强制执行这些想法的方式。但我们的理论可能并不完美，我们期望随着领域的发展事情会发生变化，所以也需要一些灵活性和谦逊。

我们欢迎你在 app.devin.ai^[16] 尝试我们的工作。如果你喜欢与我们一起发现一些这些智能体构建原则，请联系 walden@cognition.ai^[17]。