你可以把传统代码仓库想成一座只有少数窗口的档案馆。人类工程师依次来借档案、交修改，尚能应付；如今，大批编码Agent同时开工，成百上千条支线一起读写，窗口很快就会堵住。OpenAI遇到的正是这个问题：Codex放大了并行开发的规模，原有Git服务开始出现慢操作、合并失败和可靠性下降。于是，它没有要求所有人换掉Git，而是重做了服务器背后的“档案馆”。新系统名叫Pando。
这件事值得关注，不只因为它是一次性能优化。编码Agent过去主要被当作写代码的工具，现在，它们产生的工作量已经开始反过来改造代码托管、测试和迁移等基础设施。更有意思的是，Pando本身也由多支Codex agent团队参与实现。
本文关于Pando的架构、性能和建设过程，均来自OpenAI发布的《Scaling Git at OpenAI》，目前缺少独立信源交叉验证。
换后端，不换Git
Git是软件行业事实上的标准版本控制系统，用来记录代码如何一步步变化。开发者日常执行的push、fetch和clone，分别可以粗略理解为提交修改、获取更新和复制整个仓库。Git后端则是服务器端真正保存代码历史、处理这些请求的部分。
Pando是一个“Git-compatible backend”，也就是兼容Git的后端。它不是取代Git的全新版本控制系统。它保留了Git协议和常用客户端，工程师与Agent无须改变日常操作；OpenAI重做的是内部承载大量并发请求的服务端。
压力集中在一个monorepo上。monorepo即单体代码库：许多项目和共享组件都放在同一个大型版本库里。这样便于统一协作，但仓库越大，同时修改它的人和Agent越多，存储、读取与合并的压力也越高。
据OpenAI介绍，过去一年，其monorepo的规模和负载快速增长。Codex带来的并行开发增加了分支、push、merge、fetch和clone的数量。原有系统一度出现慢操作、合并失败，可靠性降至90%以下。目前，这个monorepo的全部开发已经由Pando承载。
关键变化是允许“各走各的”
Pando的一项核心设计，是让互不相关的分支更新可以并行处理。分支可以理解为从同一份代码上岔出去的修改路线：有人改登录页面，另一个Agent调整测试工具，只要两边没有冲突，就不必排在同一个写入窗口后面等待。
这叫横向扩展写入：增加机器后，多个分支的提交可以同时处理，而不是全部挤到单一写入节点。它尤其适合大量Agent并行产出代码的场景。
读取同样重要。每次代码变化后，CI——持续集成系统——通常会重新拉取代码，再自动执行构建和测试。提交越密集，CI和开发环境重复读取同一段代码历史的次数就越多。OpenAI称，Pando针对大量客户端同时读取相同历史的情况做了优化。
按OpenAI公布的数据，Pando上线后，push延迟的中位数降低了近5倍；系统目前每天传输接近1 petabyte的Git数据。这里的“中位数”指一半请求快于这个值，另一半慢于它。它能反映典型请求的等待时间，但不能告诉我们最慢的一批请求改善了多少。
为Agent修路，也让Agent施工
Pando的建设过程比性能数字更能说明变化。OpenAI称，项目从立项到投入生产只用了10周：一名工程师设计核心架构，多支Codex agent团队参与实现，最后由少数工程师部署。多个模型先后接力改进系统；一些Agent会话连续运行数百小时，专门寻找性能和可靠性的边缘问题。
团队还让GPT-6 Astra生成Lean和TLA+形式化描述。所谓形式化描述，就是用严格的数学语言写下系统必须遵守的规则，再检查大量操作同时发生时会不会自相矛盾。OpenAI把它称为“theory of Pando”，并表示这套描述帮助团队发现和修复了实现漏洞。与此同时，其他Agent持续对Git与Pando进行红队测试，也就是主动寻找可能破坏系统的输入和操作方式。
这形成了一个很有代表性的闭环：Agent增加代码基础设施的负载，参与建设新的基础设施，又被用来验证和攻击自己参与建设的系统。
搬家时，旧仓库没有关门
OpenAI称，迁移没有中断工程工作。Pando先作为读写代理放在旧系统前面，让新旧后端保持同步，再分阶段转移流量。缓存还会合并重复请求，减轻旧系统的压力。它更像是一边营业一边搬迁，而不是挑一个晚上关闭所有服务，再赌一次整体切换。
Codex也参与了迁移。团队为它制作了迁移技能，开发者可以让Codex搬动开发环境和服务。最终，数百个依赖旧API、webhook和仓库下载方式的集成完成迁移。OpenAI还表示，会把Git客户端侧的改进提交给上游Git项目，使其中一部分成果有机会被公司外部使用。
为什么这是一个基础设施信号
“Codex逼出一套新Git后端”是一个醒目的概括，但因果关系不宜说得太满。OpenAI的原话是，Pando面向“Codex所实现的开发规模”设计；材料并不能证明Codex是建设Pando的唯一原因。
更稳妥的判断是：当编码Agent从偶尔补几行代码，走向大量、长时间、并行地操作同一个代码库，原本围绕人类协作节奏设计的服务端会遇到新的压力。需要扩容的不只是模型本身，还有保存代码、分发历史、触发测试和迁移依赖的整条链路。Pando是这一变化已经进入基础设施层的一个标志性案例。
局限与未知
- 目前只有OpenAI自己的介绍，缺少第三方基准测试，无法判断Pando与其他Git后端相比处于什么水平。
- 材料没有披露容量上限、尾部延迟、成本或更完整的架构细节，因此不能仅凭“中位数降低近5倍”推断所有请求都获得同等改善。
- OpenAI表示会向上游Git项目提交客户端改进，但哪些部分会被接受、何时能供外部开发者使用，仍未确定。