上周晚些时候，发布了两篇标题似乎截然相反的精彩博客文章。Cognition 团队的《不要构建多智能体系统》，以及Anthropic 团队的《我们如何构建多智能体研究系统》。
尽管标题相反，但我认为它们实际上有很多共同之处，并包含一些关于如何以及何时构建多智能体系统的见解。
- 上下文工程至关重要
- 主要“读取”的多智能体系统比“写入”的系统更容易构建。
上下文工程至关重要
构建多智能体（甚至单智能体）应用程序中最困难的部分之一是如何有效地将任务的上下文传达给模型。Cognition 博客文章引入了“上下文工程”一词来描述这一挑战。
在 2025 年，现有的模型非常智能。但即使是最聪明的人，如果没有被要求做什么的上下文，也无法有效地完成自己的工作。“提示工程”一词是为了描述为 LLM 聊天机器人以理想格式编写任务所需的努力而创造的。而“上下文工程”是下一个层次。它关乎在动态系统中自动完成这项工作。它需要更多的细微差别，并且有效地成为构建 AI 智能体的工程师的首要任务。
他们通过几个简单的例子表明，使用多智能体系统会**更难**确保每个子智能体都拥有适当的上下文。
Anthropic 博客文章没有明确使用“上下文工程”一词，但它在多个地方都提到了相同的问题。很明显，Anthropic 团队在上下文工程方面花费了大量时间。以下是一些亮点：
长时对话管理。生产中的智能体经常进行跨越数百轮的对话，这需要仔细的上下文管理策略。随着对话的延长，标准的上下文窗口变得不足，需要智能的压缩和记忆机制。我们实现了这样的模式：智能体在进行新任务之前，会总结已完成的工作阶段并将关键信息存储在外部内存中。当上下文限制接近时，智能体可以生成具有干净上下文的新子智能体，同时通过仔细的交接来保持连续性。此外，它们还可以从内存中检索研究计划等存储的上下文，而不是在达到上下文限制时丢失之前的工作。这种分布式方法可以防止上下文溢出，同时在长时间交互中保持对话的连贯性。
在我们的系统中，主智能体将查询分解为子任务，并将其描述给子智能体。每个子智能体都需要一个目标、一个输出格式、关于要使用的工具和来源的指导，以及明确的任务边界。如果没有详细的任务描述，智能体就会重复工作、留下空白或找不到必要的信息。
上下文工程对于使智能体系统可靠运行至关重要。这一见解指导了我们开发 LangGraph，即我们的智能体和多智能体框架。LangGraph。在使用框架时，您需要完全控制传递给 LLM 的内容，并完全控制运行哪些步骤以及按什么顺序运行（以生成传递给 LLM 的上下文）。我们在 LangGraph 中优先考虑这一点，它是一个低级编排框架，没有隐藏的提示，没有强制的“认知架构”。这使您能够完全控制执行所需的适当上下文工程。
主要“读取”的多智能体系统比“写入”的系统更容易构建。
主要用于“读取”任务的多智能体系统的设计比专注于“写入”任务的系统更容易管理。在比较两篇博客文章时，这种区别就很明显：Cognition 的代码重点系统和 Anthropic 的研究导向方法。
编码和研究都涉及读写，但它们强调的方面不同。关键的见解是，读取操作本质上比写入操作更具并行性。当您尝试并行写入时，您会面临有效传达智能体之间的上下文，然后连贯地合并它们的输出的双重挑战。正如 Cognition 博客文章所指出的：“操作包含隐式决策，而冲突的决策会导致糟糕的结果。”虽然这适用于读写，但冲突的写入操作通常会产生比冲突的读取操作糟糕得多的结果。当多个智能体同时编写代码或内容时，它们的冲突决策可能会产生难以协调的不兼容输出。
Anthropic 的 Claude Research 很好地说明了这一原理。虽然系统涉及读写，但多智能体架构主要处理研究（读取）部分。实际的编写——将发现综合成一份连贯的报告——则由一个主智能体在一个统一的调用中专门处理。这一设计选择认识到协作编写会引入不必要的复杂性。
然而，即使是侧重于读取的多智能体系统也并非易事。它们仍然需要复杂的上下文工程。Anthropic 在实践中发现了这一点。
我们最初允许主智能体给出简单的、简短的指令，例如“研究半导体短缺”，但发现这些指令通常足够模糊，以至于子智能体误解了任务或执行了与其他智能体完全相同的搜索。例如，一个子智能体研究了 2021 年的汽车芯片危机，而另外两个智能体则重复了调查当前 2025 年供应链的工作，而没有有效的劳动分工。
生产可靠性和工程挑战
无论使用多智能体系统还是复杂的单智能体系统，都会出现一些可靠性和工程方面的挑战。Anthropic 的博客文章很好地强调了这些挑战。这些挑战并非 Anthropic 使用场景独有，实际上相当通用。我们一直在构建的许多工具都旨在通用地解决这些问题。
持久化执行和错误处理
智能体是有状态的，错误会累积。智能体可以长时间运行，在多次工具调用中保持状态。这意味着我们需要持久化执行代码并在此过程中处理错误。如果没有有效的缓解措施，小的系统故障可能对智能体来说是灾难性的。发生错误时，我们不能仅仅从头开始重启：重启成本高昂，并且会让用户感到沮丧。相反，我们构建了可以在智能体出错时从其出错处恢复的系统。
这种持久化执行是我们智能体编排框架 LangGraph 的一个关键部分。LangGraph。我们认为所有长期运行的智能体都会需要这个功能，因此它应该内置到智能体编排框架中。
智能体调试和可观测性
智能体做出动态决策，并且在相同提示下不同次运行之间是非确定性的。这使得调试更加困难。例如，用户会报告智能体“找不到明显的信息”，但我们却无法看到原因。是智能体使用了糟糕的搜索查询？选择了差劲的来源？遇到了工具故障？添加完整的生产跟踪使我们能够诊断智能体失败的原因并系统地修复问题。
我们长期以来认识到，LLM 系统的可观测性不同于传统的软件可观测性。一个关键原因在于它需要针对调试这类挑战进行优化。如果您不确定这具体意味着什么——请查看 LangSmith，我们用于（除其他功能外）智能体调试和可观测性的平台。LangSmith。在过去的两年里，我们一直在构建 LangSmith 来处理这些类型的挑战。尝试一下，看看为什么这如此关键！
智能体评估
Anthropic 文章中有一个专门的部分是关于“智能体的有效评估”。我们喜欢其中的几个关键要点：
- 从小型评估开始，大约 20 个数据点就足够了。
- LLM 作为判断器可以自动化实验评分。
- 人工测试仍然必不可少。
这与我们的评估方法完全契合。我们已经将评估功能集成到 LangSmith 中一段时间了，并且已经开发了几个功能来帮助实现这些方面。
- 数据集，轻松整理数据点。Datasets
- 在服务器端运行 LLM 作为判断器（更多功能即将推出！）。LLM-as-a-judge
- 注释队列，协调和促进人工评估。Annotation queues
结论
Anthropic 的博客文章也包含了一些关于多智能体系统可能有效或无效的领域的智慧。
我们的内部评估表明，多智能体研究系统尤其擅长那些涉及同时追求多个独立方向的广度优先查询。
多智能体系统之所以有效，主要是因为它们有助于花费足够的 token 来解决问题……多智能体架构有效地扩展了超出单个智能体限制的任务的 token 使用量。
为了经济可行性，多智能体系统需要任务的价值足够高，能够支付增加的性能成本。
此外，一些需要所有智能体共享相同上下文或涉及智能体之间许多依赖关系的领域，目前不太适合多智能体系统。例如，大多数编码任务比研究任务包含真正可并行化的任务要少，而且 LLM 智能体在实时协调和委派给其他智能体方面还不够出色。我们发现，多智能体系统在涉及大量并行化、超出单个上下文窗口的信息以及与众多复杂工具交互的有价值的任务方面表现出色。
正如在构建智能体时很快显现的那样，没有“一刀切”的解决方案。相反，您需要探索多种选项，并根据您要解决的问题选择最佳的选项。
您选择的任何智能体框架都应该允许您在此光谱上任意滑动——这是我们在 LangGraph 中独有的重点。
弄清楚如何使多智能体（或复杂的单智能体）系统正常运行还需要新的工具。持久化执行、调试、可观测性和评估都是新的工具，它们将使您作为应用程序开发者的生活更轻松。幸运的是，这些都是通用工具。这意味着您可以使用 LangGraph 和 LangSmith 等工具来现成地获得这些功能，从而使您能够更专注于应用程序的业务逻辑，而不是通用基础设施。