让多个 AI 智能体同时开工，效率翻倍的前提是它们互不打架。一个 agent 在重构模块，另一个在修 bug，两边都往同一个目录里写文件、跑测试，互相覆盖、互相干扰只是时间问题。社区在并行使用上形成的约定很一致：一个 agent 一条分支一个 worktree，各自圈地，互不侵犯。这篇对比单线与并行的差别，讲清 worktree 的机制、--worktree 的用法，以及大任务开工前的预防性提交；并行出乱之后的回退，见代码回退一篇。
为什么并行会互相踩脚
并行的诱惑很直接：让一个 agent 写功能，另一个修 bug，第三个补测试，效率翻倍。但工作目录是共享资源：两个 agent 同时改同一个文件，后写的覆盖先写的；A 跑测试把构建产物刷新，B 正好读到半个文件；更隐蔽的是上下文失配——A 的改动改变了文件内容，B 基于旧内容做出的判断全部作废，接着又在过时的地基上继续施工。这些冲突不是概率问题，是时间问题：并行任务一旦碰同一批文件，出错只是早晚。根子在于一份工作区这个前提被并行打破了，解法不是指望两个 agent 礼让，而是给每个 agent 一份自己的工作区。
| 冲突形态 | 怎么发生 | 你看到的现象 |
|---|---|---|
| 文件覆盖 | 两个 agent 同时改同一个文件 | 后写的盖掉先写的 |
| 构建产物读到一半 | A 跑测试刷新产物，B 正好在读 | B 拿到半个文件 |
| 上下文失配 | A 的改动换了文件内容，B 仍按旧内容判断 | B 的判断全部作废 |
worktree 是什么：一份仓库多份工作区
git worktree 是 git 的原生能力：同一个仓库，同时检出多个工作目录，每个目录对应一条分支，彼此独立。对 agent 并行来说它正好对症：agent A 在 worktree-a 的 feature-a 分支上改它的文件，agent B 在 worktree-b 的 fix-b 分支上改自己的，文件层面物理隔离，谁也覆盖不了谁。两边各自跑测试互不干扰，完工后各自提交，最后在分支层面合并——冲突留到合并这一步集中解决，比中途互相覆盖可控得多。分支怎么组织的通用讨论，见分支策略一篇；仓库与分支的选取思路见仓库分支选取一篇。
隔离约定与 --worktree 用法
Codex 提供让 agent 在独立 worktree 里启动的方式（截至发稿版本，以官方更新日志为准），开工即隔离，不用手工建目录。约定上，社区通行一 agent 一分支一 worktree：每个并行任务开一条命名清晰的分支，配一个专属 worktree，任务结束分支合并、worktree 清理。两条纪律要守住：一是别让两个 agent 共用一条分支——分支是合并的单位，共用就失去了隔离的意义；二是 worktree 里也要照常走审批与验证，隔离解决的是文件冲突，不是质量关口，每份工作区里的 diff 都要人工过目。多任务的拆分与编排更偏工作流层面，与 agent 的边界对照见工作流与智能体一篇。
并行前的预防性提交
并行开工前还有一个便宜又关键的动作：把当前工作区的干净状态 commit 一次。理由有两层。其一，未提交的改动没有回退点，并行期间出了问题，回退命令会连你自己的半成品一起清掉——先提交，agent 的改动与你的改动在版本历史上分得清清楚楚。其二，提交是合并的地基：并行分支最终要合回来，起点越干净，合并冲突越少。顺手再补两件小事：把任务范围在描述里写清，减少两个 agent 碰同一文件的概率；给每条分支定好合并顺序，避免最后一起合冲突叠加。这套预防做完，并行才真正省心。想让约定落地，可以让 DeepSeek 把一 agent 一分支一 worktree 整理成团队并行开工的检查清单，再让豆包模拟一次双任务并行的开工流程，对着清单逐步走一遍。
worktree 隔离速查
- 并行共用工作目录，冲突是时间问题不是概率问题
- worktree：一份仓库多份工作区，每份配一条分支
- 约定：一 agent 一分支一 worktree，完工合并清理
- --worktree 启动即隔离，版本行为以官方更新日志为准
- 开工前预防性 commit，回退点与合并地基都靠它
关于 worktree 隔离的三问三答
- 不用 worktree，开两个会话错开时间行不行？串行可以，真并行不行；只要两个会话同时都在写文件，覆盖与失配的风险就存在。
- worktree 之间能看到彼此的改动吗？文件层面不能，各自是独立目录；分支层面的提交同属一个仓库，合并前互相可见，但不会互相覆盖。
- worktree 占磁盘空间吗？每份工作区有独立文件副本，大仓库会多占空间；任务完工及时清理，git 自带的清理命令或手动删目录都可以。
