一个研究问题经常包含几项可以分别调查的工作。例如，比较三种知识库方案，要查部署方式、权限规则和数据导出能力。单 Agent 可以依次完成；多 Agent 则可以分头取得材料，再整合成同一份比较。

真正增加难度的，是分工之后的连接：子任务怎样划分，哪些信息需要传递，结论怎样合并，以及谁判断调查已经充分。 多智能体研究需要设计的，正是这些协作关系。

结合 Anthropic 的多智能体研究系统，我把这些关系整理为三部分：

• 协作结构： 多 Agent 带来什么收益，Lead 与 Subagent 怎样配合。
• 任务执行： 怎样拆分和委派任务，怎样并行搜索并交回证据。
• 结果判断： 怎样汇总、补查和评估，什么情况下额外协调不值得。

下面用知识库方案比较作为简化例子，讨论机制，不涉及具体产品推荐。

一、多智能体研究怎样组织h2

研究型协作先要回答两个问题：分开探索有什么收益，整体任务由谁协调。

1. Multi-Agent：并行探索、上下文隔离与协调成本h3

并行探索：减少独立工作之间的排队

调查甲方案的部署文档，不必等到乙方案的权限说明查完。这类工作可以同时进行，最后再按同一标准比较。多 Agent 对宽范围研究有价值，首先因为任务存在多个可以独立推进的方向。

但“查得更多”与“答得更好”之间还隔着证据筛选和汇总。如果几个 Agent 都重复搜索同一份介绍，增加的是工作量，未必是覆盖范围。

独立上下文：把探索细节留在各自分支

一个研究方向会产生大量中间材料：读过的页面、未成功的查询、版本差异和暂时的假设。Subagent 可以在自己的 Context 中处理这些内容，再把关键发现交给 Lead。

这里增加的是系统的探索空间，而不是 Lead 的单次窗口。子任务输出经过筛选，主 Agent 才不必同时承担所有分支的阅读负担。这个收益延续了上下文隔离的思路。

专门职责：让不同分支采用合适的方法

部署研究需要看安装条件，权限研究需要核对规则，导出研究则需要确认格式和限制。不同分支可以有不同的搜索路线和关注点，不必让每次推理同时兼顾全部问题。

这些收益也有成本：重复背景、额外推理、工具调用、等待和汇总。我的判断依据是，拆分后能否产生有用且可整合的独立结果。范围很小的事实查询，或者每一步都依赖同一份最新判断的任务，未必值得增加协作。

2. Lead / Subagent：分配任务与汇总研究h3

这类架构把“总体安排”和“局部探索”分开：Lead 持有用户目标并组织研究，Subagent 接受子任务，在局部范围内自行决定搜索步骤。

Lead：负责计划、委派和整合

Lead 先把用户问题转化为比较标准，再决定分工。结果回来后，它检查覆盖是否完整、口径是否一致；必要时追加调查，材料充分后组织最终回答。

因此，Lead 的主要工作不是重复所有子任务，而是处理分支之间的关系。甲采用企业版文档、乙采用免费版文档，这种比较尺度不一致的问题，需要在总体层面发现。

Subagent：运行自己的搜索循环

Subagent 不只是一次模型调用。它可以先搜索资料，读到版本限制后换一个查询，发现证据不足后继续打开参考页面。它有局部目标，也有独立的 Tool Loop。

例如，权限分支读到“支持文档级权限”，还需要查明权限是否继承、是否能覆盖上层设置。停在一句概述上，尚未完成用户真正需要的调查。

Citation Agent：为报告定位引用

Anthropic 的实现还设置了 Citation Agent，在研究材料与报告形成后定位来源。这是该系统的角色安排，不是所有多 Agent 系统都必须拥有的组件。

它帮助把报告陈述对应到证据位置；事实范围仍需核对。例如“某版本支持”被写成“所有版本支持”，问题出在结论本身，添加链接不会自动修正它。

二、研究任务怎样分解、委派与汇总h2

