全部文章

边知识 · 边知道

源码管理再更新：OpenAI Pando 对照 Scion 与 Origin

OpenAI 发布自研 Git 后端 Pando，将内部 monorepo 的 median push 延迟压到原来的五分之一左右。本文将其纳入此前 Scion 与 Origin 的对比框架，拆解三条技术路线：离开 Git、重做 Git 服务端，以及只换存储与投递后端。

边边 约 8 分钟读完

此前在《Scion 与 Origin》一文中，我们对比过 Anthropic 与 Cursor 如何应对 agent 带来的代码变更暴涨。2026 年 11 月 2 日，OpenAI 工程博客公开了为内部 monorepo 打造的新后端 Pando，给这道题补上了第三种解法。

Pando 完全兼容标准 Git 协议与客户端，工程师和 agent 的日常命令无需改动。上线生产后，OpenAI 内部 monorepo 的 median push 延迟降了接近 5 倍（同篇博客后文与官方 X 亦表述为降低近 80%，两者口径一致）。目前这套系统每天投递接近 1 PB 的 Git 数据，单小时峰值超过 57 TB，其中超过 99% 直接由本地磁盘缓存承接。

改造成因来自 Codex 带来的并发压力。随着并行任务增加，仓库里同时出现了更多分支、更多 push 与更多 merge，开发机、研究任务和 CI 也在高频执行 fetch 与 clone。旧系统开始频繁遇到 fetch / push 变慢和 merge 失败，整体可靠性一度掉到 90% 以下。OpenAI 判断症结在于服务端承载这个 monorepo 的方式，因此选择留在 Git 协议上，重做底层后端。

Pando 核心代码由团队在 Codex 协助下开发，从启动到上线历时约 10 周，并从约 4 月起承接生产流量。它的职责边界很清晰：只管 Git 数据的存储与投递，代码审查等流程继续留在既有的内部工具里。

三条路线：离开 Git、重做服务端、只换存储与投递层

把三家公司的方案放在一起，可以看到针对同一瓶颈的三种切口：

Anthropic Scion 选择离开 Git。 Scion 采用客户端-服务端架构，提交、合并与 blame 均在服务端完成，底层数据存入 Spanner 与对象存储，客户端只做稀疏或虚拟检出。根据 Anthropic 公布的生产数据，其日合并量从 5 月的约 2,500 次增长到 9 月的超过 30,000 次；主分支历史约 100 GB，CI 每天执行约 2,500 万次检出。迁移后，相对原先数百台 Git 镜像的架构，服务端 CPU 与内存占用缩小了约 200 倍，检出耗时从数分钟降至数秒，仅 CI 环节就省下约 25% 的 CPU。Scion 定位为 Anthropic 内部系统，官方明确表示不会做成通用 Git 替代品。

Cursor Origin 选择留在 Git，重做服务端。 其底层存储系统 Continuity 把 S3 上的预写日志（WAL）作为唯一事实来源，节点 NVMe 盘上的普通 Git 仓库仅作为热缓存；前端继续兼容标准 git 客户端，并支持镜像 GitHub 仓库，CI 场景则搭配 CloneKit 加速克隆。在合成压测中，Origin 读吞吐可线性扩展到 100 个副本，push 吞吐在 S3 Standard 下约为 120 次/秒，在 S3 Express One Zone 下超过 300 次/秒。Origin 目前处于早期商业测试阶段，面向 Cursor 付费计划开放。

OpenAI Pando 同样留在 Git，但切口更窄：只做仓库的 backend。 Pando 的核心目标是横向扩展写能力（支持多分支并发 push）并拉高读吞吐。在一致性模型上，Pando 让不同分支的更新彼此独立，提供因果一致性（causal consistency），放弃了全仓库同一时刻的 point-in-time 快照。OpenAI 团队评估过三阶段提交（3PC）和对象存储 WAL 等常见扩容方案，判断这些方案在无关分支并发写入时仍会互相阻塞，或者在读吞吐上跟不上需求。因此，Pando 在存储与投递上直接复用 Git 的 packfile，通过 packfile-uri 将数据包卸载给缓存层投递；底层用 blob store 存包、用元数据存储维护 ref 版本，并在后台执行类似 LSM 树的 compaction。OpenAI 同时把部分改进补丁回馈给了上游 Git 社区，并表示正在探索如何向外界开放相关技术，目前该系统仍仅限内部使用。

