「多 Agent 并行开发」拆开看，其实是终端窗口 × git worktree

"多 Agent 并行开发"这个说法容易让人以为背后有个调度器，几个 AI 实例互相通气、分工协作。拆开看，事实没那么玄乎。

Claude Code 的每个终端窗口就是一个独立的 Agent 实例，实例之间没有直接通信。所谓"多 Agent 并行"，本质是：多个终端窗口 × 多个 git worktree 目录。三个终端各自 cd 进三个不同的 worktree，各跑各的 claude，仅此而已。

每个 Claude 实例只认识三样东西：自己终端内的对话历史、自己所在 worktree 目录下的代码文件、项目根目录的 CLAUDE.md（自动加载）。跨终端的信息传递，全靠人工搬运。

前置条件

这套流程要立得住，三个条件缺一不可：

• 每个轨道都有对应的设计文档（DD）：DD 是 Agent 的"工作说明书"，没有 DD 就没有边界约束。
• 共享基础组件已经合并进 main：并行的几个 Agent 都依赖这些组件。
• 各轨道文件目录完全分离：不同 Track 的组件/页面目录不交叉，一旦两个 Track 要改同一个文件，这套隔离就立刻失效。

我的判断是，第二条最容易被忽略：共享组件不该有人在某个 Track 里顺手重复造一遍，那会让"隔离"这个前提名存实亡。

完整流程

第一步，建 worktree。 在主仓库目录（不是任何一个 worktree 内）执行 git worktree add .worktrees/{track} feat/{track}，每条轨道一个。建议把 .worktrees/ 加进 .gitignore，别污染仓库记录。

第二步，开新终端，初始化 Agent。 cd 进对应 worktree，起 claude。Claude Code 启动时上下文是空的，第一条消息要说清楚：我是谁、做什么、设计意图在哪、边界在哪。

这一步最容易被图省事跳过，但恰恰最关键——不说清楚，Agent 不会自己去猜。

第三步，Agent 独立工作。 读 DD 文档拿设计意图，读 CLAUDE.md 拿架构约定，读当前代码摸清现状，然后按 DD 的实施计划逐项编码，跑完自测（typecheck/build）后告知"已完成，等待 Review"。

第四步，Review。 触发方式很朴素，一句"需要 review feat/{track} 分支"，Agent 跑 git diff main...feat/{track}，按固定格式生成报告，落盘到 review-docs 目录。Review 和 Dev 可以是同一个 Claude 实例（同一窗口切角色），也可以另开终端专门做。

第五步，分级修复。 A 类（Critical/Major bug、架构违规）立即改；B 类（重构建议、低优先级项）写进 enh-todo.md，不阻塞这一轮。修复完，Agent 回写 REV 报告，打钩 + 追加修复记录。

第六步，Squash Merge。 修复完成后回到主终端：git checkout main && git merge --squash feat/{track}，一个干净的 commit，把过程中的多个 WIP 压缩掉，保持 main 分支历史整洁。

第七步，清理。 git worktree remove .worktrees/{track}，本地分支可选删除。

几个容易问到的点

两个 Agent 会不会改到同一个文件？不会，前提是 worktree 完全隔离、各 Track 文件目录不交叉。真要改共享文件（比如 types/api.ts），应该先在 main 上改好，各 worktree 再 pull 下来。

一个 Track 先完成，能先 Merge 吗？可以。各 Track 分支独立，互不影响，先完成的先合，其他 Track 通过 git rebase main 同步基础代码即可。

main 分支一直在变，worktree 怎么跟上？git fetch origin && git rebase origin/main，跟平时用 worktree 没什么两样。

我的判断

这套流程真正值钱的地方，不是"并行"这两个字，而是worktree 隔离 + DD 当边界这个组合——物理上隔开文件目录，杜绝了两个 Agent 手忙脚乱改到同一处的可能；DD 文档顶上了本该由"多 Agent 互相通气"才能达成的共识，让互不通信的几个实例各自都清楚自己该做什么、不该碰什么。

长期来看，"多 Agent 协作"这个说法迟早会被拆解成更朴素的两件事：任务边界怎么划、状态怎么隔离。会通信的调度器不是必需品，物理隔离加一份写清楚的工作说明书，往往就够用了。