OpenAI 揭秘全新 Git 后端 Pando：重构架构承载 AI 智能体高并发

过去一年，OpenAI 内部单体代码仓库的规模呈爆炸式增长。Codex 的广泛应用改变了研发节奏，工程师与 AI 智能体能够并行开展海量工作。然而，伴随而来的分支暴增、持续集成（CI）并发获取和频繁推送，让原有系统不堪重负，代码合并可靠性一度跌破 90%。

为突破瓶颈，OpenAI 构建了全新的 Git 后端系统 Pando。在完全兼容现有 Git 协议与工作流的前提下，Pando 成功将代码推送延迟的中位数降至原先的约五分之一（降幅近 80%），目前每天稳定分发近 1 PB 的 Git 数据。

传统 Git 扩展方案的瓶颈

Git 最早专为 Linux 内核补丁交流设计。当代码仓库膨胀到巨型单体规模时，扩展主要受制于两个维度：大量写入端并发推送不同分支，以及大量读取端并发获取相同历史。

业内传统的扩展方案通常面临以下局限：

1. 三阶段提交（3PC）：在多个副本间维持强一致性。写入时需跨节点协调多数派确认，磁盘性能与多轮通信延迟成为推送瓶颈；
2. 共享预写日志（WAL）：通过对象存储中的共享清单对全局更新排序。尽管上传包文件可以并行，但更新清单时的原子比较与交换（CAS）操作极易在高并发下产生争用。

更关键的是，传统 Git 服务倾向于“按需”为每个客户端实时计算并生成专属包文件（packfile），在大并发读取时会消耗巨额的 CPU 和磁盘 I/O。

Pando 的架构创新：因果一致性与包复用

Pando 重新评估了系统约束，做出了两项核心设计取舍：

1. 采用因果一致性（Causal Consistency）

Pando 放弃了全局统一快照的要求，转为独立协调每个分支的更新。只要不是同时推送同一个分支，写入操作便互不阻塞。

客户端推送时，Pando 将传入的包文件作为不可变对象直接流式写入底层对象存储，并在元数据服务中记录一个“引用版本”（包含新分支头、对应包文件及其依赖版本）。该写入流程只需 $O(1)$ 次元数据操作。尽管客户端读取多个分支时可能无法得到绝对同一时刻的全局视图，但这完全满足工程师与 AI 智能体对单一分支顺序性的实际需求。

2. 定向通告与包文件复用

传统服务器在推送时会通告全部引用，不仅元数据传输量庞大（可达百兆以上），还会导致生成的包文件难以被其他客户端复用。Pando 默认仅向客户端通告指定的主干分支作为基准。如此一来，生成的包文件能被其他已同步主干的读取端直接复用，服务器无需重复计算差异。

达到线速的读取与分层合并压缩

为了实现极致的读取吞吐，Pando 深度利用了 Git 协议中较少使用的 packfile-uri 特性。服务器在响应获取请求时仅发送一个空包，随后指示客户端直接从多区域缓存服务（Express）中并行下载所需的实际包文件。

通过一致性哈希路由与区域缓存，Pando 的缓存命中率超过 99%，在云服务商普通虚拟机上即可跑满 10 Gbps 的物理网络带宽。

为了避免客户端因大量细碎包而下载过载，Pando 引入了类似日志结构合并树（LSM-tree）的分层压缩机制：

• 每次推送生成最小粒度的 L0 包；
• 后台进程按几何级数将包归集为 L1 至 L4 覆盖集，并在后台重新组织对象压缩；
• 覆盖集同时充当跳表索引，让 Pando 能够以 $O(\log \Delta)$ 的对数时间复杂度规划出最优包组合。

借助 AI 仅用 10 周落地

Pando 项目由一名工程师主导设计，在多个智能体团队协作下编写，从启动到投入生产仅耗时 10 周。系统完全采用 Rust 编写，借助确定性模拟测试框架排查并发竞态，并利用新一代 AI 模型（包括 GPT-6 Astra）编写 Lean 和 TLA+ 形式化规范，构建严密的理论证明与红队安全测试。

在上线初期，Pando 先以读穿透、写直达的透明代理模式运行，随后借助 Codex 自动为开发者完成开发环境迁移。在实际生产中，Pando 曾在一小时内分发超 57 TB 数据，且 99% 以上直接命中本地磁盘缓存。

持续回馈开源社区

在研发 Pando 的过程中，OpenAI 团队发现了多项 Git 在大规模并发下载、断点续传和索引构建方面的边界缺陷，并已陆续向上游贡献代码。团队还维护了自己的 Git 开源分支，引入了支持并行下载与“显式 have”等多项改进，后续进展均可通过其公开补丁跟踪器进行追踪。

随着越来越多团队引入 AI 智能体参与软件开发，源码控制面临的并发挑战将成为行业常态。OpenAI 表示，将继续拓展 Pando 的承载能力，并持续将核心优化成果回馈给全球开源生态。