Git 没坏，是提交代码的人变了

11 月 2 日，OpenAI 发文介绍 Pando，一套自研的 Git 服务器后端。上个月 13 日，Anthropic 也发文介绍了自研的源代码管理系统 Scion。

两家碰到的是同一个问题：AI agent 写代码太快，管代码的系统成了整个公司开发速度的瓶颈。两家的解法方向相反。

先交代一下 Git。它是程序员管理代码版本的工具。每次改动存成一个“提交”，推送（push）到公司服务器，同事再从服务器拉取（fetch）。“分支”是同一份代码的平行草稿，各改各的，改好再合并进主线。两家都把全公司的代码放在同一个大仓库里，业内叫 monorepo。

OpenAI 的路线是改造 Git。工程师和 agent 还是敲 git push、git pull，只把服务器换成 Pando。推送代码的中位等待时间缩短近 80%，每天往外分发近 1PB 代码数据，约 100 万 GB。

Anthropic 的路线是替换 Git。Scion 有自己的客户端和服务器，提交、合并都在服务器上完成，配套的代码审查、代码搜索工具也是自己写的。CI 每次改动后自动构建和测试，拉代码从几分钟变成几秒，服务器占用的 CPU 和内存只有原来那套的 1/200。

两套系统都不对外提供。OpenAI 说正在研究怎么把 Pando 的技术提供给用户，过程中给 Git 修的问题已经提交给 Git 官方，有几项进了正式版。Anthropic 说 Scion 只适合巨型代码仓库，用它得把代码审查、搜索、CI 全部换掉，别的公司很难直接用，所以只分享设计思路，希望 GitHub、GitLab 和开源社区吸收其中有用的部分。

如果你的团队用 GitHub 或 GitLab，OpenAI 这条路离你更近：改进直接进 Git，工具链不用换。两家都认为别的公司迟早会碰到同样的问题，Anthropic 预计未来 6 到 12 个月这类问题会更常见。

Git 为什么扛不住。提交量涨得太快。以 2024 年第一季度为基准，OpenAI 合入主线的提交数到 2026 年第三季度涨到近 15 倍，第四季度预计约 25 倍。Anthropic 每天合入的改动，5 月约 2500 个，9 月超过 3 万个，4 个月变成原来的 12 倍多。

压力会叠加。一个工程师同时有好几个改动等着测试，每推送一次，又有好几个测试任务去拉同一份代码。

OpenAI 从去年年底开始拉代码、推代码都变慢，合并经常失败，可靠性一度低于 90%，相当于每 10 次操作有超过 1 次出问题。

Anthropic 的主线历史接近 100GB，压缩后的工作副本超过 25GB，光 CI 每天就要拉约 2500 万次代码，全量下载的话每天超过 600PB。它最多时开了几百台 Git 镜像服务器分担压力，越来越难维护。

Anthropic 总结了根本原因：Git 的设计假设每个人都离线工作，所以每人手里都要有一份完整仓库。现在拉代码的大多是 agent 和自动任务，它们一直联网，背着整个仓库跑反而成了负担。

写代码时，别让所有人排一条队。多人同时推送，服务器要保证每个分支“现在指向哪个提交”的指针不被改乱。Git 里把这个指针叫 ref，可以理解成书签。

OpenAI 评估过两种常见做法，都要让整个仓库的改动排成一条队。一种是三阶段提交，几台服务器各存一份完整仓库，每次推送要过半数服务器同意，分三轮来回确认，推送量一大，各台服务器的硬盘先忙不过来。另一种是预写日志，所有改动先记进一本共享的流水账，再照着执行，不管改哪个分支都要抢着往同一本账上写，账记得太快，服务器又来不及照着更新，别人拉到新代码要等更久。

Pando 的办法是每个分支各管各的。推 A 分支和推 B 分支互不等待，只有两个人同时推同一个分支才会冲突。代价是同时看好几个分支，看到的可能是各自不同时刻的状态。OpenAI 说，人和 agent 实际只关心单个分支的前后顺序。

