利用Git引用与CRDT协调多个AI编程智能体

传统多Agent并行编程：难点不在于Git合并，而在于“分支角色混乱”

在自动化编程和软件工程领域，团队越来越依赖多个AI Agent同时干活。两个AI智能体并行开发时，看似天然应该用Git分支来隔离彼此的工作，但真正跑过路的人都知道，结果往往是一团乱麻。问题并不在于Git合并文本的能力，而在于一个分支被同时赋予了三种彼此冲突的角色：它既是Agent私有的临时工作区，又是Agent之间互相通信的协调状态，还得是项目最终被接受的状态。一个东西承担三种身份，自然会崩。 这个实验展示了另一种做法，让两个AI Agent从一开始就基于同一份基础代码，彼此看不见对方的会话，各自把修改作为不可变操作发布到属于自己的私有Git引用（refs）上，最后通过一个无冲突复制数据类型（CRDT）把双方的意图“叠”在一起。最关键的是，协调器从不把任何一个Agent的分支合并进工作分支，最终却能生成同时包含双方修改的任务状态，而且整个结果可以仅凭Git存储库里的对象和引用来重建。这意味着，一个全新的会话不需要任何Agent的对话记录，也可以完整还原成果。

核心思路：先把“状态”从“分支”里剥离出来

为什么分支方案先天不足

在传统自动化编程协作中，开发者习惯用分支表示“我改到哪了”。但在多Agent协作场景里，这会让分支变得极其沉重。本地未提交的私有工作、已经确认要对齐的团队共识、最终要交付的正式版本，全压在分支这一个概念上。一旦其中任何一个Agent需要长期工作，分支就会失衡，Git仓库状态也会变得难以理解。 这个实验的核心解法，是引入一个轻量的协调层，这个协调层由Git对象库、私有引用，和一个确定性的CRDT归并函数构成。每个Agent只向自己的私有引用上追加操作，而不是往共享分支上合并代码。

CRDT在这里不是用来合源码的

需要明确一点，“无冲突”并不是说任意两段并发修改的源代码在语义上都能正确结合。它指的是，Agent们发布的是结构化意图（操作），而不是直接改完的代码文件。所有合法的操作构成一个集合，操作之间通过CRDT的合并规则，可以得出确定性的收敛结果。至于结果是否在业务上真的正确，还是需要人来审核或后续自动化测试来把关。

手把手跑通一次双Agent并行协作实验

第一步：搭建一个带两个私有引用的仓库

先新建一个Git仓库，准备好主分支（main 或 master）以及两个Agent各自的专用引用，比如refs/heads/agent-alpha 和 refs/heads/agent-beta。所有参与者都从同一个初始提交开始，保证基线一致。

第二步：定义操作集和CRDT归并规则

这个场景里，任务是一个带有两个独立字段的对象，一个是任务状态“status”，另一个是验收要求“acceptance”。Agent Alpha负责把状态从 open 改为 in_progress，Agent Beta负责写入一条新的验收要求。每个操作都包含操作ID、Agent标识、字段名、旧值和新值。CRDT的归并规则可以很简单：对于不同字段，直接同时生效；对于同一字段，则使用操作ID作为全局唯一顺序依据，按操作表的顺序决定最终值。这样无论先应用Alpha再应用Beta，还是反过来，最终结果都一样。

第三步：两个Agent各自发布操作

每个Agent在自己的工作区里完成修改后，不直接提交到工作分支，而是把一条不可变操作记录写入Git对象库，并只前进自己的私有引用指针。比如Alpha更新refs/heads/agent-alpha，Beta更新refs/heads/agent-beta。这一步非常干净，双方完全没有发生任何分支合并或代码折叠。

第四步：用Git refs同步，而不用merge