对照表

维度Git 典型托管Anthropic ScionCursor OriginOpenAI Pando
架构分布式，默认完整克隆客户端-服务端；服务端完成提交 / 合并 / 查询Git forge；S3 WAL 为唯一事实来源Git 兼容后端；blob + 元数据分离；按分支独立更新
Git 兼容性原生不兼容，需整套工具链迁移标准 git 客户端；可镜像 GitHub协议与客户端兼容；日常工作流不变
一致性与存储要点本地保存完整历史Spanner + 对象存储；稀疏 / 虚拟检出S3 WAL + NVMe 热缓存；CloneKit 快照因果一致性；复用 packfile；LSM 式 compaction
可用范围所有人仅 Anthropic 内部Cursor 付费计划（早期测试）仅 OpenAI 内部；对外技术分享探索中
公布数据-生产：2,500→30,000+ 合并/天；资源约小 200 倍合成压测：120 / 300+ push/秒；读扩至 100 副本生产：median push 延迟降约 5×（~80%）；近 1 PB/天；单小时 >57 TB

读表时需注意数据口径的差异：Anthropic 与 OpenAI 披露的是生产环境实测结果，Cursor 披露的是合成压测数据；Scion 与 Pando 是服务自家超大 monorepo 的内部基建，Origin 则是面向外部团队的商业产品早期形态。这张表适合用来看清各家的架构取舍，不宜直接用来做横向性能跑分对比。

对普通团队意味着什么

当 coding agent 密度上升后，工程基础设施的瓶颈正持续从「写出代码」移向「合并、测试、审查与同步仓库」。三家公司面对同一波冲击，根据各自的约束给出了不同答案：

  • 离开 Git（Scion）：前提是客户端几乎全是在线运行的 agent 与自动化任务，传统的离线全量克隆成了纯负担。这条路的代价是把代码审查、搜索和 CI 整条工具链全部重写，只在拥有超大 monorepo 且 token 与基建预算极高的组织里划算。
  • 留在 Git、重做托管服务端（Origin）：保留标准 git 客户端与周边生态，把一致性与扩展性下沉到「对象存储日志 + 本地热缓存」层。对已有 GitHub / GitLab 工作流的团队来说迁移摩擦较小，但需独立评估早期商业服务的稳定性与平台锁定风险。
  • 留在 Git、只换存储与投递层（Pando）：工程师和 agent 的使用习惯原封不动，专门替换抗不住并发 push 与海量 fetch 的存储投递后端。OpenAI 同时把部分改动推回上游 Git，整体思路是先把现有协议的吞吐极限撑起来，再探讨后续的产品化可能。

对绝大多数工程团队而言，当下并不需要急着替换 Git。更务实的做法是先排查现有流程里默认遵循「人类节奏」的环节：每次任务都做全量克隆、CI 排队串行跑、合并队列阻塞、所有变更不加区分地等待人工逐行审查。一旦并发 agent 数量上去，这些环节会最先成为卡点。如果团队的 monorepo 确实已经大到日常 push / fetch 经常拖慢研发节奏，再根据自身约束对号入座：是彻底重构客户端工作流，还是保留 Git 协议、升级底层存储与托管层。

OpenAI 在博客中表示会继续向 Git 社区回馈补丁，并探索对外分享 Pando 的相关能力；Anthropic 此前也表达过将有效经验带回 Git 生态的意愿。最终的产品形态虽然还未定型，但「agent 规模的源码管理」已经从两家对照扩展成了三条清晰的技术路线。

参考