如何以及何时构建多智能体系统

上周晚些时候，两篇出色的博客文章相继发布，虽然标题看似对立。“不要构建多智能体” 是由 Cognition 团队撰写，而 “我们如何构建多智能体研究系统” 则出自 Anthropic 团队之手。 尽管标题相反，但我认为它们在实质内容上有着诸多共通之处，并提供了关于何时以及如何构建多智能体系统的深刻见解：

1. 上下文工程至关重要
2. 以“读取”为主任务的多智能体系统相较于执行“写入”任务的系统更容易管理

上下文工程是关键

构建多智能体（甚至单智能体）应用过程中，最难的部分之一便是如何有效地向模型传递其被要求执行任务的上下文。Cognition 的博客文章首次引入“上下文工程”这一术语，专门用来描述这一挑战。

2025年，现有的模型已经非常智能。然而，即使是最聪明的人，在缺乏任务上下文的情况下也难以高效地完成工作。人们通常将“提示工程”视为一种努力，即将任务内容以LLM聊天机器人的理想格式进行表述。而“上下文工程”则是这一概念的更高层次，它涉及在动态系统中自动完成上下文的构建。这一过程需要更为细致的处理，实际上成为构建AI代理的工程师面临的核心挑战。

他们通过几个简单的示例指出，使用多智能体系统会使确保每个子智能体拥有适当上下文变得更加困难。

Anthropic的博客文章并未明确使用“上下文工程”这一术语，但在多个地方提及了相同的问题。显然，Anthropic团队在上下文工程方面投入了大量时间与精力。以下是一些重点内容：

长时段对话管理。在实际应用中，智能体可能需要进行数百轮的对话，因此需要精心设计的上下文管理策略。随着对话持续时间的增长，标准的上下文窗口往往显得不足，这就要求具备智能压缩与记忆机制的支持。我们采用了一种机制：在执行新任务前，智能体会总结已完成的工作阶段，并将关键信息存储于外部记忆中。当上下文容量接近限制时，智能体可以生成具备清晰上下文的新子智能体，同时通过细致的交接保持对话的连贯性。此外，它们还能从自身记忆中检索已保存的上下文（例如研究计划），而非在达到限制时丢失先前的进展。这种分布式方法不仅有效防止上下文溢出，还能在长时间的交互中维持对话的一致性。

在我们的系统中，主智能体负责将查询拆解为子任务，并向各个子智能体清晰地描述任务内容。每个子智能体都需要明确的目标、输出格式、所使用的工具及信息来源的指引，以及清晰的任务边界。若缺乏详尽的任务描述，智能体可能会重复执行任务、遗漏关键信息，或难以获取所需的数据。

上下文工程对于确保多智能体系统稳定运行具有关键作用。这一认识引导了我们开发 LangGraph 的过程，这是我们构建多智能体系统的核心框架。在使用该框架时，你需要对传递给大语言模型（LLM）的内容拥有完整的控制权，同时决定执行哪些步骤及其顺序，以生成准确的上下文。我们通过LangGraph实现了这一点，它是一个底层的编排框架，不隐藏提示信息，也不强制采用特定的“认知架构”。这使你能够灵活掌控，进行所需的上下文工程。

以“读取”为主要功能的多代理系统比以“写入”为主要功能的系统更容易管理

主要负责“读取”任务的多智能体系统通常比专注于“写入”任务的系统更容易管理。这种差异在对比这两篇博客文章时更加突出：Cognition的代码导向系统与Anthropic的研究导向方法。

编码与研究均涉及读取和写入，但侧重点有所不同。核心观点在于：读取操作本质上比写入操作更容易实现并行化。在尝试并行化写入任务时，往往会遇到双重挑战——一方面需要高效地在智能体之间传递上下文，另一方面还需将各智能体的输出进行协调整合。正如Cognition博客中所指出的：“操作隐含着决策，而冲突的决策会导致不良结果。”这一原则同样适用于读取与写入，但冲突的写入操作通常会产生比冲突的读取操作更为严重的后果。当多个智能体同时进行代码或内容的编写时，其冲突的决策可能导致不兼容的输出，而这些输出往往难以统一协调。

Anthropic的Claude Research系统很好地体现了这一原则。尽管该系统包含读取与写入两个环节，但多智能体架构主要承担读取（即研究）任务。实际的写入工作——将研究成果整合成一份连贯的报告——则由一个主智能体在统一的调用中完成。这一设计选择意识到，协作式写作可能带来额外的复杂性。

然而，即便以读取为主的多智能体系统，实现起来也并非易事。它们依然需要复杂的上下文工程。Anthropic在这方面有着深刻的体会：

