Codex 先把 Git 服务器压垮了，于是 OpenAI 重写了它：Pando 是怎么来的

Codex 让一个人的产出变成一个团队，Git 服务器先扛不住了

OpenAI 在 2026 年 11 月 2 日发表了工程博客《Scaling Git at OpenAI》，公开了它为自家单仓（monorepo）重写的 Git 后端：Pando。文章的起因写得很直白：过去一年，单仓的规模和需求以“惊人的速度”增长，团队需要改造源代码控制系统，才能跟上 Codex 带来的并发工作量。Pando 现在已经支撑 OpenAI 单仓的全部开发，官方称它把推送延迟的中位数砍掉了将近 5 倍，每天交付将近 1 PB 的 Git 数据。

这个故事的起点不是 Git 本身不行，而是使用 Git 的方式变了。Codex 让一个工程师同时手握好几个等着进 CI 的改动，每次推送又会触发好几个任务去拉取同一个提交；开发环境、研究任务、CI 都在不停地克隆和拉取。分支变多、推送变多、合并变多、拉取变多，量变到了一定程度，旧的服务端架构就开始出现慢拉取、慢推送和失败的合并，可靠性一度跌到 90% 以下。OpenAI 团队问了一个关键问题：这是 Git 本身的极限，还是我们提供单仓服务的方式到了极限？他们的答案是后者。

这个判断决定了整个项目的走向。很多达到这种规模的公司会选择换掉 Git，用一套自己定义的版本控制系统，代价是所有工具、脚本和 agent 都要重新学一遍。OpenAI 反其道而行之：保留 Git 协议和客户端，只重建服务端。这样做的好处在文章里说得很清楚：工程师和 agent 的工作方式完全不用变，现有工具继续工作，而且对客户端的改进还能回馈给整个 Git 社区。对一家正在大力推 Codex 的公司来说，这个选择还有一层算计：模型本来就最熟悉 Git 命令，换掉 Git 等于亲手拆掉 agent 最顺手的工具。

Pando 的两个设计目标也因此定得很干净。第一，写要能横向扩展：针对大量分支的并发推送做优化。第二，读的吞吐要拉满：让客户端下载数据的速度快到能跑满自己的网络带宽。这两个目标听起来像所有存储系统的通用口号，但 Pando 的特别之处在于它为此放弃了什么——而放弃的东西，恰恰是多数 Git 系统默认当成必须项的两样东西。

放弃的第一样东西：全仓一致的快照

多数 Git 服务会给所有引用（ref）维护一个全局顺序：仓库在某一个时刻是什么样子，所有人看到的应该是一致的。代价是，所有分支的更新都要排队过同一个协调点——哪怕你要推的两个分支之间毫无关系，也得一个一个来。写量一大，这个协调点就成了瓶颈。

Pando 的做法是：每个分支独立协调。推到互不相关的分支可以并行进行，单个分支内部的更新仍然保持可串行化，读者拉取某个分支时，看到的是写出这个分支的那位写者的历史。代价是，读者同时看多个分支时，看到的可能不是同一个时间点的状态：一个人可能看到 foo 分支是版本 1、bar 分支是版本 2，另一个人看到的正好反过来。OpenAI 在文章里把这个取舍摊开说了，并给出了判断：用户和 agent 实际依赖的是单个引用的更新顺序，而不是所有引用的全局顺序。

这个判断对不对，取决于你的工作方式。对绝大多数团队来说，它是对的：你关心的是 main 分支有没有按顺序前进、你的功能分支有没有被意外改动，而不是“在某一毫秒，全仓所有分支的组合状态”。但对那些把“全仓快照”当成正确性前提的工具——比如某些跨分支的发布编排、全局审计——这个放松就可能踩坑。Pando 的取舍提醒我们：一致性不是非黑即白的东西，而是一组可以按需拆开的保证；关键是你得说清楚，你放弃的是哪一种保证，以及谁会因此受影响。

技术上，Pando 用“因果一致性”（causal consistency）来实现这个模型。每次分支移动，系统在元数据存储里记一条 ref 版本，包含新的分支尖端、提供它的 pack，以及这个 pack 依赖的更早的 ref 版本。读的时候，系统把这些 ref 版本重放给客户端，重建出写者的视角。推送时，唯一竞争的键就是分支指针本身，用类似原子比较交换（compare-and-swap）的操作保护。于是，扩展写吞吐的办法就变得很朴素：加 Pando 服务器、加元数据存储单元、加对象存储，仅此而已。

放弃的第二样东西：给每个客户端定制 pack

Git 的 pack 是把多个对象压缩在一起传输的格式。传统做法是：服务器根据客户端已经有的对象（haves）和想要的对象（wants），现算一份专属 pack 发过去。这样做的好处是传输量最小，坏处是每次拉取都要花 CPU 和磁盘 I/O 去算——读者一多，服务器就被算 pack 的活儿拖垮了。

