OpenAI 自研 Git 后端 Pando：推送中位延迟降近 5 倍，日送出近 1 PB 数据
OpenAI 11 月 2 日公开自研 Git 后端 Pando：保留 Git 协议只重建服务端，已承载整个 monorepo，推送中位延迟自报降近 5 倍，日送出近 1 PB 数据，但数字未经第三方验证，暂不对外提供。
- 01THE ANNOUNCEMENT：OpenAI 11 月 2 日发表官方工程博客，公开 Pando 的设计与生产数据。
- 02THE CONFIRMATION：ExplainX 同日独立报道，核对近 5 倍延迟、近 1 PB 日流量与 10 周开发周期一致。
- 03THE WATCHPOINT：Pando 是否对外提供、第三方能否复现其性能数据，以及依赖全局快照的工具如何适配松弛一致性。
WHAT HAPPENED发生了什么
OpenAI 11 月 2 日在官方工程博客发表《Scaling Git at OpenAI》，公开自研 Git 后端 Pando：保留 Git 协议与客户端，只重建服务端，现已承载公司整个 monorepo 的开发。
动因是 Codex 带来的并行开发量：一位工程师可同时推进多个改动，每个推送触发多个 CI 任务拉取同一提交，旧系统出现推送与拉取变慢、合并失败，可靠性一度跌破 90%。
Pando 的两处取舍是放弃仓库级全局一致性与每位客户端专属 packfile：各分支更新独立协调，跨分支读取不保证同一时刻快照；服务端复用已存储的 packfile 供多客户端拉取，客户端可能多下载已有的对象。
官方自报的生产数据：推送中位延迟降近 5 倍（约 80%），每天送出近 1 PB Git 数据，单小时峰值超过 57 TB packfile，99% 以上字节来自本地磁盘缓存，2026 年 4 月起承载生产流量。
Pando 从立项到生产只用了约 10 周：核心由一位工程师设计，Codex 智能体团队负责实现，少数工程师部署，并用 Lean 与 TLA+ 形式化方法找 bug；部分客户端改进已回馈 Git 上游。
WHY IT MATTERS智能体先把版本控制写爆了
Pando 的真正信号不在 Git 本身，而在工作量结构的变化：一个人加多个智能体会话，行为上等于一支小团队，短命分支与重复拉取成倍增加。旧 Git 服务端的全局协调点先成为瓶颈，而不是 Git 的对象模型。
OpenAI 的解法是保住接口、换掉服务端，让人类与智能体都不必重新学习工具。这条路线会被其他大规模工程团队复制：先问自家 Git 托管的推送延迟与合并失败率，而不是先换版本控制系统。
WHY IT MATTERS数字是自报，取舍是公开的
近 5 倍延迟、近 1 PB 日流量、57 TB 峰值小时，全部来自 OpenAI 对自家系统的描述，没有旧系统基线、硬件规格与误差范围，外部目前无法复现。交互式架构对比也明确标注为教学模型。
但取舍本身是公开且可验证的：跨分支读取不再是同一时刻快照，依赖全局快照的工具需要自行评估。Pando 是否对外提供仍是未知数，官方只说正在探索分享方式。
SIGNAL JUDGMENT接口不变，后端先行
Tokenta Signal 判断：Pando 的信号不在又一个内部系统，而在智能体规模化之后，工程基础设施的瓶颈从模型能力移到了提交、拉取与合并的吞吐上。保住 Git 接口、只换服务端的选择，说明下一轮基建竞争拼的是让智能体无感扩容，而不是让人类换工具。
WHAT REMAINS UNCERTAIN还有什么不确定
EVIDENCE证据
OpenAI 官方工程博客与 ExplainX 独立报道双源确认，原文链接已打开验证。
PRIMARY SOURCES原始来源
- OpenAI 官方工程博客
https://openai.com/index/scaling-git-at-openai - ExplainX 独立报道
https://explainx.ai/blog/openai-pando-git-backend-codex-monorepo-5x-faster-pushes-petabyte-per-day-2026