一个人指挥四个 Agent：vibe 项目的多 Agent 并行开发工作流实战

你有没有过这种体验：开一个 coding agent 让它写登录页，然后你就坐在那儿刷手机等它跑完。十五分钟过去，它说写完了，你 review，发现按钮颜色错了，让它改，又等十分钟。一上午过去，你干完了"一件事"，其中 80% 的时间在等。

这不是 agent 慢，是你把它当成了打字员。agent 的真正用法是把它当员工——而员工，是可以同时雇好几个的。

核心判断先摆出来：一个人指挥 2 到 4 个 coding agent 并行干活，是 2026 年独立开发者最划算的生产力杠杆。但它也是最容易翻车的做法：四个 agent 同时改你的代码，没有章法就是四倍的灾难。这篇指南讲的就是这套章法：什么时候上并行、任务怎么切、隔离怎么做、怎么合流、怎么控成本，以及一份真实的踩坑清单。

这不是新概念。Simon Willison 在 2025 年 10 月就写过《Embracing the parallel coding agent lifestyle》（simonwillison.net/2025/Oct/5/parallel-coding-agents/），讲他怎么同时开三四个 agent 干活；Theo Browne 在 2026 年 10 月搞 ts-rust 编译器移植时，更是直接说自己的活不是写代码，是"管团队"——他同时跑十几个 agent 线程，每天早上像收邮件一样一个个 triage。下面这套东西，就是把这种玩法拆成普通人能照抄的步骤。

先泼冷水：什么时候值得并行，什么时候别折腾

并行不是银弹，它只在一种情况下成立：任务能拆成互不依赖的块。如果你的任务是"给这个函数修个 bug"，别并行——一个 agent 五分钟干完的事，开四个纯属行为艺术。

值得并行的信号有三个。第一，你手里有一张功能清单，各项之间依赖很弱：登录页、落地页、邮件模板、后台管理页，这是经典的可并行组合。第二，你在等一个 agent 跑长任务（比如"把测试覆盖率补到 80%"），手头闲着，不如再开一个。第三，同一个任务里"写代码"和"写测试""写文档"可以分开，后者几乎不需要你介入。

不值得并行的信号同样三个。第一，任务强耦合：A 的输出是 B 的输入，比如"先定 schema 再写 API"，这种串行依赖就别硬并行——让 agent A 等 agent B 的接口，能等到天荒地老。第二，你还没想清楚要做什么：需求模糊时开四个 agent，等于花四倍的钱加速制造垃圾。第三，你的心智带宽不够，这是硬上限：并行数量 = 你能同时 review 的 diff 数量，再多你就看不过来，review 不过来的并行等于没 review。

一句话：能并行的前提是"任务独立"，不是"agent 很多"。先拆任务，再开 agent，顺序别反。

任务切分：三条线够你应付 90% 的场景

切分任务有三条线：

按模块切（最常用）。登录模块、支付模块、通知模块，每个 agent 领一个。要求只有一条：模块之间通过明确接口通信，接口先定死。接口没定死就并行，等于让四个厨师在没菜谱的情况下做一桌菜。

按层切。前端一个 agent，后端一个 agent。适合前后端边界清晰的项目，比如 Next.js + 独立 API 服务这种。层与层之间同样要先定契约：API 的路径、参数、返回结构，写成文件提交到 main，所有 agent 都对着它开发。

按性质切（性价比最高）。一个 agent 写功能代码，一个 agent 写测试，一个 agent 写文档。写测试和写文档的 agent 几乎不需要和你交互，产出还直接可用。很多人不敢这么干，觉得"测试得等代码写完"——不用，接口契约在手，测试 agent 对着契约写 mock 先行，代码合进来再跑一遍就行。

三条线可以叠加，比如"前端 agent A 做登录页 UI，agent B 给登录接口写集成测试"。切分之前先干一件五分钟的事：在纸上把任务画成卡片，有依赖的连线。没有入边的卡片才能并行开工，有依赖的排后面。这个动作能省掉后面四小时的返工，别偷懒。

