当写代码的主力从人类工程师变成不知疲倦的 AI 智能体，最先撑不住的居然是沿用了二十多年的 Git。2026 年 11 月 2 日，OpenAI 发文披露了全新自研的 Git 后端系统 Pando。去年底，由于内部编程智能体 Codex 推动并行开发激增，OpenAI 单一代码主仓库（monorepo）的可靠性一度跌破 90%，拉取与推送卡顿，代码合并频繁失败。Pando 上线接管全部主仓库研发后，在不改变工程师和 Agent 现有工作流的前提下，将生产环境的中位推送延迟降低了近 5 倍（近 80%），目前每天传输近 1PB 的 Git 数据。
把几组硬指标放在一起看，就能明白 OpenAI 遭遇的流量冲击有多凶猛：
- 流量规模.日吞吐逼近 1PB，单小时峰值超过 57TB，其中超过 99% 的字节直接由区域本地磁盘缓存提供。
- 传输极速.在标准云虚拟机上，克隆（clone）和拉取（fetch）操作能直接跑满 10 Gbps 的网卡带宽。
- 架构解耦.不可变的打包文件（packfiles）存入 Blob 存储，引用（ref）版本与依赖关系存入元数据存储；推送时流式验证直传而不必解压到本地仓库，拉取时直接下发
packfile-uri缓存链接。 - 开源范围.OpenAI 公开的
github.com/openai/git仓库仅包含其 Git 客户端分支（增加了并行 pack 下载与索引、explicit haves等特性），Pando 服务端本身尚未开源。
机器级并发：为什么 Codex 会把传统 Git 逼到死角
Git 诞生于靠邮件交换 Linux 内核补丁的年代。过去二十年里，Google（Piper+CitC）、Meta（Sapling+Mononoke+EdenFS）和微软（Scalar 与 GVFS）都在改写源码管理基础设施。但上一代大厂造轮子，解决的是静态规模问题：工程师人数多、历史代码库体积庞大、本地检出缓慢。
OpenAI 撞上的则是动态机器流量。在 Codex 驱动的研发模式下，一名人类工程师可以同时挂起多个变更分支，每一次推送又会瞬间唤醒成百上千个沙盒容器、研究任务和 CI 节点，同时去拉取同一个提交（commit）。这种机器级并发恰好击中了传统 Git 服务端的两处软肋。
写入端卡在全局协调。无论是采用三阶段提交（3PC，如早期托管平台的多副本强同步）还是预写日志（WAL，通过共享清单排定顺序），传统架构往往追求全仓库所有分支的强一致快照。哪怕两个 Agent 推送的是完全不相干的特性分支，也必须在同一个协调点上排队抢锁。
读取端死于动态计算。每次客户端发起拉取，传统 Git 服务端都会对比双方历史，动态找出缺失对象并实时压缩成专属的 packfile。当上千个 CI 容器在同一秒拉取同一个提交时，服务端的 CPU 会在重复的打包计算中瞬间耗尽。
带宽换算力：Pando 的三次反直觉交换
要喂饱日均 1PB 的吞吐，修补旧引擎已经没用了。我更在意的是 Pando 架构背后的工程算计：它几乎把传统 Git 视为理所当然的设计约束全反了过来，做了一笔用内网带宽和存储冗余换取服务端零计算的买卖。
算力在 AI 时代太贵，而机房里的 10Gbps 光纤和对象存储很便宜。
Pando 砍掉的第一刀是全局快照。它退而采用因果一致性（Causal Consistency），只保证单个分支（per-ref）的更新可串行化以及读己之写（read-your-own-write）。不相关的分支可以完全并行写入；代价则是当一个客户端同时读取多个分支时，看到的可能是不同时间点的状态组合。对于单线推进的 Agent 和 CI 任务来说，全局快照本就是昂贵的心理安慰。
第二刀砍向了动态打包。Pando 不再为每个拉取请求量身定制 packfile，而是直接跨请求复用已经落盘的不可变 packfile，甚至在后台压缩（compaction）时也保留每一层级的历史包。客户端拿到的只是一串指向区域缓存的 packfile-uri 链接，像从 CDN 下载静态视频一样把数据拖回本地。
这种粗暴复用必然带来带宽浪费。客户端在拉取时可能会下载一批自己本地已经拥有的冗余对象；而且在默认设置下，Pando 的特性分支推送只以主干（trunk）作为基准进行宣告，这意味着开发者或 Agent 在非主干分支上重复推送、或者使用堆叠分支（stacked branches）时，会反复重发主干之外的对象，白白消耗上传带宽。但账不是这么算的：在云数据中心内部，让客户端多跑一点 10Gbps 内网流量，比让核心 Git 服务端因为 CPU 算差量而雪崩要划算得多。
硅谷基建暗战与尚未解决的窄门
如果只看 OpenAI 原文里的性能对比，很容易得出 Pando 独步天下的印象。但这里有两处细节我不太买账，读者也需要看清背后的边界。
原文中那场 Pando 碾压 3PC 和 WAL 的测试，是一项配置了 1000 个客户端向各自独立分支推送的合成教学模拟，并不是针对竞品实际生产环境的实测基准。更巧的是，就在 OpenAI 发文前一个月（2026 年 10 月），GitHub 刚刚公开了其底层 Spokes 架构向 Agent 规模演进的方案，同样引入了按引用（per-reference）串行化、Azure Blob 存储分离以及不参与写入法定人数的虚拟只读副本。
这恰恰说明，用存储计算分离、按分支解耦协调和 CDN 式分发来改造 Git，不是某一家公司的独门绝技，而是整个硅谷在被 Coding Agent 流量冲垮后摸索出的共同答案。
十九世纪铁路网刚铺开时，蒸汽机车的速度很快，但真正决定运力的往往是道岔和单轨路段的调度系统。所谓“兵马未动，粮草先行”，如今 AI 编程工具创业公司和各大企业的研发基建团队都在拼命采购算力、部署智能体，却很少有人意识到：当一个团队里的每个工程师都带着十几个 Agent 日夜赶工时，老旧的代码托管后端和 CI 拉取链路会率先成为系统性雪崩点。
- 风险.Pando 彻底消除了不同分支之间的写锁竞争，但对同一个引用（如 main 主干分支）的并发推送依然必须串行排队；当数千个 Agent 在各自的特性分支上跑满 10Gbps 完成开发、最终同时转身向主干分支合入时，Pando 本身并不能消灭主干合并风暴，企业依然必须依赖外部的合并队列（Merge Queue）与测试调度来把守最后一道窄门。
从可靠性跌破 90% 到日吞吐 1PB，OpenAI 用 Pando 给行业提了个醒：当写代码的主体变成了机器，所有按人类手速设计的软件工程基建，都得重修一遍。