企业准备把资料调研助手升级成多智能体系统，通常先想到增加角色：市场分析 Agent、技术分析 Agent、报告 Agent。真正接入工作后，却可能出现三个问题：大家搜索同一批材料，汇总时丢失证据，一个子任务卡住后整份报告迟迟无法交付。
角色名称不能解决这些问题。系统需要明确谁负责拆任务、每个子任务拿到什么上下文、结果如何汇合，以及何时停止继续搜索。
本文以 Anthropic 公开的研究型多智能体架构为入口，讨论企业实现时的任务契约、记忆范围和协作验收。文中的配置与状态设计是工程建议，不是 Anthropic 内部源码。
一、先区分公开机制和架构类比
Anthropic 在2025年6月13日发布的工程说明中，采用由 Lead Agent 协调、子智能体分头研究的模式。Lead Agent 保存计划，子智能体独立探索并返回结果，主智能体再判断是否需要补充研究；引用环节负责将报告内容对应到来源位置。
当时的说明同时指出，子智能体按批次同步等待仍会形成瓶颈，异步协调涉及额外的一致性与错误传播问题。这里讨论的是该公开说明所描述的系统，不能当成今天所有 Claude 产品的统一实现。Anthropic 原始工程说明
读图时还应注意两点：
- 把用户、记忆、工具入口、报告交付等列成九个环节，不代表系统固定运行九个 Agent。
- 计划持久化与结果共享，不代表每个 Agent 实时读写同一份完整上下文。
下面把这些机制转成企业可以自行验证的实现设计。
二、什么任务值得拆成多个 Agent
先画依赖关系，再决定并行度。比如研究三个产品的公开部署要求，可以按产品分头收集；但要对一份刚生成的候选清单做核验，必须先拿到清单，不能假装这两步相互独立。
一个实用的判断表是：
| 任务特征 | 建议起点 | 原因 |
|---|---|---|
| 单一事实查询、来源明确 | 单个 Agent 或直接查询 | 协调成本可能超过收益 |
| 多个相对独立的信息分支 | 少量并行子任务 | 可分别收集证据再汇总 |
| 每一步都依赖上一轮结果 | 顺序工作流 | 并行不能消除真实依赖 |
| 多个角色同时修改同一对象 | 先设计写入协调 | 否则容易覆盖或重复执行 |
| 需求本身尚不明确 | 先澄清交付标准 | 拆得更细不会自动消除歧义 |
不要用报告字数决定 Agent 数量。更有用的问题是：这些工作能否独立产生有价值的结果，汇总时需要交换多少信息，失败时能否单独恢复？
三、Lead Agent 应维护一份任务契约
Lead Agent 不应只把"研究一下产品A"转发出去。每个子任务至少需要目标、范围、可用来源、输出格式、预算和停止条件。
下面是面向企业调研助手的字段示例：
yaml
task_id: product_a_deployment
objective: 收集产品A的企业部署要求
scope:
include: [部署方式, 数据存储位置, 身份集成]
exclude: [营销口号, 未证实的性能比较]
sources: 优先官方技术文档
output:
- finding
- evidence_ref
- observed_at
- unresolved_questions
limits:
max_tool_calls: 8
deadline_seconds: 180
stop_when: 覆盖必需字段，或明确记录无法确认的项目其中8次调用和180秒只是演示值，需要按任务成本和工具延迟调整，不是通用最佳实践。
拆分完成后，Lead Agent 还要维护覆盖表：哪些问题已经分配，哪些仍有空白，哪些成果互相依赖。这样才能避免两个子任务各做一半，却没有任何一个人负责剩下的关键问题。
主智能体也不应因为需要完整报告，就自动获得所有业务系统的权限。协调职责与数据授权是两件事。
四、共享记忆可以怎样分层
"共享记忆"最好拆成三类明确的数据：
| 类型 | 建议保存什么 | 谁负责修改 |
|---|---|---|
| 全局计划与任务目录 | 目标、子任务状态、依赖和停止条件 | 协调器维护 |
| 子任务工作状态 | 已查来源、局部假设、待核问题 | 对应子任务维护 |
| 成果与证据索引 | 已提交结果、来源片段、版本和冲突 | 按提交规则写入，汇总方核验 |
不必把全部搜索历史广播给所有 Agent。子任务通常只需要与其目标有关的背景，汇总方则需要结论、证据和未解决问题。
如果希望多个 Agent 共享某个结论，建议保存带版本的记录，而不是直接覆盖一段自由文本：
json
{
"task_id": "product_a_deployment",
"result_version": 2,
"status": "partial",
"finding": "某项部署条件仍待确认",
"evidence_refs": ["doc_a#section_2"],
"unresolved_questions": ["是否适用于目标地区"]
}这里的 doc_a#section_2 是示例证据标识。实际系统应能据此取回对应材料，并验证访问权限。
同一事项出现冲突时，保留两份证据和各自适用范围，再交给明确的合并规则或复核环节处理。最后写入的记录不一定更准确。
记忆还能用于中断恢复，但恢复的是任务进度与证据，不是保证模型会重走完全相同的推理路径。
五、并行协作要同时处理五个问题
1. 先消除重复任务，再增加并发
按产品、区域、时间范围或证据类型分工，通常比给几个 Agent 同一句"大范围调研"更容易验收。
允许有限交叉核验，但应明确这是故意安排的复核工作。否则重复搜索只会增加成本，并使相同来源看起来像多个独立证据。
2. 用结构化结果交接，保留原始成果引用
返回值至少包含发现、来源、适用范围和未知项。长表格或完整报告可以存成独立成果，向协调器传递引用与摘要。
汇总时发现关键结论需要细节，应回读原始成果。连续多轮摘要容易丢失限定条件，不能只凭一句二手概括判断事实是否成立。
3. 明确等待、超时与降级策略
建议把子任务状态区分为 queued、running、completed、partial、failed。部分完成不应伪装成完全成功，超时也不意味着没有任何可用成果。
对于可以独立交付的分支，可以先汇总已完成结果并标记缺口；对必要依赖，则应等待、有限重试或停止交付。不能为了让流程显示绿色，就省略关键证据。
若增加异步执行，还要规定取消信号如何传播、旧结果是否仍被接受，以及已经结束的任务如何拒绝迟到写入。
4. 对工具调用实施实际约束
工具说明负责让 Agent 理解接口，执行服务负责检查授权和参数。即使通过 MCP 等标准化方式连接，权限、数据范围和调用审计仍需要由具体系统实现。
查询失败时应返回可区分的原因，例如权限不足、目标不存在或服务暂不可用。把所有错误都返回空列表，会让 Agent 把工具故障误判成"没有相关信息"。
5. 给系统设置总预算和停止条件
子任务各自没有超限，不代表整体成本可接受。还应控制总调用量、并发数和墙钟时间，防止主智能体不断创建新分支。
停止条件可以是必需问题已覆盖、关键证据已达到要求，或者预算耗尽且剩余问题明确标注。最终交付应说明证据缺口，不能靠继续生成文字填满结构。
六、引用层应该验证什么
为一句话添加链接，与证明这句话正确之间还有距离。引用检查至少需要回答：
- 链接指向的材料是否真实存在，是否能够读取？
- 材料的具体片段是否支持对应结论？
- 时间、地区、版本和样本范围是否一致？
- 汇总过程是否把条件句改成了确定事实？
- 多个来源是否实际上转述同一份材料？
例如，来源只说"支持一种部署方式"，报告却写成"所有客户都能使用"，即使附上正确链接，结论仍然越出了证据范围。
引用环节可以辅助检查，但不能保证消除全部事实错误。对于缺少公开证据的项目，应保留"未能确认"；对于冲突证据，应展示冲突和适用范围。
七、验收整套协作，而不只看最终报告
建议保留一个单 Agent 基线，再用相同任务集比较多智能体方案。避免仅凭某次成功演示宣布架构更好。
| 验收维度 | 重点观察 |
|---|---|
| 覆盖度 | 必需问题是否全部回答或明确标记未知 |
| 证据质量 | 关键结论是否由可回查材料支持 |
| 协作效率 | 重复搜索、重复成果和无效等待 |
| 恢复能力 | 中断后是否能接续，是否出现重复写入 |
| 资源消耗 | 总成本、总延迟与尾部慢任务 |
| 边界控制 | 越权请求是否拒绝，取消后是否停止执行 |
测试样本应包含子任务超时、来源冲突、权限不足和部分完成。评估重点是结果与过程是否达到要求，不必强制每一次执行都使用完全相同的搜索顺序。
企业采用这类架构，可以先从一个协调器和少量独立子任务开始。只有当并行带来的覆盖或效率收益超过协调成本时，再扩展角色与任务数量。
Runwise 对Anthropic多智能体研究系统的角色与协作流程拆解提供了理解入口。本文将其进一步转为任务契约、记忆分层、并行故障处理与验收设计，供企业技术团队按自己的场景验证。