多智能体源码协作系列 · 第 1 篇 / 共 8 篇

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

本系列记录一套部署在三台物理机上、跑真实生产项目的多 Agent 协作系统的设计与取舍。所有机制均已投产，关键结论可复现。

当写代码的是 Agent：我们把这个时代的\”多进程问题\”又解了一遍

一、先看四个事故现场

在展开理论之前，先看四个场景。它们都来自我们生产环境的真实事件，细节已做泛化处理，但机制原样保留——如果你也在让多个 AI Agent 共享一份代码库，大概率似曾相识。

场景一：死掉的 Agent 留下一把\”幽灵锁\”。 一个 Agent 会话在认领了某个模块后中途崩溃。它声明的认领记录还挂在协调账本上，于是后续所有 Agent 都礼貌地绕开这个模块——没有人接手，任务停摆了半天，直到有人人肉发现\”这个会话早就死了\”。这和半个多世纪前进程崩溃后信号量不释放是同一类问题：锁的生命周期和持有者的生命周期没有绑定。

场景二：\”实习生\”拿着主人的钥匙。 我们早期给一个自动化脚本配置了 Git 凭据，它提交时用的身份和人类开发者完全一样。当它把一段未经评审的调试代码推进主线时，事后审计竟然查不出\”这是谁干的\”——因为 Git 权限模型是为\”人\”设计的，而 Agent 用的就是主人的身份。主体变了，身份体系没有跟上。

场景三：两次\”都通过测试\”的提交，合并后是错的。 两个 Agent 各自在本地分支修改同一个文件，各自跑完测试都是绿的，先后 push。Git 忠实地合并了文本——但两个修改背后是两个互相矛盾的意图：一个想把超时调大，另一个正想把超时调小。合并后的代码能跑，行为却是错的。Git 保得住文本，保不住意图。

场景四：未经验证的代码溜进了主线。 一个 Agent 直接在共享检出上改了几行代码，图省事跳过了构建验证就同步回主线。下游 Agent 基于这份\”带病\”的代码继续开发，错误被放大了一层才被发现。没有服务端强制校验时，\”约定\”只是建议。