OpenAI 如何用 Pando 后端扩展 Git 以支撑 Codex 智能体规模开发

OpenAI 工程团队发文介绍其为 monorepo 自研的 Git 仓库后端 Pando。过去一年，Codex 让工程师能并行推进更多工作，分支、推送、合并与 CI 拉取需求叠加，原有系统出现拉取和推送缓慢、合并失败，可靠性一度低于 90%。Pando 在不中断工程工作、不改变团队使用 Git 方式的前提下完成替换，现已承载 OpenAI monorepo 的全部开发。 Pando 的两个目标是写入水平扩展与读取吞吐最大化：前者针对大量分支的并发推送，后者让客户端能跑满可用网络带宽。它同时保持与 Git 协议和客户端兼容，使工程师和智能体都能沿用现有工作流。生产环境中，Pando 将中位推送延迟降低近 5 倍，每天交付近 1 PB 的 Git 数据。 文章先回顾 Git 的对象与引用模型：对象分为 blob、tree、commit、tag，按内容哈希标识且不可变；分支和标签是指向 commit 的引用。fetch 时客户端告知所需与已有的 commit，服务端据此生成 packfile；push 则请求更新引用，且发送的 pack 可能依赖服务端已有对象。复制仓库必须同时保证对象与引用可用，并协调对同一分支的竞争性更新。 OpenAI 评估了两类常见方案。三阶段提交（3PC）在每个副本保存完整仓库，推送需多数副本接受引用更新，协调过程多轮往返，副本磁盘性能与通信延迟都落在推送路径上。基于 WAL 的方案用 blob 存储中的共享 manifest 排序更新，通过 compare-and-swap 原子替换，但即使推送无关分支也要竞争同一 manifest，批量提交则以排队和延迟为代价。 Pando 选择放宽两项常见假设：不再提供全仓库一致的时间点快照，改用因果一致性，让不同分支的更新独立并行，代价是同时查看多个分支的读者可能看到不同时间点；不再为每个客户端生成独立 packfile，而是跨 fetch 复用 packfile，客户端可能下载部分已有对象，但服务端能以极少计算把相同字节发给众多客户端。由此写入可按分支扩展，读取可走缓存。