技术 · 深入
任务塞进一个会话，越并行越乱
隔离归工作区，汇总归审阅
这是多任务并行前的环境隔离 + 结果集中审阅方法：每个任务开一个独立 git worktree（独立分支、独立工作目录），各派一个编码 Agent 在里面跑，跑完统一回到主线按 diff 逐份审阅，再决定合并还是丢弃。解决的是「几个任务塞进同一个会话、改到同一个文件，最后谁也说不清哪处改动是谁的」。
方法 · 一图看懂
1
拆任务 — 把会话里的多个任务拆开，每个写清目标、涉及文件、验收标准。
2
开工作区 — 一个任务对应一个 git worktree 和一个独立分支，彼此不共享工作目录。
3
并行跑 — 每个 Agent 只在自己的 worktree 内改文件，同名文件不跨区，跑完各自提交。
4
集中审 — 结果回主线按 diff 逐份审，判断依据是改动本身，而不是「谁先说完成」。
5
合并或丢弃 — 通过审阅的合回主干，冲突或超出范围的整份丢弃重跑。
档位差异：一个会话排队 vs 一人一间
初档是「一个大模型 + 一个工作目录」，多个任务排队做，改坏了只能靠 git 回滚，而且前后任务的改动会互相污染。深档把隔离放到文件系统这一层：worktree 让每个 Agent 有自己的一份工作目录和分支，改动在物理上就分开了，冲突只在合并时出现，不在执行时出现。Orca 就是把这个做法做成了产品：不同编码 Agent 各进独立 worktree 并行跑，再集中审阅结果（GitHub 周榜 7 天新增 9,622 星、累计 106,018 星）。
审阅这一关不能省
并行跑得快，审阅跟不上就等于白跑。审阅必须做到一份 diff 一条结论：改了什么、为什么改、有没有超出范围。三个常见坑：①Agent 顺手改了任务范围外的文件；②两个任务改了同一处逻辑，到合并时才暴露；③Agent 自述「已完成」，实际只改了一半。所以「集中审阅」是流程里跟执行同等重要的一步，不是收尾动作——审阅不通过就整份丢弃，不进入下一轮。
原理 · 为什么有效
为什么有效：并行的成本不在执行，而在冲突被发现的时间点。所有任务共用一个工作目录时，冲突要等到运行或提交才发现，那时已经分不清责任；用 worktree 隔离后，冲突被推迟到合并这一刻，以 diff 的形式显式出现，可以逐个判断。同时，隔离让「丢弃」变得便宜——一个任务做歪了，删掉它的 worktree 就行，主干从头到尾没被污染。这就是并行之前要先隔离的原因：不是为了让更多 Agent 同时跑，是为了让坏结果可以整份扔掉。
适用场景
适用：多个任务彼此独立、都要改文件、并且需要保留能随时回滚的干净主干——多 Bug 并行修复、多方案并行试写、多分支实验。不适用：任务之间强依赖（B 必须先看到 A 的改动才能做），或者只是读代码不改文件（隔离没有收益）。也不适合一个人盯不过来的时候：开了 5 个 worktree 却只审得动 1 份 diff，剩下 4 份就是负债。
自测 · 5 问
现在这几个任务，改的文件会不会重叠？
每个任务是不是有独立工作目录和分支，还是都在一个目录里排队？
结果回来后，我审的是 diff 还是 Agent 的自述？
审阅不通过的产物，我是整份丢弃，还是让它接着改？
我开出来的并行数，是我审得过来的数吗？
怎么上手 · 验证步骤
第一步，把手上任务列成清单，标出每个任务会碰哪些文件，重叠的先合并成一个。第二步，为每个任务各开一个 git worktree 和独立分支，把 Agent 的权限限制在这个目录内。第三步，并行执行，要求每个 Agent 结束时交出「改了哪些文件 + 验收点」。第四步，回到主线逐个 worktree 看 diff，通过的合并，不通过的整体丢弃。第五步，合并后跑一次完整测试，确认主干干净。
合并前检查：每个要合进来的分支，你能不能说清它改了什么、为什么改？说不清的就别合。合并后再确认一次——主干上有没有出现你没审过的文件改动，只要出现，就说明隔离或审阅漏了一环。