OpenAI 也开始改造 Git 了

10 月 13 日，Anthropic 发布了 Redesigning source control at Anthropic，介绍自研版本控制系统 Scion。当时写过一篇《Anthropic 自研版本控制 Scion》，核心是 Claude 产生代码的速度太快，以至于 Git、构建和 CI 这些原本服务于人类开发者的基础设施开始成为瓶颈。

不到一个月，11 月 2 日，OpenAI 也发布了技术文章 Scaling Git at OpenAI，介绍他们开发的 Git 后端 Pando。

两家公司遇到的问题非常相似：AI Agent 让软件开发的并发量大幅增加，源码管理系统开始跟不上代码生产速度。但解决方式有明显区别。

Anthropic 选择重新设计版本控制系统，把 Monorepo 完整迁移到了 Scion；OpenAI 则保留 Git 协议和客户端，重新设计服务端，让现有 Git 能支撑大规模 Agent 并发开发。

Codex 让 Git 开始承受更大的压力

和 Anthropic 面临的情况类似，OpenAI 也发现，随着 AI Coding Agent 大规模参与代码开发，原有的版本控制基础设施逐渐难以支撑不断增长的并发需求。

对于 Anthropic，这种变化主要来自 Claude；而在 OpenAI，推动代码生产规模快速增长的则是 Codex。

过去，一个工程师可能同时维护几个分支。现在，借助 Codex，一个工程师可以让多个 Agent 并行处理不同任务。每个 Agent 都可能独立提交代码、推送分支、触发 CI，而每次 CI 又可能启动多个任务，重复拉取同一份代码。

于是 Git 的两个核心操作都开始承受压力：

• Push： 大量 Agent 同时向不同分支提交代码，要求服务端能够处理高并发写入。
• Fetch / Clone： CI、Agent 沙箱和研发环境频繁获取代码，要求服务端具有极高的数据分发能力。

OpenAI 提到，从 2025 年底开始，他们的 Monorepo 基础设施就逐渐无法跟上需求。Push、Fetch 变慢，Merge 失败，系统可靠性有时甚至低于 90%。

他们最终开发了 Pando，一个全新实现的 Git 服务端后端。

根据官方披露，Pando 已经承载 OpenAI Monorepo 的全部开发工作，并取得了几项结果：

这些数据来自 OpenAI 的生产环境及性能验证。需要注意，10 Gbps 是在其基础设施中验证的网络吞吐能力，并不代表所有 Git 客户端都能达到这个速度。

Pando 是怎么设计的？

先来看一下 Pando 的整体架构。

图：Pando 整体逻辑架构简化示意，后台 Compaction 流程未展开。根据 OpenAI 官方文章整理。

Pando 保留了 Git 原有的客户端协议和对象模型，但重新设计了服务端的数据存储、并发控制和数据分发机制。

从架构上看，Pando 的核心可以分为几个部分：

• Git 服务层： 负责处理客户端 Push、Fetch 等请求，包括对象验证、Ref 更新和数据获取规划。
• 元数据存储： 管理 Ref、版本信息以及 Packfile 之间的依赖关系。
• 对象存储： 保存不可变的 Git Packfile，避免依赖单台服务器的本地磁盘。
• Express 区域缓存： 缓存频繁访问的 Packfile，减少对象存储访问和重复数据传输。

此外，Pando 还有后台 Compaction 任务，负责将多个小 Packfile 合并整理，降低客户端 Fetch 时需要处理的文件数量。

基于这套架构，Pando 主要解决了三个问题：不同分支如何并行写入、已有 Packfile 如何复用，以及大量 Packfile 如何高效组织和查询。

1. 放宽一致性，让不同分支并行写入

Git 仓库包含两类关键数据：对象（Object）和引用（Ref）。

Object 保存文件内容、目录结构和提交历史，这些对象通过内容哈希标识，创建后不可变。

Ref 则是可变的，例如 refs/heads/main，用于指向某个 Commit。

对于分布式 Git 服务来说，难点在于如何保证对象和 Ref 的一致性。

传统的多副本架构可以通过三阶段提交（3PC）协调多个副本，或者通过共享 WAL 对更新进行排序。这些方案有一个共同问题：即使两个 Agent 修改的是完全不同的分支，也可能因为全局协调产生竞争。

假设三个 Agent 同时工作：

Agent A → feature/payment
Agent B → feature/order
Agent C → feature/search

