Multi-Agent Research System：什么时候值得拆多个 Agent

原文：Multi-agent research system

我读这篇时真正关心的问题

读这篇文章之前，我脑子里其实一直卡着一个问题：

Multi-agent 到底什么时候是必要的，什么时候只是把系统搞复杂？

这个问题不是凭空来的。前面读 Don't Build Multi-Agents 的时候，我更强烈地感受到 multi-agent 的危险：多个 agent 不是简单并行，而是多个隐形决策中心。它们会在不同上下文里补全未知部分，最后产出几套局部世界观。

所以我再读 Anthropic 这篇文章时，关注点就变成了：

• Anthropic 为什么在 research 场景下选择 multi-agent？
• 这个系统里不同 agent 的分工、通信和控制方式是什么？
• 它解决的问题是否足以抵消 multi-agent 的复杂度？
• 它和 “Don't Build Multi-Agents” 的观点到底冲突不冲突？

读完之后，我现在更愿意这样理解：

multi-agent 不是默认更高级的架构，
而是某些高价值、宽搜索、可拆分任务里的资源扩展方式。

它不是为了省 token，也不是为了让系统看起来更像“组织”。相反，它通常会花更多 token、更多工具调用、更多工程设计，去换更大的搜索覆盖面和更高质量的综合结果。

一句话结论

这篇文章给我的核心判断是：

Multi-agent 的价值来自多个独立上下文窗口、多条工具调用路径和多轮动态决策；它适合高价值、可并行、边界清楚的研究任务，不适合边界模糊、强依赖、低价值的小任务。

如果一个任务需要所有 agent 共享完整上下文，需要频繁实时协作，或者子任务边界本身就说不清楚，那拆 agent 大概率不是提效，而是在制造协调成本。

所以真正重要的问题不是：

能不能拆成多个 agent？

而是：

任务是否值得拆？
边界是否清楚？
输出是否可验证？
错误是否能回收？
成本是否能接受？

1. Multi-agent 解决的不是“更聪明”，而是“宽搜索”

Anthropic 这篇文章里，multi-agent 的主要场景是 research。

Research task 有几个特点：

• 问题是开放式的，很难提前写死完整流程。
• 研究过程依赖中间发现，后续方向会被前面结果改变。
• 信息空间很大，需要持续检索、筛选、判断和压缩。
• 单个 agent 的上下文窗口、工具调用路径和搜索速度都会成为瓶颈。

这里的 subagent 不是简单检索器，也不是机械摘要器。它更像一个可调度的小型决策单元，在自己的边界内搜索、判断、取舍和提炼，最后把高密度结果交还给 lead agent。

文章里有一个我觉得很关键的理解：搜索本身就是压缩。

从巨大信息空间里找资料，不只是“拿回来更多内容”。真正有价值的是：

检索 -> 判断 -> 取舍 -> 提炼 -> 压缩成主 agent 可用的信息

所以 research 系统里的 subagent 做的不是把网页搬回来，而是把一个研究方向里的信息密度提高。

2. 什么时候适合 multi-agent？

这篇文章让我把适用边界整理得更清楚了。

适合 multi-agent 的任务，一般有这些特征：

• 高价值，结果质量值得付出更高 token 成本。
• 宽搜索，需要同时探索多个相对独立的方向。
• 子任务边界清楚，可以相对独立执行。
• 信息量超过单个上下文窗口。
• 需要大量工具调用或复杂外部信息源。
• 后续方向会被中间发现动态改变。

不适合 multi-agent 的任务也很明确：

• 简单事实查询。
• 低价值小任务。
• 需要所有 agent 共享同一完整上下文的任务。
• 子任务之间依赖很多，需要频繁实时协作。
• 边界模糊，拆完之后每个 agent 都要自己猜上下文。

这其实和 “Don't Build Multi-Agents” 并不冲突。

Cognition 那篇文章提醒的是：不要在没有统一上下文、没有清晰边界、没有回收验证机制的情况下，让多个 agent 并行变成多个隐形决策中心。