从用户问题到最终报告，需要把任务边界、委派要求与证据交接连接起来。

3. Task Decomposition：按对象、主题与依赖划分工作h3

任务分解要同时满足两件事：局部可以推进，整体能够汇总。

知识库比较至少有两种拆法：

拆分方式	子任务负责什么	汇总时需要处理什么
按对象	每个 Agent 调查一家方案的全部指定能力	对齐字段、版本和解释尺度
按主题	分别调查部署、权限、导出，覆盖所有方案	将不同主题的发现合成各方案画像

按对象拆，分支容易形成完整的局部认识；按主题拆，则方便对某一维度深入调查。哪一种更合理，取决于资料怎样分布、哪些背景会被反复共享，以及子任务之间有多少依赖。

动态分解发生在看到当前任务和新证据以后。 如果某一家有两个部署版本，Lead 可以追加版本核对，而不必从一开始就为所有可能情况创建分支。这与固定并行和动态编排的区别是一致的。

任务数量也不是固定配置。一个只需查官方地址的问题，没有必要开出完整研究团队；某一分支已经证据充分，也不需要为了保持人数对称继续搜索。

我会用三个问题检查拆分：

• 子任务是否能在不持续等待其他分支的情况下产出结果？
• 返回结果是否直接服务于用户要求？
• 分支之间的重复背景和交接成本，是否小于独立探索的收益？

这三个问题比“应该开几个 Agent”更能解释分工的依据。

4. Delegation：明确子任务目标、范围与输出h3

角色名称只说明大致职责，委派还要提供执行这次任务所需的信息。对于研究型 Subagent，至少要讲清目标、范围、来源、输出和结束条件。

例如，下面的委派比“研究甲方案”更容易执行：

核实甲方案的部署方式、权限能力和导出限制。以官方文档为依据，记录适用版本。返回每项结论、关键限定、来源和未确认项；不调查价格，不替其他方案作比较。覆盖指定字段后返回，缺少公开证据的项目明确说明。

这段说明不是提前规定每条搜索命令，而是规定应该取得什么结果，以及不能把什么当作结果。Subagent 仍然可以根据新发现调整路线。

输入要足够，输出要可接续

如果用户只考虑私有部署，子任务就必须知道这个前提。否则它可能认真调查云服务，却没有回答当前任务。

输出也不能只有“支持”“不支持”。Lead 需要知道支持什么版本、有哪些限制，以及依据在哪里。输出约定的价值，是让下一位能够继续判断，而不是重新做一遍调查。

搜索指引要约束方法，不必穷举步骤

宽范围研究可以先找到资料入口，再逐步深入影响结论的细节。开始就使用很长、很具体的查询，可能在尚未认识资料结构时把搜索范围收得过窄。

工具也要匹配资料位置：公开产品文档可以通过网页搜索取得；内部记录则需要访问实际保存它们的系统。换关键词不能解决查错地方的问题。

提示改进要对应可观察的失败

几个分支反复查同一主题，应该检查任务边界；返回结果缺少版本，应该检查输出要求；已经证据充分却继续搜索，应该检查结束条件。

这些都是提示工程的具体对象。它改进的是任务理解与协作行为，不只是让语气更像“专业研究员”。

5. Parallel Search 与 Synthesis：并行取证与结果汇总h3

两层并行，处理不同位置的等待

Lead 同时启动多个 Subagents，是任务层的并行；Subagent 同时查询几份互不依赖的资料，是工具层的并行。

两者可以配合，但不能跳过前置依赖。需要先确定版本才能选择文档的操作，仍然应顺序执行。一个 Agent 也能并行调用工具，因此并行调用本身不等于多智能体协作。

证据交接：压缩细节，保留判断条件

“支持导出”如果实际只指文本，不含附件，省略限定就会改变结论。好的摘要应缩减搜索过程，而不是缩减事实适用范围。

较大的产物可以留在外部，回传可读取的引用；重要结论仍要带上来源与限定。这样既减少模型之间重复搬运，也保留了核查入口。

