# OpenAI 也开始改造 Git 了
10 月 13 日，Anthropic 发布了 [Redesigning source control at Anthropic](https://www.anthropic.com/engineering/redesigning-source-control)，介绍自研版本控制系统 Scion。当时写过一篇[《Anthropic 自研版本控制 Scion》](https://www.leafw.net/anthropic-scion/)，核心是 Claude 产生代码的速度太快，以至于 Git、构建和 CI 这些原本服务于人类开发者的基础设施开始成为瓶颈。
不到一个月，11 月 2 日，OpenAI 也发布了技术文章 [Scaling Git at OpenAI](https://openai.com/index/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 的全部开发工作，并取得了几项结果：
| 指标 | Pando 的表现 |
|---|---|
| Push 中位延迟 | 降低近 80%，约提升 5 倍 |
| Git 数据分发量 | 每天接近 1 PB |
| 单小时最高分发量 | 超过 57 TB Git Pack 数据 |
| 区域缓存命中率 | 超过 99% |
| Fetch / Clone | 能够跑满 10 Gbps 网络链路 |
| 从启动到生产 | 10 周 |
这些数据来自 OpenAI 的生产环境及性能验证。需要注意，10 Gbps 是在其基础设施中验证的网络吞吐能力，并不代表所有 Git 客户端都能达到这个速度。
## Pando 是怎么设计的？
先来看一下 Pando 的整体架构。
```mermaid
flowchart TB
A["Codex Agent A"]
B["Codex Agent B"]
C["Codex Agent C"]
P["Pando Git 服务
Push 验证 / Fetch 规划"]
M[("元数据存储
Ref / 版本 / 依赖关系")]
S[("对象存储
不可变 Git Packfiles")]
E["Express 区域缓存"]
G["Git Clients / CI"]
A -->|Push| P
B -->|Push| P
C -->|Push| P
P <-->|元数据读写| M
P -->|上传 Packfile| S
S -->|Packfile 数据| E
E -->|下载 Packfile| G
G -->|Fetch 请求| P
P -.->|返回 Packfile URI| G
classDef client fill:#f1f5f9,stroke:#64748b,color:#334155
classDef service fill:#dbeafe,stroke:#3b82f6,color:#1e40af
classDef metadata fill:#ccfbf1,stroke:#0d9488,color:#115e59
classDef storage fill:#dbeafe,stroke:#2563eb,color:#1e40af
class A,B,C,G client
class P,E service
class M metadata
class S storage
```
*图：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 同时工作：
```text
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，并逐步合并压缩。
```text
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 Scion | OpenAI Pando |
|---|---|---|
| 产品定位 | 自研版本控制系统 | 新的 Git 服务端后端 |
| Git 兼容性 | 使用独立客户端和协议 | 保留 Git 协议与工作流 |
| 数据模型 | Changeset、Blob、派生索引 | Git Object、Ref、Packfile |
| Commit | 服务端执行 | 客户端本地执行 |
| Merge / Rebase | 服务端执行 | 保留 Git 工作流 |
| 本地仓库 | 按需缓存，支持虚拟化 Checkout | 保留 Git 本地仓库 |
| 分支管理 | 尽量减少 Ref 的使用 | 保留 Ref，独立协调 |
| 数据传输 | 按需请求 Tree / Blob | 复用已有 Packfile |
| 主要优化方向 | 减少数据物化与本地仓库维护 | 提高并发 Push 和 Fetch 吞吐 |
| 迁移方式 | 完整迁移版本控制生态 | 分阶段替换 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](https://openai.com/index/scaling-git-at-openai/)
2. [Redesigning source control at Anthropic，Anthropic，2026-10-13](https://www.anthropic.com/engineering/redesigning-source-control)
3. [Anthropic 自研版本控制 Scion，Leafw's Blog，2026-10-14](https://www.leafw.net/anthropic-scion/)
4. [OpenAI Git 公共仓库](https://github.com/openai/git)