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