OpenAI 如何改造 Git 应对编程 Agent 并发

AI 编程代理同时开出十几个分支，每次 push 又触发多个 CI 任务拉取同一份提交，Git 服务面对的就不再是人的操作节奏。OpenAI 为此构建了兼容标准 Git 客户端的新后端 Pando，自报 push 中位延迟降低近 80%，每天提供接近 1 PB 的 Git 数据。

这套设计最值得读的地方，是它如何取舍一致性：保住同一分支的更新顺序，放弃所有分支在同一时刻的统一快照，再通过复用 packfile 承接大量读取。性能数字很亮眼，但适用条件也很明确。

为什么不同分支的 push 要互相等待

原文转述，OpenAI 的 monorepo 在作者所说的「去年年底」开始出现 fetch、push 变慢和合并失败，可靠性一度低于 90%。原文没有给出这个相对时间对应的具体年份。压力来自两个方向：大量客户端向不同分支写入，以及开发环境、研究任务和 CI 反复读取相同历史。

要理解解决办法，先区分 Git 存储的两类数据。

对象（objects）包括 blob、tree、commit 和 tag，它们不可变，由哈希标识。同一个对象复制到哪里，内容都不会变。引用（refs）则是指向提交的可变指针，例如分支指向的最新提交。两个客户端同时修改同一分支时，服务端必须裁定谁能成功。

原文比较了两种分布式方案。全副本之间采用三阶段提交，需要多数副本接受更新，多轮协调和副本磁盘速度都会进入 push 的等待链路。另一种方案把 packfile 并行写入 blob 存储，再通过共享 manifest 的比较并交换（compare-and-swap）操作排列更新顺序。上传能并行，但所有更新争用一个 manifest，各副本还得读取并索引日志里的 pack。OpenAI 的模拟显示，后一种成本会体现在读取延迟上。

Pando 的选择是缩小协调范围。收到 push 后，先把 packfile 存成不可变 blob，再在元数据存储中记录 ref 的新版本，包含新提交位置、关联 pack 和依赖关系。同一 ref 的更新保持可串行化，不同分支则可以并行推进。

Pando 保留了单个 ref 的更新顺序，放弃了跨 ref 的全局时点快照。

代价也很具体：连续读取两个分支，不能再假设读到的是整个仓库同一时刻的状态。普通功能分支和 CI 通常能接受；依赖多分支原子视图的工具需要重新检查。

fetch 为什么可以少做很多重复计算

写入之外，Pando 还改了 Git 通信中两处容易膨胀的工作。

第一处是 ref 通告。Git 通常在 push 或 fetch 开始时通告 refs，分支越多，列表越长。Pando 只通告选定集合；对新功能分支，使用指定的主干分支作为基准，让通告规模不随分支总数继续增长。团队还提到向 Git 贡献「explicit haves」概念，让服务端能够将分支顶端信息与历史信息分开通告。

第二处是 packfile 的生成。常规 Git 通常根据客户端的 have/want 协商，为每个客户端计算所需的 pack。大量 CI 拉取相同提交时，这部分计算存在重复。

Pando 使用 push 阶段记录的提交映射，查出客户端已有和缺少的内容，再通过 Git 的 packfile-uri 机制返回下载链接。客户端从便于缓存的服务下载预先准备好的 pack。作者转述，区域缓存让它能够跑满 10 Gbps 链路。

这里的收益有一个明确前提：许多读取请求需要相同或可复用的数据。CI 扇出越明显，复用就越有价值。

小 push 又会带来大量小 pack，影响压缩和协商效率。因此，Pando 在后台采用类似日志结构合并树（LSM tree）的压实方式，把 pack 从 L0 到 L4 按几何层级合并。较少、较大的 pack 有助于改善压缩效果和首字节时间，也让前台请求少承担整理工作。

延迟降低近 80%，证据能支持到哪一步

OpenAI 表示，团队用 Rust 花了 10 周构建 Pando，验证方式包括兼容性测试套件和确定性模拟测试。部署时先把它放在旧系统前面，作为读写穿透代理，再通过内部 Git CLI 包装器分批迁移客户端。

这条迁移路径很实用：先接住真实流量，再逐步扩大范围，不必一次切换所有开发环境。

上线后的数据包括：push 中位延迟降低近 80%，与「提速近 5 倍」的表述一致；合并可靠性改善；单小时提供超过 57 TB 的 pack，缓存命中率超过 99%。每天接近 1 PB 的数据量，则说明读取和缓存体系承担了相当大的吞吐。

但这些都是公司自报结果。原文没有提供独立基准，没有跨仓库形态对比，也没有给出尾延迟和完整成本拆分。「少量 CPU 核心」不足以说明存储、网络、缓存及后台压实的总成本。

形式化验证的描述也要单独看待。团队称，使用 GPT-6 Astra 的代理编写了 Lean 和 TLA+ 规格，并持续对 Git 和 Pando 进行红队测试。但规格没有公开，也没有披露发现了什么缺陷。因此，这能说明他们采用了哪些验证手段，不能据此认定整个系统已获得完整正确性证明。

我的判断

我认可这套设计的方向：先确认业务需要什么保证，再决定协调应该发生在哪里。不同功能分支之间通常没有必要为每次 push 建立全局顺序，而相同提交被多个 CI 任务读取，也适合使用共享数据和缓存。

不过，弱化一致性不是免费的性能优化。发布、镜像或仓库分析工具如果同时读取多个 refs，就要确认自己是否依赖统一快照。仅仅保持 Git 客户端兼容，并不能替这些工具回答语义是否仍然满足要求。

与继续扩充全副本资源、优化共享 manifest 相比，Pando 改动了协调边界，理论上更贴合大量分支并行写入的负载。但作者没有给出足够的对照数据，无法判断普通团队采用同类设计是否划算。

这是一个重负载 monorepo 的架构案例，还不是可直接部署的通用方案。

原文只说 OpenAI 正探索向开源社区分享技术的方式，目前不能自行运行 Pando。对多数前端和全栈团队，理解它如何减少协调与重复计算，比等待替换 Git 后端更有用。

能拿来做什么

• 如果 CI 经常等待 fetch，先统计相同提交被多少任务重复拉取，以及时间花在协商、传输还是本地处理。Pando 的经验支持优先检查重复读取，但没有证明所有 fetch 瓶颈都能靠缓存解决。
• 如果团队大量使用 AI 编程代理并行开分支，观察并发 push 是否影响其他分支，并检查发布、镜像脚本是否依赖多个 refs 的统一快照。这能帮助判断服务端扩容或迁移时哪些语义必须保留。
• 如果维护内部 Git 服务，可以关注原文提到的上游贡献：packfile-uri 中断与续传修复、更好的 tracing，以及 explicit haves。它们比尚未开放的 Pando 更可能先进入现有工具链，具体可用版本原文没有说明。
• 如果要评估类似架构，分别测量不同分支写入并发和相同提交读取并发，再补上尾延迟与总成本。只看 push 中位数，无法判断高峰期体验和运维代价。