很良心，Claude把迭代、评估的过程和思考都给出来了。显然是想教育市场的。
Claude 的 Research 功能通过多个 Claude agents 协作，能够更高效地探索复杂主题。本文将分享我们在构建该系统过程中遇到的工程挑战与经验教训。
Claude 的 Research 现在具备了跨 Web、Google Workspace 及其他集成工具执行复杂任务的能力。
从原型到生产系统的演进过程中，我们在系统架构、工具设计与 prompt engineering 上学到了很多关键经验。一个 multi-agent system（多智能体系统）由多个 LLM 驱动的智能体构成，它们以工具循环（tool use loop）为基础协同工作。我们的 Research 系统中，有一个主 agent 负责制定研究计划，并调用工具来创建并行的 subagents 同时进行信息搜索。多智能体系统带来了新的挑战，例如智能体之间的协调、评估方式以及系统可靠性等问题。
多智能体系统的优势
研究工作往往是开放式问题，很难预设固定路径。你无法硬编码一条探索复杂问题的流程，因为研究的过程具有动态性与路径依赖性。人类进行研究时，会不断根据新发现调整策略，追踪新的线索。
这种不可预测性使得 AI agents 非常适合研究任务。研究需要灵活地转向或挖掘新兴相关内容，模型必须具备在多轮交互中自主决策的能力。一种线性的 one-shot pipeline（一次性流水线）并不适合此类任务。
搜索的本质是压缩------从海量信息中提取出关键洞见。Subagents 通过独立上下文窗口并行运行，能够探索问题的不同方面，然后将最关键的 tokens 压缩给主 agent。这种结构也实现了关注点分离（separation of concerns）：每个 subagent 使用不同工具、prompt、探索路径，从而避免路径依赖并支持深入、独立的研究。
一旦模型智能达到一定门槛，多智能体系统将成为扩展性能的关键方式。比如人类个体智力在过去十万年变化不大，但人类社会通过集体智能与协调机制，在信息时代实现了指数级提升。同样，即使是通用智能体也面临单个 agent 的局限，而 agent 组则可以做得更多。
我们的内部评估显示，对于需要同时展开多个独立方向的 breadth-first 查询，多智能体系统表现尤为优秀。我们发现，Claude Opus 4 担任主 agent、Claude Sonnet 4 作为 subagents 的系统，比单个 Claude Opus 4 的性能提升了 90.2%。例如在"找出 S&P 500 信息技术公司所有董事会成员"这一任务中，多智能体系统能够通过任务分解并行处理找到答案，而单智能体系统在缓慢的线性搜索中失败了。
这些系统的工作原理可以归结为"让模型消耗足够多的 token 去解决问题"。我们在 BrowseComp（用于评估 agent 浏览能力）中的分析表明，任务 token 的使用量单独就可以解释 80% 的性能差异；另外两个关键因素是工具调用次数与所用模型种类。这进一步验证了我们的架构设计------通过并行 agent 分担 token 使用，提升整体处理能力。Claude 最新版本的模型在 token 使用效率上极高，例如使用 Claude Sonnet 4 比在 Claude Sonnet 3.7 上增加两倍 token 预算的性能提升还大。多智能体系统通过横向扩展 token 使用，有效应对了超出单个 agent 能力的任务。
不过也有代价：这类架构在实践中 token 消耗极大。数据表明，多智能体系统的 token 消耗大约是普通 chat 的 15 倍，普通 agent 的 4 倍。因此，多智能体架构需用于任务价值足够高、能够承担其 token 成本的场景。此外，那些需要所有 agent 共享上下文或 agent 之间依赖紧密的任务，当前并不适合多智能体模式。例如，大多数编程任务的并行空间有限，LLM agents 也尚不擅长实时协调与分工。我们发现最适合多智能体的任务是：高度并行、信息超出单个上下文窗口、需与多个复杂工具交互的场景。
Research 系统架构概览
我们的 Research 系统采用 orchestrator-worker 架构：一个主 agent 负责整体流程，派遣多个并行 subagents 执行专业子任务。
当用户提交查询时，主 agent 分析问题、制定策略，并生成 subagents 同时处理不同方面的搜索任务。如上图所示，subagents 利用搜索工具迭代获取信息（此例为 2025 年的 AI agent 公司），返回公司列表后由主 agent 汇总出最终答案。
传统 RAG（Retrieval Augmented Generation）方式使用的是静态检索：即返回与输入查询最相似的一批 chunks，然后基于这些 chunks 作答。而我们的架构采用多步骤动态搜索机制：动态定位相关信息，根据中间发现调整搜索策略，并最终生成高质量回答。
该流程图展示了我们的多智能体 Research 系统的完整工作流程。
当用户提交查询后，系统会创建一个 LeadResearcher agent ，进入一个迭代式的研究流程。LeadResearcher 首先会思考研究方法，并将其计划保存到 Memory 中以保留上下文，因为一旦上下文窗口超过 200,000 个 token，将会被截断，因此保留研究计划非常关键。
随后，LeadResearcher 会创建若干个具有明确研究任务的 Subagents （图中展示了两个，但实际数量不限）。每个 Subagent 会独立执行网页搜索，利用 interleaved thinking（交错思维）对工具结果进行评估，并将发现反馈给 LeadResearcher。
LeadResearcher 对这些结果进行综合判断，并决定是否需要进一步研究------如果需要，可以创建更多 subagents 或调整研究策略。
一旦信息收集充分，系统将退出研究循环，并将所有发现传递给 CitationAgent，由其处理文档和研究报告，定位具体的引用位置，以确保所有观点都能准确溯源。
最终，系统将带有完整引用的研究结果返回给用户。
Prompt 工程与 agent 评估策略
多智能体系统相比单智能体系统，面临更高的协调复杂度。早期版本的问题包括：对简单问题生成了 50 个 subagents、无休止地在 web 上搜索不存在的内容、agent 之间频繁打扰彼此等。由于每个 agent 的行为主要受 prompt 控制，因此 prompt engineering 是我们最主要的调优手段。
我们学到的 prompt 工程经验包括：
- 像 agent 一样思考：我们在 Console 上模拟 prompt 和工具调用的真实交互，观察 agent 的行为路径。这种方法立刻揭示了很多失败模式：比如 agent 在已有充分结果的情况下继续搜索、构造过长无效的搜索语句、选择了错误工具等。
- 教会 orchestrator 如何分工：主 agent 要学会拆分任务并为 subagent 分配明确目标、输出格式、可用工具、搜索范围。早期简单指令如"研究芯片短缺"常常引发 subagent 重复劳动或误解任务边界。
- 根据任务复杂度调节 effort：通过在 prompt 中嵌入 effort scaling 规则，帮助主 agent 做出资源分配决策。比如：简单查询仅需 1 个 agent + 少量工具调用；对比查询用 2-4 个 agent；复杂研究任务可用 10+ agent 明确分工。
- 工具选择和设计至关重要：agent 工具接口的易用性与准确性和人类界面一样重要。坏的工具描述会导致 agent 使用错误工具。例如：在只有 Slack 上存在上下文的任务中，如果 agent 去搜索 web，注定失败。我们通过 prompt 加入判断规则，如：先评估所有工具、匹配工具与用户意图等。
- 让 agent 自我改进：Claude 4 模型在 prompt 优化上表现出色。我们甚至创建了 tool-testing agent，自动诊断 MCP 工具的问题并优化工具描述，提升后续 agent 成功率。
- 先广再深的搜索策略：早期 agent 倾向于使用过长、过具体的搜索查询，结果覆盖面差。我们鼓励先用宽泛短语，评估后再逐步聚焦。
- 引导 agent 的思维过程：我们使用 Claude 的 extended thinking 模式作为可控的草稿板，让 agent 显式输出自己的思考与规划过程，提升决策透明度和执行力。
- 并行工具调用提升速度与覆盖率：主 agent 可并发创建 3-5 个 subagent，而每个 subagent 又能同时调用 3+ 工具。该策略将复杂查询的耗时降低达 90%。
这些提示中没有硬性规则，而是遵循高效人类研究者的启发式策略，并在 prompt 中加以体现，例如：任务分解、动态调整搜索路径、辨别高质量来源、理解何时需要广度 vs 深度等。
多智能体系统的有效评估方式
构建可靠 AI 应用，评估至关重要，多智能体系统也不例外。但它们评估难度更高。传统评估假设 AI 每次执行路径相同：输入 X → 路径 Y → 输出 Z。但多智能体系统不是这样工作的。即使输入相同，agent 的行为路径也可能完全不同：可能一个搜索 3 个来源，另一个搜索 10 个；或者使用不同工具得出相同结果。
因此，我们通常不能仅通过"是否按照预设步骤执行"来判断对错，而是需要更灵活的评估方式：即 agent 是否达成了正确结果，且过程是否合理。
快速启动评估：从小规模样本开始
在早期 agent 开发阶段，一个 prompt 的小修改可能带来从 30% → 80% 的成功率跃升。因此，用少量示例也能看出变化趋势。我们起步使用了约 20 个查询样例，覆盖真实使用场景。与其等到有几百个测试用例再开始，不如立即用几个样例测试迭代。
使用 LLM 作为评估者（LLM-as-judge）
研究任务输出是自由文本，通常没有唯一标准答案，因此难以程序化评估。但 LLM 非常适合充当评估者。我们使用一个 LLM 评委，根据以下评分标准打分：
- factual accuracy（事实准确性）：内容是否与来源一致？
- citation accuracy（引用准确性）：引用是否对应正确主张？
- completeness（完整性）：是否覆盖了所有被请求的方面？
- source quality（来源质量）：是否优先使用权威来源而非低质量二手内容？
- tool efficiency（工具使用效率）：是否使用了正确的工具，调用次数合理？
我们曾尝试用多个 LLM 分别打不同维度，但发现"一个 prompt 输出 0.0-1.0 分数 + pass/fail 结果"更加稳定，也更接近人工判断。这种方法在 test case 有标准答案的情况下效果尤其好，比如"列出研发投入最多的三家医药公司"。
这种评估方式支持我们规模化地评估数百个结果。
人工评估发现自动方法无法捕捉的问题
人类测试者能发现一些自动化评估遗漏的问题，例如：
- 不常见查询中的幻觉回答
- 系统崩溃
- 来源选择偏差：如过度偏好 SEO 优化内容而忽视权威论文
我们发现 early agents 常常选择排名高但质量低的网页，而跳过了如学术 PDF、专家博客等高价值来源。通过 prompt 中增加"来源质量启发式"，我们解决了这个问题。
哪怕在有自动化评估的世界里，人工测试仍不可或缺。
多智能体的涌现行为与 Prompt 策略设计
多智能体系统中经常出现"涌现行为"------即小变动引发不可预测的大变化。例如，修改主 agent 的逻辑会导致 subagents 行为完全改变。
因此，最好的 prompt 并非"严格规则"，而是"协作框架"：
- 如何分工
- 如何处理问题
- 每个任务该投入多少 effort（token/calls/time）
成功的关键是：
- 精心设计的 prompt 与工具接口
- 高质量启发式
- 强 observability（可观测性）
- 快速迭代反馈回路
我们在 Cookbook 中开源了部分实际使用的 prompt，可供参考。
生产稳定性与工程挑战
传统软件出错常常是"功能失效"，但 agent 系统一旦出错，可能会改变整个任务路径，导致结果完全不同。这种错误是"复合型"的，非常难调试与恢复。
多智能体系统中常见的生产挑战
1. Agent 是有状态的，错误会累积传播
Agent 会跨多个工具调用保持状态运行。一旦某个环节出错，不能简单地"重启从头再来"------这会浪费大量 token，并让用户沮丧。
我们采用了以下策略：
- 允许系统"从中间恢复"
- 明确告知 agent 某个工具挂了，让它灵活调整
- 与此并行：构建了可靠的断点机制与 retry 机制
AI 的适应性 + 系统的确定性，共同实现了鲁棒性。
2. 调试方式必须与传统不同
由于 agent 是非确定性的（即便 prompt 相同，每次运行路径可能不同），调试非常难。
举例：用户说"agent 没找到明显信息"，但我们不知道：
- 是搜索语句写得烂？
- 是网页工具失效了？
- 是选择了劣质来源？
解决办法：
- 引入完整的 production tracing（包括 token 使用、tool 使用、subagent 创建等结构化日志）
- 在不监控内容的前提下，监控行为结构 → 实现隐私保护下的高级观测
3. 部署过程必须谨慎协调
Agent 系统像一张由 prompt、工具、执行逻辑组成的高状态网络。每次部署新版本时，系统中有些 agent 正在运行，不能统一强制升级。
我们使用 rainbow deployments：
- 渐进式流量迁移：新旧版本并行
- 避免中断已运行的 agent
4. 同步执行是瓶颈
目前的架构是：
- 主 agent 同步等待一批 subagent 返回结果
- Subagent 之间不协调
- 整个系统可能卡在某一个 subagent 上
虽然同步逻辑简单，但会成为性能瓶颈。理想情况下，我们希望异步执行：
- 主 agent 和 subagent 同时工作
- agent 能随时 spawn 新 agent
- 高并发下保持状态一致性、协调性、错误传播控制
我们预计未来模型能力增强后，这类异步架构将值得投入。
结语：从原型到生产，是"最后一公里"也是最难一程
构建 AI agent 系统，原型阶段只是开始。要做到真正的"生产可用"，工程复杂度会迅速飙升：
- 普通软件一个错误可能导致 5% 误差
- Agent 系统中，一个错误会让整个探索路径跑偏，最后输出完全错误答案
这就是为什么从 demo 到 product 往往是一道鸿沟。
尽管挑战重重，我们依然发现多智能体系统在开放式研究任务中极具价值。用户表示 Claude 帮他们：
- 发现了原本没考虑到的商业机会
- 导航复杂的医疗保险选项
- 解决难缠的技术问题
- 节省数日研究时间，挖掘到了自己独立难以发现的深层信息联系
这些系统的可靠运行，离不开：
- 严谨的 prompt 与工具设计
- 稳健的测试机制与可观测性
- 工程、产品与研究团队的密切协作
我们已经看到它们正在改变人们解决复杂问题的方式。
用户使用场景统计（Clio embedding plot）
目前 Claude Research 功能的主流使用场景包括：
- 构建专业领域的软件系统（10%）
- 开发优化技术/专业内容（8%）
- 业务增长与营收战略制定（8%）
- 学术研究与教育材料支持（7%）
- 信息验证（关于人物、地点、组织）（5%）
附录：一些多智能体系统的杂项技巧
1. 用"最终状态评估"而非"过程步骤评估"
在涉及多轮对话、状态变更的场景中，传统"逐步验证"的评估方式无效。我们采用：
- 聚焦最终输出是否符合预期
- 为复杂流程设置"checkpoints"判断是否在关键步骤完成了状态变更
- 允许多种路径达到同一个目标
2. 管理长对话（long-horizon conversation）
Agent 可能跨数百轮对话进行任务。需管理上下文爆炸问题：
- 用外部 memory 存储阶段性总结
- 超 context 限制后，用新的 agent 继续任务，并通过 memory 实现无缝衔接
这种"分布式上下文管理"确保长任务连贯性。
3. 用 artifact（产物）系统减少"电话游戏"效应
Subagent 的结果无需都通过主 agent 转发。例如：
- Subagent 直接调用工具把结果写入外部存储（如文件系统）
- 返回 lightweight 的 reference 给主 agent
- 特别适用于代码、报告、图表等结构化产出物
这提升了 fidelity 与性能。