三个分支之间没有直接依赖，理论上可以完全并行地 Push。

但如果所有 Ref 更新都要经过同一个共享日志或全局协调过程，就会出现不必要的等待。

Pando 的做法是采用因果一致性（Causal Consistency），放宽整个仓库在同一时间点上的一致性要求。

不同 Ref 可以独立更新，只有同时修改同一个 Ref 的操作才需要竞争。

例如，两个 Agent 同时更新 feature/payment，Pando 会通过类似 Compare-and-Swap 的机制控制并发，避免其中一个更新意外覆盖另一个。

代价是，客户端一次读取多个分支时，可能看到不同时间点的版本。比如看到 foo 的旧版本和 bar 的新版本。

但对于大多数 Git 工作流，开发者真正需要的是某个分支自身的更新顺序，以及读取该提交所需的完整历史，很少需要整个仓库所有分支的全局一致快照。

Pando 用这个取舍消除了不同分支之间的大量协调成本。

2. 复用 Packfile，减少重复计算

这是 Pando 设计中很有价值的一部分。

Git 使用 Packfile 将多个 Object 压缩存储和传输。

传统 Git Fetch 时，客户端会告诉服务端：

• have：我已经有哪些 Commit。
• want：我希望获取哪些 Commit。

服务端根据两者计算客户端缺少哪些 Object，然后生成对应的 Packfile。

问题在于，即使多个客户端想获取同一个 Commit，只要它们本地已有的历史不同，服务端就可能需要分别计算和生成不同的 Packfile。

在大规模 CI 场景下，这意味着大量重复的 CPU 和磁盘 I/O。

Pando 改变了这个流程。

当客户端 Push 时，Pando 会在验证上传内容的同时，直接把 Packfile 写入对象存储，并在元数据中记录它所依赖的历史版本。

后续其他客户端 Fetch 时，服务端根据客户端已有的版本，找到能够覆盖目标历史的 Packfile，然后让客户端直接下载。

也就是说，Push 时产生的 Packfile，可以直接用于其他客户端的 Fetch。

为了让这件事成立，Pando 还修改了 Git 服务端向 Push 客户端通告 Ref 的策略。

传统 Git 服务端通常会提供较多 Ref，帮助客户端尽量减少上传的数据。但这会导致生成的 Packfile 依赖各种不同的历史，降低复用能力。

Pando 默认只向新功能分支的 Push 通告指定的主干分支（Trunk），限制 Packfile 可以依赖的公共历史。

这样，只要其他客户端已经拥有对应的 Trunk 历史，就能直接使用这个 Packfile。

代价是客户端可能重复上传或下载部分对象。不过在 OpenAI 的工作负载中，这个代价比较小：

• Push Packfile 中位大小低于 20 KiB。
• P99 大小低于 3 MiB。

相比于减少服务端计算和提高缓存复用率，这部分额外传输可以接受。

3. 使用 LSM Tree 思想压缩 Packfile

直接复用 Packfile 又带来了一个新问题。

如果每次 Push 都产生独立的 Packfile，那么一个每天发生数万次提交的仓库，客户端可能需要下载数万个小文件才能追上主分支。

Pando 借鉴了 LSM Tree 的 Compaction 思想。

每次 Push 产生一个 L0 Packfile，后台任务将多个小 Packfile 组织成更大版本范围的 Cover，并逐步合并压缩。

L0: [P1] [P2] [P3] [P4] [P5] [P6]
          ↓ Compaction
L1: [    Cover A    ] [    Cover B    ]
          ↓ Compaction
L2: [           Cover C             ]

图：Pando Packfile 分层整理示意，具体 Cover 大小及层级关系以实际配置为准。

目前 OpenAI 的 Monorepo 已经使用到 L4 级别。

这些 Cover 既能减少实际传输的文件数量，也能充当 Ref 版本历史上的跳表索引，让 Fetch 能够快速确定需要哪些 Packfile。

官方给出的复杂度是：

• Push 同步元数据读写：O(1)。
• Fetch 元数据查询：O(log Δ)，其中 Δ 是客户端已有版本与目标版本之间最短的 Ref 版本距离。

有意思的是，Pando 不会简单删除合并前所有层级的 Packfile，而是保留不同层级的数据，根据客户端实际需要选择合适的版本范围。

