Anthropic 多 Agent 协作系统解读：从并行研究到共享代码库与 PPT Master 的适用边界

原文一：How we built our multi-agent research system

原文二：Building a C compiler with a team of parallel Claudes

实践项目：PPT Master

前置阅读：《Building effective agents》系统解读 · 《Effective harnesses for long-running agents》系统解读

“多 Agent”很容易被理解成一个简单结论：既然多个 Agent 可以同时工作，就应该尽可能并行。

Anthropic 的两篇文章恰好说明事情没有这么简单。Research 系统让一个 lead agent 把开放问题分给多个搜索 subagent；C 编译器实验则让多个 Claude Code 实例在共享代码库里长期工作。两者都使用并行，却有完全不同的任务结构、状态模型和验证方式。

把它们放在一起学习，真正值得提炼的不是“如何多开几个 Agent”，而是下面五个问题：

1. 工作是否真的可以并行；
2. 子任务之间有多少依赖；
3. 多个 Agent 是否会修改同一份状态；
4. 环境能否持续给出可靠反馈；
5. 协调成本是否低于并行收益。

本文按这五个维度建立适用边界，再用 PPT Master 的三个现行场景检验：为什么事实研究只使用一个隔离 worker，为什么视觉审查可以条件式并行，以及为什么核心页面生成仍然必须串行。

一、两篇文章讨论的不是同一种多 Agent 系统

先看两套架构的基本差异。

维度	Multi-agent Research	Parallel Claudes C Compiler
任务	开放式信息检索与综合	长周期共享代码库开发
拓扑	lead agent 编排多个 subagent，最后还有 CitationAgent	多个对等 Agent 通过 Git、任务锁和测试环境协作
子任务	通常按主题、来源或问题分面拆分	按失败测试、模块、性能、文档等工作项拆分
共享状态	subagent 主要拥有独立上下文，结果返回 lead agent	所有 Agent 最终修改同一个代码库
冲突来源	重复搜索、遗漏分面、错误工具选择、结果不完整	抢同一任务、合并冲突、回归、相互覆盖修改
验证	来源质量、事实准确、引用、完整性、工具效率	编译器测试套件、CI、已知正确的编译器 oracle、真实项目编译
核心瓶颈	调度与综合	状态同步与验证反馈

这一区分很重要。

Research 系统通过 上下文隔离 获得广度：每个 subagent 独立搜索一个方向，再把高信号结果压缩给 lead agent。C 编译器实验通过 共享环境 获得持续进展：每个 Agent 都在本地副本中工作，但最终必须把修改合并回同一个上游仓库。

前者首先是信息并行问题，后者首先是状态并发问题。

二、Research 系统：并行的价值来自独立探索

Anthropic 的 Research 功能采用 orchestrator-worker 架构。lead agent 分析用户问题、制定研究策略，并创建多个 subagent 同时探索不同方向；subagent 独立使用搜索工具、判断结果质量，然后把发现返回 lead agent。lead agent 再决定是否需要补充研究，最后把材料交给 CitationAgent 定位引用。

为什么研究适合并行

开放式研究具有三个特征：

• 事先无法准确预测检索路径；
• 一个新发现可能触发新的搜索方向；
• 多个问题分面往往可以独立探索。

例如，寻找一组公司的全部董事会成员，可以按公司拆成多个相互独立的检索任务。每个 subagent 使用自己的上下文窗口，不必等待其他公司搜索完成。

Anthropic 将这种过程描述为一种压缩：subagent 从大规模外部语料中提取高信号事实，再把压缩后的结果交给 lead agent。它不只是增加并发，还增加了可以投入问题的总上下文容量。

收益伴随显著成本

Anthropic 报告，在一项内部研究评估中，由 Opus 4 lead agent 与 Sonnet 4 subagent 组成的系统比单 Agent Opus 4 高出 90.2%；将 3—5 个 subagent 并行启动、并让 subagent 并行调用三个以上工具后，复杂查询的研究时间最多缩短 90%。

