多 Agent 协作：子 Agent、worktree、后台审查与事件日志
把一项任务交给多个 Agent，难的不是开几个，而是三件事：每个 Agent 能看到什么，能改哪里，最后由谁把结果合起来并验证。单个 Agent 怎样在循环里提出动作、接受校验，见 Harness 和有界 Agent 循环；本文讨论的是多个这样的循环同时运行时，需要额外处理的问题。
主要案例是 Meta 的 Muse Code。它在 2026 年 8 月 5 日以 beta 发布，8 月 31 日结束 beta，从设计上就围绕多个协作的 Agent。文中再对照 OpenAI Agents API、Claude Code 和 Antigravity 的做法。产品细节均核对于 2026-10-01。
四种角色
多 Agent 系统里常见四种角色，它们承担的责任不同：
- 协调者：拆分任务、分派、汇总，并对最终结果负责；
- 有边界的 worker：只完成分到的那一块，交回可检查的结果；
- 后台观察者：不接具体任务，持续盯住某一个质量维度并提出建议；
- 显式审查者：在结果完成后做一次审查。
Muse Code 四种都有。主会话（lead）派生子 Agent，每个子 Agent 负责一项有边界的任务。另有一组后台观察者，分别负责记忆召回、技能召回、目标跟踪和验证，在整个会话中常驻；按 Meta 的说法，这些背景 Agent “在每个会话中始终保持活跃，而不是为单个任务临时派生”（发布文章）。观察者只能提出建议：“它提议，由调和器决定”，被接受的建议才会进入主 Agent 的下一回合。这样，审查意见不会打断主 Agent，也不会绕过它直接改代码。
三条要分开看的边界
“给每个子 Agent 一个独立环境”听起来是一件事，实际上至少包含三条不同的边界：
前两条最容易混淆。上下文分开，不等于文件分开：OpenAI 的文档明确写着，协调者和子 Agent 共享同一个环境的文件系统，“创建子 Agent 不会新建环境”。反过来，文件分开也不等于一切都分开：按 Git 手册，worktree 只单独保存 HEAD、index 这类每个工作树自己的文件，其余仓库内容都共享，包括对象库和默认的仓库配置。两个 worker 在各自的 worktree 里启动开发服务器，仍可能抢同一个端口、写同一个测试数据库。
权限边界还有一个细节：Claude Code 的文档提醒，只禁用 Write 和 Edit 并不能阻止写文件，因为 Bash 仍然可用。限制工具时要看实际能产生的效果，而不是工具的名字。权限、审批和沙箱的整体关系见 Agent 安全。
一次有边界的并行修改
下面是一个虚构的例子：给一个服务同时增加一个 API 字段、更新前端展示、补充文档。
- 协调者先定接口。 字段名、类型、默认值写进每个 worker 的任务说明。这是 worker 之间唯一需要共享的决定，必须在分派前定下。
- 按会不会写代码分配目录。 改后端和改前端的两个 worker 各开一个 worktree；只负责查资料的 worker 留在共享检出里，Muse Code 的文档正是这样建议的。
- worker 交回证据，不交回结论。 每个 worker 交回提交和自测结果，而不是一句“做完了”。
- 协调者合并一次，跑一次共享验收。 合并后的测试才能发现两边各自通过、合起来却不一致的问题。
- 冲突回到协调者。 接口需要改动时由协调者决定并重新分派，不让 worker 直接改对方的代码。
本站认为第 1 步最值得注意。Cognition 在 2025 年 6 月的文章里用实例说明，并行 Agent 各自做出的隐含决定可能互不兼容，因此每个动作都应当基于系统其他部分已作出的相关决定（原文）。这是基于案例的工程论证，不是对照实验，没有衡量这种失败有多常见，但它描述了拆分任务时可能出现的一种失败方式。
消息、取消与容量
Agent 之间需要传话时，要先弄清消息的来源和效力。Muse Code 的会话消息只在同一用户、同一台 macOS 或 Linux 机器上的独立交互会话之间传递，内容是最多 8,192 字节的纯文本；收到的消息被当作“未经验证的 Agent 数据”，不会获得发送方的权限。Antigravity CLI 在 1.2.9 加入了 @<子 Agent> <消息> 语法，可以直接给某个子 Agent 的对话发消息；桌面版 Antigravity 2.0 也在 9 月下旬加入了子 Agent 的实时卡片和直接发消息。
取消通常不是即时的。Muse Code 的文档说明取消是协作式的：被取消的子 Agent 如果还没走到检查点，会继续运行；正在写入的会先把这次写完。所以“停止所有 Agent”之后，仍要检查工作目录的实际状态。
容量也有上限。Muse Code 默认一棵 Agent 树最多同时运行 8 个 Agent（含主会话），未配置的 ultra 根会话则是 64 个；这个值可以在 1 到 64 之间调整，子 Agent 再派生的子 Agent 共享同一个容量；树满时，新的派生请求会被拒绝。
事件日志能恢复什么
Muse Code 把每次运行记录为只追加的事件日志，其中包括模型调用、工具调用与结果、审批决定。会话中断后，恢复靠的是从日志重建对话。日志还区分两类副作用：已经确认完成的记为完成；只宣布过、却没有确认结果的，Agent 要先检查实际状态再决定是否重试（审计与恢复）。
“可重放”的含义需要说清楚。Muse Code 的确定性重放用记录下来的事件重建当时的上下文，“不调用模型、不运行工具、也不联网”。它能用来审计和回归测试，却不能保证外部副作用只发生一次。重试如何避免重复扣款、重复发消息，仍要靠长时运行 Agent 里讲的幂等键和状态核对。
什么时候值得用多个 Agent
公开的证据指向同一个方向：彼此独立的任务适合拆，紧密耦合的任务不适合。Anthropic 在 2025 年 6 月报告，它的多 Agent 研究系统在内部研究评测上比单个 Opus 4 高出 90.2%，但 token 消耗约为普通对话的 15 倍，而且不太适合子任务之间依赖很强的工作（原文）。这些是厂商的内部评测，适用范围限于它测试的研究任务。
审查也有成本。Anthropic 在 Sonnet 5.5 的发布页中说明，最高推理强度下模型更常启动拆给多个子 Agent 的代码审查，在 Cognition 检查的两个案例中，这导致了超时或超出任务范围的改动，FrontierCode 得分反而低于低一档的设置。这只说明了一种失败机制，不代表它出现的频率。
本站据此的判断是：先用单个 Agent 把任务跑通，再把确实独立、能各自验收的部分拆出去，例如分别阅读不同的文档、在不同模块里排查问题、并行跑互不相干的实验。紧密耦合的改动、需要大量共享隐含决定的设计、以及重复的审查，拆开之后往往更慢、更贵。比较时用同一批任务，看完成时间、token 消耗和返工次数，而不是看同时开了几个 Agent。
各工具的做法
以下核对于 2026-10-01：
终端层面的持久化又是另一回事。Herdr 能让多个 Agent 的终端在重启后恢复，但它不负责拆分任务、合并结果或隔离工作目录。选择工具时，先确定自己需要的是哪一层。