结果汇总：对齐、核查，再补查

Lead 首先对齐版本、时间和字段，再分析差异。结论冲突时，应回到来源找条件差异，而不是按多数决选答案。

如果乙的权限结果只有一段宣传介绍，Lead 可以追加一个窄任务：“核实文档权限与空间权限的继承关系。”这种补查直接针对缺口，不必重新调查整个产品。

补查也需要收敛：要求的字段已有依据或明确标注未知，关键矛盾已经处理，继续搜索不再改善判断，就可以形成回答。

Anthropic 当时的实现按批次等待子任务完成。这说明分支可以并行，汇总仍可能被慢分支阻塞。异步调度能改变等待方式，但不会消除结果一致性和交接问题。系统运行机制

三、多智能体研究的质量怎样评估h2

研究路线可以不同，仍然需要检查结果依据、协作过程和完成任务的代价。

6. Evaluation：检查报告质量、执行过程与成本h3

评估多 Agent，既要看回答，也要看取得回答的过程。搜索路径可能不同，不能仅因为步骤与参考流程不同就判错。

结果质量：用户要求是否被证据充分地回答

维度	知识库比较中怎样检查
准确性	能力和限制是否符合资料，版本是否一致
引用	来源是否支持对应陈述
覆盖	三个指定维度是否都得到处理
来源质量	是否使用具有直接依据的资料
不确定性	缺少证据的项目是否被如实标注

这里的完整，不是让所有格子都有肯定答案。明确哪些资料尚未公开，也是一项研究结果。

执行过程：协作在哪个环节失效

同样是漏掉导出限制，可能有三种原因：Lead 没有委派这项调查；Subagent 没找到资料；或者资料已经返回，却在汇总时丢失。

查看委派、工具结果和子任务输出，才能区分这三种情况。它们需要不同修改，不能都归结为“再强调一次完整性”。

LLM Judge 可以按照明确标准辅助检查报告，人工审阅则补充难以自动判断的来源偏差和解释问题。两者的作用都是提供反馈，而不是替系统作无条件的正确性保证。

成本：更快交付与更少消耗不是一回事

并行可能降低实际等待时间，同时增加总 token 和调用量。比较方案时，需要把质量、等待和总消耗放在一起，而不是只数运行了几个 Agent。

当分支高度依赖同一份状态、经常需要重新同步大量背景时，协调成本会迅速上升。这也是研究型协作不能直接推广为所有任务默认架构的原因。

几个关键问题，串起任务分工、证据与评估h2

多 Agent 的收益为什么不只是加速？

独立 Context 可以分担探索资料，不同职责可以集中处理不同问题。加速只是其中一项收益，证据覆盖与信息筛选同样重要。

怎样判断子任务划分是否合理？

看它能否相对独立地推进、是否返回整体需要的结果，以及交接成本是否可控。单纯把一个题目切成几句，并没有保证这些条件成立。

动态拆分与固定并行的区别是什么？

固定并行提前规定分工；动态拆分根据当前输入与新证据确定子任务。动态的是任务安排，不是取消目标和边界。

为什么委派必须约定输出？

因为结果要被另一个 Agent 使用。没有来源、版本和未确认项，Lead 很难区分事实、假设与遗漏，也无法可靠比较不同分支。

汇总为什么不能只是拼接摘要？

子任务通常只保证自己的局部范围。版本对齐、结论冲突和整体覆盖属于跨分支问题，需要在汇总时重新检查。

研究路径不固定，评估依据是什么？

以准确性、引用、覆盖和来源质量评价结果，以调用记录检查过程与成本。不同路径可以同样合格，但无依据的结论不会因为路径复杂而变得可靠。

独立 Context 能否解决多个 Agent 改同一项目的冲突？

不能。它隔离模型所见的信息，不自动隔离外部代码和业务状态。共享项目还需要任务认领、版本同步和集成验证。

参考资料h2

• Anthropic · How we built our multi-agent research system