但同一篇文章也给出了成本边界：普通 Agent 通常消耗约为聊天交互 4 倍的 token，多 Agent 系统约为聊天交互的 15 倍。

因此，研究并行不是免费提速。它适合任务价值高、搜索方向多、信息量超过单个上下文窗口的场景，而不适合一个简单事实也启动大量 subagent。

调度必须明确

Anthropic 早期系统出现过三个典型问题：

• 简单问题一次创建几十个 subagent；
• 多个 subagent 做了重复搜索；
• Agent 为不存在的来源持续搜索，无法停止。

解决方式不是增加更多角色，而是让 lead agent 明确每个任务的：

• 目标；
• 输出格式；
• 工具与来源范围；
• 与其他任务不重叠的边界；
• 与问题复杂度相称的 effort budget。

文章给出的经验是按复杂度分配资源：简单事实可能只需要一个 Agent 和少量工具调用，直接比较可以使用少量 subagent，真正复杂的广度研究才值得扩展到更多并行工作者。

这说明 并行度本身也是需要管理的资源。

三、Research 系统的共享状态被刻意压低

Research subagent 之间通常不直接共同编辑一个核心制品。它们各自在独立上下文中搜索，将结果返回 lead agent，由 lead agent 负责综合。

这降低了写冲突，但没有消除协调问题。

lead agent 仍然是同步瓶颈

Anthropic 当前描述的 lead agent 会同步等待一组 subagent 完成。这样做简化了协调，却意味着：

• lead agent 无法在执行中实时调整 subagent；
• subagent 无法彼此协调；
• 一个慢任务可能阻塞整个批次；
• 异步执行虽然能提高并发，却会引入状态一致性和错误传播问题。

因此，Research 系统并不是“所有 Agent 自由协作”，而是 受 lead agent 控制的分批并行。

文件制品可以降低转述损失

原文附录提出：当 subagent 产出结构化报告、代码或数据可视化时，可以让它直接写入持久化制品，再把轻量路径返回协调者。

这样有两个收益：

1. 大结果不需要在聊天中重复转述；
2. 后续阶段可以直接读取原始制品，避免 lead agent 二次压缩造成信息损失。

这不是取消协调者，而是把协调消息从“完整内容”缩减为“状态与制品引用”。

四、C 编译器实验：并行的难点变成共享代码库

第二篇文章记录了一项能力边界实验：16 个 Agent 在近 2000 次 Claude Code 会话中，构建一个约 10 万行、用 Rust 编写的 C 编译器。项目 API 成本略低于 2 万美元，并能在 x86、ARM 和 RISC-V 上构建 Linux 6.9。

这些数字说明实验规模，但不能被简化成“16 个 Agent 可以独立完成生产级编译器”。文章同时明确列出局限：

• 16 位 x86 阶段仍调用 GCC；
• 自有汇编器和链接器尚不稳定；
• 不能编译所有项目；
• 生成代码效率低于 GCC；
• Rust 代码质量与专家实现仍有距离；
• 新功能和修复经常破坏已有能力。

原文把它定位为能力 stress test 和早期研究原型，而不是成熟的软件开发流程。

没有中央 orchestrator

每个 Agent 在独立 Docker 容器中克隆仓库，完成工作后把修改推回本地上游仓库。Agent 通过 current_tasks/ 下的文本文件锁定任务，以减少两者同时处理同一问题的概率。

一个典型周期是：

1. 写入任务锁；
2. 完成修改；
3. 拉取其他 Agent 的更新；
4. 处理合并冲突；
5. 推送修改并释放任务锁；
6. 新会话在新容器中继续下一项工作。

这套机制没有高层 orchestrator，也没有复杂的 Agent 间通信。Agent 主要从仓库状态、任务锁、README、进度文件和测试结果中判断下一步。

所以它依赖的不是强协调中心，而是一个能让 Agent 自我定位的环境。

五、任务独立性决定并行是否真实存在

