多 worktree 并行 agent 交付：吞吐瓶颈是隔离，不是模型

背景：一个人带一队 agent 之后，瓶颈挪到了哪

最近两个多月在两个产品仓库里合入了 400 多个 PR，高峰期同时开着五到十个 Claude Code session，每个 session 对着自己的任务干活。这个吞吐不是靠模型变强白捡的——模型只是让「写代码」不再是瓶颈，瓶颈立刻挪到了别处：并行的 session 互相踩脚、评审循环不收敛、CI 排队。复盘下来，真正起作用的是四种隔离，全部是普通的工程活，没有一件和 prompt 有关。

工作区隔离：worktree 即会话，治理先行

每个任务一个 git worktree、一条分支，session 绑定 worktree，PR 是唯一合入通道。这一层大家都会。容易被跳过的是治理先行：仓库第一周先立好 agent 规范（AGENTS.md 写成索引而不是手册，按任务指到具体文档）、ADR、CI 门禁和守卫脚本，并且在 README 里明示 skeleton 状态——服务能编译、健康检查通过，但没接线的能力不算能力，不许报告为可用。agent 的产出质量对「仓库怎么描述自己」极其敏感：这些文件不是给人看的礼仪，是给并行 agent 的运行时约束，缺了它们，放量就是放乱。

运行时隔离：端口从约定变成分配

多个 worktree 同时起本地全栈，第一个撞上的是端口。方案是槽位制：slot N 把所有应用端口整体平移 10×N，slot 0 恰好等于历史端口表，单 checkout 的人零感知；脚本自动认领「兄弟 worktree 没占、端口也空闲」的最低槽位并 pin 进本地文件，需要时用环境变量覆盖。配套一条幂等的 make up：槽位 → 渲染配置 → 数据库 → 迁移 → 基建 → 服务，全部就绪才返回。个人站点仓库里早就撞过同一个问题的缩微版（audit 固定端口 3000 被别的 worktree 占用），当时是手工改 3001 绕开的——对比之下结论明显：并行度上去之前，把端口从「约定」变成「分配」，一次性解决。

事实隔离：需求镜像进仓库，revision 锚定

需求文档住在协作平台（飞书），agent 干活在仓库，上下文靠人肉搬运必然漂移。做法是整库归档：十来份 PRD 全部镜像进 docs/product/，每份文件头记录同步时的 revision 号，协作平台保持需求的唯一真相源，仓库这份是带锚点的只读镜像。markdown 导出会丢飞书的嵌入式电子表格（一共 109 张），规范性表格——数值、状态枚举、验收标准、异常边界——逐张导出核对回填。这个笨活的副产品是抓出了好几处正文和表格互相矛盾的地方：需求文档自己都不知道自己错了，镜像过程就是一次免费的需求审计。交付跟踪用 GitHub epics + sub-issues，把 PRD 拆到验收项粒度，session 直接对着验收项开工。

评审有界：agent 互审必须有终止条件

用另一个 agent 做 PR 评审，默认行为是不收敛的：修 → push → 请求 review → 又来一轮低优先级发现 → 再修，没有任何一步是终点。规则改成以「完成的评审轮」为单位：连续两轮只剩 P2/P3 级发现就终止通用评审，只给「有具体影响证据的高危 P2」留一个受限例外；「没有发现」直接结束，而不是再触发一轮确认。这条策略本身配了八个 decision eval——评审策略也是代码，改它同样要回归。

CI：时间省在缓存上，不省在覆盖上

并行 PR 多了，CI 时延直接变成吞吐上限。省时间的坑有二：一是 Go 构建缓存被指到每次全新创建的 gitignored 目录，等于每次全冷编译两遍；二是 GitHub Actions 的 cache 作用域是「写入分支 + 默认分支」，CI 只挂在 pull_request 事件上的话，每个 PR 的首跑永远全冷——需要一个从 main 写缓存的 warm 任务，它不 gate 任何东西，只负责让所有 PR 有缓存可读。覆盖则反向收缩：full-stack smoke 从每 PR 必跑改成按需调用，CI 里数据库栈只起 Postgres 单件。快检查天天跑、慢检查按需跑，这个分层在个人站的 audit（quick/deep 两级）里是同一个取舍。

可迁移的判断

并行 agent 交付的瓶颈排序：隔离 > 评审终止条件 > CI 时延 > 模型能力。四种隔离互相独立、缺一不可：工作区（worktree + 治理文件）、运行时（端口槽位）、事实（需求镜像 + revision 锚定）、评审（有界收敛）。做完这些，人的工作从写代码变成排产和验收，而其中对吞吐贡献最大的一步是把 PRD 拆到验收项粒度——它决定了每个 session 能不能不问人就开工。