Anthropic 这篇文章说的是：在 research 这种高价值、宽搜索、可拆分任务中，如果你把边界、预算、工具、停止条件和验收机制设计清楚，multi-agent 可以扩大搜索覆盖面。

所以两篇文章合起来看，结论反而更完整：

不要为了拆而拆。
如果要拆，先设计边界、预算、验收和回收机制。

3. 它不是省 token，而是用成本换覆盖面

我一开始很容易把 multi-agent 想成“并行之后更省时间、更高效”。但这篇文章把一个事实说得很直接：

Multi-agent 通常不是省 token 的方案。

文章提到，agents 通常比 chat 多约 4 倍 token，multi-agent systems 比 chat 多约 15 倍 token。

这个数字不一定能直接套到所有项目里，但方向很明确：multi-agent 的经济性是核心边界。

它的优势主要体现在三类资源扩展上：

• 上下文扩展：多个 agents 拥有独立上下文窗口，可以把研究任务分散到多个上下文里并行处理。
• 工具调用扩展：多个 agents 可以并行调用搜索、数据库、内部系统等工具，扩大覆盖面。
• 模型组合扩展：lead agent 可以使用更强模型负责规划和综合，subagents 可以使用更适合探索或成本更低的模型执行局部任务。

但代价也很直接：

• token 消耗显著增加。
• 工具调用更多，成本和延迟更难控制。
• 协调复杂度上升。
• 需要设计任务边界、停止条件、验收机制和状态管理。
• 如果任务无法拆分，会制造重复工作和上下文混乱。

我现在会把它理解成一个交换：

用更多 token、更多并行工具调用、更多工程约束，
换取更大的搜索覆盖面和更高质量的综合结果。

这句话很重要，因为它能防止我把 multi-agent 当成默认优化。

4. Research 架构：orchestrator-worker，不是群聊

Anthropic Research 使用的是比较典型的 orchestrator-worker 架构：

• Lead Agent：分析用户问题，制定研究策略，拆分任务，创建 subagents，回收结果并综合。
• Subagents：在各自边界内独立搜索、评估、筛选、压缩信息。
• Citation Agent：最后处理 claim 和 source 的对应关系，确保结论有引用支撑。

这个架构的重点不是“多个 agent 聊天”，而是一个动态研究循环：

1. 用户提交 query。
2. Lead Agent 分析问题并形成初步策略。
3. Lead Agent 将问题拆成多个边界清楚的研究方向。
4. 多个 subagents 并行执行搜索和信息处理。
5. Subagents 返回结构化、高密度结果。
6. Lead Agent 判断是否需要继续研究。
7. 必要时继续创建 subagents 或调整策略。
8. 信息足够后进入综合，并交给 Citation Agent 做引用校验。

这里的关键是 multi-step search。

系统不是一次性取回材料后直接生成答案，而是在每一步根据已有发现决定下一步要查什么、是否需要新 subagent、是否需要换工具、是否已经足够。

5. 它和传统 RAG 的区别

这里不能简单说“RAG vs multi-agent”。它们不是两个并列替代品。

更准确地说：

• 传统 RAG 更像单轮静态检索。
• Agentic research 把检索变成多轮动态动作。
• Multi-agent 架构进一步把多个动态检索方向分散给不同 subagents 并行执行。
• Subagent 内部仍然可以使用 RAG、搜索工具、数据库、Slack、Google Workspace 等 retrieval 能力。

传统 RAG 的流程更像：

用户问题 -> 找相似 chunks -> 生成答案

Agentic research 更像：

用户问题
-> 判断研究方向
-> 搜索
-> 根据中间发现调整问题
-> 换关键词 / 换工具 / 开新分支
-> 判断是否足够
-> 综合

所以 multi-agent 不是简单替代 RAG，而是把 RAG、搜索和工具调用放进 agent 的动态规划循环里，让它们成为可以反复决策、调度和组合的动作。

6. Prompt engineering 在这里不是“写漂亮提示词”

这篇文章里 prompt engineering 的重点，不是写一句看起来很聪明的提示词，而是把系统行为变得更可控。

它要处理的是：

• 资源预算。
• 任务边界。
• 工具选择。
• 搜索策略。
• 输出格式。
• 停止条件。
• 验收标准。
• 失败复盘机制。