C 编译器实验揭示了一个很清楚的边界。

多个独立失败：天然适合并行

当测试套件存在大量不同失败时，每个 Agent 可以选择一个失败独立修复。接近 99% 通过率后，也可以让不同 Agent 分别尝试编译 SQLite、Redis、libjpeg、Lua 等项目。

这些任务具有不同输入、不同失败点和相对独立的修改范围，并行能直接提高吞吐量。

单一关键路径：增加 Agent 没有帮助

当团队开始编译 Linux 内核时，所有 Agent 都遇到同一个阻断错误。它们反复处理同一问题，并相互覆盖修改。此时虽然有 16 个 Agent，但真正可运行的关键路径只有一条。

实验后来引入 GCC 作为已知正确的 oracle：先让大部分文件使用 GCC 编译，只让待检查子集使用新编译器，再逐步缩小错误范围。这个测试设计把一个整体失败重新分解为多个可独立定位的子问题。

因此：

核心判断

并行度不是 Agent 数量，而是当前环境中可以被独立验证、独立推进的任务数量。

如果所有 Agent 都在等待同一个状态、修改同一个热点或通过同一个串行门，增加 Agent 只会增加冲突。

六、验证反馈是长期自治的导航系统

C 编译器项目最重要的投入并不是无限循环，而是测试、环境和反馈。

每个新 Agent 都从空上下文进入容器。如果环境只能回答“失败”，它无法判断失败属于哪个模块，也不知道修改是否导致回归。高质量验证需要提供：

• 足够细的失败定位；
• 可重复的快速路径；
• 不污染上下文的简洁输出；
• 详细结果的文件化记录；
• 防止新提交破坏既有功能的 CI 门。

文章特别强调，测试输出不应把数千字节无用内容灌入上下文。终端只显示少量进度和摘要，详细信息写入可检索日志；快速模式运行对单个 Agent 确定、跨 VM 随机的抽样，让各 Agent 能稳定识别自身回归，同时由不同 VM 扩大覆盖。

这与 Research 系统的评估原则互补：

• Research 更适合按结果质量、来源、引用和完整性评价；
• 代码系统更适合通过可执行环境持续验证状态；
• 两者都不能只规定一条“正确过程”并检查 Agent 是否逐步照做。

多 Agent 系统的可靠性首先来自反馈环境，其次才来自协调提示。

七、五个维度的适用边界

综合两篇文章，可以用五个维度判断是否值得并行。

1. 并行度

问：当前是否存在多个可以同时推进的真实工作项？

搜索不同主题、检查不同页面、修复不同失败通常可以并行；同一个关键 bug、同一份叙事决策和同一组相互依赖的页面通常不行。

2. 任务依赖

问：子任务 B 是否必须看到 A 的完整结果后才能正确开始？

依赖越多，就越适合串行或分阶段并行。把有向依赖图误当作平行列表，会产生返工而不是提速。

3. 共享状态

问：多个 Agent 是否会写同一文件、同一模块或同一决策面？

只读检索的冲突小；共享代码库需要锁、版本控制、合并和回滚；共享设计决策比文本冲突更难自动合并。

4. 验证反馈

问：每个子任务完成后，环境能否独立判定其结果是否有效？

没有可执行检查、来源验证或固定 rubric 时，协调者只能凭表面结果判断。并行会更快地产生无法确认的输出。

5. 协调成本

问：拆分、描述、启动、同步、综合、冲突处理和重复上下文的成本是多少？

如果任务本来只需一次小工具调用，创建多个 Agent 明显得不偿失。如果一个高价值任务包含大量独立方向，协调成本才可能被吞吐量收益覆盖。

可以将决策简化为：

条件	建议
高独立性、低共享写、可独立验证	并行
有阶段依赖，但阶段内任务独立	分阶段并行
高共享写、强顺序依赖、验证集中在最终状态	串行
任务很小或价值不足以覆盖协调成本	单 Agent

