我们如何构建多 agent 研究系统

导读

这篇文章介绍 Claude Research 背后的 production multi-agent architecture：一个 lead research agent 负责计划、拆分和综合，多个 subagents 并行搜索，最后由 citation agent 将结论对齐到来源。

说明：本文按 Agent Learning 的中文阅读页格式，对原文结构与关键技术细节做逐节中文转述与解读；为避免整篇镜像转载，正文保留原文章节脉络、关键数字和术语，但不做逐字复刻。

核心观点

• 系统采用 orchestrator-worker 架构：lead agent 协调 specialized subagents 并行搜索。
• 在 Anthropic 内部 research eval 中，多 agent research 相比 single-agent Claude Opus 4 提升 90.2%。
• BrowseComp 分析中，token usage 解释了 80% 的 performance variance；token usage、tool calls 和 model choice 合计解释 95%。
• agents 通常使用约 4x chat token，multi-agent systems 约 15x chat token。
• 多 agent 最适合高价值、强并行、信息超过一个 context window、工具复杂的任务。
• lead agent 计划、写 Memory、创建 subagents、审查结果，并决定是否继续研究。
• citation agent 将最终 claims 映射回 source locations。
• 生产可靠性需要 checkpoints、tracing、restart/resume、deterministic retry 和不中断运行 agent 的部署策略。

正文

为什么开放研究适合多 agent

开放式 research 的路径高度依赖早期发现。一个线索会引出另一个线索，过早选择单一路径可能漏掉关键来源。

单 agent 的瓶颈是搜索广度和 context window。它可以深入一条线索，但很难同时保留多个方向的细节。

多 agent 架构用额外 token 换并行探索：subagents 各自搜索不同方向，lead agent 再综合证据。

orchestrator-worker 架构

系统核心是 lead research agent。它理解用户问题、制定计划、把中间状态写入 Memory、创建 subagents，并根据结果决定是否继续研究。

subagents 负责并行搜索、阅读来源、提取证据和返回局部结论。它们拥有独立 context window，因此不会互相污染，也能在各自方向上深入。

最终还有 citation agent，把报告中的具体 claim 映射回 source locations，降低长报告中引用漂移或无来源断言的风险。

性能与成本信号

文章给出几个重要数字：多 agent research 在内部 eval 中相比 single-agent Claude Opus 4 提升 90.2%。这说明开放研究任务确实受益于并行探索和更大 context 总量。

但成本也明显上升。agents 通常用约 4x chat token，multi-agent systems 约 15x chat token。BrowseComp 分析中，token usage 解释了 80% 的 performance variance；token usage、tool calls、model choice 合计解释 95%。

这些数字共同说明：多 agent 的优势很大程度来自投入更多 search effort。它适合高价值任务，不适合所有查询默认开启。

早期失败与 prompt 策略

早期系统会过度 spawn subagents、无休止搜索、重复工作、写过长查询，或者选择不合适工具。这些不是模型单点问题，而是 delegation policy 不清晰。

prompting 需要教 lead agent 如何分工、如何按 query complexity 调整 effort、如何先 broad 再 narrow，以及如何用 thinking scratchpad 记录计划。

多 agent 成败不在于能不能创建 subagent，而在于 lead 是否知道什么时候创建、创建几个、如何合并、何时停止。

生产可靠性

长时间运行的多 agent 系统必须支持 checkpoints、tracing、restart/resume 和 deterministic retry。否则一次子任务失败或部署更新就可能破坏整个 research session。

部署策略也要保护正在运行的 agents。产品系统不能假设所有 agent 都是短请求；它们可能运行很久，拥有中间状态和未完成工作。

这使 multi-agent research 同时是模型问题、harness 问题和分布式系统问题。

深度解读

多 agent research 的核心不是“agent 越多越聪明”，而是用并行 context 和额外 token 扩展搜索空间。它把研究任务拆成可并发探索的方向，再通过 lead agent 和 citation agent 收敛。真正稀缺的是 orchestration：如何决定 effort、避免重复、控制成本、验证引用、保存中间状态。对工程团队来说，多 agent 架构只有在任务价值足以支付 15x token 级别成本时才合理；否则它会把复杂度和账单一起放大。

落地启示

• 只在高价值、强并行、信息分散的任务上使用多 agent。
• 让 lead agent 明确 delegation 策略、预算和停止条件。
• 为 subagents 分配不同搜索方向，避免重复工作。
• 引入 citation pass，把最终 claim 对齐到来源位置。
• 保留 trace、Memory 和 checkpoints，支持长任务恢复与复盘。