我们最初允许主智能体提供简单且简短的指令，例如“研究半导体短缺”，但发现这些指令往往不够清晰，容易导致子智能体误解任务或重复进行相同的搜索工作。例如，有子智能体专注于2021年的汽车芯片危机，而另外两个则重复调查了2025年的供应链状况，缺乏有效的分工协作。

生产可靠性和工程挑战

无论是多智能体系统还是复杂的单一智能体系统，都会面临一系列可靠性和工程上的挑战。Anthropic的博客文章对此进行了深入探讨。值得注意的是，这些挑战并不仅限于其特定的应用场景，实际上具有普遍性。我们所构建的许多工具正是为了应对这类常见问题而设计的。

持久执行与错误处理

智能体具有状态性，错误可能累积。智能体可以长时间运行，并在多个工具调用之间保持状态。这要求我们以持久化的方式执行代码，并在运行过程中妥善处理错误。若缺乏有效的应对机制，轻微的系统故障可能对智能体产生灾难性影响。当错误发生时，我们不能简单地从头开始重启：重启不仅对用户来说成本高昂，也会带来不愉快的体验。因此，我们构建了能够在智能体出错后恢复其运行状态的系统。

这种持久化的执行是我们的智能体编排框架 LangGraph 的核心功能之一。我们认为，所有需要长时间运行的智能体都将依赖这一能力，因此应将其集成到智能体编排框架中。

智能体调试与可观察性

智能体在运行过程中会做出动态决策，即使使用相同的提示，其行为也可能具有不确定性。这给调试带来了更大的挑战。例如，用户可能会反馈智能体“未能找到明显的信息”，但我们无法确切判断具体原因。是搜索查询不够有效？信息来源选择不当？还是遇到了工具故障？通过引入完整的生产级追踪功能，我们得以准确诊断智能体失败的原因，并系统性地进行优化与修复。

我们一直意识到，对于LLM系统而言，其可观测性与传统软件存在显著差异。一个重要原因在于，它需要针对调试这类问题进行专门优化。如果你还不清楚这具体意味着什么，可以查看 LangSmith，这是我们用于（包括但不限于）智能体调试和可观测性的平台。过去两年，我们一直在构建LangSmith以应对这些挑战，并建议你亲自尝试，体会其重要性。

智能体评估

在Anthropic的博客文章中，有一个专门章节讨论“智能体的有效评估”。我们认为其中一些关键观点如下：

• 从简单的评估开始，甚至20个数据点就已足够
• 以LLM作为评估者可实现实验评分的自动化
• 人工测试依然至关重要

这与我们在评估方面的做法不谋而合。我们一直在将评估功能融入LangSmith平台，并已开发出一些有助于提升评估效率的特性：

• 数据集，便于高效整理数据点

• 在服务器端运行 LLM-as-a-judge（即将添加更多功能！）

• 注解队列 用于协调和推动人类评估工作

结论

Anthropic 的博客文章也提供了关于多智能体系统在哪些情况下可能或可能不表现最佳的见解：

我们内部的评估结果显示，多智能体研究系统在需要同时探索多个独立方向的广度优先查询任务中表现尤为突出。

多智能体系统之所以有效，是因为它们能够更合理地利用大量 token 来解决复杂问题……通过多智能体架构，可以高效扩展 token 的使用，以应对那些超出单个智能体处理能力的任务。

从经济角度来看，多智能体系统适用于那些任务价值足够高，足以覆盖性能提升成本的场景。

此外，某些领域由于需要所有智能体共享相同上下文或存在智能体间的高度依赖关系，目前并不适合采用多智能体系统。例如，大多数编程任务中真正可并行处理的部分较少，而当前的LLM智能体在实时协调与任务委派方面仍显不足。我们发现，多智能体系统在需要高度并行化、信息量超出单个上下文窗口，以及需与众多复杂工具交互的任务中表现尤为突出。

在构建智能体的过程中，很快就会意识到并不存在适用于所有场景的通用解决方案。相反，应探索多种可能性，并根据具体问题选择最合适的方案。

你选择的任何智能体框架都应允许你在这一谱系上灵活切换——这一点我们在LangGraph中特别强调。

要让多智能体系统（或多智能体架构、复杂单智能体系统）高效运行，也需要借助新的工具。这些工具包括持久执行、调试、可观察性和评估，它们能够显著降低应用开发人员的工作复杂度。幸运的是，这些工具具有通用性，这意味着你可以直接使用如LangGraph和LangSmith等平台，快速获得成熟的解决方案，从而更专注于应用程序的业务逻辑，而非底层基础设施的实现。

来源：LangChain Blog 原文地址：https://blog.langchain.dev/how-and-when-to-build-multi-agent-systems/