隔离：git worktree 一人一分支，谁也别踩谁

四个 agent 在同一个目录里跑，结局一定是互相覆盖、互相删文件、git 历史一团浆糊。隔离是并行的地基，有三层，缺一不可。

第一层：git worktree，每个 agent 独立工作目录 + 独立分支

这是整个工作流里最关键的一条命令，背下来：

# 给 agent-a 开一个独立工作区，分支 feature/auth-ui
git worktree add ../proj-agent-a -b feature/auth-ui

# agent-b：支付模块
git worktree add ../proj-agent-b -b feature/payment

# agent-c：邮件模板
git worktree add ../proj-agent-c -b feature/email-template

# 查看所有工作区
git worktree list

# 收工清理：分支合流之后删掉工作区
git worktree remove ../proj-agent-a
git worktree prune

铁律：agent 只能在自己的 worktree 里活动，push 到自己的分支，永远不许直接动 main。合并只由你来做，后面会讲为什么这个权力不能下放。

第二层：运行时隔离，端口和数据库都要分开

四个 agent 同时起 dev server，端口撞车是经典翻车现场。做法很土但有效：每个 worktree 配独立的环境变量。

#../proj-agent-a/.env.local
PORT=3101
DATABASE_URL=postgresql://localhost:5432/proj_a

#../proj-agent-b/.env.local
PORT=3102
DATABASE_URL=postgresql://localhost:5432/proj_b

#../proj-agent-c/.env.local
PORT=3103
DATABASE_URL=postgresql://localhost:5432/proj_c

数据库要么一人一个库（推荐，Postgres 建库就是一条 CREATE DATABASE 命令），要么至少表名前缀隔离。别让 agent A 的 migration 把 agent B 的数据扬了——这种事故修起来比写代码本身贵十倍。Redis 之类的共享服务也一样：db index 按 agent 编号分开，写进开工包里。

第三层：文件级约定，禁区写死

在开工包里明确：哪些目录是你的地盘，哪些是禁区。比如 schema.prisma 和 migrations 目录，除非你就是那个被授权改 schema 的 agent，否则碰都不许碰。依赖文件（package.json、pnpm-lock.yaml）默认也是禁区，确有需要先 @你审批。

开工包：agent 上岗前必须收到的四样东西

agent 不是人，不会"意会"。你含糊，它就自由发挥；自由发挥就是事故。所以每个 agent 开工前，给它一份书面开工包。最省事的办法：写进每个 worktree 的 AGENTS.md（或 CLAUDE.md，看你用的工具认哪个），再加一段本次任务的 prompt。四样东西缺一不可：目标、边界、验收标准、禁止事项。

模板直接抄：

# 开工包：登录页 UI（agent-a）

## 目标
在 app/[locale]/login 下实现登录页 UI，支持邮箱 + 密码登录。
视觉稿：design/login.png（已从 Figma 导出，照着还原）。

## 边界
- 只动 app/[locale]/login/ 和 components/auth/ 两个目录
- 不许改 prisma/schema.prisma，不许动 migrations/
- 不许新增 npm 依赖；要用新库先 @我 审批

## 验收标准
- [] pnpm build 通过，pnpm lint 无 error
- [] 移动端 375px 宽度下无横向滚动
- [] 登录失败显示中文错误提示，不许用 alert()
- [] pnpm test login 相关用例全绿

## 禁止事项
- 不许重构登录页之外的代码，"顺手优化"是最贵的优化
- 不许把密钥、token 写进代码或提交到 git
- 拿不准就停下来问，不要猜；猜错的代价比问贵十倍

## 汇报格式
完工后用 5 行以内告诉我：改了哪些文件、怎么验证、还有什么风险。

