多个子代理并行改代码，先划分好谁写哪份文件

代码里的问题已经定位，要试两种修复方案，于是你把它们分给两个子代理，各试一个。结果两个方案都要改同一个接口契约：各改各的，最后合不到一起，两个子代理还都汇报“完成”。

你打开 Git，满屏冲突，可冲突只是表面。

真正的问题是，开工之前没人先把共同的接口定下来，最后也没人负责整合。子代理各有独立的上下文，思路互不干扰，可它们面对的是同一个文件系统；worktree 能把分支和工作文件分开，数据库和网络却仍然共用。

把“上下文隔离”和“文件隔离”当成一回事，是并行出问题最常见的原因。

所以责任要在并行之前划清：子任务写出目标、范围和产物，能不能并行要看任务能否各自独立产出结果，共享文件只指定一个写入者，多路只读调查的结果，核对完环境和时间窗口再整合。

整合落到具体的人，并行才真的省事。文中的一张分工图，会把开头那个两方案的任务，排成一份能执行的方案。

01 上下文隔离与文件隔离是两件事

Subagent（子代理）把子任务放进独立上下文，官方文档列出可以配置的工具、模型、权限、最大轮次和 memory。大仓库搜索、目录审查、测试失败提炼这类高噪声探索，都可以让过程输出留在子任务，主会话接收结构化摘要。

子任务的目标、范围和产物必须明确。例如，一次故障调查可以这样写：

请只读调查本次故障时间窗口内的错误，判断是否与最近部署有关。
范围：已提供的脱敏日志和最近一次部署差异。
不要修改文件，不重启服务，不写入数据库或发送外部消息。
输出：
1. 相关记录与时间。
2. 与部署差异相符或不符的证据。
3. 优先假设和未确认项。
4. 一个能区分假设的下一步检查。
最多探索 8 轮；达到预算或缺少关键输入时，返回已取得的证据和缺口。

这个示例把“随便看看故障”收紧为有输入、有范围、有产物的调查。实际配置还应限制工具与权限；运行时轮次上限用 maxTurns 落实，自然语言里写的预算只是提示。返回应区分证据、假设和未完成部分，达到预算后保留尚未完成的调查。

worktree 为同一 Git 仓库提供另一份工作目录，通常对应独立分支。需要试验性改动时，可以使用 isolation: worktree 等对应配置，再提出：

请在隔离 worktree 中尝试方案 A。
只修改 auth 相关文件。
完成后输出改动摘要、测试结果和是否建议合并。

worktree 分开了分支与工作文件，但不隔离所有 Git 状态、网络或数据库。试验代码若仍连接同一个数据库，写入就仍可能影响它。执行权限和外部资源限制需要单独落实。

所以，只读高噪声探索只需 Subagent；需要分开代码改动时再加 worktree；涉及执行权限和外部资源时，继续用 permissions、sandbox 和服务端控制，见Hook 明明报错了，危险操作还是执行了。

02 根据任务依赖安排并行

三个目录分别审查、三种方案分别调研、多个失败测试独立定位、多篇文档分别检查，都可能在最后合并结果。前提是各自输入足够明确，能够独立推进并产生结果。

启动并行前，先列出各子任务的输入、输出、文件范围和整合方式。判断能否并行的关键，是它们能否独立产生结果。

存在紧密状态依赖时先顺序处理；共享核心文件指定唯一写入者，其他任务只读或提供建议。使用 worktree 可以分开试验，共同接口的设计依赖和最终整合工作仍然在。

主会话负责保留总体目标、整合证据、检查交叉影响。三个摘要都说“完成”，整合后的结果是否通过验证，还要重新查。

03 只读调查：分派之后怎么整合

假设当前授权只有“查明可能原因”，可读取脱敏日志和部署记录，不允许改生产状态。主会话保留目标与证据整合职责。日志很多，可以把日志分析和最近变更分析分别交给只读 Subagent，两者先各自返回证据，不一起修改文件。这两项只读探索可以使用现有工作目录。

假设日志子任务提出“可能需要重启”，当前仍应返回建议、证据和未确认影响。授权范围仍由用户决定。只有用户明确要求执行修复，并确定对象、影响和执行范围后，才进入相应操作。

最后整合结果时，检查两份证据是否来自同一环境、版本和时间窗口。如果日志来自旧部署，即使两份摘要都写着“已完成”，当前根因也要重新查。分派减轻过程负担，整合仍需核对共同事实。

04 代码修改：先定接口，再分头实现

回到开头：已经定位到代码问题，需要试验两种修复方案。这时会产生文件写入，控制方案需要随之变化。

可以为试验准备独立 worktree，但先明确每个方案的输入、修改范围、验证标准和整合负责人。目录分开了，数据库、网络服务这些外部资源还是共用的；测试仍应指向获准的隔离环境。

如果两个方案都要改同一个接口契约，应先由一个负责人确定契约，再开展后续实现。尚未决定共同接口就让两个子任务分别推进，后续冲突往往来自设计依赖，不只是 Git 合并问题。

可以这样组织：

主会话：确认共同目标、接口边界和验收标准
  ├─ 只读子任务：检查调用方与兼容性
  ├─ 只读子任务：检查测试覆盖和遗漏条件
  └─ 修改负责人：根据确认结论实施一个候选方案
       ↓
审查差异，运行方案验证
       ↓
集成后重新检查受交叉影响的行为

这是一个示例分工，实际重构可以多些或少些任务。能独立产生结果的工作才适合并行；共享文件指定唯一写入者，其他任务提供建议。即使采用多个 worktree，集成责任也必须明确。

高噪声探索怎样隔离出主会话，可以参考Claude Code 越聊越乱，该清空还是压缩里的子任务写法。

回到开头那两个方案：先由一个人定下接口契约，再分头实现，最后由主会话整合并重新验证。这一步由主会话来做，各个子任务的“完成”只是输入。