Agent 把 Git 写崩了，OpenAI 只好重写 Git 后端：规模先到的地方不是模型，是基建

OpenAI 11 月 2 日的工程文章讲了一个很实在的教训：Codex 让工程师一次准备多个改动，每个改动又生出分支、推送、合并和 CI 拉取，单仓的流量被推到原有 Git 后端扛不住的地步，可靠性一度跌破 90%。它的解法不是换一套版本控制系统，而是重写服务端：新后端 Pando 保持 Git 协议和客户端不变，改掉引用和包文件的存储与分发方式，让互不相关的分支可以独立接受推送、让包文件可以被复用和缓存。

数字全部是 OpenAI 自家生产环境的口径，要打折读：从立项到上线只用了 10 周，2026 年 4 月起跑生产流量；推送中位延迟降了将近 5 倍，约等于砍掉 80%；每天接近 1 PB 的 Git 数据，单小时峰值超过 57 TB，其中 99% 以上来自本地磁盘缓存。主干提交量从 2024 年第一季度到 2026 年第三季度涨了 1378%，第四季度的 2442% 只是 OpenAI 自己的预测，不是已发生的结果。Pando 也没有开源、没有下载地址，总裁 Greg Brockman 只说了“在考虑”提供给外部。

我的判断是：agent 规模化最先压垮的往往不是模型能力，而是大家以为早就够用的共享基建。对普通团队来说，Pando 本身用不上，但教训可以直接抄：分支一多，先算推送、拉取和 CI 的账——分支策略收紧、包缓存和区域缓存先做、CI 拉取去重，别等合并开始频繁失败才救火。这个结论在单人小仓库、分支很少的场景下不成立，那里真正的瓶颈还是需求和代码质量，不是 Git 后端。