如何以及何时构建多智能体系统
上周晚些时候发布了两篇标题看似相左的精彩博文：Cognition 团队的《不要构建多智能体》与 Anthropic 团队的《我们如何构建多智能体研究系统》。
尽管标题对立，但两者实则存在诸多共识，并揭示了构建多智能体系统的关键原则：
- 上下文工程至关重要
- 以”读”为主的多智能体系统比以”写”为主的更易实现
上下文工程至关重要
构建多智能体（甚至单智能体）应用最困难的部分，是向模型有效传达其执行任务的上下文。Cognition 博文提出”上下文工程”概念来描述这一挑战：
2025 年的模型已具备极高智能。但即使最聪明的人类，若缺乏任务上下文也无法高效工作。”提示工程”是为 LLM 聊天机器人优化任务描述格式的术语，而”上下文工程”是其进阶形态——在动态系统中自动实现这一过程。这需要更精细的设计，成为构建 AI 智能体的工程师的首要任务。
通过几个示例，他们证明多智能体系统会加剧子智能体获得恰当上下文的难度。
Anthropic 博文虽未直接使用”上下文工程”术语，但多次提及相同问题。其团队在上下文工程上投入了大量精力，主要成果包括：
长周期对话管理：生产环境中的智能体常需进行数百轮对话，这要求精密的上下文管理策略。随着对话延长，标准上下文窗口不再够用，必须采用智能压缩和记忆机制。我们实现的模式包括：智能体总结已完成工作阶段；将关键信息存入外部存储器后再执行新任务；当接近上下文限制时，智能体可创建全新上下文的子智能体并通过严谨交接保持连续性；此外，它们能从记忆库检索存储的上下文（如研究计划），避免因达到上下文限制而丢失先前工作。这种分布式方法既防止上下文溢出，又保障了长交互中的对话连贯性。
在我们的系统中，主导智能体将查询分解为子任务并描述给子智能体。每个子智能体需要明确目标、输出格式、工具/数据源使用指南以及清晰的任务边界。缺乏详细任务描述会导致工作重复、任务遗漏或关键信息缺失。
上下文工程是确保智能体系统可靠运行的核心要素。这一洞见指引着我们开发 LangGraph——专为智能体及多智能体设计的底层框架。使用框架时，开发者必须完全控制输入 LLM 的内容，并精准掌控执行步骤的顺序（以生成输入 LLM 的上下文）。LangGraph 作为底层编排框架，既无隐藏提示词，也不强制”认知架构”，为您实现所需的上下文工程提供完整控制权。
“读”为主的多智能体系统比”写”为主的更易实现
以”读”为核心任务的多智能体系统比侧重”写”的系统更易管理。对比两篇博文可清晰看出差异：Cognition 聚焦编码系统，而 Anthropic 侧重研究场景。
编码和研究都包含读写操作，但侧重点不同。关键洞察在于：读操作天然比写操作更易并行化。当尝试并行化写操作时，你面临双重挑战——既要实现智能体间上下文的有效传递，又要将输出结果协调融合。正如 Cognition 博文指出：”操作隐含决策，冲突决策导致不良结果。”虽然读写操作皆然，但冲突的写操作通常造成更严重的后果。当多个智能体同时编写代码或内容时，冲突决策会产生难以调和的矛盾输出。
Anthropic 的 Claude Research 系统完美诠释了这一原则。虽然系统同时涉及读写，但多智能体架构主要处理研究（读）环节。而实际写作——将研究发现综合为连贯报告——则刻意交由单一主导智能体通过统一调用来完成。这种设计承认：协作写作会引入不必要的复杂性。
但即使是以读为主的多智能体系统也非易事，它们仍需要复杂的上下文工程。Anthropic 团队亲历了这一挑战：
最初我们允许主导智能体下达简单指令（如”研究半导体短缺”），却发现这些模糊指令常导致子智能体误解任务或重复执行相同搜索。例如：一个子智能体探究 2021 年汽车芯片危机时，另两个子智能体却在重复调研 2025 年供应链现状，未能实现有效分工。
生产可靠性与工程挑战
无论使用多智能体系统还是复杂单智能体，都会面临可靠性及工程挑战。Anthropic 博文对此有精彩阐述。这些挑战具有普适性，我们构建的工具链正致力于通用性解决此类问题。
持久化执行与错误处理
智能体具有状态且错误会累积：智能体可能长期运行，在多次工具调用间保持状态。这要求实现持久化代码执行和错误处理。若无有效容错机制，微小系统故障对智能体可能是灾难性的。错误发生时，我们无法简单重启——重启成本高昂且损害用户体验。因此我们构建了能从错误发生点恢复执行的系统。
持久化执行是智能体编排框架 LangGraph 的核心能力。我们相信所有长期运行的智能体都需要此功能，因此应将其内置至编排框架中。
智能体调试与可观测性
智能体动态决策且每次运行具有非确定性（即使提示相同），这增加了调试难度。例如用户报告”智能体未找到明显信息”时，我们难以定位原因：是搜索查询不当？选择了劣质数据源？还是工具调用失败？引入全链路生产追踪后，我们才能诊断失败原因并系统修复问题。
我们早已认识到：LLM 系统的可观测性不同于传统软件。关键差异在于它需针对此类调试挑战进行优化。若想具体了解，请体验专为智能体调试与可观测性设计的平台 LangSmith。过去两年我们持续完善 LangSmith 以应对此类挑战，欢迎试用体验其关键价值！
智能体评估
Anthropic 博文专门章节讨论”智能体的有效评估”，核心观点包括：
- 评估从小规模开始，约 20 个数据点即具价值
- LLM-as-a-judge 可自动化实验评分
- 人工测试依然不可或缺
这与我们的评估理念高度契合。我们持续在 LangSmith 中构建评估功能，主要特性包括：
- 数据集：轻松管理数据点
- 服务端运行 LLM-as-a-judge（更多功能即将推出！）
- 标注队列：协调人工评估流程
结论
Anthropic 博文还包含关于多智能体系统适用场景的洞见：
内部评估表明，多智能体研究系统尤其擅长处理需要同时探索多个独立方向的广度优先查询。
多智能体系统的有效性在于能投入足够 token 解决问题…当任务超出单智能体能力时，多智能体架构可有效扩展 token 使用量。
要实现经济可行性，多智能体系统需应用于任务价值足以覆盖性能提升成本的项目。
此外，当前某些领域并不适合多智能体系统：需要所有智能体共享相同上下文，或存在复杂依赖关系的场景。例如多数编码任务中真正可并行的工作少于研究任务，且 LLM 智能体尚不擅长实时协调与委托。我们发现多智能体系统更擅长处理具有高并行价值、信息量超出单个上下文窗口、需对接众多复杂工具的任务。
正如构建智能体时日益显现的规律：不存在”放之四海皆准”的解决方案。开发者需要根据待解决问题，探索多种方案并选择最优路径。
您选择的智能体框架应支持在此光谱中自由滑动——这正是 LangGraph 的独特设计理念。
实现多智能体（或复杂单智能体）系统还需要新工具链。持久化执行、调试、可观测性和评估等工具将极大提升应用开发效率。值得庆幸的是，这些均属通用工具。这意味着您可直接采用 LangGraph 和 LangSmith 等现成方案，从而更专注于应用业务逻辑而非基础设施构建。
