Git 诞生于「用邮件给内核传补丁」的时代,二十多年里开发者一直围着它改造工具链。但 OpenAI 这份复盘暴露了另一件事:当写代码的主体从人变成 Agent,Git 服务端的默认假设会集体失效。

被撑破的是服务端

OpenAI 的 monorepo 主要是 Python,外加 Rust 服务和 Go 服务。Codex 改变的是规模与节奏:分支、推送、合并,以及来自开发环境、研究任务和 CI 的拉取全部成倍增加;一次推送会让多个任务去 fetch 同一个 commit。到 2025 年底后端开始吃力:慢 fetch、慢 push、合并失败,可靠性一度掉到 90% 以下。

传统上扩 Git 服务大致两条路,OpenAI 都评估过:三阶段提交让每个副本保留完整仓库,需多数派接受才能发布 ref 更新,读可本地服务、客户端拿到一致视图,但每次推送都要多轮副本往返;共享 WAL 把所有 ref 更新写进同一份 manifest,用 compare-and-swap 原子替换,写可并行上传,但不相关分支仍要争抢它。

Pando 的选择很明确:放弃仓库级一致,换成因果一致性。

一致性让位,分支级并发写

Pando 把每次分支移动记成一个 ref version:新 tip、提供它的 pack、以及它依赖的更早 ref version,写进元数据存储;packfile 作为不可变 blob 存进 blob store,两者都能横向扩展。写入时它一边把 packfile 流式写入 blob store,一边用单次解码完成校验,不必展开进本地仓库;随后用多键事务记录 ref version 并原子更新 ref 指针,顺带给出 read-your-own-write 保证,整个写操作只需常数次元数据读写。

代价写在明处:读多个分支时,客户端不能假设这些读对应同一时间点;但无关分支的推送完全并行,只有同一 ref 的并发推送才冲突。

还有个容易被忽略的细节:Git 协议里 server 会把所有 ref 广播给客户端,分支数到百万级时单这次广播就能超过 100 MiB。Pando 只广播选定的 ref 集合,默认推送新特性分支时只广播一个主干分支作基线,代价是连续推送同一分支要多传主干之外的东西;换来的是 packfile 中位数不到 20 KiB,第 99 百分位不到 3 MiB。

把 packfile 当 CDN 缓存

读取路径上,Pando 不再为每个客户端单独生成 packfile。它用推送时记录的提交映射,把客户端的 have / want 反解成一组 ref version,选出覆盖这些对象的已存 packfile,返回 packfile URI 让客户端自取。Git 协议规定一次 fetch 只能塞一个 packfile,但 packfile-uri 机制允许服务端额外返回下载地址,于是它内联传一个空 packfile,真正的数据走名为 Express 的服务——在各区域缓存 blob store,用一致性哈希路由,命中率超过 99%。用标准云厂商虚拟机,clone 和 fetch 能打满 10 Gbps 链路。

小 packfile 太多是另一个问题:每次推送都发一个 URI,客户端追一次主干要下载几万个文件。Pando 在后台把 packfile 合并成 cover,从 L0 逐级几何放大,目前主干用到 L4,设计接近日志结构合并树的压缩。cover 还充当 ref version 之上的跳表,让 fetch 规划能以对数时间选出要发的包;各层级的 packfile 都保留不回收,因为读任意对象时从 L0 读通常比从 L4 读更省。效果是单小时服务过超过 57 TB 的 Git packs,其中 99% 以上的字节来自本地磁盘缓存。

用 Codex 造 Codex 的基础设施

Pando 从立项到上线生产只用了十周:核心由一名工程师设计,多个 Agent 团队实现,由少数工程师部署,今年 4 月开始承接生产流量。它用 Rust 写、不带遗留依赖;为了让 Agent 能自我验证,团队先写了符合性测试套件比对标准 Git 行为,又搭了确定性模拟环境检查系统不变量。

用 GPT-6 Astra 时,Agent 写 Lean 和 TLA+ 把「Pando 理论」形式化,用来在实现里找 bug 并证明系统性质;还有连续数百小时的会话专门找边缘 case,Agent 则昼夜不停地用 Daybreak 能力模型做红队。上线方式是读写透传代理到旧系统,逐步切流量不中断。

反哺上游,以及「所以呢」

在 Pando 上暴露出的客户端 bug 修完就回推 Git 上游:并发下载、中断传输后的清理、已完成下载的续传、接受已有 pack 时的校验。还贡献了「explicit haves」概念——服务端可单独广播分支当前 tip,而不广播推送方可能已略过的历史,客户端于是能用 --force-with-lease 只对主干构包。这些改动有一部分已进了上游 Git。

这件事真正的意义可能不在 Git。Git 服务端二十年的前提是「一个人写、一个人推」,当 Agent 把分支数、推送频率和并发拉取同时抬起来,被打破的是服务端而非客户端。OpenAI 干脆放弃仓库级一致、接受因果一致性,说明在他们的负载里全局 ref 顺序已不重要到可以牺牲——这是「机器主导工作流」的具体信号。更值得注意的是另一层:十周、单人设计、Agent 实现,这套基础设施本身也是 Agent 写的,连证明系统正确性的 Lean 和 TLA+ 也是 Agent 写的。瓶颈从「模型够不够强」转移到了「系统怎么设计、谁来 review」。

不过 Pando 并未开源,没有公开 API 和部署指南,外界能直接拿到的只有回推上游的 Git 客户端补丁。对同规模团队的启示是:先量一下工具链里,有多少假设是「一个人一次一个分支」。

原始技术细节见 OpenAI 工程博客 Scaling Git at OpenAI(https://openai.com/index/scaling-git-at-openai/),关键指标的第三方交叉印证见 AlphaSignal 报道(https://alphasignal.ai/news/openai-s-pando-cuts-push-latency-80-serving-a-petabyte-of-git-daily)。