Pando 的做法是：复用已经存下来的 pack。推送时客户端发来的 pack 被原样存成不可变对象，之后别的客户端来拉取时，服务器直接挑已经存好的 pack 发过去，不再现算。代价是客户端可能会下载一些自己已经有的对象，浪费一点带宽；换来的是服务器几乎不用为每个读者做计算，同一份字节可以发给很多人。OpenAI 还为此用了一个 Git 协议里不太受关注的特性 packfile-uri：服务器在 HTTP 响应里只传一个空 pack，真正的 pack 以链接形式让客户端另外下载。

这个设计里还有一个很妙的细节：推送时服务器只向客户端宣告一小部分分支，默认只有一个主干分支（trunk）。原因有两个：一是分支一多，光是宣告所有分支的清单就能超过 100MB；二是宣告的分支越少，客户端生成的 pack 依赖的东西就越少，服务器将来复用这个 pack 时就越容易证明“拉取的客户端已经有这些依赖”。代价同样实在：如果工程师反复推同一个分支，或者把一个功能分支叠在另一个上面，客户端就得把主干之外的东西反复重发。OpenAI 给出了自家单仓的实测数字：推送 pack 的中位数不到 20KB，99 分位数不到 3MB——在他们的工作负载下，这笔交易划算。

读路径的另一半是缓存。Pando 有一个叫 Express 的 pack 投递服务，在每个区域做缓存，配合一致性哈希做请求路由，缓存命中率超过 99%。OpenAI 称，在普通云厂商虚拟机上，克隆和拉取可以跑满 10 Gbps 的网络链接。单小时最高交付超过 57TB 的 Git pack，其中 99% 以上来自本地磁盘缓存。这些数字都是 OpenAI 自家生产环境的自述，没有第三方复现，但至少说明了一件事：当 pack 可以复用时，读的瓶颈就从“服务器算力”变成了“网络带宽”，而带宽是花钱就能买到的东西。

写路径与压实：小 pack 是怎么不拖垮系统的

每次推送产生一个最小的 L0 pack，日积月累，一个客户端要追赶主干时，一天就可能需要下载成千上万个 pack。Pando 的办法是借鉴日志结构合并树（LSM）的压实思路，在后台把 pack 合并成更大的 cover，从 L0 一路做到 L4。cover 有两个作用：一是提高压缩率，二是充当 ref 版本上的跳表，让服务器在对数时间内选出客户端需要的 pack 集合。

和很多 Git 服务器不同，Pando 不会把各层级的 pack 垃圾回收掉，而是全部留着继续服务。因为不同客户端落后的程度不同，有的需要 L0 的小 pack，有的需要 L4 的大 cover，留着各层反而让每次拉取都能挑到最合适的粒度。这个选择再次体现了 Pando 的整体哲学：用存储换计算——磁盘便宜，算力贵，尤其是在读者远多于写者的场景里。

写路径本身也被压到了很薄。推送时，Pando 在把 pack 流式写入对象存储的同时做单次验证，不需要先把 pack 解包到本地仓库；然后用一次多键事务在元数据存储里记下新的 ref 版本并原子地移动分支指针。OpenAI 称，整个写操作只需要常数次元数据读写，与推送大小无关；读的时候，选 pack 需要的元数据读取次数是对数级别的，取决于客户端落后了多少个 ref 版本。这些复杂度数字是理解 Pando 扩展性的关键：写不随推送变大而变贵，读不随落后距离线性变贵，系统才敢说“加机器就能扩”。

10 周、一个人设计、一群 agent 实现

文章里最容易被引用的一段，是 Pando 的建造过程：从启动到上线生产只用了 10 周，核心由一位工程师设计、由多组 agent 实现、由少数工程师部署，2026 年 4 月开始承载生产流量。实现语言选了 Rust，从零开始、没有历史包袱；验证手段包括：针对标准 Git 行为的一致性测试套件、用于找竞态条件的确定性模拟测试、用 GPT-6 Astra 写 Lean 和 TLA+ 形式化“Pando 理论”并以此找 bug、以及全天候用 Daybreak 能力的模型做红队测试。

这段话很容易被读成“AI 写了个 Git 后端”，但更准确的读法是“AI 在强约束下完成了大量实现工作”。约束包括：一致性测试套件（agent 改坏了立刻能发现）、确定性模拟（竞态条件可以复现）、形式化方法（性质可以被证明而不是被感觉）。换句话说，agent 的产出之所以敢上线，是因为验证体系比实现本身更扎实。这对 vibe 项目是一个很实在的启示：让 agent 写关键基础设施之前，先问自己有没有等价的验证手段——没有测试套件和形式化检查兜底，再快的实现速度也不值得信任。

部署过程同样值得学。Pando 最开始是作为旧系统的读写穿透代理（read- and write-through proxy）上线的，两套系统保持同步，流量可以逐个系统地迁移，过程中还能靠 Pando 的缓存合并请求、给旧后端减负。客户端迁移则分阶段进行，OpenAI 先发了自己的 Git 发行版（包括放进 ChatGPT 桌面应用），再通过内部的 Git CLI 包装器逐步迁移，并迁移了数百个依赖旧 API、webhook 和仓库下载的集成——而 Codex 本人也参与了这场迁移，团队做了专门的 skill，帮开发者准备已有的检出、迁移开发环境。没有停机、没有“某天全员换工具”的大动作，这才是基础设施升级该有的样子。

