OpenAI 在 11 月初公开了 Pando：一个用 Rust 写的、Git 兼容的仓库后端，用来支撑它自己的单体仓库（monorepo）。它不是要替代 Git 本身，而是保留 Git 协议和客户端兼容，把存储层换成一套为「agent 规模」设计的实现。推动这件事的直接原因是 Codex——它让工程师能并行做更多工作，直接带来更多分支、更多推送、更多合并、更多来自开发环境和 CI 的拉取与克隆，原有的仓库系统从去年年底开始跟不上，拉取推送变慢、合并失败，可靠性一度跌破 90%。这篇拆它的两个核心取舍和背后的数字。
从启动到生产
Pando 是全新项目，无遗留依赖，用 Rust 实现。核心设计由一名工程师完成，多个 agent 团队实现，少数几名工程师部署，从启动到上线只用了 10 周，今年 4 月开始承载生产流量。开发过程本身就是它要服务的那种工作流的缩影：团队给 Codex 写了对照标准 Git 行为的一致性测试套件，让 agent 改动后跑测试；还写了确定性模拟框架验证不变量，用它发现并修掉了微妙的竞态回归。更进一步的验证用了 GPT-6 Astra，让 agent 写 Lean 和 TLA+ 来形式化「Pando 理论」，找实现 bug、证系统性质。
两个放弃的假设
大多数 Git 服务把两件事当成必需：一是仓库级一致性，即所有 refs 有一个点时间快照；二是为每个客户端单独生成 packfile。Pando 把这两个假设都放弃了，换来可扩展性。
第一个，用因果一致性替代仓库级一致性。推送时，传入的 packfile 作为不可变 blob 存进 blob store；每次分支移动，metadata store 记录一个 ref version，包含新的分支 tip、提供它的 pack、以及这个 pack 依赖的更早 ref versions。拉取时重放一组 ref versions 重建客户端状态。单个 ref 的更新有串行化保证，但跨仓库不做全局时间点一致——两个客户端可能各自看到 foo/bar 处于不同的版本组合。实践里人和 agent 并不关心全局顺序，只依赖单个 ref 的更新顺序，所以这个取舍是划算的。
第二个，复用 packfile。传统服务器给每个客户端现算一个 pack，Pando 则让同一批字节服务多个客户端。它完全依赖 Git 协议里一个被低估的特性 packfile-uri：服务器返回链接让客户端单独下载额外的 packfile，内联只传一个空 packfile。OpenAI 为此还向 Git 上游贡献了多项 packfile-uri 改进。
推送与拉取的复杂度
写入路径上，Pando 边验证边把 packfile 流式写进 blob store，不把它解包到本地仓库，用单遍解码验证推送，再用多键事务在 metadata store 记录 ref version、原子更新 ref 指针，提供读自己写的一致性。推送的 metadata 读写是 O(1)，与推送大小无关；唯一竞争的键是 ref 指针，用类似 compare-and-swap 的原子操作保护。推送到不相关 refs 完全并行。读取路径上，拉取需要 O(log Δ) 次 metadata 读取，Δ 是客户端已有与想要之间最短的 ref version 距离。
控制 pack 大小与压缩
百万级分支时，全量 ref 公告本身就能超过 100 MiB。Pando 只公告精选分支子集，默认只公告主干作为基准，这让客户端生成的 pack 能被后续拉取复用，也把 pack 压小：OpenAI 单体仓库里 packfile 中位数低于 20 KiB、第 99 百分位低于 3 MiB。代价是向同一分支反复推送时要重发主干之外的内容。后台还有一套借鉴 LSM-tree 的压缩机制：每次推送产生 L0 级 packfile，后台 worker 把 packfile 合并成覆盖多个 ref versions 的 cover，级别几何扩展，目前用到 L4。所有级别的 packfile 都保留、不做垃圾回收，cover 同时充当 ref versions 上的跳表，让 pack 选择在对数时间内完成。
关键数字
| 指标 | 数值 |
|---|---|
| 启动到生产 | 10 周 |
| 核心设计 | 1 名工程师 |
| 每日 Git 数据交付 | 近 1 PB |
| 单小时峰值 pack 服务 | 超 57 TB |
| Express 缓存命中率 | 超 99% |
| 推送延迟（中位数） | 降低近 5 倍 |
| 克隆/拉取吞吐 | 标准云 VM 打满 10 Gbps |
| 原系统可靠性最低点 | 低于 90% |
交付近 1 PB/天只需少量 CPU 核心；Express 缓存服务用一致性哈希把 packfile 请求路由到各区域的本地缓存，命中率超 99%。
对开发者意味着什么
两点。一是这篇文章明确点出一个趋势：大型且快速变化的仓库将成为软件开发的新常态，而 agent 会持续加速这个变化，传统 Git 服务的性能假设正在被打破。二是它展示了「为 agent 规模重做基础设施」的完整方法论——从一致性的取舍、pack 复用，到用一致性测试和形式化验证让 agent 参与实现，每一步都指向可扩展性。OpenAI 已经把多项改进贡献回上游 Git，并公开了补丁跟踪器，普通团队短期用不到 Pando，但能从它的设计取舍里看到下一代会话级开发协作的样子。
待观察
两点要盯。一是文章没有给绝对性能数字，比如推送延迟的毫秒值、提交和分支总数，只有相对改善和吞吐量，很难直接对标自己的仓库。二是这是 OpenAI 单体仓库的特定场景，通用仓库、尤其是小团队的小仓库，未必需要这套复杂度。方向是清楚的：当代码开始由 agent 以远超人类的并发去读写时，存储层的假设就得重写。