开工包的质量 = 并行质量的上限。写得越具体，agent 的自由发挥空间就越小，你的 review 负担就越轻。写开工包花 10 分钟，能省掉后面 1 小时的返工扯皮。这笔账一定要算清楚：你偷懒省下的 10 分钟，会变成 agent 自由发挥的 1 小时。

合流：你是唯一的 merger，谁也别想绕过你

并行开发里最危险的幻觉是"agent 说写完了 = 可以合了"。不行。你是这条流水线上唯一的 merger，所有分支必须经过你的 review 才能进 main，没有例外。Theo Browne 那种"让 agent 自己 merge"的玩法，是他跑了 150 个 PR、只出 2 个 regression 之后才敢给的特权——特权是终点，不是起点。你在到达他的量级之前，老老实实当守门员。

Diff review 清单：每次合流前逐条过

• 接口契约对上了吗？它改的接口签名，和其他 agent 依赖的一致吗？这是最常见的跨 agent 事故：A 改了返回字段，B 还在按老字段解析，合进去就是线上 500。
• 迁移冲突：prisma migrations 有没有两个 agent 各生成一个？有就手合并成一个，按时间顺序排好再合。
• 重复造轮子：agent B 是不是又写了一个和 utils 里现成的差不多的函数？agent 最爱干这事，review 时顺手删掉，告诉它下次先搜。
• 依赖新增：package.json 里多了什么？每个新增依赖问一句"真的需要吗"，agent 拉依赖比你还爽快。
• 测试是真绿还是假绿：自己跑一遍，别信 agent 的"测试通过了"。把它的验证步骤重跑一遍只要两分钟，信它一次可能要还两小时。

冲突仲裁三步

两个分支改了同一处，别慌，按三步走：先看，再定，后锁。先看：git diff 两个分支，把冲突点标出来；再定：接口层面的冲突以"先定好的接口文档"为准，谁偏离谁改，实现层面的冲突选更简单的那个；后锁：合流后立刻跑全量测试，绿了才算完，红了就 revert——先保 main 的干净，再慢慢修分支。

每天固定 1 到 2 个"合流窗口"

比如午饭前一次、晚饭前一次，集中处理所有待合流的分支。平时让 agent 们各自跑，不要来一个合一个——频繁切换上下文烧的是你自己的脑子。合流窗口之外，你的任务只有两件：写开工包，和回答 agent 的提问。守住这个节奏，一人管四个 agent 才不累。

费用与失控：并行 = 花费 ×N，先设预算再开工

这是最实在的一节。开 4 个 agent，你的 token 账单就是 4 倍速。Theo Browne 移植 ts-rust 时烧掉的 token 按 API 价算是 40 万美元量级——他走订阅实际只花了几百刀，订阅制就是并行玩家的护城河，这也是他同时开着好几个 Claude 账号的原因。你没他那体量，就得自己设护栏：

第一，per-run 上限。给每个 agent 设单次运行的费用或 token 上限。你用的工具如果支持预算参数就直接用；不支持就包一层 wrapper 脚本，统计用量超了自动停。没有上限的 agent 就像没有额度的信用卡，账单来的时候才知道心疼。

第二，定时 kill 巡检。每 30 分钟看一眼四个 agent 的状态。别看它的"思考过程"，只看产出：文件有没有变化、测试有没有推进、它有没有在等你回答问题。可以写个极简的巡检脚本定时跑：

# 巡检脚本示例：列出各 agent 会话的运行时长和最近产出时间
# 按你实际用的工具替换 agent-cli 这部分
for s in agent-a agent-b agent-c agent-d; do
echo "=== $s ==="
agent-cli session info "$s" --show-runtime --show-last-output-time
done

# 配合 cron 每 30 分钟跑一次，输出重定向到日志
# */30 * * * * /home/you/bin/agent-patrol.sh >> /home/you/logs/patrol.log

