本系列记录一套部署在三台物理机上、跑真实生产项目的多 Agent 协作系统的设计与取舍。所有机制均已投产，关键结论可复现。当写代码的是 Agent：我们把这个时代的"多进程问题"又解了一遍一、先看四个事故现场在展开理论之前，先看四个场景。它们都来自我们生产环境的真实事件，细节已做泛化处理，但机制原样保留——如果你也在让多个 AI Agent 共享一份代码库，大概率似曾相识。场景一：死掉的 Agent 留下一把"幽灵锁"。一个 Agent 会话在认领了某个模块后中途崩溃。它声明的认领记录还挂在协调账本上，于是后续所有 Agent 都礼貌地绕开这个模块——没有人接手，任务停摆了半天，直到有人人肉发现"这个会话早就死了"。这和半个多世纪前进程崩溃后信号量不释放是同一类问题：锁的生命周期和持有者的生命周期没有绑定。场景二："实习生"拿着主人的钥匙。我们早期给一个自动化脚本配置了 Git 凭据，它提交时用的身份和人类开发者完全一样。当它把一段未经评审的调试代码推进主线时，事后审计竟然查不出"这是谁干的"——因为 Git 权限模型是为"人"设计的，而 Agent 用的就是主人的身份。主体变了，身份体系没有跟上。场景三：两次"都通过测试"的提交，合并后是错的。两个 Agent 各自在本地分支修改同一个文件，各自跑完测试都是绿的，先后 push。Git 忠实地合并了文本——但两个修改背后是两个互相矛盾的意图：一个想把超时调大，另一个正想把超时调小。合并后的代码能跑，行为却是错的。Git 保得住文本，保不住意图。场景四：未经验证的代码溜进了主线。一个 Agent 直接在共享检出上改了几行代码，图省事跳过了构建验证就同步回主线。下游 Agent 基于这份"带病"的代码继续开发，错误被放大了一层才被发现。没有服务端强制校验时，"约定"只是建议。