跳到主要内容

Parallel Worktrees / Multi-Agent：治理与风险

并行工作流真正困难的地方，不是同时开很多 lane，而是同时保持很多 lane 都可验证、可解释、可合流。只要 owner、收口顺序和独立证据链不清，并行就不是加速器，而是冲突放大器。

现在先做什么​

治理检查表​

治理面最低要求失控时会发生什么
lane owner谁能开、谁能合、谁负最终回归。lane 越开越多，但 nobody owns final merge。
合同共享所有 lane 用同一份边界和验收。每条 lane 各自理解 spec。
独立证据每条 lane 都有自己的验证和变更记录。最终只剩一个大 diff。
合流节奏有冲突处理和回归顺序。合流时彼此覆盖、回滚困难。

权限与 owner​

  • lane 谁能开、谁能合并、谁有最终回归责任，先写清再执行。
  • 高耦合核心目录默认归 owner 串行处理，外围任务再并行。
  • 不要让多个 agent 各自理解 spec，再由 owner 事后猜哪个才是准的。
  • 每条 lane 都要有清晰停止条件，避免“先开着再说”。

验证与 review​

  • 每条 lane 先过自己的验证，再进入合流和集成测试。
  • 合流时必须说明冲突怎么解、保留了哪些风险、还有哪些延期项。
  • review 要看证据链，不要只看“模型说已经做完”。
  • 最终 merge 应由 owner 基于各 lane 证据统一判断，而不是谁先做完谁先推。

最常见失控模式​

  • lane 越开越多，但 nobody owns final merge。
  • 多条 lane 在同一份合同上反复冲突。
  • 最终只能拿到一个“大 diff”，拿不到每条 lane 的独立证据。
  • 并行节省不了多少时间，却显著增加了沟通和回归成本。

什么时候先停下来​

  • lane 的边界开始频繁重叠。
  • owner 说不清当前谁先合、谁后合。
  • 某些 lane 已经没有稳定验证，却仍在继续推进。
  • spec 或合同本身在并行过程中还在大幅变化。

读完回哪里​

来源​