整个读取过程又结合 Git 的 packfile-uri 能力，将数据分发交给对象存储和区域缓存。

OpenAI 为此专门维护 Express 服务，通过一致性哈希路由 Packfile 请求，区域缓存命中率超过 99%。

最终，服务端主要负责验证、版本协商和选择 Packfile，大量数据传输由缓存承担。

和 Anthropic 的 Scion 有什么不同？

回到之前介绍过的 Scion。

Anthropic 和 OpenAI 都遇到了 Agent 造成的高并发开发问题，也都采用不可变数据、内容寻址、分布式存储和多层缓存等技术，但两者对 Git 本身的态度明显不同。

Anthropic：重新考虑是否还需要完整的本地 Git

Scion 的一个基本假设是，绝大多数客户端都是始终在线的 Agent 和 CI Job。

因此，Git 为离线开发提供的完整本地仓库，在他们的工作负载下反而成为负担。

Scion 把 Commit、Merge、Rebase 等操作放到了服务端，客户端只维护有限的对象缓存和工作文件。

甚至有些 CI 任务只需要知道两个版本的差异，完全可以通过 API 查询，无须真正 Checkout 仓库。

Scion 还取消了 Git Packfile 机制，直接使用基于 Tree 和 Blob 的按需对象传输。

Anthropic 披露，Scion 的 CPU 和内存基础设施占用相比原 Git Mirror 架构减少约 200 倍，CI 和研究任务的 Checkout 从分钟级降到秒级。

OpenAI：保留 Git，但改变服务端实现

Pando 采用了另一种方式。

OpenAI 认为 Git 的客户端协议和开发工作流依然有价值，问题更多出在传统 Git 服务端处理高并发请求的方式上。

他们保留 Commit、Branch、Push、Fetch 等现有工作流，将大部分优化集中在服务端：

• 不同 Ref 之间独立协调。
• 将 Packfile 直接写入对象存储。
• 尽可能复用 Packfile。
• 利用区域缓存分发数据。
• 通过后台 Compaction 优化历史数据访问。

这意味着现有开发工具和工作流可以继续使用，迁移成本相对可控。

当然，Pando 也并非完全不需要客户端配合。为了获得最佳性能，OpenAI 维护了自己的 Git 发行版本，并对 packfile-uri、并行下载和 explicit haves 等能力做了改进。

其中一部分改动已经贡献到上游 Git。

两条路线是否存在优劣？

很难直接比较。

Scion 和 Pando 的性能数据来自不同的系统、工作负载与基准，不能用 Scion 的 200 倍基础设施缩减和 Pando 的 80% Push 延迟下降，简单判断哪个方案更好。

Scion 优先考虑的是 Agent 和 CI 如何以更低的成本获取及操作源码，因此把大量能力集中到服务端，甚至允许客户端不建立完整工作副本。

Pando 优先考虑的是如何在保留 Git 生态的情况下，提高写入并发和数据分发吞吐。

两者解决的是相互关联、但侧重点不同的问题。

我认为短期内 Pando 的路线更容易被现有 Git 服务商借鉴。因为它对现有工具链的侵入性相对较低，而且部分优化已经开始进入 Git 开源生态。

Scion 则提供了一个更有探索性的方向：如果主要使用者变成始终在线的 Agent，版本控制系统还有没有必要维持 Git 目前的客户端和服务端对称模型？

Agent 时代的软件工程会发生什么变化？

这两篇文章放在一起看，比单独讨论它们的实现更有意思。

1. Agent 正在改变软件工程的工作负载

传统研发基础设施通常围绕人类工程师的工作节奏设计。

一个工程师一天可能只提交几次代码，代码评审和 CI 的速度通常足以跟上。

Agent 的工作方式却不同。

一个工程师可以同时启动十几个 Agent，每个 Agent 持续编写代码、提交、运行测试、修复问题，再进入下一轮。

结果是代码提交、分支创建、CI 调度和构建的频率迅速提高。

Anthropic 的数据比较直观：2026 年 5 月日均合并约 2,500 次代码变更，9 月已经超过 30,000 次。

这意味着研发基础设施需要开始面对高并发系统的问题，例如吞吐量、热点竞争、缓存命中率、分布式一致性和资源隔离。

过去讨论这些问题，可能更多是在数据库、消息队列和分布式存储领域。现在连版本控制系统也开始需要采用类似的技术。

