智能体高并发如何改变 Git 后端设计

GitHub 的 Git 存储架构 Rubicon，正在应对智能体密集推送带来的压力。所给节选称，测试中有 5,000 个智能体同时操作一个仓库，每秒发送 7,200 次 push，读取仍保持低延迟。文章将其与 OpenAI 的 Pando 对照：吞吐量之外，更需要程序员理解的是仓库一致性承诺的变化。

目前能确认什么

摘要没有说明放弃了哪项保证，但节选给出了答案：两个系统都不再承诺，客户端能读到整个仓库所有引用在同一时刻的快照。

引用（ref）可以理解为指向提交的名字，分支就是常见例子。单个分支的更新仍保持串行化；但读取多个分支时，拿到的分支头可能分别来自不同时刻，不能直接视为一张同步快照。

这种拆分与 Git 的数据结构有关：对象不可变，并按内容命名，多个写入方可以并行存储对象；引用更新才需要协调。Rubicon 将 pack 数据放入 Azure Blob Storage，由 Ref-CAS 协调引用更新，事务只锁定涉及的引用。

按节选描述，Rubicon 仍处于有限私有预览。测试数字也不能直接当作任意仓库的吞吐承诺，给出的材料没有交代完整负载和延迟指标。

我的判断

对程序员最直接的影响，是检查自动化脚本是否把多个分支头当成同一时刻的状态。镜像同步、跨分支发布、比较多个分支后决定操作的工具，都可能依赖这个前提。

单分支更新有序，不等于跨分支读取一致。

每个智能体使用独立分支，可以减少同一引用上的竞争，但最终合入主干仍需协调。至于跨引用事务的具体边界、客户端怎样获取一致视图，还要等官方技术说明确认，不能仅凭协议兼容就认定旧脚本语义完全不变。