Pando：智能体规模的 Git，故意放弃整库一致性

OpenAI 工程博文《Scaling Git at OpenAI》不是软性「我们喜欢 Git」的表态，而是对智能体编码如何压垮源码控制的系统判断。Codex 把分支与 push 量抬高后，旧 monorepo 路径出现慢拉取、失败合并，可靠性有时低于 90%。实验室的答案是 Pando：保留 Git 协议与客户端，改写负载下的一致性与 pack 生成方式。

实际发布了什么

Pando 对准两件事：面向多分支并发 push 的水平可扩展写入，以及足以打满客户端链路的读取吞吐。它已承接 OpenAI monorepo 的全部开发。生产中，中位 push 延迟约降 5 倍（约 80%）。系统每日送出接近 1 PB 的 Git 数据。有一小时送出逾 57 TB pack，其中逾 99% 字节来自本地磁盘缓存。

架构取舍写得很清楚。文中建模的传统分布式 Git（跨完整副本的三阶段提交，或对象存储里共享的 WAL／清单）仍会让无关分支的 push 抢同一个整库协调点。Pando 把各分支更新独立记入元数据存储，把收到的 pack 存成不可变 blob。拉取某个引用时，重放生成该 tip 的 pack 历史。只有同时推同一引用才会冲突。同时读多个分支的客户端，不能假定这些读描述整库同一瞬间。

读取路径上，Pando 复用 packfile，而不是按每个客户端的 have／want 现算一份。客户端可能多下一些本地已有对象。服务器却能用很少计算把同一批字节供给很多读者。Push 协商默认只通告少量引用（通常是指定 trunk），使客户端打出的 pack 只依赖服务器允许省略的对象，从而更容易在后续 fetch 里复用。后台压缩把 L0 pack 合成更高层 cover（monorepo 用到 L4），类似 LSM 跳跃表，使规划随客户端落后程度近似对数增长。

OpenAI 称一小支团队借助 Codex，约 10 周把 Pando 从立项推到生产。上线先以读写穿透代理与旧系统并行，再切流量。实验室还发布公开 Git 发行版，含 packfile-uri 与并行下载／索引等工作，并跟踪拟合入上游的补丁。

台面上的证据

主要数字来自 OpenAI 自有 monorepo 生产数据，以及对比三阶段提交、对象存储 WAL 与 Pando 的教学型仿真。硬指标包括中位 push 约降 5 倍、约 1 PB／日、单小时 57 TB 且缓存命中逾 99%、仅通告 trunk 时中位 pack 小于 20 KiB（p99 小于 3 MiB）、标准云虚机上 clone／fetch 打满 10 Gbps。文中无第三方独立基准。

钢人与缺口

钢人。 智能体成倍增加分支与对同一提交的 CI 拉取后，整库锁步就是错瓶颈。因果一致性更贴近人与智能体的真实依赖：关心单分支更新顺序，而不是所有引用的全局快照。复用 pack 是把服务端 CPU 移出热路径、同时服务大量读者的可行办法。

缺口：失去多引用的同一时刻快照。连续推特性分支可能重复发送 trunk 之外的对象。仿真是教学模型，不是外部评测。Pando 此处未作为产品开源；OpenAI 称在探索如何对外共享。实验室用形式化与红队智能体自检，外人尚无法复现整栈。

谁该在意，下一步看什么

跑大量智能体 CI 的平台与 monorepo 团队，应把「兼容 Git 协议」与「单机 Git 假设」分开看。评测与基础设施应在多写入者下测 push 到 fetch 的往返，而不只看 clone 体积。卖「AI 编码」、却没有引用争用方案的厂商，会撞上 OpenAI 去年末遇到的墙。

未来六个月看：OpenAI 是否公开更多 Pando 或托管形态；上游 Git 是否吸收更多 packfile-uri 与 explicit-haves；其他实验室在智能体分支量上升后是否报告类似因果一致性后端。

收束

耐看的句子不是「Git 过时了」。而是：智能体规模的写入逼后端放弃整库一致性，让无关分支不必互相等待，同时用 pack 复用压低读取成本。 六个月后，要么更多 monorepo 做出类似「协商与缓存 pack 分离」的设计，要么智能体编码会继续压垮经典 Git 服务器。