当 AI 把 Git 推到极限：OpenAI Pando 与 Anthropic Scion 的两种大仓库救火路线

三、OpenAI Pando：把 Git 当作接口，把服务端换掉

OpenAI 先检查了常见的分布式 Git 服务方案。第一种是复制完整仓库，再用三阶段提交协调引用更新。它能给所有副本一个一致视图，但每次推送必须等待多数副本完成多轮通信；随着写入增加，磁盘和网络延迟都会进入推送关键路径。

第二种是把包文件放进对象存储，再用共享预写日志排序所有引用更新。包上传可以并行，但每次发布仍要比较并交换同一个全局清单。即使推送的是两个毫无关系的分支，也要争用这个清单。批量合并可以降低部分开销，代价是排队和更高延迟。对象存储扩容并不能消除全局协调点，副本仍需读取、索引这些包文件，追上写入速度。

Pando 的答案不是把协调做得更快，而是缩小协调范围。每次推送只与目标引用相关。更新不同分支可以并行，只有同时移动同一个引用时才需要冲突。读取某一引用时，客户端需要观察到生成这个引用的写入者所依赖的历史，这被称为因果一致性。一个客户端同时读取多个分支时，看到的分支版本可能来自不同时间点，但读取单个分支不会跳到自己因果链条之外。