协调器从Git对象库里直接读取两个私有引用指向的提交，提取其中的操作内容，再交给一个纯函数（reducer）处理。这个reducer是确定性的，只要输入的是同样的操作集合，不管按什么顺序喂入，输出都一样。这就是CRDT的互换律和幂等律在起作用，重复回放同一操作也不会重复应用。

第五步：物化最终接受状态

协调器把归并后的操作结果，转换成一份完整的任务文件，生成一个新提交放到工作分支上。这个提交不是任何Agent分支的合并提交，而是协调器自己生成的一个产物。最终的任务文件里，Alpha把状态字段改成了 in_progress，Beta新增了验收要求，两边的贡献都在。

第六步：验证会话能否重建结果

实验最后要证明的是，模拟一个全新的恢复场景：彻底关掉协调器和所有Agent进程，只留下Git仓库，然后从最新的工作分支提交开始，倒推出所有Agent的私有引用和已提交对象，再走一遍相同的归并流程，得出来的结果必须和之前完全一致。这一步通过后，整个方案的可靠性就有了硬保障。

这个方案到底要验证哪些关键点

根据原文的实验要求，验证协议覆盖以下内容，少了任何一项都不能算真正跑通：

• 所有Agent必须从同一个基础提交出发，基线完全一致。
• 每个Agent都能在完全不接触其他Agent工作区或对话记录的前提下独立工作。
• 每个Agent都有自己专属的发布引用，互相之间没有任何竞争。
• 操作ID采用全局唯一机制（例如UUID），保证不碰撞。
• 先应用Alpha后应用Beta的结果，与先应用Beta后应用Alpha的结果完全一致。
• 同一操作重复回放不会改变结果，也就是具备幂等性。
• 最终任务文件同时包含两项独立修改。
• 工作分支上没有任何来自Agent分支的合并提交。
• 新会话仅凭Git引用和已提交对象即可重建完整结果。

这些验证点意味着，这套协调模式已经具备直接落地到自动化编程流水线的基础，而不只是停留在概念验证。

对接真实编程Agent时，要注意哪些坑

真实世界中的编程Agent通常都会修改多个文件，生成大量代码变更。直接把CRDT套用到源码级别并不现实。更稳妥的做法是，让Agent输出结构化的“意图声明”，例如“新增一个接口”“修改某个函数的调用签名”，再通过一个受控的转换层把这些意图变成具体改动。人工或自动审核依然非常重要，尤其是在冲突可能影响业务逻辑的情况下。 另外，实验中也明确指出了一些容易失败的场景：当两个Agent修改同一个字段时，CRDT不能解决语义冲突，只是提供一个确定的排序结果；如果Agent产生了大量不可预测的随机性操作，操作表会膨胀，需要归档策略；再就是Git对象库不断积累不可变操作，长期运行时要考虑垃圾回收机制是否会影响历史重建能力。 在生产环境的加固方面，可以考虑引入操作日志压缩、定期做状态快照、把协调器做成持久化服务，以及为每个Agent增加权限控制，限制其只能写自己的私有引用。这些改进并不会改变核心模型，只是让它更健壮。

这个模型有多大价值

给两个或更多AI Agent搭一个并行协作框架，关键在于不要让某一个分支同时承担“私人草稿箱”“交流信箱”和“正式发布公告栏”三个职责。用Git refs承载私有操作通道，用CRDT对操作做最终态归并，再用协调器生成被接受的状态，这条路既巧妙，又非常工程化。它不需要对Git本身做任何扩展，只需要一套定义良好的操作协议和一个纯函数，就能在现有的Git服务上实现多Agent的可靠协作。 这个思路对自动化编程和软件工程实践很有参考价值。如果你正在搭建基于AI的编码流水线，或者正在为多个Agent如何共用一个代码仓库而发愁，这套“Git引用+CRDT+确定性归并”的模型值得花一个小时完整地跑一遍。得到的最重要结论是，多Agent并行不会因为Git退出冲突模式就自动成功，真正需要的是让每个Agent的意图变得可合并、可重放、可恢复。