第三，僵尸 agent 识别与处决。判断标准很简单：30 分钟没有任何文件产出、也没有向你提问的 agent，就是僵尸。别心疼，直接杀掉会话，分支删掉重开一个。僵尸 agent 最大的成本不是它烧掉的 token，而是它占着一个任务名额、让你误以为"有人在干"——等你发现它一下午啥也没干，时间已经没了。杀僵尸要快、要狠，这是当"管理者"的基本功。

第四，每日预算封顶。比如每天 20 美元（按你的订阅或用量折算），到了就停，明天再说。并行最大的诱惑是"反正机器在跑"，但机器跑的每一秒都是钱。把每日花费记下来，一周后你会清楚地知道：哪个 agent 性价比高，哪个任务不值得并行。

一句话：并行之前先算账，算不清账的并行叫烧钱。

反模式清单：这些坑都是真金白银踩出来的

• 两个 agent 同时改 schema。A 加了个字段，B 删了个字段，migration 打架，数据库起不来。解法：schema 是"独占资源"，一次只许一个 agent 碰，或者干脆由你亲手改。这是隔离第三层里禁区条款存在的原因。
• agent A 等 agent B 的接口等到天荒地老。你让 A"等 B 的登录接口好了再联调"，A 就会每隔十分钟问你"B 好了吗"。解法：接口先定死写成文件，A 对着 mock 数据开发，联调统一放到合流窗口做。永远不要让 agent 之间产生运行时依赖。
• review 走马观花，把 bug 合进 main。并行最累的是 review，累了就容易"看着差不多就合了"。解法：合流清单是 checklist 不是建议；累了就歇，main 的干净比今天多合一个分支重要一万倍。
• agent 互相"帮忙"。你没拦着的话，agent A 会跑到 agent B 的目录里"顺手修个 bug"，然后两个分支全乱，git 历史没法看。解法：开工包里写死活动目录，发现越界一次就警告——这等于代码审查里的红线，碰一次就谈话。
• 开工包写得太粗，四个 agent 四种理解。"做个好看的登录页"这种描述，四个 agent 会给你四个风格的登录页。解法：验收标准必须是可检查的——命令、像素、文案，形容词一律翻译成数字。"好看"= 对照 design/login.png 还原，色值误差为 0。

今日开工 SOP：最小可用的一套流程

把上面全部收成一张每天能照抄的清单：

1. 列出今天的任务卡片，画依赖线，挑出无依赖的 2-4 张
2. 接口先定死：共享的 types / API 契约写成文件，提交到 main
3. git worktree 一人一个，分支名 feature/<任务>-<agent名>


4. 每个 worktree 放一份开工包（AGENTS.md + 本次任务 prompt）
5. 环境变量区分端口和数据库，dev server 先都跑起来确认不撞车
6. 启动 agent，告诉它："完工按汇报格式告诉我，拿不准就问"


7. 每 30 分钟巡检一次：只看产出，不看"思考过程"
8. 僵尸 agent（30 分钟无产出、无提问）直接杀掉重开，不纠结


9. 逐个分支过 diff review 清单（接口契约/迁移冲突/重复造轮子/依赖/真绿假绿）
10. 冲突按"接口文档为准、实现选简单的"三步仲裁
11. 合流后跑全量测试：绿了收工，红了 revert，先保 main 干净
12. git worktree remove 清理已合流的工作区


13. 看一眼今天的 token 账单，记下来
14. 没干完的任务分支留着，明天接着跑——分支就是你的"进度保存"

最后说一句大实话：多 agent 并行的本质，是把"你写代码"变成了"你管一个四人小团队"。而管团队的本事——拆任务、定接口、做 review、控预算——和写代码的本事是两套肌肉。Simon Willison 和 Theo Browne 玩得转，不是因为他们 prompt 写得好，而是因为他们早就想明白了：在 agent 时代，你的核心产出不是代码，是判断。代码让 agent 写，判断留给自己。这才是"一个人指挥四个 agent"真正的分工。