建立 agent 行为的心智模型

工程师需要观察 agent 的真实执行轨迹，而不是只看最终答案。

要看的是：

• 它为什么选择某个工具？
• 它为什么写出这种搜索 query？
• 它为什么继续搜索？
• 它为什么提前停止？
• 它是否重复搜索？
• 它是否误选工具？
• 它是否过度发散？

本质上，是通过可观测性建立可预测性，再用失败轨迹迭代 prompt。

教会 orchestrator 怎么派活

Lead Agent 不能只给 subagent 一个模糊任务，比如“研究半导体短缺”。它必须明确分配：

• 目标是什么。
• 任务边界是什么。
• 和其他 subagents 的边界如何避免重复。
• 应该使用哪些工具或信息源。
• 输出格式是什么。
• 需要交付什么证据、结论、gap 或置信度。

完整链路不只是“分配任务”，而是：

分配任务
-> 子任务执行
-> 结构化返回
-> Lead Agent 验收结果
-> 判断是否补查或进入综合

根据问题复杂度分配 effort

资源分配规则应该写进 Lead Agent 的 system / developer prompt 中，因为 Lead Agent 负责判断任务复杂度和预算。

资源预算主要有两个维度：

• 开几个 subagents。
• 每个 subagent 允许或期望多少次工具调用。

原文给出的量级是：

• 简单事实查询：1 个 agent，3 到 10 次工具调用。
• 直接比较类任务：2 到 4 个 subagents，每个 10 到 15 次工具调用。
• 复杂研究任务：10+ 个 subagents，并且职责清楚地划分。

这些数字不是通用规范。真正落地时，还是要根据项目成本、延迟要求、模型能力、工具质量和历史数据持续调整。

工具描述要有 affordance

工具是 agent 接触外部世界的接口。工具描述写差了，agent 很容易走错方向。

工具、skills、MCP server、subagent 能力说明，本质上都需要清晰的 affordance。也就是让 agent 能自解释地理解：

• 这个能力解决什么问题。
• 什么时候应该使用。
• 什么时候不该使用。
• 输入输出格式是什么。
• 和相似工具的区别是什么。
• 数据来源和限制是什么。

工具描述的目标不是让人觉得完整，而是让 agent 能快速判断：

为什么调用？
怎么调用？
调用后会得到什么？

先宽后窄

研究型搜索应该先宽后窄。

Agent 常见失败是上来就写过长、过具体的 query，导致结果过少，或者被早期假设锁死。

更合理的策略是：

1. 先用短而宽的 query 探索全局。
2. 观察有哪些方向、实体、关键词和来源。
3. 再逐步缩小范围，深入关键分支。
4. 最后压缩成主任务真正需要的信息。

并行不只发生在 lead agent 层

并行有两层：

• Lead Agent 并行启动多个 subagents。
• 每个 subagent 内部也可以并行调用多个工具。

前者解决“怎么分工”，后者解决“分工后怎么执行”。没有并行执行，multi-agent 的搜索覆盖和速度优势会被削弱。

7. Eval 的基础不是 judge，而是 trace

Multi-agent 系统不能只按固定路径评估，因为它的执行路径本身是动态生成的。

传统软件或简单 workflow 更容易写成：

输入 X -> 按固定步骤 Y 执行 -> 期待输出 Z

但 multi-agent research 中，同一个问题可能出现不同的合理路径：

• 这次开 3 个 subagents，下次开 5 个。
• 这次先查网页，下次先查内部文档。
• 这次某个 subagent 深挖行业背景，下次另一个 subagent 先做竞品比较。
• 工具调用顺序、搜索 query、引用来源都可能不同。

因此，评估重点要从“是否走了固定步骤”转向两类判断：

• 能力评估：最终答案是否正确、完整、有引用支撑、满足用户意图。
• 过程评估：执行过程是否合理，比如边界是否合理、工具是否用对、是否重复搜索、是否遗漏关键分支、是否浪费 token。

LLM-as-judge 在这里有用，但它不能凭空判断。

