Anthropic 多智能体研究系统构建详解
原文链接: www.anthropic.com/engineering…
发布日期: 2025年6月13日
引言
Claude 现已具备 Research 能力，能够在网络、Google Workspace 以及各种集成应用中进行搜索，以完成复杂任务。
这个多智能体系统从原型到生产环境的历程，让我们学到了关于系统架构、工具设计和提示词工程的关键经验。多智能体系统由多个智能体（LLM 在循环中自主使用工具）协同工作组成。我们的 Research 功能涉及一个智能体根据用户查询规划研究流程，然后使用工具创建多个并行智能体同时搜索信息。具有多个智能体的系统在智能体协调、评估和可靠性方面引入了新的挑战。
本文将详细介绍对我们有效的原则——希望你在构建自己的多智能体系统时能够运用这些原则。
多智能体系统的优势
研究工作涉及开放式问题，很难预先预测所需的步骤。你无法为探索复杂主题硬编码一条固定路径，因为这个过程本质上是动态的且依赖于路径。当人们进行研究时，他们往往会根据发现不断更新方法，跟随调查过程中出现的线索。
这种不可预测性使得 AI 智能体特别适合研究任务。研究需要灵活性，能够在调查展开时转向或探索切线联系。模型必须自主运行多轮，根据中间发现做出关于追求哪些方向的决策。线性的一次性流水线无法处理这些任务。
搜索的本质是压缩：从海量语料库中提炼洞察。子智能体通过在各自的上下文窗口中并行运作来促进压缩，同时探索问题的不同方面，然后将最重要的 token 浓缩给主研究智能体。每个子智能体还提供关注点分离——独立的工具、提示词和探索轨迹——这减少了路径依赖并实现了彻底、独立的调查。
一旦智能达到一定阈值，多智能体系统就成为扩展性能的重要方式。例如，尽管过去 10 万年来个体人类变得更加聪明，但人类社会在信息时代变得 指数级 更强大，这是因为我们的 集体 智慧和协调能力。即使是通用智能体在作为个体运作时也面临限制；智能体群体可以完成更多工作。
我们的内部评估显示，多智能体研究系统在广度优先查询方面表现尤其出色，这类查询涉及同时追求多个独立方向。我们发现，以 Claude Opus 4 作为主智能体、Claude Sonnet 4 作为子智能体的多智能体系统，在我们的内部研究评估中比单智能体 Claude Opus 4 高出 90.2%。例如，当被要求识别信息技术标普 500 公司的所有董事会成员时，多智能体系统通过将任务分解给子智能体找到了正确答案，而单智能体系统由于缓慢的顺序搜索未能找到答案。
多智能体系统之所以有效，主要是因为它们帮助花费足够的 token 来解决问题。在我们的分析中，三个因素解释了 BrowseComp 评估（测试浏览智能体定位难以找到的信息的能力）中 95% 的性能差异。我们发现，token 使用量本身解释了 80% 的差异，工具调用次数和模型选择是另外两个解释因素。这一发现验证了我们将工作分布在具有独立上下文窗口的智能体之间的架构，以增加并行推理的容量。最新的 Claude 模型在 token 使用上充当大的效率乘数，因为升级到 Claude Sonnet 4 带来的性能提升比在 Claude Sonnet 3.7 上加倍 token 预算更大。多智能体架构有效地扩展了超出单个智能体限制的任务的 token 使用量。
但也有缺点：在实践中，这些架构消耗 token 很快。在我们的数据中，智能体通常使用比聊天交互 多约 4 倍 的 token，而多智能体系统使用比聊天 多约 15 倍 的 token。为了经济可行性，多智能体系统需要任务的价值足够高以支付增加的性能成本。此外，一些需要所有智能体共享相同上下文或涉及智能体之间许多依赖关系的领域，目前不太适合多智能体系统。例如，大多数编码任务涉及比研究更少的真正可并行化任务，而且 LLM 智能体还不太擅长实时协调和委派给其他智能体。我们发现多智能体系统擅长涉及大量并行化、超出单个上下文窗口的信息以及与众多复杂工具交互的高价值任务。
💡 多智能体系统适用场景分析
| 特征 | 适合多智能体 | 不适合多智能体 |
|---|---|---|
| 任务类型 | 开放式研究、信息收集 | 编码任务、顺序依赖任务 |
| 并行化程度 | 高度可并行化 | 需要共享上下文 |
| 信息量 | 超出单个上下文窗口 | 在单个上下文内可处理 |
| 工具复杂度 | 众多复杂工具 | 简单工具集 |
| 任务价值 | 高价值（值得更多 token 成本） | 低价值简单任务 |
💡 Token 使用量对比
graph LR
A[聊天交互] -->|基准| B[1x Token]
C[单智能体] -->|4倍| D[4x Token]
E[多智能体系统] -->|15倍| F[15x Token]
Research 的架构概述
我们的 Research 系统使用具有编排器-工作器模式的多智能体架构，其中主智能体协调流程，同时委派给并行运作的专门子智能体。
当用户提交查询时，主智能体分析它，制定策略，并生成子智能体同时探索不同方面。如上图所示，子智能体充当智能过滤器，通过迭代使用搜索工具收集信息，在这个例子中是关于 2025 年的 AI 智能体公司，然后将公司列表返回给主智能体，以便它可以编译最终答案。
使用检索增强生成（RAG）的传统方法使用静态检索。也就是说，它们获取与输入查询最相似的一些块，并使用这些块生成响应。相比之下，我们的架构使用多步搜索，动态查找相关信息，适应新发现，并分析结果以制定高质量答案。
上图展示了完整的工作流程：当用户提交查询时，系统创建一个 LeadResearcher 智能体，进入迭代研究过程。LeadResearcher 首先思考方法并将其计划保存到 Memory 以持久化上下文，因为如果上下文窗口超过 200,000 个 token，它将被截断，保留计划很重要。然后它创建具有特定研究任务的专门 Subagents（这里显示两个，但可以是任意数量）。每个 Subagent 独立执行网络搜索，使用交错思考评估工具结果，并将发现返回给 LeadResearcher。LeadResearcher 综合这些结果并决定是否需要更多研究——如果需要，它可以创建额外的子智能体或完善其策略。一旦收集到足够的信息，系统退出研究循环并将所有发现传递给 CitationAgent，它处理文档和研究报告以识别引用的具体位置。这确保所有声明都正确归因于其来源。最终的研究结果，带有完整的引用，然后返回给用户。
💡 Research 系统工作流程
graph TD
A[用户提交查询] --> B[创建 LeadResearcher 智能体]
B --> C[思考方法并保存计划到 Memory]
C --> D[创建专门的 Subagents]
D --> E1[Subagent 1: 网络搜索]
D --> E2[Subagent 2: 网络搜索]
D --> E3[Subagent N: 网络搜索]
E1 --> F[使用交错思考评估结果]
E2 --> F
E3 --> F
F --> G{需要更多研究?}
G -->|是| D
G -->|否| H[传递给 CitationAgent]
H --> I[处理文档并添加引用]
I --> J[返回带引用的最终结果]
💡 RAG vs 多智能体架构对比
| 特性 | 传统 RAG | 多智能体架构 |
|---|---|---|
| 检索方式 | 静态检索 | 动态多步搜索 |
| 适应性 | 固定查询模式 | 根据发现自适应调整 |
| 信息处理 | 一次性获取相似块 | 迭代收集和分析 |
| 结果质量 | 依赖初始相似度匹配 | 持续优化直到满足需求 |
研究智能体的提示词工程和评估
多智能体系统与单智能体系统有关键区别，包括协调复杂性的快速增长。早期智能体犯了一些错误，比如为简单查询生成 50 个子智能体、无休止地在网上搜索不存在的来源、以及用过多更新分散彼此注意力。由于每个智能体由提示词引导，提示词工程是我们改善这些行为的主要杠杆。以下是我们学到的一些智能体提示原则：
1. 像你的智能体一样思考
要迭代提示词，你必须理解它们的效果。为了帮助我们做到这一点，我们使用 Console 构建了模拟，使用来自我们系统的确切提示词和工具，然后逐步观察智能体工作。这立即揭示了失败模式：智能体在已经有足够结果时继续、使用过于冗长的搜索查询、或选择错误的工具。有效的提示依赖于建立智能体的准确心理模型，这可以使最有影响力的更改变得明显。
2. 教会编排器如何委派
在我们的系统中，主智能体将查询分解为子任务并向子智能体描述它们。每个子智能体需要一个目标、一个输出格式、关于使用哪些工具和来源的指导，以及清晰的任务边界。没有详细的任务描述，智能体会重复工作、留下空白或无法找到必要的信息。我们最初允许主智能体给出简单、简短的指令，如"研究半导体短缺"，但发现这些指令往往模糊到子智能体误解任务或执行与其他智能体完全相同的搜索。例如，一个子智能体探索 2021 年汽车芯片危机，而另外 2 个重复调查当前 2025 年的供应链，没有有效的分工。
3. 根据查询复杂度调整努力程度
智能体难以判断不同任务的适当努力程度，因此我们在提示中嵌入了扩展规则。简单的事实查找只需要 1 个智能体进行 3-10 次工具调用，直接比较可能需要 2-4 个子智能体各进行 10-15 次调用，复杂研究可能使用超过 10 个子智能体，各有明确分工。这些明确的指导方针帮助主智能体有效分配资源，并防止在简单查询上过度投入，这是我们早期版本中常见的失败模式。
💡 查询复杂度与资源分配
| 查询类型 | 子智能体数量 | 工具调用次数 | 示例 |
|---|---|---|---|
| 简单事实查找 | 1 | 3-10 | "谁是某公司的CEO？" |
| 直接比较 | 2-4 | 每个10-15 | "比较A和B公司的营收" |
| 复杂研究 | 10+ | 明确分工 | "识别标普500信息技术公司的所有董事会成员" |
4. 工具设计和选择至关重要
智能体-工具接口与人机接口一样关键。使用正确的工具是高效的——通常是严格必要的。例如，一个在网上搜索只存在于 Slack 中的上下文的智能体从一开始就注定失败。随着 MCP 服务器让模型访问外部工具，这个问题变得更加复杂，因为智能体会遇到质量参差不齐的未见过的工具描述。我们给智能体明确的启发式规则：例如，首先检查所有可用工具，将工具使用与用户意图匹配，搜索网络进行广泛的外部探索，或优先使用专门工具而非通用工具。糟糕的工具描述可能会让智能体走上完全错误的道路，因此每个工具都需要一个独特的目的和清晰的描述。
5. 让智能体自我改进
我们发现 Claude 4 模型可以成为出色的提示词工程师。当给出一个提示和一个失败模式时，它们能够诊断智能体为何失败并建议改进。我们甚至创建了一个工具测试智能体——当给定一个有缺陷的 MCP 工具时，它尝试使用该工具然后重写工具描述以避免失败。通过数十次测试该工具，这个智能体发现了关键的细微差别和错误。这个改善工具人体工程学的过程为使用新描述的未来智能体减少了 40% 的任务完成时间，因为它们能够避免大多数错误。
6. 先广后窄
搜索策略应该模仿专家人类研究：在深入细节之前先探索全局。智能体经常默认使用过长、过于具体的查询，导致返回很少的结果。我们通过提示智能体从简短、广泛的查询开始，评估有什么可用的，然后逐步缩小焦点来抵消这种倾向。
7. 引导思考过程
扩展思考模式使 Claude 在可见的思考过程中输出额外的 token，可以作为可控的草稿本。主智能体使用思考来规划其方法，评估哪些工具适合任务，确定查询复杂度和子智能体数量，并定义每个子智能体的角色。我们的测试表明，扩展思考改善了指令遵循、推理和效率。子智能体也进行规划，然后在工具结果后使用交错思考来评估质量、识别差距并完善下一个查询。这使子智能体在适应任何任务时更加有效。
8. 并行工具调用变革速度和性能
复杂的研究任务自然涉及探索许多来源。我们早期的智能体执行顺序搜索，这非常慢。为了提速，我们引入了两种并行化：(1) 主智能体并行而非串行启动 3-5 个子智能体；(2) 子智能体并行使用 3+ 个工具。这些更改将复杂查询的研究时间减少了高达 90%，允许 Research 在几分钟而不是几小时内完成更多工作，同时覆盖比其他系统更多的信息。
💡 智能体提示词工程原则
graph TD
Root((提示词工程<br/>8大原则))
Root --> A[1. 像智能体一样思考]
Root --> B[2. 教会编排器委派]
Root --> C[3. 根据复杂度调整努力]
Root --> D[4. 工具设计选择关键]
Root --> E[5. 让智能体自我改进]
Root --> F[6. 先广后窄]
Root --> G[7. 引导思考过程]
Root --> H[8. 并行工具调用]
A --> A1[构建模拟观察智能体]
A --> A2[建立准确心理模型]
B --> B1[明确目标和输出格式]
B --> B2[清晰的任务边界]
C --> C1[简单: 1智能体 3-10调用]
C --> C2[复杂: 10+智能体分工]
D --> D1[检查所有可用工具]
D --> D2[优先专门工具]
E --> E1[诊断失败模式]
E --> E2[重写工具描述]
F --> F1[短广泛查询开始]
F --> F2[逐步缩小焦点]
G --> G1[扩展思考规划]
G --> G2[交错思考评估]
H --> H1[3-5子智能体并行]
H --> H2[每个子智能体3+工具并行]
我们的提示策略专注于灌输良好的启发式方法而非僵化的规则。我们研究了熟练的人类如何处理研究任务，并将这些策略编码在我们的提示中——策略如将困难问题分解为更小的任务、仔细评估来源质量、根据新信息调整搜索方法、以及识别何时专注于深度（详细调查一个主题）vs. 广度（并行探索多个主题）。我们还通过设置明确的护栏来主动减轻意外副作用，以防止智能体失控。最后，我们专注于具有可观测性和测试用例的快速迭代循环。参见我们 Cookbook 中的开源提示获取我们系统的示例提示。
智能体的有效评估
好的评估对于构建可靠的 AI 应用至关重要，智能体也不例外。然而，评估多智能体系统提出了独特的挑战。传统评估通常假设 AI 每次都遵循相同的步骤：给定输入 X，系统应该遵循路径 Y 产生输出 Z。但多智能体系统不是这样工作的。即使起点相同，智能体也可能采取完全不同的有效路径来达到目标。一个智能体可能搜索三个来源而另一个搜索十个，或者它们可能使用不同的工具找到相同的答案。因为我们并不总是知道正确的步骤是什么，我们通常无法只检查智能体是否遵循了我们预先规定的"正确"步骤。相反，我们需要灵活的评估方法，判断智能体是否在遵循合理流程的同时实现了正确的结果。
立即用小样本开始评估
在早期智能体开发中，变化往往会产生巨大影响，因为有大量唾手可得的改进机会。一个提示调整可能将成功率从 30% 提升到 80%。效果量如此之大，你只需几个测试用例就能发现变化。我们从一组代表真实使用模式的约 20 个查询开始。测试这些查询通常让我们清楚地看到变化的影响。我们经常听说 AI 开发团队推迟创建评估，因为他们认为只有包含数百个测试用例的大型评估才有用。然而，最好立即开始小规模测试，用几个例子，而不是延迟到你可以构建更彻底的评估。
LLM-as-judge 评估在做好时可以扩展
研究输出很难以编程方式评估，因为它们是自由形式的文本，很少有单一正确答案。LLM 自然适合评分输出。我们使用了一个 LLM 评判器，根据评分标准评估每个输出：事实准确性（声明是否与来源匹配？）、引用准确性（引用的来源是否与声明匹配？）、完整性（是否涵盖所有请求的方面？）、来源质量（是否使用一手来源而非较低质量的二手来源？）、以及工具效率（是否合理次数使用了正确的工具？）。我们尝试了多个评判器来评估每个组件，但发现单个 LLM 调用使用单个提示输出 0.0-1.0 的分数和通过/失败评级是最一致的，并且与人类判断最一致。当评估测试用例 确实 有明确答案时，这种方法特别有效，我们可以使用 LLM 评判器简单地检查答案是否正确（即它是否准确列出了研发预算前 3 大的制药公司？）。使用 LLM 作为评判器允许我们可扩展地评估数百个输出。
人工评估捕捉自动化遗漏的内容
测试智能体的人会发现评估遗漏的边缘情况。这包括对不寻常查询的幻觉答案、系统故障或微妙的来源选择偏差。在我们的案例中，人工测试人员注意到我们早期的智能体持续选择 SEO 优化的内容农场，而非权威但排名较低的来源如学术 PDF 或个人博客。在我们的提示中添加来源质量启发式规则帮助解决了这个问题。即使在自动化评估的世界里，手动测试仍然必不可少。
多智能体系统具有涌现行为，这些行为在没有特定编程的情况下出现。例如，对主智能体的微小更改可能会不可预测地改变子智能体的行为。成功需要理解交互模式，而不仅仅是单个智能体行为。因此，这些智能体的最佳提示不仅仅是严格的指令，而是定义分工、问题解决方法和努力预算的协作框架。做好这一点依赖于仔细的提示和工具设计、可靠的启发式方法、可观测性和紧密的反馈循环。
💡 智能体评估方法对比
| 评估方法 | 优点 | 局限 | 适用场景 |
|---|---|---|---|
| 小样本立即评估 | 快速发现大效果变化 | 可能遗漏边缘情况 | 早期开发阶段 |
| LLM-as-judge | 可扩展、一致性好 | 需要明确评分标准 | 大规模输出评估 |
| 人工评估 | 发现边缘情况和微妙偏差 | 不可扩展 | 质量验证和发现新问题 |
💡 LLM 评判器评分维度
graph TD
Root((LLM 评判器))
Root --> A[事实准确性]
Root --> B[引用准确性]
Root --> C[完整性]
Root --> D[来源质量]
Root --> E[工具效率]
A --> A1[声明与来源匹配?]
B --> B1[引用来源与声明匹配?]
C --> C1[涵盖所有请求方面?]
D --> D1[一手来源 vs 二手来源?]
E --> E1[合理次数使用正确工具?]
生产可靠性和工程挑战
在传统软件中，一个 bug 可能会破坏功能、降低性能或导致宕机。在智能体系统中，微小的更改会级联成大的行为变化，这使得为必须在长时间运行的过程中维护状态的复杂智能体编写代码变得非常困难。
智能体是有状态的，错误会复合
智能体可以长时间运行，在许多工具调用中维护状态。这意味着我们需要持久执行代码并在过程中处理错误。没有有效的缓解措施，微小的系统故障可能对智能体来说是灾难性的。当错误发生时，我们不能只是从头开始重启：重启对用户来说代价高昂且令人沮丧。相反，我们构建了可以从错误发生时智能体所在位置恢复的系统。我们还利用模型的智能优雅地处理问题：例如，让智能体知道工具何时失败并让它适应，效果出奇地好。我们将基于 Claude 构建的 AI 智能体的适应性与重试逻辑和定期检查点等确定性保障相结合。
调试需要新方法
智能体做出动态决策，即使使用相同的提示，运行之间也是非确定性的。这使调试变得更难。例如，用户会报告智能体"找不到明显的信息"，但我们看不出原因。智能体是在使用糟糕的搜索查询吗？选择了糟糕的来源？遇到工具故障？添加完整的生产追踪让我们能够诊断智能体为何失败并系统地修复问题。除了标准的可观测性之外，我们还监控智能体决策模式和交互结构——所有这些都不监控单个对话的内容，以维护用户隐私。这种高层次的可观测性帮助我们诊断根本原因、发现意外行为并修复常见故障。
部署需要仔细协调
智能体系统是高度有状态的提示、工具和执行逻辑的网络，几乎持续运行。这意味着每当我们部署更新时，智能体可能在其过程中的任何位置。因此我们需要防止我们善意的代码更改破坏现有智能体。我们不能同时将每个智能体更新到新版本。相反，我们使用彩虹部署来避免中断正在运行的智能体，通过逐步将流量从旧版本转移到新版本，同时保持两者同时运行。
同步执行创建瓶颈
目前，我们的主智能体同步执行子智能体，等待每组子智能体完成后再继续。这简化了协调，但在智能体之间的信息流中创建了瓶颈。例如，主智能体无法引导子智能体，子智能体无法协调，整个系统在等待单个子智能体完成搜索时可能被阻塞。异步执行将实现额外的并行性：智能体并发工作并在需要时创建新的子智能体。但这种异步性增加了结果协调、状态一致性和跨子智能体的错误传播方面的挑战。随着模型可以处理更长、更复杂的研究任务，我们预计性能收益将证明复杂性是值得的。
💡 生产环境挑战与解决方案
| 挑战 | 问题描述 | 解决方案 |
|---|---|---|
| 有状态错误复合 | 微小故障可能是灾难性的 | 断点恢复 + 模型适应性 + 确定性保障 |
| 非确定性调试 | 相同提示不同结果 | 完整生产追踪 + 高层次可观测性 |
| 部署协调 | 智能体可能在任何状态 | 彩虹部署：逐步转移流量 |
| 同步执行瓶颈 | 等待子智能体完成 | 未来：异步执行（需权衡复杂性） |
💡 彩虹部署流程
graph LR
A[旧版本 100%] --> B[旧90% 新10%]
B --> C[旧70% 新30%]
C --> D[旧50% 新50%]
D --> E[旧30% 新70%]
E --> F[旧10% 新90%]
F --> G[新版本 100%]
结论
构建 AI 智能体时，最后一英里往往成为旅程的大部分。在开发机器上运行的代码库需要大量工程工作才能成为可靠的生产系统。智能体系统中错误的复合性质意味着对传统软件来说的小问题可能完全破坏智能体。一个步骤失败可能导致智能体探索完全不同的轨迹，导致不可预测的结果。由于本文描述的所有原因，原型和生产之间的差距往往比预期的要宽。
尽管有这些挑战，多智能体系统已被证明对开放式研究任务很有价值。用户表示 Claude 帮助他们发现了他们没有考虑过的商业机会、导航复杂的医疗保健选项、解决棘手的技术 bug、并通过发现他们独自不会发现的研究联系节省了多达数天的工作。多智能体研究系统可以通过仔细的工程、全面的测试、注重细节的提示和工具设计、强大的运营实践，以及研究、产品和工程团队之间紧密协作——这些团队对当前智能体能力有深刻理解——在规模上可靠运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。
上图是一个 Clio 嵌入图，显示了人们今天使用 Research 功能最常见的方式。顶级用例类别包括：
- 在专门领域开发软件系统（10%）
- 开发和优化专业和技术内容（8%）
- 制定业务增长和收入生成策略（8%）
- 协助学术研究和教育材料开发（7%）
- 研究和验证有关人员、地点或组织的信息（5%）
💡 Research 功能核心使用场景
| 使用场景 | 占比 |
|---|---|
| 在专门领域开发软件系统 | 10% |
| 开发和优化专业和技术内容 | 8% |
| 制定业务增长和收入生成策略 | 8% |
| 协助学术研究和教育材料开发 | 7% |
| 研究和验证人员/地点/组织信息 | 5% |
致谢
本文由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford 撰写。这项工作反映了 Anthropic 多个团队的集体努力，使 Research 功能成为可能。特别感谢 Anthropic 应用工程团队，他们的奉献将这个复杂的多智能体系统带入生产环境。我们也感谢早期用户提供的出色反馈。
附录
以下是多智能体系统的一些额外杂项提示。
评估跨多轮改变状态的智能体的最终状态
评估在多轮对话中修改持久状态的智能体提出了独特的挑战。与只读研究任务不同，每个动作都可以改变后续步骤的环境，创建传统评估方法难以处理的依赖关系。我们发现专注于最终状态评估而非逐轮分析是成功的。不要判断智能体是否遵循了特定流程，而是评估它是否实现了正确的最终状态。这种方法承认智能体可能找到通向同一目标的替代路径，同时仍确保它们交付预期结果。对于复杂的工作流程，将评估分解为应该发生特定状态变化的离散检查点，而不是尝试验证每个中间步骤。
长期对话管理
生产智能体经常参与跨越数百轮的对话，需要仔细的上下文管理策略。随着对话延长，标准上下文窗口变得不足，需要智能压缩和记忆机制。我们实施了模式，其中智能体在继续新任务之前总结已完成的工作阶段并将基本信息存储在外部记忆中。当上下文限制接近时，智能体可以生成具有干净上下文的新子智能体，同时通过仔细的交接保持连续性。此外，它们可以从记忆中检索存储的上下文（如研究计划），而不是在达到上下文限制时丢失之前的工作。这种分布式方法在扩展交互中保持对话连贯性的同时防止上下文溢出。
子智能体输出到文件系统以减少"电话游戏"
直接子智能体输出可以绕过主协调器处理某些类型的结果，提高保真度和性能。而不是要求子智能体通过主智能体传达一切，实施工件系统，让专门智能体可以创建独立持久的输出。子智能体调用工具将其工作存储在外部系统中，然后将轻量级引用传回协调器。这防止了多阶段处理过程中的信息丢失，并减少了通过对话历史复制大型输出的 token 开销。该模式对于代码、报告或数据可视化等结构化输出特别有效，其中子智能体的专门提示产生比通过通用协调器过滤更好的结果。
💡 附录：高级技巧总结
graph TD
Root((高级技巧))
Root --> A[最终状态评估]
Root --> B[长期对话管理]
Root --> C[子智能体文件系统输出]
A --> A1[评估最终状态而非过程]
A --> A2[离散检查点验证]
B --> B1[总结工作阶段]
B --> B2[存储到外部记忆]
B --> B3[生成新子智能体保持连续性]
C --> C1[绕过主协调器]
C --> C2[轻量级引用传递]
C --> C3[减少token开销]
📝 总结
核心要点
-
多智能体系统的价值：适合开放式研究任务，通过并行化和独立上下文窗口有效扩展 token 使用量，在内部评估中比单智能体高出 90.2%
-
架构设计：采用编排器-工作器模式，主智能体协调，子智能体并行探索，配合 Memory 持久化和 CitationAgent 引用验证
-
提示词工程 8 原则：
- 像智能体一样思考
- 教会编排器委派
- 根据复杂度调整努力
- 工具设计选择关键
- 让智能体自我改进
- 先广后窄
- 引导思考过程
- 并行工具调用
-
评估策略：立即用小样本开始、LLM-as-judge 可扩展评估、人工评估捕捉边缘情况
-
生产挑战：有状态错误复合、非确定性调试、部署协调、同步执行瓶颈——通过断点恢复、追踪可观测性、彩虹部署等方案解决
-
核心权衡：多智能体系统消耗更多 token（约 15 倍于聊天），需要任务价值足够高以支付成本
原文作者: Jeremy Hadfield, Barry Zhang, Kenneth Lien, Florian Scholz, Jeremy Fox, Daniel Ford
