继Anthropic之后，OpenAI 也重建了自己的版本控制系统
内容提要
OpenAI 披露其内部 Git 后端 Pando：AI Agent 的高并发使传统 Git 不堪重负。Pando 保留 Git 协议，以因果一致性支持不同分支并行写入，并通过 Packfile 复用、区域缓存和分层 Compaction 提升读取吞吐，使 Push 中位延迟降低近 5 倍，日处理近 1PB 数据。系统用 Rust 实现，Codex 参与开发，并以 Lean、TLA+ 验证正确性，10 周内投入生产。这表明 AI Agent 正倒逼软件基础设施重构。
延伸解读
一致性取舍：因果一致性为何适合Agent工作流
Pando放弃全局一致性，改用因果一致性，只保证单个Ref更新的可串行化语义和Read-your-own-write。这意味着不同分支的Push可以并行，无需全局协调。代价是客户端同时读取多个分支时，可能看到不同时间点的版本。OpenAI认为，对Agent日常开发而言，单个分支的提交顺序比全局顺序更重要。这种设计体现了按业务需求选择一致性边界的思路。
读取优化：Packfile复用与分层Compaction的协同
传统Git服务端需为每个客户端实时计算差异并生成Packfile，在大量Agent同时Fetch时造成重复计算。Pando将Push上传的Packfile直接流式写入对象存储，Fetch时通过packfile-uri返回下载地址，让客户端从Express缓存直接下载。配合分层Compaction（L0到L4），既改善压缩率，又像Skip List一样加速历史查找。区域缓存命中率超过99%，单小时服务57 TB Packfile。
Agent参与基础设施构建：验证与迁移同样关键
Pando由Codex参与构建，10周投入生产。但OpenAI并未降低正确性要求：用Lean和TLA+对设计进行形式化建模，构建确定性模拟测试框架检查并发行为，多个Agent持续运行数百小时寻找边界条件。迁移方面，采用Read-through/Write-through Proxy逐步切换流量，定制Git发行版和CLI Wrapper分阶段迁移客户端，并迁移数百个依赖旧API的集成。Agent不仅写代码，还参与验证和迁移。
基础设施重构信号：CI/CD与构建系统面临类似压力
Pando揭示的趋势是：AI Agent改变软件开发负载模型，从人类驱动的有限并发转向机器驱动的高并发。Git只是最先暴露瓶颈的环节。文章指出，CI/CD需要支持更高并发并让Agent参与调度与修复；构建系统需要更强的远程缓存、增量构建和构建图复用，避免多个Agent重复下载依赖和编译相同模块。基础设施本身正成为Agent的工作对象，形成“Agent越强、基础设施压力越大”的循环。
Q&A
OpenAI 为什么要重建 Git 后端？
因为 AI Agent 大规模接管开发后，一个工程师可同时启动几十个 Codex Agent，每个 Agent 独立创建分支、提交、Push 并触发 CI，导致 Git 服务端承受前所未有的并发压力。2025 年底 OpenAI 内部 Monorepo 出现 Fetch/Push 变慢、Merge 失败增加、可靠性跌破 90% 等问题，促使团队重新设计 Git 服务端。
Pando 是什么？它和 Git 是什么关系？
Pando 是 OpenAI 内部重新设计的 Git 后端系统。它完全保留 Git 协议和开发者工作习惯，开发者仍可使用 git add、commit、push、fetch、pull 等命令，改变发生在服务端架构。Pando 有两个设计目标：让写入水平扩展、让读取吞吐最大化。
Pando 如何解决多分支并发写入的问题？
Pando 采用因果一致性模型，放松全局一致性。客户端 Push 时，上传的 Packfile 作为不可变 Blob 直接流式写入对象存储；元数据服务记录分支新版本，每个分支独立维护版本指针，不同分支的更新可并行执行。只有多个客户端同时更新同一个 Ref 时才需竞争协调，并保证单个 Ref 更新的可串行化语义和 Read-your-own-write。
Pando 如何提升海量读取的性能？
Pando 复用已生成的 Packfile，避免为每个客户端重复计算差异。Push 时 Packfile 直接流式写入对象存储；Fetch 时服务端根据客户端已有 Commit 和目标 Commit 选择已存储的 Packfile，通过 Git 协议的 packfile-uri 机制返回下载地址，客户端直接从 Express 缓存下载。全球多集群通过一致性哈希路由，缓存命中率超过 99%，Fetch/Clone 可跑满 10 Gbps。
Pando 的 Compaction 机制是做什么的？
每次 Push 产生一个最小的 L0 Packfile，后台 Worker 持续收集并组织成更高层级的 Cover（L1 到 L4），类似 LSM Tree。Compaction 有两个作用：改善压缩率，减少重复数据；加速 Fetch，Cover 承担类似 Skip List 的作用，通过多层索引快速定位所需 Packfile。Pando 不会像传统 Git GC 那样删除低层 Packfile，而是保留各层级以服务不同客户端的 Fetch 请求，用额外存储空间换取更低读取延迟。
Pando 是用什么语言实现的？如何保证正确性？
Pando 用 Rust 实现，没有引入遗留系统依赖，以满足并发、内存安全和性能要求。OpenAI 构建了 Git 协议兼容性测试套件、确定性模拟测试框架，并使用 GPT-6 Astra 让 Agent 编写 Lean 和 TLA+ 模型进行形式化建模，发现并修复实现问题。多个 Agent 持续运行数百小时寻找边界条件问题，还使用具备 Daybreak 能力的模型进行自动化安全测试。
Pando 取得了哪些实际效果？
Push 中位延迟降低近 5 倍（约 80%），每天处理接近 1 PB 的 Git 数据，单小时服务过 57 TB Packfile，其中超过 99% 的传输字节来自本地磁盘缓存。系统从启动到投入生产仅用 10 周，2026 年 4 月开始承载生产流量，核心架构由一名工程师设计，主要实现由多个 Codex Agent 团队完成。
OpenAI 是如何在不影响业务的情况下迁移到 Pando 的？
OpenAI 最初采用 Read-through 和 Write-through Proxy 模式，让 Pando 与原有系统保持同步，逐步迁移流量而非一次性切换。同时为开发机器和 ChatGPT Desktop App 提供定制 Git 发行版，通过内部 Git CLI Wrapper 分阶段迁移客户端，迁移数百个依赖旧 API、Webhook 和 Repository 下载的集成，并利用 Codex Skills 帮助开发者迁移开发环境。
Pando 对 Git 社区有什么贡献？
OpenAI 没有将改进全部封闭在内部，已将部分优化贡献给 Git 上游，包括并行下载和索引独立 Packfile、packfile-uri 相关改进，以及显式 haves 等能力，未来可能惠及更广泛的 Git 用户。
Pando 的出现反映了 AI 时代基础设施的什么趋势？
它表明 AI Agent 正在改变软件开发的负载模型，原本为人类开发者设计的基础设施可能需要重新设计。文章指出三个值得关注的方向：CI/CD 需要重新设计以支持高并发和 Agent 参与调度；构建系统需要更强的数据复用能力（远程缓存、增量构建）；软件工程基础设施本身将成为 Agent 的工作对象。Agent 越强，代码产出越多，基础设施压力越大，形成循环，这可能是 AI Software Factory 规模化前必须经历的基础设施演进。