如果系统包含 memory、subagent 输出和复杂工具调用，judge 不能只看最终答案。实际落地时，通常需要把一次运行的日志或快照整理成评估包，再交给 judge。

评估包可能包括：

• 用户原始问题。
• 相关 memory 或上下文摘要。
• Agent 最终答案。
• 引用来源或 source snippets。
• Subagent 输出摘要。
• 工具调用轨迹摘要。
• 成本、耗时、错误和重试情况。
• 明确评分标准。

所以我现在更愿意这样记：

Trace 记录发生了什么。
Eval 判断做得好不好。
Judge 只是 eval 的一种执行方式。

没有 trace，eval 很难评估过程；没有结构化评估包，LLM judge 也只能凭感觉打分。

人工评估仍然必要。它更容易发现自动评估漏掉的边缘 case、任务理解偏离、来源质量偏差、看似合理但实际不可靠的研究路径，以及 prompt 或工具描述导致的隐性失败模式。

8. 生产可靠性：模型适应性 + 工程兜底

从原型到生产，agent 系统的难点不只是模型能力，而是长期运行、有状态、非确定性、工具依赖和部署协调。

传统软件中的 bug 可能是接口报错、功能不可用或性能下降。Agent 系统中的小问题更容易演变成行为偏移。一次工具失败、一次错误搜索、一次错误摘要，都可能污染后续上下文，让 agent 走向完全不同的轨迹。

Agent 是有状态的，错误会累积

Research agent 可能运行很久，跨越很多次工具调用和多个 subagents。它的状态包括：

• 用户目标。
• 当前 plan。
• 已发现信息。
• Subagent 返回结果。
• Memory 和上下文摘要。
• 未解决的问题。
• 已经发生的错误或重试。

因此，失败后不能简单从头重跑。从头重跑成本高、耗时长，也可能因为非确定性得到另一条不同路径。

生产系统需要：

• checkpoint：定期保存运行状态。
• resume：失败后从中断点继续。
• retry logic：对工具失败或临时错误做确定性重试。
• error reporting：把工具失败明确告诉 agent，让它调整策略。
• state persistence：把 plan、发现、来源、gap 等持久化。

这里的可靠性不是只靠 agent 自我修复，而是：

模型适应性 + 工程兜底

模型可以在工具失败时调整策略，但系统必须有 checkpoint、resume、retry 这类确定性机制。

需要停止条件和验收标准

如果没有停止条件，multi-agent 会一直搜索。

比较清晰的停止条件包括：

• 目标已满足。
• 信息已经重复。
• Subagent 越界。
• 来源足够。
• 继续工具调用的边际收益很低。
• 剩余 gap 可以明确声明。

Lead Agent 也需要验收 subagent 输出：

• 是否回答了分配问题？
• 是否遵守边界？
• 是否有来源？
• 是否和其他结果冲突？
• 是否需要补查？

如果没有这一步，subagent 的错误会被直接综合进最终答案。

Tracing 是调试入口

Agent 调试不能只看最终答案。

用户可能只报告“它没找到明显信息”，但真正原因可能是：

• 搜索 query 写差了。
• 选错工具。
• 工具失败。
• 来源质量差。
• Subagent 重复劳动。
• Lead Agent 综合时丢失信息。
• Citation Agent 引用对齐错误。

所以生产系统需要 full production tracing，记录 agent 的关键决策和执行轨迹。

文章还提到高层级 observability：监控 agent 的决策模式和交互结构，而不是直接查看用户会话内容，以兼顾隐私和诊断能力。

部署需要版本隔离和渐进切换

Agent 系统是由 prompts、tools、execution logic、memory、checkpoint schema 等组成的有状态网络。

部署新版本时，正在运行的 agents 可能处于不同阶段：

• 有的刚完成 planning。
• 有的已经创建了 subagents。
• 有的正在等待工具返回。
• 有的已经保存了旧 checkpoint。

如果强行把所有运行中任务切到新版本，可能出现：

• 旧 checkpoint 新代码读不懂。
• 旧 subagent prompt 和新 lead agent 协议不一致。
• 工具 schema 改了，旧 agent 解析失败。
• 正在运行的任务被新逻辑破坏。

