OpenAI 公开自研 Git 后端 Pando：中位推送延迟降近 5 倍，每天交付近 1PB 数据，10 周用 Codex 建成

核心背景与行业痛点

AI 编程智能体让「一个工程师同时开好几个分支」变成常态，每次推送又会触发多个 CI 任务去拉同一个提交，源码托管成了新瓶颈。OpenAI 在 11 月 2 日的工程博客里说，从去年底开始，单体仓库的支撑系统跟不上 Codex 带来的并发量：fetch 和 push 变慢、合并失败，可靠性一度低于 90%。他们没有换掉 Git，而是重写了服务端，做出兼容 Git 协议和客户端的新后端 Pando，工程师和智能体的用法完全不变。

架构亮点与底层机制

Pando 主动放弃了两项传统 Git 服务默认的要求。第一是全仓库一致性：它按分支独立协调更新，只有推同一分支才会冲突，代价是同时读多个分支时可能看到不同时间点。第二是给每个客户端单独打包：推送来的 packfile 边校验边写入 blob 存储，元数据库记录分支版本和依赖，之后的 fetch 直接挑选已有的包，通过 Git 的 packfile-uri 让客户端去区域缓存 Express 下载，缓存命中率超过 99%。后台按类似 LSM 树的方式把小包逐级合并（目前到 L4），让拉取规划在对数时间内完成。

权威 Benchmark 与实测跑分对比

以下均为 OpenAI 官方口径：中位推送延迟降低近 5 倍（约 80%）；每天交付近 1PB Git 数据，只用少量 CPU 核；单小时峰值超过 57TB，99% 以上字节来自本地磁盘缓存；在普通云主机上，clone 和 fetch 可以跑满 10Gbps 网络。博客里与三阶段提交、共享预写日志两种方案的对比是教学用模拟，官方明确说不是生产 Benchmark。第三方独立复现：官方未公布。

开发者实战落地与开箱指南

Pando 目前只在 OpenAI 内部使用，官方说正在探索如何开放给用户，暂无可用产品。现在能直接用上的是 OpenAI 公开的 Git 分支版本和已合入上游的 packfile-uri 改进。如果你的团队也在大量跑编码智能体，这篇文章值得参考的点是：按分支而不是按仓库做一致性，推送只以主干为基准以便复用包，以及先做读写代理再分批迁移、全程不停机。另一个看点是开发方式本身：一名工程师设计核心，Codex 智能体团队实现，还让智能体写 Lean 和 TLA+ 做形式化验证。