回馈给 Git 的部分，可能比 Pando 本身走得更远

因为 Pando 建在 Git 协议和客户端之上，团队在过程中发现了 Git 自身处理可复用 pack 时的 bug 和性能机会，并把修复贡献回上游：并发下载时的边界情况、中断传输后的清理、续传已完成下载、接受已有 pack 时的校验、packfile-uri 下载的追踪和字节统计，等等。公开的 Git 构建里，客户端已经可以并行下载和索引多个独立 pack，还新增了“显式 haves”功能，让服务器可以单独宣告某个分支的当前尖端。

这部分工作的意义，某种程度上比 Pando 本身更大：Pando 目前还只是 OpenAI 内部系统，没有开源、没有自托管包、没有公开 API 或部署指南，官方只说“正在探索分享技术的方式”。但回馈上游的客户端改进，是所有 Git 用户迟早能用上的东西。对小团队来说，这也是一个判断信号：如果一家公司只谈自己的内部系统多厉害，却没有任何东西回流到公共生态，那它的经验对你大概率不可复用；反过来，愿意把改进推回上游的团队，它的文章通常也更值得细读。

数字要打折，启示不用打折

把官方数字再摆出来过一遍：推送延迟中位数降了将近 5 倍（文章另一处表述为将近 80%）、每天交付将近 1 PB Git 数据、单小时最高 57TB 以上、缓存命中率 99% 以上、合并可靠性从一度跌破 90% 恢复到更高水平。这些数字全部来自 OpenAI 对自己系统的描述：没有旧系统的基线对照、没有“少数 CPU 核心”到底是几核的硬件说明、没有误差范围，文章里的三方一致性模型对比模拟也被明确标注为“合成教学模型，不是生产基准”。所以，数字本身只能当成“在 OpenAI 的单仓和工作负载下成立”的陈述，不能直接换算成你团队的收益。

但有三条启示是不用打折的。第一，agent 时代的基础设施账要重算：一个人加几个 agent 会话，行为上就像一个小团队，分支、推送、拉取、CI 的量级都会翻倍；你的 Git 托管、CI runner、制品库的瓶颈，很可能比你想象的来得更早。与其等到合并开始失败才动手，不如现在就盯住三个指标：推送延迟、合并失败率、每次克隆的拉取耗时。

第二，接口稳定比后端时髦重要。Pando 最大的产品决策不是因果一致性或 pack 复用，而是“不换接口”。对 vibe 项目来说，同理：给 agent 用的工具链、脚本、CI 配置，尽量建在稳定的公开接口上，而不是某个 agent 工具的私有格式。接口稳，换后端、换模型、换工具的成本才低；接口一锁死，每次升级都是一次迁移。

第三，验证体系决定 agent 能走多远。Pando 敢用 agent 实现核心，靠的是测试套件、确定性模拟和形式化方法三层网。你的项目不一定需要 TLA+，但至少应该有：agent 改动必须通过的测试、失败时能复现的最小用例、以及“改坏了能一键回滚”的部署方式。没有这三样，agent 写得越快，你离生产事故就越近。

一张给小团队的自查清单

如果你现在就想判断自己的基础设施离 Pando 描述的问题有多远，不用等什么新产品，先跑一遍这张清单。第一，过去一个月，你的仓库有没有出现过推送明显变慢、合并无故失败、或者 CI 拉取同一个提交反复超时的情况？如果有，记下发生的频率和时段——这是最直接的早期信号。第二，统计一下你的 CI 里有多少次拉取是在重复下载同一个提交：agent 会话、云开发环境、并行任务都会制造这种重复拉取，重复率越高，说明你的读路径越值得优化。第三，检查你的分支策略：长期不删的陈旧分支越多，服务器宣告和协商的成本就越高，定期清理分支是最便宜的性能优化。

第四，问自己一个问题：如果明天团队里每个人都同时开三个 agent 会话，你的 CI 并发上限、Git 托管的速率限制、制品存储的带宽，哪一个会先到顶？这个思想实验不用花一分钱，却能提前暴露最脆弱的那一环。很多团队第一次认真算这笔账时，才发现瓶颈根本不在代码托管，而在某个一直被忽略的环节，比如自托管 runner 的磁盘速度，或者某个每次全量克隆的脚本。Pando 的故事说到底就是一句话：agent 把“人”的规模问题，提前变成了基础设施的规模问题。

最后回到 Pando 本身：它现在还不是你能下载的东西，官方也没有给出对外提供的时间表和价格。对读者来说，这篇文章的价值不在于“等一个产品”，而在于它提前写出了 agent 时代基础设施的考卷：当写代码的人从一个人变成一个人加一群 agent，你的版本控制、CI 和存储，还撑得住吗？OpenAI 用 10 周给出了它自己的答案；你的答案，可以从盯住那三个指标开始。