Anthropic 提到使用 rainbow deployments。我的理解是：

新任务慢慢走新版本，老任务不要半路切换系统。

这句话对 agent 系统尤其重要，因为它不是无状态请求，而是可能已经跑了很久的动态过程。

9. 同步 subagents 和异步协调

文章说当前 lead agents 执行 subagents 是同步的：Lead Agent 开一批 subagents，等待这一批全部完成，再综合并进入下一步。

同步方式的优点是协调简单，状态一致性更容易维护。瓶颈是：

• 一个慢 subagent 会卡住整批结果。
• Lead Agent 不能根据早返回的信息立即调整方向。
• Subagents 之间也不能互相协调。

异步执行可以让 agents 并发工作，并在需要时动态创建新 subagents，理论上能提升信息流动速度。

但它会带来结果协调、状态一致性、错误传播等复杂问题。

所以我现在不会把“异步 multi-agent”理解成天然更高级。它更像下一层复杂度：能力更强，但状态管理和错误传播也更难。

10. 我沉淀下来的可复用原则

最后把这篇文章压缩成一些我之后做 agent 系统时会反复检查的问题。

先判断是否真的适合 multi-agent

任务需要同时满足几个条件：

• 高价值。
• 宽搜索。
• 可拆分。
• 边界明确。
• 工具调用多。
• 输出可以验收。

如果这些条件不成立，先别拆。

Subagent 任务必须有契约

一个 subagent 任务至少要说清楚：

• 目标。
• 边界。
• 工具建议。
• 输出格式。
• 来源要求。
• gap 和置信度。
• 停止条件。

否则它不是 specialist，而是一个在局部上下文里自行脑补的决策中心。

Lead Agent 要负责预算和验收

Lead Agent 不只是派活，还要负责：

• 根据复杂度决定 subagent 数量。
• 设定工具调用预算。
• 检查 subagent 是否越界。
• 判断结果是否冲突。
• 决定是否补查。
• 最后综合和取舍。

工具描述也是系统设计

工具描述要有自解释性：

• 用途。
• 适用场景。
• 不适用场景。
• 输入输出。
• 数据限制。
• 和相似工具的区别。

Agent 能不能用好工具，很大程度上取决于它是否能理解工具的 affordance。

Eval 要同时看结果和过程

只看最终答案不够。

要看：

• 最终答案是否正确、完整、有来源。
• 执行过程是否合理。
• 工具是否用对。
• 搜索是否重复。
• subagent 边界是否清楚。
• token 是否浪费。
• 是否有遗漏的关键分支。

生产系统需要工程兜底

Multi-agent research 不是一个 prompt 就能上线。

它需要：

• checkpoint。
• resume。
• retry。
• tracing。
• eval packet。
• 版本隔离。
• 渐进部署。
• 高层级 observability。

我现在越来越觉得，agent 工程里最容易被低估的，不是“模型能不能想明白”，而是：

系统能不能在模型想歪、工具失败、上下文变长、版本更新时，把过程稳住。

最后：它和其他几篇文章的关系

这篇文章更像补上了 multi-agent 的正面案例：在 research 这种宽搜索场景里，拆多个 agent 是有意义的。

但它并没有推翻 Don't Build Multi-Agents。反而让我更确定：multi-agent 的关键不是“多个”，而是多出来之后的治理。

如果和 Building Effective Agents、Effective Context Engineering for AI Agents 放在一起看，我会把这几篇文章串成一条线：

Building Effective Agents:
先理解最小智能单元、workflow、agent 和工具边界。

Effective Context Engineering:
再理解 context 不是越多越好，而是要被选择、压缩、组织和约束。

Don't Build Multi-Agents:
然后意识到多个 agent 会制造多个隐形决策中心。

Multi-Agent Research System:
最后看到在高价值宽搜索场景里，multi-agent 如何通过边界、预算、trace、eval 和可靠性工程被治理起来。

所以我最后记住的不是“要不要用 multi-agent”，而是：

Multi-agent 是一种昂贵但有用的搜索扩展方式。只有当任务值得、边界清楚、过程可观察、结果可验收时，它才真的成立。