夜雨聆风
我让 4 个 AI 同时干活,结果它们打起来了
上一篇我介绍了一个偷懒的招：把历史对话扔给 subagent，让它去写 wiki。
我那天兴致一上来，干脆开了 4 个 subagent 并行干活，准备见证奇迹。
奇迹没等到，等到了一场凶案现场。
回过头看，这不是 AI 的锅，也不是 prompt 写得不够好的锅。这是一切「主-从并行」协作里都会出现的老问题，人类用了 30 年才学会怎么处理，AI 协作还在原始社会。
现场还原：4 个工人同时进场
任务很简单：我让一个主 AI（直接和我对话的那个）做规划，然后派 4 个 generalPurpose 类型的 subagent，每个 subagent 写 1 篇 synthesis 文档。
4 篇文档主题完全独立，互不重叠。听起来是教科书级的「可并行任务」。
为了稳妥，我在每个 subagent 的 prompt 里都加了一句：
你只负责写自己那篇 synthesis。不要更新 index.md，也不要更新 log.md，最后我统一来更。
加粗、感叹号、能用的强调都用上了。然后 4 个一起启动。
不到 5 分钟，4 个 subagent 全部「任务完成」返回。每个都很礼貌地告诉我：「您的文档已写入 synthesis/xxx.md，共 ××× 行。」
我一看，4 篇文章都齐齐整整在那躺着，内容质量也不错。
完美。
翻车瞬间：少了 3 条记录
我准备做最后的统一更新，打开 index.md，傻眼了。
之前其他 AI 工具陆陆续续写过的 3 条索引记录，消失了。
不是错位，不是格式乱，是干脆没了。
log.md 里也少了几条历史条目。我盯着屏幕愣了几秒：刚才不是只让它们各写各的吗，谁动的目录？
排查：抓到那个不老实的
我把 4 个 subagent 的执行日志一条条捞出来看。
3 个 subagent 老老实实，只写了自己那篇 synthesis，碰都没碰 index.md 和 log.md。
第 4 个，干了一件事：
它写完自己的 synthesis 之后，「贴心地」打开了 index.md，发现里面没有自己刚写的这一条。它的 AI 大脑里大概飞过这么一句台词：「这里漏了我，我帮加上。」
然后它重写了整个 index.md 文件，只包含它自己那一条。
把另外 3 条原有记录、再加上其他几个 subagent 还没来得及被加进去的记录，一起冲没了。
我在 prompt 里写的「不要更新 index.md」，它当没看见。或者它看见了，但觉得「我这是在帮你」。
更扎心的是：这种「自作主张」的概率不高，10 个 subagent 里大概 1 个会犯。但只要犯一次，整个目录就废了。
根因：这不是 AI 的问题，这是并行的问题
我冷静下来想，这事换成 4 个真人也一模一样。
想象 4 个员工同时编辑一份共享 Excel：
1.没有 git
2.没有锁
3.没有「谁在改这一行」的提示
4.每个人都基于自己打开的版本写东西
5.后保存的把先保存的覆盖了
这是计算机科学里最古老的问题之一，叫写冲突（write conflict）。
Git 用 30 年教会了我们：先 pull，再改，再 push。冲突了要 merge。
可 AI subagent 之间是什么状态？
1.互相不知道对方存在
2.没有任何通信通道
3.每个都觉得自己是唯一在改文件的
4.写文件的方式是「整篇覆盖」，不是「追加」
这等于退回到了「多个人编辑同一份共享文档但谁也不知道别人也在编辑」的石器时代。
冲突是必然的，不冲突是运气。
解法：班长制
那天晚上我重新设计了规则，叫班长制。
核心就一句话：共享文件由一个人改，独立文件随便分给谁改。
具体三条规矩：
第一条：subagent 只写自己的「独立文件」
比如各自的 synthesis 文档，谁的归谁，不重叠不冲突。
第二条：所有「共享文件」必须由主 AI 串行写
index、log、目录性的、聚合性的，一律走主 AI 这一道。subagent 只能「汇报我写完了什么」，不能自己去登记。
第三条：这条规则要写进 wiki 的 schema 里
不能靠每次 prompt 临时强调。Schema 是宪法，subagent 启动前会读，写在那里就是硬约束。
我做完这件事之后，又跑了几次同样的并行任务，再没翻车过。
通用启示：不止 AI，不止并行
事故复盘到这里，技术问题已经解决了。但这件事让我琢磨了好几天，有几条更普适的东西想分享。
第一条：并行听起来很美，但只有「任务能完全切片」才适用。
4 个 AI 写 4 篇独立文章，安全。
4 个 AI 同时维护一份目录，必然冲突。
判断一个任务能不能并行，不是看你想不想快，是看任务的「产出物」有没有重叠。重叠的部分越多，并行带来的麻烦就越大，可能比串行还慢。
第二条：AI 的「自作主张」是协作里最大的不稳定因素。
你写「不要做 X」，10 个里 9 个会照办，1 个会觉得「我帮你做了更好」。
这事在带人的时候也熟——交代过的事还是会被人按自己的理解重做。区别是你和人可以事后吵一架达成共识，AI 不会被你骂醒，下次该越权还会越权。
防御性设计就要假设那 1 个会越权，通过权限和流程把它「想越权也办不到」。
第三条：软规则不够，要硬约束。
Git 之所以解决了写冲突，不是因为程序员都很自觉先 pull 再 push，是因为不 pull 就 push 不上去——硬约束。
AI 协作如果只靠 prompt 里的「请不要 XX」，等于在共享文档上贴一张「请勿编辑」的纸条。99 次有用，1 次有人撕了纸条进去乱改，整个文档就废了。
要么权限隔离（subagent 根本没权限写共享文件），要么强制串行，要么加锁。能用代码约束的，别用语言约束。
第四条：班长制不止 AI 适用。
带过项目的人都熟：3 个人一起干一件事，最后一定要有一个人收口、合并、对外。没有这个人，就是「3 个版本的方案各自往前推，最后谁也不认谁」。
AI 协作只是把这件事浓缩到了 5 分钟内发生而已。
主-从并行的协作里，永远要有一个班长。
写在后面
AI Wiki 系列写到这里，4 篇了，正好收个尾。
回头看一下这 4 篇的脉络：
#1《和 AI 聊的干货第二天就没了》
聊天记录是流水，wiki 是河床。让 AI 自己写、自己读结构化笔记，知识才会复利。
光说「写 wiki」没用，得把规则写死：什么时候写、写在哪、怎么取名、归档判断三档。Schema 是整个系统的地基。
新写的能归档，老对话也能捞回来。用 subagent 批量处理历史会话，省下大量手工活。
#4 也就是这一篇
并行听起来很美，但要有班长。共享资源永远是协作里最脆的那环。
整个系列写下来，我自己最大的感受不是「AI 多厉害」，是「AI 协作把人类协作里所有的老坑又走了一遍」：版本冲突、权限边界、责任划分、自作主张……每一条都不新，只是换了个主语。
工程的智慧是普适的。30 年前用在版本控制上的招，今天换个皮就能用在 AI 上。这大概是这个系列写完之后我最舍不得的一条收获。
这个系列就到这里了，下一个系列见。
👉 推荐阅读