八、PPT Master 的 topic-research：隔离分支只有一个 worker，不是研究团队

PPT Master 的 topic-research 只在 topic-only 输入或现有材料留下规划所需的外部事实缺口时运行。

现行契约明确要求：

• 主 Agent 判断材料是否充分，并定义 gap brief；
• 在宿主支持并允许隔离执行时，只派发一个具有搜索能力的 research worker；隔离执行不可用时由主 Agent 本地完成；
• worker 只写一份研究补充 Markdown 和一份事实溯源 JSON；
• 原始网页和抓取记录留在 worker 上下文；
• 主 Agent 验证两个制品的结构与一致性；
• 导入后，内容所有者完整读取研究补充和事实 JSON，再进入规划。

它使用 subagent 的主要原因是 隔离检索噪声，不是扩大并行搜索宽度。

这与 Anthropic Research 系统有两点相似：

• 原始搜索过程不必进入主上下文；
• 持久化制品比聊天转述更适合承接完整结果。

但差异同样明确：PPT Master 没有动态创建多个研究 subagent，没有 lead agent 循环追加多轮并行研究，也没有独立 CitationAgent。把它描述成“多 Agent 研究系统”会夸大当前机制。

为什么一个 worker 合理？因为这里的研究任务已经被主 Agent 收束成一份明确 gap brief，最终还必须形成一对统一制品。增加 worker 会引入来源去重、事实冲突和多份制品合并成本，而当前没有证据表明这些成本能换来必要收益。

九、PPT Master 的 visual-review：完成页面后的条件式并行

在宿主支持并行 subagent 原语时，visual-review 是 PPT Master 中真正采用批量并行的阶段，但它有严格前提：

• 所有 SVG 页面已经生成；
• 静态质量检查已经通过；
• 尚未进入最终后处理与导出；
• 用户明确要求视觉回看。

主流程不会自动触发它，也不会因为页面多或模型能力强就推荐它。

为什么这里可以并行

视觉审查面对的是已经完成、页表和上游设计合同固定的页面集合；单页 SVG 仍可在 rubric 允许的范围内原地修复。每个页面有独立 SVG、渲染 PNG、页面角色和固定 rubric。审查任务可以按页切分，而且单页的位置或间距修复通常不需要改变其他页面。

现行编排是：

1. 主流程先调用 renderer 生成全页 PNG；renderer 通过项目级文件锁串行化实际渲染，随后主 Agent 规范化成功与失败记录；
2. 一个 orchestrator 把 N 页分成每批不超过 K 页，默认 K=5；
3. 每个 batch subagent 并行启动；
4. batch 内部仍按页串行处理；
5. subagent 只能做 rubric 允许的原子修复；
6. 每页写独立 JSON，并保留 SVG 备份；
7. orchestrator 汇总状态，品牌或结构决策交回主 Agent 与用户。

这种设计同时控制了两种成本：批处理让 rubric、Design Spec 和 lock 不必为每页重复加载；每个 batch 保持有限页数，又避免单个 subagent 上下文过大。

宿主不支持多 Agent 原语时，同一批次结构退化为主 Agent 顺序处理。因此并行是条件能力，不是交付契约。

十、PPT Master 的核心页面生成：串行是一致性要求

PPT Master 的 Default Generate 对核心 SVG 生成给出了相反的约束：

• 页面必须由当前主 Agent 创建；
• 不得委派给 subagent；
• 按 Design Spec §IX 的精确页面顺序执行；
• P01 完成后运行 first-page gate；
• 门通过后，从 P02 到最后一页连续生成；
• 中间不插入批次和 checker 调用；
• 全部页面完成后再运行 final gate。

这是因为页面不是一组真正独立的文件任务。它们共享：

• 同一沟通目标和核心信息；
• 同一 palette、typography、icon 和 page rhythm；
• 跨页视觉连续性与重复元素语义；
• 已完成页面形成的实际方法样本；
• 有顺序的叙事与可能存在的跨页运动状态。

