本文永久链接 – https://tonybai.com/2026/11/04/openai-pando-rebuild-git-for-ai-agent-era
大家好，我是Tony Bai。
【导读】
当 AI Agent 开始大规模接管软件开发，一个意想不到的基础设施瓶颈出现了：Git。
过去，一个工程师可能同时维护几个分支，提交代码、等待 CI，再进行下一轮开发。但现在，一个工程师可以同时启动几十个 Codex Agent。每个 Agent 都可能独立创建分支、提交代码、Push，并触发大量 CI 任务。
结果就是：Git 服务端开始承受前所未有的并发压力。
2026 年 11 月 2 日，OpenAI 发布了一篇工程技术文章《Scaling Git at OpenAI》，首次详细披露了其内部 Git 后端系统 Pando。这是继 Anthropic 之后，又一家头部大模型厂商重建了版本控制系统。
这套系统在完全保留 Git 协议和开发者工作习惯的前提下，将 Push 中位延迟降低了近 5 倍，每天处理接近 1 PB 的 Git 数据。
更令人惊讶的是，这套系统从启动到投入生产仅用了 10 周，核心实现由 Codex Agent 团队完成。
Git 已经诞生 20 多年，为什么 AI Agent 的出现会让它遭遇新的瓶颈？OpenAI 又是如何从底层重新设计 Git 服务端的？
这背后，可能隐藏着 AI 时代软件工程基础设施的一次重要变革。
【文章要点】
- AI Agent 改变了软件开发的负载模型：从人类驱动的有限并发，转向机器驱动的高并发。
- OpenAI 没有抛弃 Git，而是保留 Git 协议，重新设计服务端架构。
- Pando 通过因果一致性，让不同分支的 Push 可以并行执行。
- 通过 Packfile 复用、区域缓存和分层 Compaction，大幅提升 Fetch 吞吐。
- Pando 采用 Rust 实现，Codex 参与开发，Lean 和 TLA+ 帮助验证系统正确性。
- 这不仅是 Git 的一次升级，更是 AI Agent 推动软件工程基础设施演进的一个信号。
AI Agent 把 Git 逼到了极限
Git 诞生于 2005 年。
过去二十多年，它几乎成为软件开发领域不可撼动的基础设施。从 Linux 内核到 Kubernetes，从个人开源项目到大型企业 Monorepo，Git 支撑了全球开发者的协作。
但 AI Agent 正在改变 Git 所面对的工作负载。
过去，一个工程师通常同时维护少量分支，完成编码后提交代码，再等待 CI 构建和测试。即使是大型研发团队，Git 服务端的并发压力也相对可控。
现在，一个工程师可以同时启动多个 Codex Agent。
每个 Agent 都可能独立完成以下操作：
- 创建自己的代码分支。
- 修改代码并生成 Commit。
- Push 到远程仓库。
- 触发 CI 构建、测试和代码审查。
- 根据反馈继续修改并提交。
这意味着，一个原本由人类开发者控制的工作流，正在变成由大量 AI Agent 驱动的并行工作流。
更麻烦的是，多个 Agent 的工作还会产生连锁效应。
一次 Push，可能触发多个 CI Job；每个 Job 都需要 Fetch 相同的 Commit。Agent 越多，代码提交和读取请求就越密集。
OpenAI 在文章中透露，早在 2025 年底，其内部 Monorepo 就已经开始出现严重问题：
- Fetch 和 Push 速度变慢。
- Merge 失败增加。
- 系统可靠性一度跌破 90%。
这让 OpenAI 团队开始思考一个问题：
究竟是 Git 本身已经无法满足需求，还是我们过去使用 Git 的方式已经无法适应 AI 时代？
最终，他们选择了一条很有意思的路线：
不抛弃 Git，而是重新设计 Git 的服务端。
这就是 Pando。
Pando：不重造 Git，重建 Git 后端
OpenAI 在 2026 年 11 月 2 日发布的文章《Scaling Git at OpenAI》中，正式介绍了内部 Git 后端系统 Pando。
它有两个非常明确的设计目标：
目标一：让写入能够水平扩展。
允许大量 Agent 同时向不同分支 Push，不要因为某个分支的更新而阻塞其他分支。
目标二：让读取吞吐最大化。
当成千上万个 Agent、CI Job 同时读取同一段代码历史时，服务端应该能够以接近网络带宽上限的速度提供数据。
这里最值得关注的是，OpenAI 并没有要求开发者改变 Git 工作习惯。
依然可以使用熟悉的命令：
git add . git commit -m "add feature" git push git fetch git pull 开发者不需要学习一套新的版本控制系统，Agent 也不需要重新适配一套完全不同的工作流。
改变发生在 Git 命令背后的服务端。
先理解 Git 的两个核心组成部分
要理解 Pando，首先需要理解 Git 的底层数据模型。
Git 仓库主要由两部分组成：
第一部分：Objects。
Git 使用内容寻址的对象存储，主要包括：
- Blob：文件内容。
- Tree：目录结构。
- Commit：提交及其父提交。
- Tag：对象标签。
这些对象通过 Hash 标识，而且具有不可变性。
第二部分：Refs。
Branch 和 Tag 等引用指向 Commit。
例如，main 分支本质上就是一个指向某个 Commit 的引用。
问题恰恰出现在这两个部分的协调上。
当多个客户端同时 Push 时，服务端不仅要接收新的 Objects，还需要更新对应的 Refs。
传统分布式 Git 服务端通常需要在多个副本之间协调这些更新，保证不同节点看到的数据一致。
如果所有分支更新都需要经过一个全局协调点，那么即使两个 Agent 修改的是完全不同的分支，也可能互相等待。
读取端也有类似问题。
传统 Git Server 通常需要根据客户端已有的 Objects 和目标 Commit，实时计算差异，再生成对应的 Packfile。
不同客户端的历史状态不同，服务端可能需要反复执行解包、对象遍历、差异计算和重新打包。
当成千上万个 Agent 同时 Fetch 时，这些重复计算就会成为巨大的资源消耗。
Pando 的设计，正是针对这两个瓶颈展开的。
两个关键设计：写入并行，读取复用
Pando 最核心的设计思想可以概括为两句话：
写入端：放松全局一致性，让不同分支独立更新。
读取端：复用已经生成的 Packfile，避免重复计算。
写入：用因果一致性换取水平扩展
核心设计一
传统分布式存储系统往往强调全局一致性。
但 OpenAI 发现，对于 Agent 驱动的代码开发场景，所有分支并不一定需要保持一个严格的全局时间点快照。
假设三个 Agent 分别操作三个分支：
Pando | +----------+----------+ | | | Branch A Branch B Branch C | | | Agent 1 Agent 2 Agent 3 | | | Push Push Push | | | +----------+----------+ 并行写入 Agent 1 更新 Branch A 时，为什么必须等待 Agent 2 更新 Branch B？
它们之间并没有直接的依赖关系。
因此，Pando 采用了因果一致性（Causal Consistency）模型。
具体做法是：
- 客户端 Push 时，Pando 将上传的 Packfile 作为不可变 Blob，直接流式写入对象存储。
- 元数据服务记录分支的新版本，包括 Commit、Packfile 以及依赖的历史版本。
- 每个分支独立维护自己的版本指针。
- 不同分支的更新可以并行执行。
- 只有多个客户端同时更新同一个 Ref 时，才需要进行竞争协调。
这带来了一个非常重要的变化：
Pando 不再要求整个仓库的所有 Ref 始终处于同一个全局一致性快照中，而是保证单个 Ref 的更新具有可串行化语义。
同时，它还提供 Read-your-own-write 保证，也就是客户端完成 Push 后，可以立即读取自己刚刚写入的内容。
当然，这种设计也有取舍。
如果一个客户端同时读取多个分支，它看到的分支版本可能来自不同时间点。
但 OpenAI 认为，对于 Agent 的日常开发工作流，单个分支的提交顺序远比所有分支的全局顺序重要。
这是一种非常典型的分布式系统设计思路：
不是盲目追求最强一致性，而是根据实际业务需求，选择恰当的一致性边界。
读取：Packfile 不再为每个客户端重复生成
核心设计二
如果说因果一致性解决了写入问题，那么 Packfile 复用解决的就是读取问题。
传统 Git Server 在处理 Fetch 时，需要根据客户端的 have 和 want，计算客户端缺少哪些对象，然后生成一个新的 Packfile。
但在 AI Agent 场景下，大量客户端其实是在读取相同的代码历史。
既然如此，为什么不让它们直接复用已经生成的数据？
Pando 的处理流程如下：
具体来说：
- Push 时，服务端不再将整个 Packfile 解包到本地 Repository，而是直接流式写入对象存储。
- Fetch 时，服务端根据客户端已有的 Commit 和目标 Commit，选择已经存储的 Packfile。
- 服务端通过 Git 协议的
packfile-uri机制，返回 Packfile 的下载地址。 - 客户端直接从 Express 下载数据。
这里有一个非常巧妙的地方。
Git 协议原本就支持 packfile-uri 扩展，但这个能力并没有被充分利用。
Pando 将它作为核心数据传输机制，并且 OpenAI 还向 Git 上游贡献了相关改进。
这样一来，Git 服务端不必为每个客户端重复生成一份 Packfile。
多个客户端可以直接下载同一份已经生成的数据。
OpenAI 在全球部署了多个 Pando 集群，每个区域都有自己的 Express 缓存服务。
通过一致性哈希将 Packfile 请求路由到对应的 Express 节点，缓存命中率超过 99%。
在标准云厂商虚拟机上，OpenAI 已经验证 Fetch 和 Clone 可以跑满 10 Gbps 网络链路。
Compaction：避免 Packfile 越积越多
但这里又产生了一个新问题。
如果每次 Push 都产生一个新的 Packfile，那么随着代码不断提交，客户端 Fetch 时就可能需要下载成千上万个小 Packfile。
这显然不可接受。
为此，Pando 引入了后台 Compaction 机制。
它的设计思想与 LSM Tree 非常相似。
每次 Push 产生一个最小的 L0 Packfile，后台 Worker 会持续收集这些 Packfile，并将它们组织成更高层级的 Cover。
可以将其理解为：
- L0：每次 Push 产生的小 Packfile。
- L1：多个 L0 Packfile 形成的覆盖层。
- L2、L3、L4：逐级合并形成更大的覆盖层。
OpenAI 表示，目前其 Monorepo 已经使用到 L4。
Compaction 有两个作用：
第一，改善压缩率。
将多个小 Packfile 重新组织成更大的 Packfile，减少重复数据。
第二，加速 Fetch。
这些 Cover 还承担类似 Skip List 的作用。
客户端需要获取某段历史时，服务端可以通过多层索引快速找到需要的 Packfile，而不必逐个扫描所有历史版本。
特别值得注意的是，Pando 并不会像传统 Git GC 那样简单地删除低层 Packfile。
不同层级的 Packfile 都会保留，用于服务不同客户端的 Fetch 请求。
这是一种很有意思的空间与时间取舍。
它用额外的存储空间，换取更低的读取延迟和更高的数据复用率。
10 周，从 Codex 到生产环境
Pando 的技术架构已经足够令人印象深刻。
但 OpenAI 文章中，还有一个更加值得 AI 工程师关注的细节：
Pando 本身就是由 Codex 参与构建的。
OpenAI 披露：
- 从项目启动到投入生产，只用了 10 周。
- 核心架构由一名工程师设计。
- 主要实现由多个 Agent 团队完成。
- 最终由少量工程师负责部署。
- Pando 从 2026 年 4 月开始承载生产流量。
这不是简单地让 AI 补全一些代码，而是让 Agent 参与构建一个复杂的分布式基础设施系统。
为什么选择 Rust？
Pando 是一个全新项目，OpenAI 最终选择 Rust 实现，并且没有引入遗留系统依赖。
这并不难理解。
Pando 涉及大量并发操作、网络传输、对象存储和元数据管理，对内存安全、性能以及并发正确性都有很高要求。
Rust 的类型系统、所有权机制和零成本抽象，为这类基础设施提供了不错的工程基础。
另外，OpenAI 还构建了 Git 协议兼容性测试套件，让 Agent 能够持续验证自己的修改是否符合标准 Git 行为。
用 Lean 和 TLA+ 验证 Agent 写出的代码
更有意思的是，OpenAI 并没有因为有了 AI Agent，就降低对系统正确性的要求。
相反，他们构建了确定性模拟测试框架，用于检查系统不变量、并发行为和潜在竞态条件。
此外，OpenAI 还使用 GPT-6 Astra，让 Agent 编写 Lean 和 TLA+ 模型，对 Pando 的设计进行形式化建模。
这些模型帮助团队发现并修复了实现中的一些问题。
其中：
- Lean 用于表达和证明数学性质。
- TLA+ 用于描述并发系统的状态转换和不变量。
- 确定性模拟测试用于反复验证系统在不同执行顺序下的行为。
多个 Agent 持续运行了数百小时，寻找和修复边界条件问题。
OpenAI 还使用具备 Daybreak 能力的模型，持续对 Git 和 Pando 进行自动化安全测试。
这体现出一种非常值得关注的工程实践：
AI Agent 不仅负责生成代码，还参与设计验证、并发测试和安全审查。
当 Agent 开始编写复杂基础设施时，形式化方法和自动化验证反而变得更加重要。
如何在不影响业务的情况下完成迁移？
重建 Git 后端是一回事，让整个组织平滑迁移则是另一回事。
OpenAI 最初采用 Read-through 和 Write-through Proxy 模式，让 Pando 与原有系统保持同步。
这样可以逐步将流量迁移到新系统，而不必一次性切换。
与此同时，他们还：
- 为开发机器和 ChatGPT Desktop App 提供定制 Git 发行版。
- 通过内部 Git CLI Wrapper 分阶段迁移客户端。
- 迁移数百个依赖旧 API、Webhook 和 Repository 下载的集成。
- 利用 Codex Skills 帮助开发者迁移现有工作环境。
最终，开发者甚至可以直接要求 Codex 帮助迁移自己的开发环境和服务。
这也是整个项目非常有意思的一点：Agent 不仅参与建设新基础设施，还参与将整个组织迁移到新基础设施。
Pando 的成绩单：每天近 1 PB Git 数据
这里有两个数据尤其值得关注。
首先，Push 中位延迟降低了近 80%，也就是接近 5 倍的改善。
其次，Pando 每天可以提供接近 1 PB 的 Git 数据，单小时服务过 57 TB Packfile，其中超过 99% 的传输字节来自本地磁盘缓存。
这说明 Pando 不是靠增加服务器数量解决问题，而是从数据组织、访问模式和缓存架构上改变了 Git 服务端的工作方式。
另外，OpenAI 也没有把这些改进全部封闭在内部。
他们已经将部分优化贡献给 Git 上游，包括并行下载和索引独立 Packfile、packfile-uri 相关改进，以及显式 haves 等能力。
这意味着，Pando 的一些设计经验未来也可能惠及更广泛的 Git 用户。
Git 只是开始：AI 正在倒逼基础设施重构
Pando 最值得关注的地方，其实不只是它解决了 Git 的性能问题。
它揭示了一个更深层的趋势：
AI Agent 正在改变软件开发的负载模型，而原本为人类开发者设计的基础设施，可能需要重新设计。
过去的软件工程基础设施，基本都是围绕人类的工作节奏构建的：
- Git 服务端处理开发者的提交和读取。
- CI/CD 根据代码变更触发流水线。
- 代码审查平台等待 Reviewer 反馈。
- 构建系统负责生成最终的软件产物。
但当一个开发者可以同时启动几十个 Agent，甚至一个组织可以运行成千上万个 Agent 时，这些系统都会面临新的挑战。
我认为，接下来至少有三个方向值得关注。
第一，CI/CD 需要重新设计。
当 Agent 可以高频提交代码，传统的固定流水线可能面临调度和资源瓶颈。
未来的 CI/CD 不仅需要支持更高并发，还需要让 Agent 能够直接参与任务调度、失败诊断和自动修复。
这方面 Docker 之父近期发布的号称第三代 CI 的 Dagger 项目值得关注。
第二，构建系统需要更强的数据复用能力。
多个 Agent 同时构建相同项目时，如果每次都重复下载依赖、编译相同模块、准备完整环境，资源浪费将非常惊人。
远程缓存、增量构建、构建图复用将变得更加重要。
第三，软件工程基础设施本身将成为 Agent 的工作对象。
这是我认为最重要的变化。
过去，Agent 主要负责业务代码，基础设施由资深工程师设计和维护。
现在，Agent 已经能够参与复杂系统的架构设计、实现、性能优化，甚至形式化验证。
OpenAI 用 Codex 构建 Pando，就是一个非常直接的例子。
于是，一个新的循环正在形成：
Agent 越强，代码产出越多，基础设施承受的压力越大；基础设施越强，又能支撑更多 Agent 并行工作。
这可能是 AI Software Factory 真正走向规模化之前，必须经历的一次基础设施演进。
小结
Git 诞生于 2005 年。
二十多年后，OpenAI 并没有选择抛弃它，而是重新思考 Git 在 AI 时代应该如何工作。
Pando 的设计给出了一个很有价值的答案：通过因果一致性解决并发写入，通过 Packfile 复用解决海量读取，再通过缓存和 Compaction 支撑规模化运行。
更有意思的是，这套系统本身也是 Codex Agent 参与构建的。
AI Agent 不仅在改变我们编写软件的方式，也正在改变支撑整个软件产业运行的基础设施。
或许，AI 编程时代真正的竞争，已经不只是哪个模型写代码更快，而是谁能率先建立起一套能够支撑成千上万个 Agent 并行工作的软件生产体系。
Pando，可能只是这场变革的一个开始。
原文地址：Scaling Git at OpenAI - https://openai.com/index/scaling-git-at-openai/
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
