Anthropic x Cognition AI x LangChain：到底要不要做多智能体？

Anthropic x Cognition AI x LangChain：到底要不要做多智能体？ Anthropic x Cognition AI x LangChain：到底要不要做多智能体？ Modified July 2, 2025 2057 2573 流程图展示了我们多智能体研究系统的完整工作流程。当用户提交查询时，系统创建一个 LeadResearcher（首席研究员）智能体，进入一个迭代的研究过程。LeadResearcher 首先思考方法，并将其计划保存到内存中以持久化上下文，因为如果上下文窗口超过 200,000 个 tokens 将被截断，保留计划至关重要。然后，它创建具有特定研究任务的专业 Subagents（子智能体）（这里显示了两个，但可以是任意数量）。每个 Subagent 独立执行网络搜索，使用交错思考评估工具结果，并将发现返回给 LeadResearcher。LeadResearcher 综合这些结果，并决定是否需要更多研究——如果需要，它可以创建额外的子智能体或完善其策略。一旦收集到足够的信息，系统就会退出研究循环，并将所有发现传递给一个 CitationAgent（引文智能体），该智能体处理文档和研究报告以识别引文的具体位置。这确保了所有声明都正确归因于其来源。最终的研究结果，连同引文，然后返回给用户。 研究智能体的提示工程与评估 多智能体系统与单智能体系统有关键区别，其中包括协调复杂性的迅速增长。早期的智能体犯过诸如为简单查询生成 50 个子智能体、为不存在的来源无休止地搜刮网络，以及因过多更新而相互干扰等错误。由于每个智能体都由提示引导，提示工程是我们改进这些行为的主要手段。以下是我们学到的一些提示智能体的原则： 1. 像你的智能体一样思考。 要迭代提示，你必须理解其效果。为了帮助我们做到这一点，我们使用我们的 Console 构建了模拟，其中包含我们系统中的确切提示和工具，然后逐步观察智能体的工作。这立即揭示了失败模式：智能体在已有足够结果时仍继续工作，使用过于冗长的搜索查询，或选择不正确的工具。有效的提示依赖于建立一个准确的智能体心智模型，这可以使最有影响力的改变变得显而易见。 2. 教协调者如何授权。 在我们的系统中，首席智能体将查询分解为子任务，并向子智能体描述它们。每个子智能体都需要一个目标、一个输出格式、关于要使用的工具和来源的指导，以及明确的任务边界。没有详细的任务描述，智能体就会重复工作、留下空白或无法找到必要的信息。我们开始时允许首席智能体给出简单的、简短的指令，如"研究半导体短缺"，但发现这些指令常常模糊不清，以至于子智能体误解了任务或执行了与其他智能体完全相同的搜索。例如，一个子智能体探索了 2021 年的汽车芯片危机，而另外两个则重复工作，调查当前的 2025 年供应链，没有有效的劳动分工。 3. 根据查询复杂性调整投入。 智能体难以判断不同任务的适当投入，所以我们在提示中嵌入了扩展规则。简单的事实查找只需要 1 个智能体进行 3 10 次工具调用，直接比较可能需要 2 4 个子智能体，每个进行 10 15 次调用，而复杂的研究可能需要超过 10 个子智能体，并明确划分责任。这些明确的指导方针帮助首席智能体有效分配资源，并防止在简单查询上过度投入，这是我们早期版本中常见的失败模式。 4. 工具设计和选择至关重要。 智能体 工具接口与人机接口同样关键。使用正确的工具是高效的——通常是绝对必要的。例如，一个在 Slack 中寻找仅存在于其中的上下文的智能体从一开始就注定要失败。通过让模型能够访问外部工具的 MCP 服务器，这个问题会更加复杂，因为智能体会遇到描述质量参差不齐的未知工具。我们为我们的智能体提供了明确的启发式方法：例如，首先检查所有可用工具，将工具使用与用户意图相匹配，为广泛的外部探索搜索网络，或优先选择专业工具而非通用工具。糟糕的工具描述会使智能体走上完全错误的道路，所以每个工具都需要一个明确的用途和清晰的描述。 5. 让智能体自我改进。 我们发现 Claude 4 模型可以是出色的提示工程师。当给定一个提示和一种失败模式时，它们能够诊断出智能体失败的原因并提出改进建议。我们甚至创建了一个工具测试智能体——当给定一个有缺陷的 MCP 工具时，它会尝试使用该工具，然后重写工具描述以避免失败。通过数十次测试该工具，这个智能体发现了关键的细微差别和错误。这个改进工具人体工程学的过程，使得未来使用新描述的智能体完成任务的时间减少了 40%，因为它们能够避免大多数错误。 6. 先广后窄。 搜索策略应该效仿专家的人类研究方法：在深入研究细节之前先探索整体概况。智能体通常默认使用过长、过于具体的查询，结果返回很少。我们通过提示智能体从简短、宽泛的查询开始，评估可用信息，然后逐步缩小焦点，来抵制这种倾向。 7. 引导思维过程。 扩展思维模式，它引导 Claude 在一个可见的思维过程中输出额外的 tokens，可以作为一个可控的草稿纸。首席智能体使用思考来规划其方法，评估哪些工具适合任务，确定查询复杂性和子智能体数量，并定义每个子智能体的角色。我们的测试表明，扩展思维提高了指令遵循、推理和效率。子智能体也进行规划，然后在工具结果后使用交错思考来评估质量，识别差距，并完善其下一个查询。这使得子智能体在适应任何任务时都更加有效。 8. 并行工具调用改变了速度和性能。 复杂的研究任务自然涉及探索许多来源。我们早期的智能体执行顺序搜索，速度慢得令人痛苦。为了提速，我们引入了两种并行化：（1）首席智能体并行启动 3 5 个子智能体，而不是串行启动；（2）子智能体并行使用 3 个以上的工具。这些改变使复杂查询的研究时间减少了高达 90%，使研究功能能在几分钟内完成更多工作，而不是几小时，同时覆盖比其他系统更多的信息。 我们的提示策略侧重于灌输良好的启发式方法，而非僵化的规则。我们研究了熟练的人类如何处理研究任务，并将这些策略编码到我们的提示中——例如分解难题为更小的任务、仔细评估来源质量、根据新信息调整搜索方法，以及识别何时应侧重于深度（详细调查一个主题）与广度（并行探索多个主题）。我们还通过设置明确的护栏来主动减轻意外的副作用，以防止智能体失控。最后，我们专注于一个具有可观察性和测试用例的快速迭代循环。 有效评估智能体 良好的评估对于构建可靠的 AI 应用程序至关重要，智能体也不例外。然而，评估多智能体系统带来了独特的挑战。传统的评估通常假设 AI 每次都遵循相同的步骤：给定输入 X，系统应遵循路径 Y 产生输出 Z。但多智能体系统并非如此运作。即使起点相同，智能体也可能采取完全不同的有效路径来达到目标。一个智能体可能搜索三个来源，而另一个搜索十个，或者它们可能使用不同的工具找到相同的答案。因为我们并不总是知道正确的步骤是什么，我们通常不能仅仅检查智能体是否遵循了我们预先规定的"正确"步骤。相反，我们需要灵活的评估方法，既能判断智能体是否取得了正确的结果，又能判断它们是否遵循了合理的过程。 立即用小样本开始评估。 在智能体开发的早期，变更往往会产生巨大影响，因为有大量低垂的果实。一个提示的微调可能会将成功率从 30% 提高到 80%。当效应规模如此之大时，仅用几个测试用例就能发现变化。我们从大约 20 个代表真实使用模式的查询集开始。测试这些查询通常使我们能够清楚地看到变更的影响。我们经常听说 AI 开发团队推迟创建评估，因为他们认为只有包含数百个测试用例的大型评估才有用。然而，最好是立即用几个例子开始小规模测试，而不是等到能够构建更详尽的评估时再行动。 精心设计的"以语言模型为评判者"的评估可以扩展。 研究产出很难通过程序化方式评估，因为它们是自由格式的文本，很少有单一的正确答案。语言模型天然适合对产出进行评分。我们使用了一个语言模型评判者，它根据一个评分标准来评估每个产出：事实准确性（声明是否与来源匹配？）、引文准确性（引用的来源是否与声明匹配？）、完整性（是否涵盖了所有被要求的内容？）、来源质量（它是否使用了主要来源而非质量较低的次要来源？），以及工具效率（它是否以合理的次数使用了正确的工具？）。我们尝试了多个评判者来评估每个部分，但发现单个语言模型调用、单个提示输出 0.0 1.0 的分数和一个通过/失败的等级，与人类的判断最为一致和吻合。当评估测试用例 确实 有明确答案时，这种方法尤其有效，我们可以使用语言模型评判者简单地检查答案是否正确（即，它是否准确列出了研发预算前三名的制药公司？）。使用语言模型作为评判者使我们能够可扩展地评估数百个产出。 人工评估能捕捉到自动化所遗漏的问题。 人工测试智能体能发现评估所遗漏的边缘案例。这些包括对不寻常查询的幻觉答案、系统故障或微妙的来源选择偏见。在我们的案例中，人工测试人员注意到，我们早期的智能体一致地选择经 SEO 优化的内容农场，而不是权威性更高但排名较低的来源，如学术 PDF 或个人博客。在我们的提示中增加来源质量的启发式方法帮助解决了这个问题。即使在一个自动化评估的世界里，手动测试仍然至关重要。 多智能体系统具有涌现行为，这些行为是在没有特定编程的情况下产生的。例如，对首席智能体的微小改变可能会不可预测地改变子智能体的行为。成功需要理解交互模式，而不仅仅是单个智能体的行为。因此，这些智能体的最佳提示不仅仅是严格的指令，而是定义了劳动分工、解决问题的方法和投入预算的协作框架。要做到这一点，依赖于仔细的提示和工具设计、可靠的启发式方法、可观察性以及紧密的反馈循环。请参阅我们 Cookbook 中的开源提示以获取我们系统中的示例提示。 生产可靠性与工程挑战 在传统软件中，一个错误可能会破坏一个功能、降低性能或导致服务中断。在智能体系统中，微小的变化会级联成巨大的行为变化，这使得为必须在长期运行过程中维持状态的复杂智能体编写代码变得异常困难。 智能体是有状态的，错误会累积。 智能体可以长时间运行，在多次工具调用中维持状态。这意味着我们需要持久地执行代码并在此过程中处理错误。没有有效的缓解措施，微小的系统故障对智能体来说可能是灾难性的。当错误发生时，我们不能简单地从头开始重启：重启既昂贵又让用户沮丧。相反，我们构建了能够从智能体出错的地方恢复的系统。我们还利用模型的智能来优雅地处理问题：例如，让智能体知道某个工具正在失灵并让它自行适应，效果出奇地好。我们将基于 Claude 构建的 AI 智能体的适应性与重试逻辑和定期检查点等确定性保障措施相结合。 调试得益于新方法。 智能体做出动态决策，并且即使使用相同的提示，每次运行之间也是不确定的。这使得调试更加困难。例如，用户会报告智能体"找不到明显的信息"，但我们看不出原因。是智能体使用了糟糕的搜索查询吗？选择了差劲的来源？还是遇到了工具故障？增加全面的生产追踪让我们能够诊断智能体失败的原因并系统地修复问题。除了标准的可观察性，我们还监控智能体的决策模式和交互结构——所有这些都在不监控单个对话内容的情况下进行，以维护用户隐私。这种高层次的可观察性帮助我们诊断根本原因、发现意外行为并修复常见故障。 部署需要仔细协调。 智能体系统是高度状态化的、由提示、工具和执行逻辑构成的网络，几乎连续不断地运行。这意味着无论何时我们部署更新，智能体都可能处于其流程的任何位置。因此，我们需要防止我们出于好意的代码更改破坏现有的智能体。我们不能同时将每个智能体更新到新版本。相反，我们使用彩虹部署来避免干扰正在运行的智能体，通过在保持新旧版本同时运行的情况下，逐步将流量从旧版本转移到新版本。 同步执行造成瓶颈。 目前，我们的首席智能体同步执行子智能体，等待每组子智能体完成后再继续。这简化了协调，但在智能体之间的信息流中造成了瓶颈。例如，首席智能体无法引导子智能体，子智能体无法协调，整个系统可能因为等待单个子智能体完成搜索而被阻塞。异步执行将能实现额外的并行性：智能体并发工作并在需要时创建新的子智能体。但这种异步性在结果协调、状态一致性和跨子智能体的错误传播方面增加了挑战。随着模型能够处理更长、更复杂的研究任务，我们预计性能的提升将证明这种复杂性是值得的。 结论 在构建 AI 智能体时，最后一英里往往成为旅程的大部分。在开发人员机器上能工作的代码库需要大量的工程改造才能成为可靠的生产系统。智能体系统中错误的复合性质意味着，对于传统软件来说是小问题的事情，可能会让智能体完全脱轨。一个步骤的失败可能导致智能体探索完全不同的轨迹，从而产生不可预测的结果。由于本文中描述的所有原因，原型与生产之间的差距往往比预期的要大。 尽管存在这些挑战，多智能体系统已被证明对于开放式研究任务非常有价值。用户表示，Claude 帮助他们找到了以前没有考虑过的商业机会，驾驭了复杂的医疗保健选择，解决了棘手的技术错误，并通过发现他们自己找不到的研究联系，节省了多达数天的工作时间。通过精心的工程设计、全面的测试、注重细节的提示和工具设计、稳健的运营实践，以及对当前智能体能力有深刻理解的研究、产品和工程团队之间的紧密协作，多智能体研究系统可以在规模上可靠地运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。 · · · 总结与解读：来自 LangChain 的视角 Cognition 和 Anthropic 两篇看似对立的文章，实际上共同揭示了构建多智能体系统的深刻见解。LangChain 团队在其文章《何时以及如何构建多智能体系统》中，为我们提供了整合这两个视角的关键洞察。 核心洞察一：上下文工程至关重要 两篇文章都反复强调了 上下文工程 的核心地位。 • Cognition AI 明确指出，多智能体系统会放大上下文传递的难度，导致子智能体因缺乏完整信息或不了解彼此的"隐式决策"而产生冲突，最终导致任务失败。他们因此推崇更简单、上下文连续的单线程智能体。 • Anthropic 虽未用此术语，但其详尽的"提示工程"原则——如长程对话管理、精细化任务授权——本质上都是在应对严峻的上下文工程挑战，以确保主智能体和子智能体之间的有效沟通和协调。 结论是明确的： 上下文工程是确保任何智能体系统（无论单体或多体）可靠运行的关键 。开发人员需要完全的控制权来设计信息流和交互顺序，以确保每个智能体在行动时都拥有恰当的上下文。 核心洞察二："读取"密集型 vs "写入"密集型 LangChain 提出了一个精辟的区分标准，这可能是理解何时应该（或不应该）构建多智能体系统的关键： 任务是"读取"密集型还是"写入"密集型？ • "读取"密集型系统更容易构建 Anthropic 的研究系统是完美的例子。研究任务主要是从大量信息源中"读取"和提炼，这种操作本质上 易于并行化 。多个子智能体可以同时探索不同方向，其"读取"操作互不干扰，最后由一个主智能体整合结果即可。 • "写入"密集型系统更难构建 Cognition 关注的编码等任务，则是典型的"写入"密集型。当多个智能体试图同时"写入"或修改同一个复杂系统（如代码库）时，它们"冲突的决策"会产生难以协调的不兼容输出，导致糟糕的结果。 这很好地解释了为什么 Anthropic 对用于研究的多智能体系统持乐观态度，而 Cognition 对其普遍适用性（尤其是在软件工程领域）表示怀疑。 共同的工程挑战 除了核心理念的异同，两篇文章都揭示了构建生产级智能体所面临的共同工程难题，LangChain 对此进行了总结： 1. 持久化执行与错误处理 长时运行的智能体必须能够保存状态，并从错误中恢复，而不是简单地从头开始。 2. 调试与可观测性 智能体的非确定性使其调试异常困难，需要全新的、为调试优化过的追踪和可观测性平台。 流程图展示了我们多智能体研究系统的完整工作流程。当用户提交查询时，系统创建一个 LeadResearcher（首席研究员）智能体，进入一个迭代的研究过程。LeadResearcher 首先思考方法，并将其计划保存到内存中以持久化上下文，因为如果上下文窗口超过 200,000 个 tokens 将被截断，保留计划至关重要。然后，它创建具有特定研究任务的专业 Subagents（子智能体）（这里显示了两个，但可以是任意数量）。每个 Subagent 独立执行网络搜索，使用交错思考评估工具结果，并将发现返回给 LeadResearcher。LeadResearcher 综合这些结果，并决定是否需要更多研究——如果需要，它可以创建额外的子智能体或完善其策略。一旦收集到足够的信息，系统就会退出研究循环，并将所有发现传递给一个 CitationAgent（引文智能体），该智能体处理文档和研究报告以识别引文的具体位置。这确保了所有声明都正确归因于其来源。最终的研究结果，连同引文，然后返回给用户。 研究智能体的提示工程与评估 多智能体系统与单智能体系统有关键区别，其中包括协调复杂性的迅速增长。早期的智能体犯过诸如为简单查询生成 50 个子智能体、为不存在的来源无休止地搜刮网络，以及因过多更新而相互干扰等错误。由于每个智能体都由提示引导，提示工程是我们改进这些行为的主要手段。以下是我们学到的一些提示智能体的原则： 1. 像你的智能体一样思考。 要迭代提示，你必须理解其效果。为了帮助我们做到这一点，我们使用我们的 Console 构建了模拟，其中包含我们系统中的确切提示和工具，然后逐步观察智能体的工作。这立即揭示了失败模式：智能体在已有足够结果时仍继续工作，使用过于冗长的搜索查询，或选择不正确的工具。有效的提示依赖于建立一个准确的智能体心智模型，这可以使最有影响力的改变变得显而易见。 2. 教协调者如何授权。 在我们的系统中，首席智能体将查询分解为子任务，并向子智能体描述它们。每个子智能体都需要一个目标、一个输出格式、关于要使用的工具和来源的指导，以及明确的任务边界。没有详细的任务描述，智能体就会重复工作、留下空白或无法找到必要的信息。我们开始时允许首席智能体给出简单的、简短的指令，如"研究半导体短缺"，但发现这些指令常常模糊不清，以至于子智能体误解了任务或执行了与其他智能体完全相同的搜索。例如，一个子智能体探索了 2021 年的汽车芯片危机，而另外两个则重复工作，调查当前的 2025 年供应链，没有有效的劳动分工。 3. 根据查询复杂性调整投入。 智能体难以判断不同任务的适当投入，所以我们在提示中嵌入了扩展规则。简单的事实查找只需要 1 个智能体进行 3 10 次工具调用，直接比较可能需要 2 4 个子智能体，每个进行 10 15 次调用，而复杂的研究可能需要超过 10 个子智能体，并明确划分责任。这些明确的指导方针帮助首席智能体有效分配资源，并防止在简单查询上过度投入，这是我们早期版本中常见的失败模式。 4. 工具设计和选择至关重要。 智能体 工具接口与人机接口同样关键。使用正确的工具是高效的——通常是绝对必要的。例如，一个在 Slack 中寻找仅存在于其中的上下文的智能体从一开始就注定要失败。通过让模型能够访问外部工具的 MCP 服务器，这个问题会更加复杂，因为智能体会遇到描述质量参差不齐的未知工具。我们为我们的智能体提供了明确的启发式方法：例如，首先检查所有可用工具，将工具使用与用户意图相匹配，为广泛的外部探索搜索网络，或优先选择专业工具而非通用工具。糟糕的工具描述会使智能体走上完全错误的道路，所以每个工具都需要一个明确的用途和清晰的描述。 5. 让智能体自我改进。 我们发现 Claude 4 模型可以是出色的提示工程师。当给定一个提示和一种失败模式时，它们能够诊断出智能体失败的原因并提出改进建议。我们甚至创建了一个工具测试智能体——当给定一个有缺陷的 MCP 工具时，它会尝试使用该工具，然后重写工具描述以避免失败。通过数十次测试该工具，这个智能体发现了关键的细微差别和错误。这个改进工具人体工程学的过程，使得未来使用新描述的智能体完成任务的时间减少了 40%，因为它们能够避免大多数错误。 6. 先广后窄。 搜索策略应该效仿专家的人类研究方法：在深入研究细节之前先探索整体概况。智能体通常默认使用过长、过于具体的查询，结果返回很少。我们通过提示智能体从简短、宽泛的查询开始，评估可用信息，然后逐步缩小焦点，来抵制这种倾向。 7. 引导思维过程。 扩展思维模式，它引导 Claude 在一个可见的思维过程中输出额外的 tokens，可以作为一个可控的草稿纸。首席智能体使用思考来规划其方法，评估哪些工具适合任务，确定查询复杂性和子智能体数量，并定义每个子智能体的角色。我们的测试表明，扩展思维提高了指令遵循、推理和效率。子智能体也进行规划，然后在工具结果后使用交错思考来评估质量，识别差距，并完善其下一个查询。这使得子智能体在适应任何任务时都更加有效。 8. 并行工具调用改变了速度和性能。 复杂的研究任务自然涉及探索许多来源。我们早期的智能体执行顺序搜索，速度慢得令人痛苦。为了提速，我们引入了两种并行化：（1）首席智能体并行启动 3 5 个子智能体，而不是串行启动；（2）子智能体并行使用 3 个以上的工具。这些改变使复杂查询的研究时间减少了高达 90%，使研究功能能在几分钟内完成更多工作，而不是几小时，同时覆盖比其他系统更多的信息。 我们的提示策略侧重于灌输良好的启发式方法，而非僵化的规则。我们研究了熟练的人类如何处理研究任务，并将这些策略编码到我们的提示中——例如分解难题为更小的任务、仔细评估来源质量、根据新信息调整搜索方法，以及识别何时应侧重于深度（详细调查一个主题）与广度（并行探索多个主题）。我们还通过设置明确的护栏来主动减轻意外的副作用，以防止智能体失控。最后，我们专注于一个具有可观察性和测试用例的快速迭代循环。 有效评估智能体 良好的评估对于构建可靠的 AI 应用程序至关重要，智能体也不例外。然而，评估多智能体系统带来了独特的挑战。传统的评估通常假设 AI 每次都遵循相同的步骤：给定输入 X，系统应遵循路径 Y 产生输出 Z。但多智能体系统并非如此运作。即使起点相同，智能体也可能采取完全不同的有效路径来达到目标。一个智能体可能搜索三个来源，而另一个搜索十个，或者它们可能使用不同的工具找到相同的答案。因为我们并不总是知道正确的步骤是什么，我们通常不能仅仅检查智能体是否遵循了我们预先规定的"正确"步骤。相反，我们需要灵活的评估方法，既能判断智能体是否取得了正确的结果，又能判断它们是否遵循了合理的过程。 立即用小样本开始评估。 在智能体开发的早期，变更往往会产生巨大影响，因为有大量低垂的果实。一个提示的微调可能会将成功率从 30% 提高到 80%。当效应规模如此之大时，仅用几个测试用例就能发现变化。我们从大约 20 个代表真实使用模式的查询集开始。测试这些查询通常使我们能够清楚地看到变更的影响。我们经常听说 AI 开发团队推迟创建评估，因为他们认为只有包含数百个测试用例的大型评估才有用。然而，最好是立即用几个例子开始小规模测试，而不是等到能够构建更详尽的评估时再行动。 精心设计的"以语言模型为评判者"的评估可以扩展。 研究产出很难通过程序化方式评估，因为它们是自由格式的文本，很少有单一的正确答案。语言模型天然适合对产出进行评分。我们使用了一个语言模型评判者，它根据一个评分标准来评估每个产出：事实准确性（声明是否与来源匹配？）、引文准确性（引用的来源是否与声明匹配？）、完整性（是否涵盖了所有被要求的内容？）、来源质量（它是否使用了主要来源而非质量较低的次要来源？），以及工具效率（它是否以合理的次数使用了正确的工具？）。我们尝试了多个评判者来评估每个部分，但发现单个语言模型调用、单个提示输出 0.0 1.0 的分数和一个通过/失败的等级，与人类的判断最为一致和吻合。当评估测试用例 确实 有明确答案时，这种方法尤其有效，我们可以使用语言模型评判者简单地检查答案是否正确（即，它是否准确列出了研发预算前三名的制药公司？）。使用语言模型作为评判者使我们能够可扩展地评估数百个产出。 人工评估能捕捉到自动化所遗漏的问题。 人工测试智能体能发现评估所遗漏的边缘案例。这些包括对不寻常查询的幻觉答案、系统故障或微妙的来源选择偏见。在我们的案例中，人工测试人员注意到，我们早期的智能体一致地选择经 SEO 优化的内容农场，而不是权威性更高但排名较低的来源，如学术 PDF 或个人博客。在我们的提示中增加来源质量的启发式方法帮助解决了这个问题。即使在一个自动化评估的世界里，手动测试仍然至关重要。 多智能体系统具有涌现行为，这些行为是在没有特定编程的情况下产生的。例如，对首席智能体的微小改变可能会不可预测地改变子智能体的行为。成功需要理解交互模式，而不仅仅是单个智能体的行为。因此，这些智能体的最佳提示不仅仅是严格的指令，而是定义了劳动分工、解决问题的方法和投入预算的协作框架。要做到这一点，依赖于仔细的提示和工具设计、可靠的启发式方法、可观察性以及紧密的反馈循环。请参阅我们 Cookbook 中的开源提示以获取我们系统中的示例提示。 生产可靠性与工程挑战 在传统软件中，一个错误可能会破坏一个功能、降低性能或导致服务中断。在智能体系统中，微小的变化会级联成巨大的行为变化，这使得为必须在长期运行过程中维持状态的复杂智能体编写代码变得异常困难。 智能体是有状态的，错误会累积。 智能体可以长时间运行，在多次工具调用中维持状态。这意味着我们需要持久地执行代码并在此过程中处理错误。没有有效的缓解措施，微小的系统故障对智能体来说可能是灾难性的。当错误发生时，我们不能简单地从头开始重启：重启既昂贵又让用户沮丧。相反，我们构建了能够从智能体出错的地方恢复的系统。我们还利用模型的智能来优雅地处理问题：例如，让智能体知道某个工具正在失灵并让它自行适应，效果出奇地好。我们将基于 Claude 构建的 AI 智能体的适应性与重试逻辑和定期检查点等确定性保障措施相结合。 调试得益于新方法。 智能体做出动态决策，并且即使使用相同的提示，每次运行之间也是不确定的。这使得调试更加困难。例如，用户会报告智能体"找不到明显的信息"，但我们看不出原因。是智能体使用了糟糕的搜索查询吗？选择了差劲的来源？还是遇到了工具故障？增加全面的生产追踪让我们能够诊断智能体失败的原因并系统地修复问题。除了标准的可观察性，我们还监控智能体的决策模式和交互结构——所有这些都在不监控单个对话内容的情况下进行，以维护用户隐私。这种高层次的可观察性帮助我们诊断根本原因、发现意外行为并修复常见故障。 部署需要仔细协调。 智能体系统是高度状态化的、由提示、工具和执行逻辑构成的网络，几乎连续不断地运行。这意味着无论何时我们部署更新，智能体都可能处于其流程的任何位置。因此，我们需要防止我们出于好意的代码更改破坏现有的智能体。我们不能同时将每个智能体更新到新版本。相反，我们使用彩虹部署来避免干扰正在运行的智能体，通过在保持新旧版本同时运行的情况下，逐步将流量从旧版本转移到新版本。 同步执行造成瓶颈。 目前，我们的首席智能体同步执行子智能体，等待每组子智能体完成后再继续。这简化了协调，但在智能体之间的信息流中造成了瓶颈。例如，首席智能体无法引导子智能体，子智能体无法协调，整个系统可能因为等待单个子智能体完成搜索而被阻塞。异步执行将能实现额外的并行性：智能体并发工作并在需要时创建新的子智能体。但这种异步性在结果协调、状态一致性和跨子智能体的错误传播方面增加了挑战。随着模型能够处理更长、更复杂的研究任务，我们预计性能的提升将证明这种复杂性是值得的。 结论 在构建 AI 智能体时，最后一英里往往成为旅程的大部分。在开发人员机器上能工作的代码库需要大量的工程改造才能成为可靠的生产系统。智能体系统中错误的复合性质意味着，对于传统软件来说是小问题的事情，可能会让智能体完全脱轨。一个步骤的失败可能导致智能体探索完全不同的轨迹，从而产生不可预测的结果。由于本文中描述的所有原因，原型与生产之间的差距往往比预期的要大。 尽管存在这些挑战，多智能体系统已被证明对于开放式研究任务非常有价值。用户表示，Claude 帮助他们找到了以前没有考虑过的商业机会，驾驭了复杂的医疗保健选择，解决了棘手的技术错误，并通过发现他们自己找不到的研究联系，节省了多达数天的工作时间。通过精心的工程设计、全面的测试、注重细节的提示和工具设计、稳健的运营实践，以及对当前智能体能力有深刻理解的研究、产品和工程团队之间的紧密协作，多智能体研究系统可以在规模上可靠地运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。 · · · 总结与解读：来自 LangChain 的视角 Cognition 和 Anthropic 两篇看似对立的文章，实际上共同揭示了构建多智能体系统的深刻见解。LangChain 团队在其文章《何时以及如何构建多智能体系统》中，为我们提供了整合这两个视角的关键洞察。 核心洞察一：上下文工程至关重要 两篇文章都反复强调了 上下文工程 的核心地位。 • Cognition AI 明确指出，多智能体系统会放大上下文传递的难度，导致子智能体因缺乏完整信息或不了解彼此的"隐式决策"而产生冲突，最终导致任务失败。他们因此推崇更简单、上下文连续的单线程智能体。 • Anthropic 虽未用此术语，但其详尽的"提示工程"原则——如长程对话管理、精细化任务授权——本质上都是在应对严峻的上下文工程挑战，以确保主智能体和子智能体之间的有效沟通和协调。 结论是明确的： 上下文工程是确保任何智能体系统（无论单体或多体）可靠运行的关键 。开发人员需要完全的控制权来设计信息流和交互顺序，以确保每个智能体在行动时都拥有恰当的上下文。 核心洞察二："读取"密集型 vs "写入"密集型 LangChain 提出了一个精辟的区分标准，这可能是理解何时应该（或不应该）构建多智能体系统的关键： 任务是"读取"密集型还是"写入"密集型？ • "读取"密集型系统更容易构建 Anthropic 的研究系统是完美的例子。研究任务主要是从大量信息源中"读取"和提炼，这种操作本质上 易于并行化 。多个子智能体可以同时探索不同方向，其"读取"操作互不干扰，最后由一个主智能体整合结果即可。 • "写入"密集型系统更难构建 Cognition 关注的编码等任务，则是典型的"写入"密集型。当多个智能体试图同时"写入"或修改同一个复杂系统（如代码库）时，它们"冲突的决策"会产生难以协调的不兼容输出，导致糟糕的结果。 这很好地解释了为什么 Anthropic 对用于研究的多智能体系统持乐观态度，而 Cognition 对其普遍适用性（尤其是在软件工程领域）表示怀疑。 共同的工程挑战 除了核心理念的异同，两篇文章都揭示了构建生产级智能体所面临的共同工程难题，LangChain 对此进行了总结： 1. 持久化执行与错误处理 长时运行的智能体必须能够保存状态，并从错误中恢复，而不是简单地从头开始。 2. 调试与可观测性 智能体的非确定性使其调试异常困难，需要全新的、为调试优化过的追踪和可观测性平台。 3. 有效评估 需要结合小数据集、自动化评估（如"LLM 即法官"）和至关重要的人工测试，来全面评估智能体的性能。 最终结论 综合来看，关于是否构建多智能体系统，并不存在一个简单的"是"或"否"的答案。 • 适用场景 多智能体系统在能够被有效分解为多个并行、独立"读取"任务的场景下（如广度优先的研究查询）表现出色。它通过扩展 token 使用量来解决单智能体无法处理的复杂问题。 • 核心挑战 其最大的软肋在于 跨智能体的上下文共享和决策协调 ，这在"写入"密集型任务中尤为致命。 • 代价 多智能体系统带来了更高的 复杂性 和 成本 （token 消耗）。 最终，构建智能体的现实是，不存在"一刀切"的解决方案。开发者需要根据具体问题的性质，在单线程智能体、多智能体等不同架构之间做出明智的权衡与选择。而任何选择，都离不开对"上下文工程"的精细把握和对新一代工程工具（如持久化、可观测性、评估框架）的拥抱。 我是蓝衣剑客，谢谢你看我的文章。 You don't have permission to access this synced block. Please log in and try again. Log In 大家好，最近我在看一些技术文章的时候，发现 LangChain总结了 Cognition AI 和 Anthropic 最近发布的关于多智能体系统的两篇重磅文章，我觉得非常有必要向大家推荐一下。 因为，随着今年智能体技术的发展，"多智能体"成了一个高频探讨的热门话题。Cognition AI 和 Anthropic 都是这个领域最前沿的公司，看看这些真正的专家们之间有哪些争论，以及他们各自的实现思路，对我们来说非常有参考价值。 本着兼听则明、偏听则暗的原则。 本文将首先完整呈现这两篇文章的核心内容，然后引用 LangChain 团队对这两篇内容的评论文章——《何时以及如何构建多智能体系统》，对这场讨论进行总结与解读。 大家好，最近我在看一些技术文章的时候，发现 LangChain总结了 Cognition AI 和 Anthropic 最近发布的关于多智能体系统的两篇重磅文章，我觉得非常有必要向大家推荐一下。 因为，随着今年智能体技术的发展，"多智能体"成了一个高频探讨的热门话题。Cognition AI 和 Anthropic 都是这个领域最前沿的公司，看看这些真正的专家们之间有哪些争论，以及他们各自的实现思路，对我们来说非常有参考价值。 本着兼听则明、偏听则暗的原则。 本文将首先完整呈现这两篇文章的核心内容，然后引用 LangChain 团队对这两篇内容的评论文章——《何时以及如何构建多智能体系统》，对这场讨论进行总结与解读。 · · · 第一篇：Cognition AI 《请勿构建多智能体》 2025 06 12 Walden Yan LLM Agent（智能体）框架的发展一直出人意料地不尽人意。本文希望基于我们自身的反复试错，为构建智能体提供一些原则，并解释为何一些看似诱人的想法在实践中其实相当糟糕。 上下文工程（Context Engineering）原则 我们将逐步引出以下原则： 1. 共享上下文 2. 行动蕴含隐式决策 为什么要思考原则？ HTML 于 1993 年问世。2013 年，Facebook 向世界发布了 React。如今已是 2025 年，React（及其衍生技术）主导了开发者构建网站和应用的方式。为什么？因为 React 不仅仅是一个编写代码的脚手架，它是一种哲学。通过使用 React，你欣然接受以一种响应式和模块化的模式来构建应用，这在今天已被人们视为标准要求，但对早期的 Web 开发者而言，这并非显而易见。 在 LLM 和 AI 智能体崛起的时代，我们感觉自己仍像是在摆弄原始的 HTML & CSS，摸索如何将它们组合起来以创造良好的体验。除了某些最基础的方法外，还没有任何一种构建智能体的单一方法成为标准。 在某些情况下，一些库（例如 OpenAI 的 https://github.com/openai/swarm 和微软的 https://github.com/microsoft/autogen）正在积极推广一些我认为是构建智能体的错误理念。具体来说，就是使用多智能体架构，我将解释其中缘由。 话虽如此，如果你是构建智能体的新手，市面上有很多关于如何搭建基础框架的资源。但当涉及到构建严肃的生产级应用时，情况就完全不同了。 构建长时运行智能体的理论 让我们从可靠性谈起。当智能体需要长时间可靠运行并保持连贯的对话时，你必须采取某些措施来控制潜在的复合错误。否则，若不小心，系统会很快崩溃。可靠性的核心在于"上下文工程"（Context Engineering）。 上下文工程 到了 2025 年，市面上的模型已经极其智能。但即便是最聪明的人，如果缺乏任务所需的上下文，也无法高效地完成工作。"提示工程"（Prompt Engineering）这个术语应运而生，指的是为 LLM 聊天机器人以理想格式编写任务所付出的努力。而"上下文工程"则是其更高阶的形式。它关乎在一个动态系统中自动完成这项工作，需要更精细