WORKHUB DEV LIFE · 07

3 个 AI 一起写代码，真正难的不是模型，而是边界

多安排几个 Agent，不会自动得到一支团队。即使只用一个 AI，把角色、边界、交接和停手写清楚，也更不容易把项目带偏。

上一篇我写了一个多 Agent 实验：三个 AI 被放进同一套代码里，各自朝着不同方向改，最后先互相覆盖，再互相清理。

这个故事最容易被记住的部分，是“AI 打起来了”。但真正值得留下的，其实是后半句：多安排几个 Agent，不会自动得到一支团队。

如果我要把三个 AI 放进一个项目，我不会先问它们谁更聪明。我会先写四条规矩：谁负责什么、哪些文件能改、怎样交接、冲突时谁停手。

即使你现在只用一个 AI，这套方法也有用：把规划、实现和审查拆开，单个 AI 也更不容易把项目带偏。

这不是给 AI 戴手铐，而是给协作划出一条能回头的路。

01 · ROLE

不要给三个 AI 同一句大任务

“把这个项目做完”听起来很完整，实际上没有告诉任何一个 Agent：它现在应该做哪一小段、做到什么算完成、能不能动别人负责的文件。

我会先把工作拆成三个角色。

• 规划 Agent
   只负责读需求、读现有代码和写执行计划。它可以提出方案，但不直接改业务文件。
• 实现 Agent
   负责一个明确的功能切片，拥有自己的目录，完成后提交变更说明。
• 审查 Agent
   默认只读。它检查类型、边界、构建和交互，指出问题，但不悄悄替实现 Agent 重写一遍。

这样拆以后，三个 Agent 的关系不再是“同时抢键盘”，而是“计划、实现、审查”三段接力。

比如做一个登录功能：规划 Agent 先写出接口和验收项；实现 Agent 只改 src/features/login/；审查 Agent 只检查构建、错误提示和异常状态，最后由协调人决定是否合并。每个角色都能推进事情，但没有谁可以悄悄改完整个项目。

02 · BOUNDARY

文件边界比提示词更重要

很多协作失败，不是因为任务描述不够长，而是因为所有 Agent 都能碰同一批文件。

我会在项目开始时写一张很小的“文件地图”：

• 规划 Agent：只写 docs/plan.md 和 docs/decisions.md
• 实现 Agent：只改分配到的 src/features/xxx/，不改全局配置
• 审查 Agent：只写 reports/review.md，不直接覆盖实现
• 协调人：负责合并、处理共享配置，以及决定是否回滚
  

  能读不等于能写，能写也不等于能合并。权限越清楚，回滚越简单。

共享文件是最危险的地方。package.json、数据库迁移、路由入口和全局样式，最好一次只允许一个角色修改；其他 Agent 如果需要变更，先写提案，等协调人确认。

我喜欢在雨天的共享空间里写东西：大家坐在同一片屋檐下，却各自有一张桌子。多 Agent 协作也应该如此：共享项目上下文，不共享所有写权限。

协作需要共享视野，也需要保留边界。

03 · HANDOFF

“完成了”不是交接信息

我以前看到 Agent 说“已完成”，会下意识地打开浏览器检查。后来我发现，真正缺的不是一句完成，而是一份可以让下一个人接着走的交接。

现在我要求每个实现 Agent 至少留下五项内容：

1. 这次实际完成了什么
2. 修改了哪些文件，为什么改
3. 对外暴露了哪些接口、字段或交互约定
4. 还剩哪些已知问题，哪些问题没有验证
5. 用什么命令验证过，结果是什么
   

   交接卡只记录下一位协作者真正需要的信息，不追求漂亮的总结。

如果一个 Agent 无法回答“我改了什么”和“我没验证什么”，那它还没有完成交付，只是停止了生成。

04 · STOP RULE

冲突时要有一个明确的停手人

三个 Agent 同时工作时，冲突一定会发生。关键不是幻想冲突消失，而是提前规定谁有权暂停流程。

1. 审查 Agent 发现冲突，只记录证据和影响，不继续扩大修改范围。
2. 实现 Agent 只修复自己负责的切片，不顺手重构共享模块。
3. 协调人决定接受、回滚或拆分变更，并更新决策记录。
4. 只有重新通过检查，下一项工作才继续进入队列。
   

   冲突处理的终点不是“谁赢了”，而是项目回到一个可验证的状态。

COPY THIS

一张可以直接复制的协作协议

如果要把这套方法交给一个新项目，我会把下面这段放在仓库的 AGENTS.md 或项目说明里：

角色：规划 Agent 只读并输出计划；实现 Agent 只负责分配的功能目录；审查 Agent 只读检查并输出报告；协调人负责共享文件和最终合并。边界：没有目录所有权就不能修改文件；共享配置必须先提案；不得覆盖其他 Agent 未交接的工作。交接：每次变更必须说明完成项、文件、接口约定、未验证风险和验证命令。停手：构建失败、公共接口冲突或越权修改时，立即停止扩散，保留现场，等待协调人决定。

它不复杂，也不保证一次就能把协作做对。但它把“请大家配合一下”换成了可以检查的动作。

THE TAKEAWAY

多 Agent 不像多请了三个同事，更像同时打开了三个终端。终端变多以后，最先需要增加的不是算力，而是交通规则。

我现在对 AI 协作的期待也简单了一点：不是让它们替我做完所有事，而是让每一次修改都知道自己从哪里来、要交给谁、出了问题怎样退回来。

如果你要在自己的项目里先试一条规则，我建议从“审查 Agent 默认只读”开始。它最容易执行，也最容易看出边界带来的好处。

你会把哪一个环节交给只读的 AI 审查者？欢迎把你的项目类型和最担心的冲突写在留言区。

WORKHUB DEV LIFE

白天写代码，也认真做小产品。记录 AI 如何参与开发，以及那些只有真正交付后才会遇到的问题。