2. 重新审视一些默认的设计约束

Scion 和 Pando 都做了一件值得关注的事：重新审视过去被认为理所当然的约束。

Scion 发现，对于始终在线的 Agent，没有必要要求客户端始终拥有完整的仓库历史。

Pando 发现，不同分支的更新也没有必要维护整个仓库的全局时间顺序。

这些取舍能够带来非常明显的性能收益。

但这并不意味着 Git 当初的设计存在问题。Git 服务于大量不同的开发场景，包括离线开发、开源协作、分布式团队和个人项目。

Scion 和 Pando 则针对高度集中的超大规模 Monorepo，进一步优化了其中最重要的工作负载。

当使用场景发生变化，原先合理的设计约束就可能成为新的扩展瓶颈。

3. 代码写得更快，交付是否也能更快？

我觉得这是比 Git 性能更值得思考的问题。

过去软件开发的一个主要限制是编写代码需要大量人力，AI Agent 正在显著降低这部分成本。

但代码生产速度提高，并不会自动让软件交付速度按相同比例提高。

代码依然需要经过测试、评审、集成、部署和运行验证。

Anthropic 在 Scion 文章中就提到，传统依赖全局锁的 Merge Queue 很难适应 Agent 的规模。测试还在执行时，可能已有数百甚至数千个变更合入。

因此，他们开始更重视合并后、部署前的自动化测试，并让 Claude 处理大量并发修改引起的冲突。

OpenAI 的 Pando 同样在提高变更从 Push 到可以被其他系统获取的效率。

两家公司正在解决软件交付链路中的不同瓶颈。

但我认为，代码产生得越多，验证每一项变更是否正确、是否满足业务约束、是否能安全上线，就会变得越重要。

未来软件工程的核心指标可能需要从提交次数、代码量，进一步转向经过有效验证的变更吞吐量。

如果一个 Agent 每天可以提交一百次代码，但最终只有少数变更能够稳定进入生产环境，那么源码管理性能的提升仍然只解决了部分问题。

4. Agent 也正在参与重建自己的基础设施

两家公司还有一个共同点：这些新系统本身也是 AI Agent 深度参与开发的结果。

OpenAI 表示，Pando 从项目启动到生产部署只用了 10 周。核心架构由一名工程师设计，多组 Codex Agent 参与实现，少量工程师负责部署。

他们还使用确定性模拟测试、Git 兼容性测试，以及由 GPT-6 Astra 编写的 Lean 和 TLA+ 形式化模型，验证系统中的并发和一致性问题。

Anthropic 则由约七人的团队，在五个月内完成 Scion、Antique 等多个系统的开发与迁移，并大量使用 Claude 完成代码实现和优化。

这可能意味着基础设施研发的组织方式也正在变化。

工程师依然需要理解分布式系统、数据结构、一致性模型和业务约束，但更多工作会转向架构设计、定义正确性条件、构建验证体系，以及判断 Agent 产出的实现是否符合预期。

而且，Agent 能更快地产出代码，也会提高系统复杂度失控的风险。越是底层的基础设施，越需要有严格的测试与验证能力。

最后

Pando 和 Scion 的出现，至少说明一个趋势：AI Agent 已经开始对软件工程基础设施产生实际影响。

Anthropic 选择重新设计版本控制系统，OpenAI 选择保留 Git 生态并重构服务端，两条路线都取得了不错的结果。

不过，对于大多数日常开发团队，目前并没有更换 Git 的必要。两家公司面对的都是非常特殊的大规模 Monorepo 工作负载，它们的性能收益也依赖特定的业务规模和基础设施条件。

真正值得借鉴的，是它们对现有架构约束的重新思考，以及利用不可变数据、缓存、并发控制和按需计算来降低系统成本的方法。

从 Scion 到 Pando，可以看到一个比较清晰的变化：当 AI Agent 大幅降低代码生产成本后，软件工程的瓶颈开始向源码管理、构建、测试、评审和交付环节转移。

未来可能还会出现更多专门为 Agent 工作负载设计的基础设施。

而 Git 只是其中一个开始受到冲击的环节。

参考资料

1. Scaling Git at OpenAI，OpenAI，2026-11-02
2. Redesigning source control at Anthropic，Anthropic，2026-10-13
3. Anthropic 自研版本控制 Scion，Leafw’s Blog，2026-10-14
4. OpenAI Git 公共仓库