两个 subagent 即使各自生成了合格页面，也可能对同一 Design Spec 形成不同的视觉解释。XML 合并没有冲突，不代表设计决策一致。

P01 gate 的作用也不是把第一页“测完就忘记”，而是先识别方法级偏差，再把修正后的构造方法带入剩余页面。把后续页面提前分发，会让这些页面在方法校准完成前开始工作。

因此，核心页面生成属于强顺序依赖、高共享决策、最终一致性要求高的任务，应保持串行。

十一、三个 PPT Master 场景的对照

维度	topic-research	visual-review	核心页面生成
并行度	隔离分支只使用一个 worker；不可用时本地执行	页面完成后按批条件并行	明确串行
任务依赖	一份 gap brief，一对统一输出	单页检查大体独立	页面顺序、风格方法和叙事连续
共享状态	worker 只写两个指定制品	每个 batch 只编辑分配页面并写独立报告	所有页面共享同一设计解释
验证反馈	主 Agent 验证 Markdown/JSON 协议与事实一致性	固定 rubric、PNG、JSON、备份和最终汇总	P01 方法门、最终质量门、精确 roster
协调成本	多 worker 合并尚无必要	批处理收益可以覆盖调度成本	并行会引入难以合并的设计漂移
触发方式	材料存在事实缺口时条件触发	用户明确请求时触发	Generate 核心流程

这个表说明 PPT Master 不是“支持并行”或“不支持并行”的二元系统。它把不同并发策略放在任务结构不同的位置。

十二、哪些 Anthropic 能力不应直接投射为 PPT Master 路线图

1. 研究系统的动态扩展不是现行机制

PPT Master 的隔离执行分支明确只派发一个 research worker，隔离不可用时由主 Agent 本地完成。未来是否增加 breadth-first 多 worker，应由真实研究覆盖不足、延迟或上下文压力触发，而不是因为 Anthropic 的产品系统采用了更多 subagent。

2. 编译器实验不是通用软件开发默认值

C 编译器项目是高成本能力实验，依赖容器、Git、任务锁、大量测试和近 2000 次会话。其结果仍有明确功能与质量缺口。不能据此认为普通文档或设计任务应默认启动长期自治团队。

3. 条件式视觉并行不授权页面并行生成

visual-review 的输入已经完成、任务按页可验证、编辑范围受 rubric 限制；页面生成需要建立共同设计方法。两者的并发条件完全不同。

4. “可以并行”不等于“值得并行”

Anthropic 两篇文章都显示，并行会增加 token、协调、状态和验证成本。只有真实吞吐量收益大于这些成本时，才有理由引入更多 Agent。

十三、我的理解：先设计可独立验证的工作，再增加 Agent

两篇文章共同指向一个经常被忽略的顺序：

任务可分解
    ↓
每个子任务有清晰边界
    ↓
环境能独立验证进展
    ↓
共享状态有同步与回滚方式
    ↓
并行收益覆盖协调成本
    ↓
才增加 Agent

多 Agent 不是任务分解的替代品。一个不可分、不可验、共享状态混乱的问题，交给更多 Agent 只会更快地放大不确定性。

核心观点

多 Agent 系统的上限由模型能力决定，但它是否可靠，首先由任务图、状态边界和反馈环境决定。

Research 系统证明了独立上下文能够扩展搜索广度；C 编译器实验证明了共享代码库需要锁、合并和高质量测试；PPT Master 则给出了一个更克制的落地：检索噪声用单 worker 隔离，完成后的页面审查按需并行，承担统一设计判断的页面生成保持串行。

这不是对并行能力的保守使用，而是让并行只出现在它能够产生净收益的地方。

参考来源

• Anthropic，2025-06-13：How we built our multi-agent research system
• Anthropic，2026-02-05：Building a C compiler with a team of parallel Claudes
• PPT Master 当前实现快照（4e6ecbc）：topic-research、visual-review、generate-pptx

← 返回 Anthropic 学习地图