flowchart LR
    C["开发者或代理
git push"] --> P["Pando 接收并流式校验
原始 packfile"]
    P --> B["对象存储
保存不可变 packfile"]
    P --> M["元数据存储
记录 ref version"]
    M --> R["目标 ref
原子比较并交换"]
    F["另一个客户端
git fetch"] --> N["根据 have 与 want
选择已有 packfile"]
    N --> E["Express 区域缓存"]
    E --> C2["客户端并行下载
packfile URI"]
    B --> E

四、Pando 为什么能并行写、线性读

1. 推送时保存原包，不再为每个读取者重新打包

传统 Git 服务端收到推送后，会验证内容并更新仓库。客户端抓取时，服务端再根据双方拥有的对象集合生成新包。Pando 尽量不做这件事。它一边流式校验推送，一边把原包写入对象存储，然后在元数据存储中记录新的引用版本。这个版本指向新提交、所依赖的协商基线以及对应的包文件。

后续读取不需要服务端解开包再重新压缩。Pando 把客户端已有的提交与想要的提交映射到引用版本，再选出覆盖缺失对象的若干历史包。包可能包含客户端已拥有的少量对象，但服务端可以反复把同一批字节提供给许多客户端，计算成本远低于为每个客户端现场生成新包。这是“牺牲一点客户端带宽，换取服务端缓存复用”的明确交易。

2. 只广播少量引用，让推送更容易复用

Git 推送前，服务端通常会广播大量引用。客户端知道服务端已有越多对象，就能把待发送包做得越小。但在拥有数百万分支时，完整引用广播本身可能超过 100 MiB，而且服务端需要维护一个昂贵的全局视图。更棘手的是，客户端根据大量分支生成的包依赖复杂，Pando 很难证明下一个读取者一定拥有这些依赖。

Pando 默认只向推送者广播一条指定主干分支。这样包只有一个明确基线，任何已经拥有该主干版本的客户端都能用同一个包抓取特性分支。代价是连续向同一分支推送，或在分支上继续叠分支时，客户端需要重复发送主干之外的对象。OpenAI 认为这个代价可接受：在其仓库里，这种方式生成的中位包小于 20 KiB，第 99 百分位小于 3 MiB。

3. 用一个空的内联包加多个并行下载

标准 Git 的 HTTP 抓取通常只允许响应里有一个包。Pando 使用 Git 协议中不太显眼的 packfile-uri 能力，正文返回空包，同时给出多个独立包链接。客户端并行下载并索引这些包，不必等待服务端流式生成一个巨大的响应。OpenAI 还向上游 Git 贡献了并行下载、中断清理、断点恢复、下载追踪和显式基线等改进。

包交付服务 Express 在不同区域缓存对象存储内容。Pando 用一致性哈希把同一包路由到稳定的缓存节点，命中率超过 99%。在普通云服务虚拟机上，克隆与抓取可以跑满 10 Gbps 网络。OpenAI 报告单小时交付超过 57 TB Git 包，其中超过 99% 的字节来自本地磁盘缓存；系统每天可交付接近 1 PB 的 Git 数据，而服务端只需要少量 CPU 核心。

4. 后台压缩像日志结构合并树

如果每次推送都留下一个小包，落后主干很多天的客户端就要下载成千上万个包。Pando 在后台执行类似日志结构合并树的压缩。新推送先形成 L0 包，后台工作器把连续引用版本归入更大的覆盖层，逐级扩展到 L1、L2、L3、L4。覆盖层既改善压缩率，也像跳表一样帮助抓取规划，让选择包的计算量随落后距离近似对数增长。

与许多会丢弃旧包的存储系统不同，Pando 保留每一层的包，因为不同客户端可能从不同历史位置开始读取。较旧的 L0 包虽然压缩率不高，但读取任意对象时可能只需解压更少数据；较大的高层包则更适合追赶主干。这种设计把“更新快”与“读得远”同时纳入存储层，而不是只优化最近一次提交。

五、Pando 的工程与迁移结果

OpenAI 用编程代理写出了一个新的 Rust 服务端，从启动到生产用了十周。核心设计由一名工程师完成，随后由多组代理实现，再由少数工程师部署。团队编写一致性测试，让代理用标准 Git 行为检验实现；还使用确定性模拟、并发不变量测试、Lean 与 TLA+ 形式化模型，寻找协商与包规划中的竞态。这个项目本身就是编程代理进入基础设施工程的案例，但设计约束、风险判断和最终责任仍由工程师承担。

部署并没有选择一次性切换。Pando 最初作为现有源代码系统的读写透传代理，两套系统保持同步，再把流量和集成逐批迁入。它可以在代理层合并与去重请求，因此迁移一个工作负载时，旧系统反而可能因 Pando 缓存而更稳定。团队还迁移了数百个依赖旧接口、网络钩子和仓库下载的集成，并为开发者准备迁移技能，让代理协助修改本地环境和服务配置。

正式承载流量后，Pando 将中位推送延迟降低近 80%，约相当于五倍改善，并提高了合并可靠性。2026 年 4 月，它开始承接生产流量。OpenAI 没有声称 Git 已经失败，反而强调协议与客户端的兼容性让工程师和代理无需改变协作习惯，也让改进能够反哺开源生态。

六、Anthropic Scion：不再把 Git 当作起点

Anthropic 的诊断更激进。Git 的优点是每个克隆都是完整、自包含的仓库，离线也能计算差异、历史、归因并检出任意版本。对绝大多数仓库，这是正确设计。但 Anthropic 的大仓库已经不再符合这个使用场景：绝大多数客户端是持续在线的代理和任务，完整仓库反而成为负担。

在规模最高时，Anthropic 维护了几百个内部 Git 镜像，并配合浅克隆、稀疏检出、承诺远端和块存储快照。这些手段都能争取时间，但不能消除维护成本。镜像越多，磁盘、内存和一致性压力越大；快照会逐渐落后主分支，依赖完整历史的差异与归因操作又需要越来越多特殊处理。

于是团队提出五个原则：客户端始终在线；客户端与服务端职责不对称；源代码控制查询本身应成为服务；每个组件都能独立横向扩展；提交、变基和合并必须足够便宜、增量且无全局锁。工作副本不再是默认状态，而是可选、稀疏、按需物化。Anthropic 明确承认这些原则只适合极大的单体仓库和代理密集写入，不代表普通 Git 用户也需要一套新系统。

七、Scion 的写入模型：变更集就是预写日志

Scion 的工作单位叫变更集。它仍然记录作者、提交信息、时间、父提交等基本信息，但不保存一个指向完整目录树的指针。变更集只列出相对第一父提交发生变化的文件，以及指向对象存储中压缩内容的地址。所有变更集都在服务端创建，因此创建后立刻对全系统可见。

这种结构让写入吞吐很高。服务端不需要接收包文件，不需要锁住某个全局引用，也不需要让所有服务器协调一次提交。Scion 技术上仍支持引用，但创建和抓取提交都不依赖引用；移动一个引用只是一行 Spanner 记录的比较并交换。单调递增的全局状态被压缩到极少数主分支或发布分支上。

变更集只保存差异，因此不能单独回答“谁最后修改了这一行”或“哪些提交碰过这个路径”。Scion 从变更集递归生成额外的派生数据，包括文件归因、路径历史、提交图跳表，以及后来增加的复制检测和路径搜索索引。每种派生数据都可以选择立即计算或延迟计算，客户端也看不到这些结构的内部表示，所以服务端可以持续替换实现而不破坏协议。

flowchart LR
    W["客户端编辑文件
提交变更"] --> S["Scion 服务端
创建 changeset"]
    S --> O["内容寻址对象存储
压缩文件对象"]
    S --> X["Spanner
变更集与引用元数据"]
    X --> D["递归派生数据
归因、路径历史、提交图跳表"]
    C["检出的客户端"] --> G["请求缺失 tree 与 blob"]
    G --> DN["节点 daemon"]
    DN --> RC["区域 cache"]
    RC --> SV["权威 Scion server"]
    O --> SV
    X --> SV

八、Scion 的读取模型：只问缺什么，不问“你已有什么”

Git 抓取需要协商。客户端告诉服务端自己已有的提交与想要的提交，服务端计算可达对象集合的差，再生成包。Scion 改变了这个问题。客户端从根目录树开始，在本地仓库中检查哪些树缺失，递归请求缺失的树，再请求对应文件内容。每个对象都由内容寻址且永不变化，因此任何一层缓存都能直接回答。

这带来三个直接结果。第一，请求天然可恢复，不再依赖一个数 GB 的单次包响应。第二，稀疏检出甚至虚拟化检出不需要额外协议，客户端直接不请求不想要的目录。第三，客户端与服务端不必围绕“已有对象”做复杂协商，缓存层也不用为每个客户端重新计算差异或做增量压缩。

Scion 客户端通过本机套接字访问节点级守护进程，守护进程维护整个节点共享的对象缓存。守护进程从周期性刷新快照开始，再向区域缓存请求树和文件对象。区域缓存以客户端可直接消费的磁盘格式从内存流式返回；缓存未命中时，才访问权威服务端，后者按需读取 Spanner 或云对象存储。

三层都保持超过 99% 的缓存命中率，也都不依赖长时间维持的状态，因此扩容相对直接。团队刻意限制层级流向，避免区域缓存故障时所有请求越过缓存压垮上游。Scion 基础设施的 CPU 与内存占用比旧 Git 镜像架构小约 200 倍；持续集成与研究任务检出从分钟级降到秒级，约快两个数量级；仅持续集成就节省 25% 的 CPU 容量。

九、Scion 的真实结果与代价

Anthropic 的七人团队用五个月完成 Scion、代码审查工具 Antique、代码搜索、源代码权限系统以及另外几套相关系统，并全量迁移大仓库。在此期间，每日合并量又增长了十倍。团队认为，这种小团队快速替换大型基础设施的方式，会随着编程代理成熟而变得更常见。

质量方面，团队用代理生成大量测试、密封模拟、模糊测试与限流验证。Claude 还发现了一个祖先查询算法遗漏索引的问题，这类优化过去可能需要专家数天或数周。与此同时，工程师仍然审查每个系统变更，只是工作重点从逐行阅读代码转向判断变更意图、系统边界和约束。文章中的例子很具体：代理可能为了满足局部模式而线性扫描提交历史，或针对一个假想风险加入过多校验，工程师必须及时说“不”。

Scion 也改变了合并流程。传统合并队列会给整个仓库加一道全局锁，让一批变更在队列中按顺序测试。代理规模下，几小时里可能有数百甚至数千个变更等待合并，这个队列本身成为瓶颈。Anthropic 没有强行复制全局锁，而是增加合并后测试与部署前测试，接受并发变更偶尔产生冲突，再让代理修复。这个决定是否适合其他组织，取决于其回滚能力、测试覆盖和生产风险，不能只看合并速度。

最后，Anthropic 明确说明 Scion 不适合作为通用 Git 替代品。它要求同时替换代码审查、搜索、权限、持续集成和所有内部集成，还需要大量模型调用预算。团队更希望将设计经验贡献给 Git 生态，例如把服务端查询做成标准化接口、改进稀疏与浅层能力、重新设计协商协议，而不是把内部系统直接包装成大众产品。

十、两条路线到底差在哪里

兼容性换来的不是保守，而是迁移半径

Pando 最被低估的优势不是性能，而是迁移边界。它继续面对标准 Git 客户端，因此工程师不需要换命令，代码审查、编辑器和持续集成大多数时候也不必同时重写。OpenAI 可以从透传代理开始，把数百个集成逐项迁移。每迁移一个部分，原有系统仍可作为后盾，问题可以被局部隔离。

Scion 的自由度更高，但迁移半径也更大。服务端不再兼容 Git，意味着客户端、审查界面、搜索、权限、持续集成和自动化接口都要围绕新协议重做。Anthropic 能在五个月完成，是因为七人团队与大量代理同时工作，并且公司愿意为内部模型调用和基础设施投入相当资源。其他团队复制其中一条数据结构经验可以，复制整套迁移计划则风险很高。

因果一致性不是弱一致性的同义词

Pando 不提供所有分支在同一瞬间的统一快照，但单个引用的更新仍然串行，客户端能读到自己的写入，并能从主干基线追踪到目标分支。对开发工作流而言，大家通常关心一个分支从哪个版本前进，而不是在毫秒级同时观察所有数万分支。代价是工具若假设一次查询能拿到全仓一致视图，就需要重新设计。

Scion 把一致性问题转移到服务端变更集与引用更新。变更集本身追加写入，不需要移动引用；真正需要比较并交换的只是主分支或发布分支这样极少数的引用。它不要求所有服务器共同排序每个提交，而是让服务端生成派生数据，从而把历史查询变成可扩展的服务调用。

问题	Pando 的答案	Scion 的答案
多个无关分支同时推送	按引用独立协调，只争用目标引用	变更集追加到预写日志，不需要全局引用锁
大量任务读取同一历史	复用推送形成的包文件，由区域缓存分发	客户端只请求缺失树与文件对象，各层缓存不可变对象
历史与归因查询	继续使用 Git 提交图，服务端减少重新打包	从变更集递归生成归因、路径历史和图索引
跨分支一致视图	主动放弃，换取写入并行	不依赖全仓快照，由服务端为每个查询组合所需历史
客户端离线能力	保留 Git 的本地对象与协商能力	弱化为有限缓存，假设客户端持续在线

压缩不是存储细节，而是读取架构

Pando 把包文件从“每次请求的临时产物”变成“可长期复用的分发单位”。后台压缩解决历史包太多的问题，同时保留每一层以服务不同落后位置的读者。Scion 则彻底取消包文件，让对象存储与缓存层直接处理不可变树和文件。前者保留 Git 对象语义，后者用对象请求替代协商与打包。

这也是为什么不能简单说 Scion 只是“更快的 Git 服务端”。它改变客户端知道什么、请求什么、缓存什么，甚至改变谁负责创建提交与合并。Pando 的核心仍然是 Git，只是把服务端从“每次现场计算”改成“记录并复用写入历史”。

十一、哪些结论已经被证明，哪些还没有

两家公司都给出了生产数据，但证据边界要讲清楚。第一，这些数字来自企业内部工作负载，不是跨公司统一基准。Pando 的“中位推送延迟降低近 80%”和 Scion 的“检出快两个数量级”不能直接转换为普通团队采用后的收益。仓库大小、分支数量、文件分布、网络位置、缓存预热和代理行为都会改变结果。

第二，Pando 仍处在 OpenAI 内部生产环境，公开 Git 改进和补丁可以复用，但完整服务端尚未作为通用产品提供。Scion 更明确地表示不适合广泛部署，其代码审查、搜索与持续集成都是内部定制系统。两篇文章提供的是架构证据与运营经验，不是可以照抄的开源发行版。

第三，可靠性提升与成本节省的完整口径没有公开。例如 Scion 说基础设施占用小 200 倍，但没有给出新旧系统的完整软硬件账单、迁移期间双系统运行成本和工程人力总额。Pando 说每天接近 1 PB，但没有把对象存储写入、压缩、缓存和跨区域流量全部折算成统一成本。采用者应该把这些数字当作方向，而不是采购报价。

第四，权限、安全和可审计性仍要单独设计。Anthropic 提到 Scion 支持仓库级与目录级权限，审查工具能表达更细的语义约束；OpenAI 强调沿用安全软件基础和标准 Git 行为测试。这些都说明源代码控制重构并不只是性能工程，任何新的缓存、代理或服务端查询接口都必须保持身份、授权和审计边界。

十二、大多数团队应该怎么选

如果一家公司的 Git 只是偶尔慢，首先应该修复持续集成、分支策略、稀疏检出、缓存与单体仓库边界。把现有系统从“所有任务克隆完整仓库”改成“只取需要目录”，通常比自研源代码控制系统便宜得多。把构建缓存、测试选择和工作区复用做好，也能移走大量并非源代码控制造成的负载。

如果瓶颈已经明确落在 Git 服务端，而团队又必须保留现有工具链，Pando 的技术路线更值得研究：保留引用语义，缩小写入争用范围；复用不可变包文件；把引用广播限制在明确基线；使用并行包下载与多级缓存；把压缩规划做成可观察的后台过程。这些原则可以先用托管服务、代理层和缓存层实现，不必第一天就重写整个服务端。

只有当仓库达到 Anthropic 描述的量级，或者组织愿意把整个开发生命周期一起迁移，Scion 才进入合理选项。判断门槛不是“仓库有 10 GB”，而是每天有数百万次检出、数万次合并、数百个代理和任务同时写入，并且现成 Git 工作流已经无法通过工程手段维持。即使达到这个门槛，也需要先回答权限、审查、持续集成、回滚、离线开发和人员培训由谁承担。

当前信号	优先动作	何时升级架构
偶尔抓取慢，持续集成重复下载	缓存依赖、稀疏检出、构建缓存、合并任务去重	缓存仍无法覆盖主要流量时
分支多后推送排队，但单分支历史正常	拆分仓库边界或研究按引用独立协调的服务端	无关分支争用成为持续故障源时
同一历史被代理和任务反复读取	不可变包或对象缓存、区域分发、并行下载	服务端仍在为每个客户端现场打包时
每日合并达到数万，代理密集写同一单体仓库	重新评估审查、合并队列、持续集成与源代码控制边界	保留 Git 需要改变整个开发生命周期时

十三、真正的分水岭不是 Git，而是工作负载假设

OpenAI 和 Anthropic 的文章放在一起看，最有价值的一点是它们都没有把“Git 慢”当成单点故障。OpenAI 发现客户端兼容性值得保留，于是重写服务端；Anthropic 发现客户端永远在线的现实与 Git 的离线完整副本假设冲突，于是重写整个系统。两个选择都从真实负载出发，而不是从“我们应该造一个新数据库”出发。

对机器人、具身智能和物理人工智能团队，这个故事也有直接含义。训练日志、仿真资产、传感器数据和模型权重会制造另一类大仓库问题；代理生成的代码、评估脚本和实验配置又会制造 Git 负载。不要等到所有东西都塞进同一个仓库后再讨论架构。先区分不可变大对象、需要版本化的代码、可重建的数据与临时产物，再为每一类选择存储和缓存边界，往往比追求一个“万能仓库”更可靠。

Pando 代表一条渐进路线：承认 Git 已经成为生态接口，只替换最昂贵的服务端路径。Scion 代表一条极限路线：当代理数量和合并速度把传统工作流推到边界之外，就连接口、客户端和持续集成一起重做。大多数组织未来一段时间最现实的动作，不是复制其中任何一套完整系统，而是先测量自己的推送争用、重复读取、检出流量与合并延迟，再判断问题到底在 Git 内部，还是在 Git 周围。

一句话总结：Pando 让 Git 在旧契约下跑得更快，Scion 则证明当旧契约本身成为瓶颈时，源代码控制可以被重新定义。前者更像可渐进的工程改造，后者是一场只有极端负载和极高投入才支撑得起的架构实验。

---

来源：OpenAI，《Scaling Git at OpenAI》，发布于 2026 年 11 月 2 日（openai.com/index/scaling-git-at-openai）；Anthropic，《Redesigning source control at Anthropic》，发布于 2026 年 10 月 13 日，2026 年 10 月 15 日更新（anthropic.com/research/redesigning-source-control）。本文为两篇原文的完整翻译与改编，包含明确标注的 RobotWorld 延伸分析；所有图表均来自对应原文。