Anthropic 走得更远：提交直接在服务器上生成，没有推送这一步，每次提交只记哪些文件变了。Scion 尽量少用分支，主线和发布分支之外基本不用，因为所有服务器都要对分支状态达成一致，规模一大就是麻烦。两家最后都把移动书签简化成一次“比较并替换”操作，Pando 改的是一个键，Scion 改的是数据库里的一行。

Anthropic 还取消了合并前的全局排队。传统做法是合并时锁住仓库，一个个测完再放行。Anthropic 说测试还没跑完，已经有成百上千个改动合进去了，排队没法做，于是改成合并后、上线前再自动测试。同时合入的改动可能冲突，Claude 修冲突的速度通常比人发现冲突还快。

拉代码时，别给每个人现场打包。传统 Git 服务器给每个来拉代码的人现场算一个专属压缩包，Git 把一批文件压在一起，相似文件只存差异，只装对方缺的部分。来的人一多，CPU 和硬盘就扛不住。两家都绕开了这一步，方法相反。

Pando 像发统一包装的快递箱：推送者上传的压缩包原样存起来，谁要就发谁，服务器几乎不用计算。为了让包人人能用，推送时只让客户端对照主干打包：主干上已有的内容一律不装，包里只有这个分支改过的文件、对应的目录清单和提交记录，压缩后中位数不到 20KB。后台再把小包逐级合并成大包，免得落后几天的人要下几万个小文件。代价是客户端偶尔会多下一些已有的内容。

Scion 像超市自取：完全不用压缩包，客户端缺哪个文件就要哪个文件。每个文件按内容算出一个编号，内容一变编号就变，同一编号的文件永远不变，所以任何一层缓存都能直接回答，不用跟其他服务器核对。客户端还可以只取自己需要的目录，或者等真读到某个文件时再下载。

两家的缓存命中率都超过 99%。

结果方面，OpenAI 推送中位等待时间缩短近 80%，用少量 CPU 核心每天分发近 1PB，最高一小时发出 57TB。用普通云服务器测试，拉代码能跑满 10Gbps 的网络带宽。

Anthropic 的服务器 CPU 和内存占用是原来 Git 镜像的 1/200，CI 和研究任务拉代码快了两个数量级，约 100 倍，光 CI 就省下 25% 的 CPU。

两套系统都是 AI 写的。Pando 从立项到上线用了 10 周，核心设计出自一名工程师，代码主要由 Codex 驱动的 agent 写，几名工程师负责部署，今年 4 月开始承接生产流量。

Scion 由 7 个人用 5 个月做完，同期还做了代码审查工具 Antique 和另外五六个系统，并完成整体迁移。Anthropic 原先手写了一版把 Git 数据导入 Scion 的程序，交给内部早期版本的 Claude Mythos Preview 重写，内存占用降到 1/20，速度快了 4 倍。

Anthropic 的工程师说，Claude 写代码已经比他们强，他们的价值在于把握系统设计和取舍，很多时候是对 Claude 说“不”。agent 会为了套用某种做法而违反系统的核心约束，也会为了假想的风险堆太多防御代码。

有网友提到，Scion 这个方向 Google 早走过。2016 年的 Piper 论文里，代码在 Spanner 上，开发者用 CitC 云端工作区，工作区只存改过的文件。当时每个工作日约 4 万次提交，其中 2.4 万次来自自动化系统，和 Anthropic 9 月的 3 万是一个量级。他的判断是，这次新的只有速度：Google 这个量积累了十几年，Anthropic 从 2500 到 3 万用了 4 个月。

有回复说，保留 Git 协议只换服务器后端是最省事的选法，客户端、CI 和整条工具链一行不用改，扛不住的压力全收在自己那一侧。也有人提醒，换系统解的是吞吐，不是审查。真正卡住的是每个 commit 没有可验收的行为可以对应：agent 一次改 40 个文件，diff 没人看得完，blame 直接断。这个提醒比系统选型更难绕过。