Anthropic 如何重新设计源代码管理
文章摘要
这是 Anthropic 工程博客 10 月 13 日发表的一篇文章，署名 Nick G. 和源代码管理团队。文章介绍了他们如何在五个月内自研版本控制系统 Scion，并把公司的单体仓库（monorepo）从 git 完全迁移过去。15 日的更新补充了对先行项目的致谢。
瓶颈从写代码转移到了基础设施。 文章开篇说，在 Anthropic，写代码已经不再是构建系统或做研究的瓶颈：Claude 可以自主迭代研究循环、对复杂程序做微观优化、从零构建新服务。新的瓶颈是那些为人类规模设计的开发基础设施：源代码管理、构建和 CI。2026 年 5 月，Anthropic 平均每天合并约 2500 次代码变更；到 9 月，每天超过 30000 次。他们认为这个增速短期内不会放缓，因为”合并代码的潜在需求几乎是无限的”，每去掉一个瓶颈，代码产量就立刻进一步增加。在同一时期，团队还构建了代码评审工具 Antique、代码搜索、源代码管理权限系统等，本文只聚焦 Scion。他们说这是个有趣的案例：Claude 写代码的能力既是造成这个局面的原因，也是他们能快速建出高质量、可扩展系统的原因。
为什么 git 不够用了。 git 是去中心化的，每个克隆都是完整的仓库，可以离线计算差异、查看历史和 blame、检出任意版本，这对绝大多数仓库来说都是正确的设计。但他们的单体仓库越来越不适合这个设计：主分支的历史接近 100 GB，压缩后的工作副本超过 25 GB；仅 CI 每天就要做约 2500 万次代码检出，还不算开发环境、智能体沙箱和研究任务，如果天真地全量拉取，每天会产生超过 600 PB 的 git 流量。浅克隆、稀疏检出、按需拉取远端、内部镜像、存在对象存储里的仓库快照，这些办法他们都用过，高峰期运营了数百个内部 git 镜像，但随着合并速度提高越来越难维护：快照离主分支最新提交越来越远，在部分克隆上维持 diff 和 blame 这类依赖历史的操作也越来越费劲。他们意识到，自己和大多数公司一样，实际上把 git 当成有一份权威副本的中心化系统在用，而几乎所有客户端都是天然在线的智能体和任务，git 适合分布式离线协作的特性反而在拖累扩展。于是问题变成：如果从一开始就假定智能体始终在线，源代码管理会是什么样子？
面向智能体规模的设计原则。 他们借鉴了谷歌 Piper 和 Meta Sapling 的经验，提出几条原则：
- 客户端始终在线： 协议围绕一个总能访问到的服务器设计，客户端需要什么数据再去取。
- 客户端与服务器不对称： 在 git 里每个客户端都能当完整的服务器；在 Scion 里，文件历史、blame、创建提交、合并、变基都由服务器完成，客户端只维护有上限的本地对象缓存、在磁盘上布置工作副本文件、监控文件系统变化。它自己几乎算不了什么，但需要的本地数据少得多。
- 完整的源代码管理服务能催生新应用： 客户端用到的所有查询都通过 API 开放，CI 任务和工具不必维护本地仓库，自动二分定位和自动回滚这类内部流水线正是依赖这种廉价的编程访问才得以大规模运行。
- 一切必须可水平扩展： 仓库数据分布式存储，每个组件独立扩展，任何地方（包括服务器上）都没有完整物化的仓库副本，也没有 git 那样的打包文件（packfile），因此不需要仓库维护。
- 提交必须廉价、增量、无锁： 所有提交、变基、合并都在服务器上进行，所以无需推送；创建提交的成本必须随变更大小而不是仓库大小增长。开发流程不鼓励使用分支、标签这类引用（主分支和发布分支除外），因为需要所有服务器达成一致的全局状态是迟早要爆的扩展问题。
- 工作副本是可选的，且天生稀疏： 比如 CI 需要某个提交与合并基点的差异，直接问服务器即可；许多写入操作也能完全通过 API 完成。协议以稀疏检出和虚拟化检出（按需物化文件）为中心，客户端只为实际读取的内容付费。
数据结构。 Scion 的工作单元叫”变更集”（changeset），是预写日志中的一条记录。git 的提交存的是指向整棵树的指针，变更集存的则是相对第一个父提交改了哪些文件，外加指向对象存储里压缩文件内容的内容寻址指针。没有打包文件要接收、没有锁和跨服务器协调、没有引用要移动，所以能以极高吞吐量接收变更集；移动一个引用只是对单行 Spanner 数据做一次比较并交换。由于变更集只记录变化，回答”谁最后改了这一行”这类问题需要额外的数据结构，比如文件 blame、路径历史、提交图的跳表等，他们统称为”派生数据”，用一个通用机制递归计算（某个变更集的值由其父提交的值算出）。好处是新增一种派生数据很容易，可以选择立即计算还是延后计算，而且客户端看不到这些内部结构，优化时不用改客户端。
扩展架构。 一小批 Scion 服务器提供获取变更集、计算差异、查找合并基点、拉取文件块等 API。所有数据都是内容寻址的，存进去就不会再变，任何服务器都可以缓存而不必和别人确认，所以服务器本质上是能顺便计算派生数据的大缓存。客户端 scn 的拉取协议和 git 不同：不告诉服务器自己已有什么，只请求自己想要的树和文件块，从根树开始逐层检查本地缺什么就要什么。每个请求针对的都是永不改变的特定对象，任何缓存都能应答，架构很像传统分层缓存，也没有动辄几 GB 的单个打包文件响应，因此可续传；稀疏和虚拟化检出也不需要特殊支持，不想要的树不请求就是了。在集群里，客户端通过套接字与节点级守护进程 scion-daemon 通信，守护进程从定期刷新的快照启动，只和本区域的缓存服务器 scion-cache 通信，后者直接从内存里以守护进程能直接使用的磁盘格式流式输出对象；缓存未命中时才去问权威的 scion-server。三层都响应相同的 RPC，但严格分层以隔离故障域。每层缓存命中率超过 99%，基础设施的 CPU 和内存占用比之前的 git 镜像体系小 200 倍；CI 和研究任务的检出速度快了两个数量级（从几分钟变成几秒），仅 CI 就省下 25% 的 CPU 容量。
经验教训。 他们开始做 Scion 时，Claude Mythos Preview 和 Claude Tag 恰好在内部可用，二者既放大了对 Scion 的需求，也大大加快了开发。一个例子是：年初他们基本手写了 git 到 Scion 的导入流水线原型，自认为不错，后来让早期内部版本的 Mythos Preview 重写，没给任何额外指示，新版本内存占用降低 20 倍、速度快 4 倍，还保留了所有关于导入顺序和数据结构的隐含不变量。他们总结了几点：
- 小团队快速开发会更常见： 七个人在五个月内构建了 Scion 和 Antique 以及六七个相关系统并完成迁移，期间每日合并量还涨了 10 倍；过去这需要一家公司花几年、投入多得多的工程师。
- 工程师的价值没有降低，但工作在变： 参与的工程师都认为 Claude 写代码比自己强，但系统间的高层理解和设计权衡仍由人提供。工程师很多时候的角色是对 Claude 说”不”：智能体有时会为了迎合一个本不该存在的模式而违反系统核心约束，比如有多个系统试图通过线性读取提交日志来查某个变更何时合入主分支，而不是去问代码评审工具。他们大量使用对抗式评审，但它也可能短视，比如一次评审对信任另一个内部服务过度戒备，导致 Claude 加了过多校验和复杂度。团队成员仍会评审每个变更请求，但现在看的是变更意图，而不是逐行读代码。
- 优化和质量大幅提升： Scion 是他们做过的测试最充分的代码库之一，有覆盖所有基础设施交互的密闭模拟、模糊测试和精细限流。Claude 还”随手”发现了一些需要专家花几天甚至几周分析的优化。
- 单体仓库的新型安全： 支持仓库和单个目录级别的权限控制，评审工具能表达复杂的审批语义约束，区分只改注释的变更和敏感的逻辑变更。
- 新的运维水平： 他们在 Slack 里开了频道，让 Claude 专门盯着单个组件的健康状况，称之为”超级粉丝”，比如 scion-daemon 超级粉丝、合并队列超级粉丝，它们能看遥测和日志，像一个除了刷图表找异常之外无事可做的资深工程师，能发现传统告警发现不了的细微问题。
- 重新审视既有观念： 在智能体规模下，传统的合并队列意义不大：测试还在跑，可能已经有成百上千个变更合入了。他们无法复制业界常见的合并队列全局锁，转而投资合并后和部署前的自动化测试；并发变更可能冲突，但 Claude 修冲突的速度比人类发现冲突还快。
对整个生态的意义。 文章明确表示 Scion 不适合作为 git 的通用替代品，只对拥有数万工程师或大群智能体的超大单体仓库有意义；而且 Anthropic 用于内部的 token 预算远超其他企业的现实意愿。Scion 与 git 差异很大，需要配套自己的代码评审、代码搜索和 CI，这些内部组件高度定制，很难打包给别人用。但他们预计这类问题会在未来 6 到 12 个月内变得普遍，所以选择分享思路，让其他人能把 Scion 的成功经验用在 git 上：git 服务器不必和客户端一样工作，代码托管平台可以提供完整的服务端 RPC，协商协议也可以改，git 的各种稀疏和浅克隆功能可以更好地组合。他们最后向 git 社区近二十年的工作致敬，表示希望与 GitHub、GitLab 和开源社区合作。
HN 评论精华
本帖 889 分、1000 多条评论，是本期评论最多的一篇。技术细节反而不是讨论的主角，大多数人在质疑那组数字背后的意义：每天 3 万次合并到底在干什么？不经逐行评审的代码质量如何？自研版本控制是否必要？署名 nickg-anthropic 的用户（应为文章作者 Nick G.）在评论区做了几次回应。
“每次不看 Claude 的代码，后来都会发现烂摊子。” 这是最高票的评论，来自 duttish：他说并不是每次评审都能发现问题，但频率高到他没法不看，”他们是怎么避免这些烂代码的？还是干脆接受它，祈祷它别太烂、别太快被发现？”tgsovlerkhgsel 认为世界本就不完美，重要的是东西能否达成目的，代码质量只是手段，Anthropic 大概是押注模型将来能清理越来越多的烂代码。lionkor 反驳说这是谬误，计算机是确定性的，设计良好的程序可以完全没有 bug。colinmarc 说代码质量和接口设计在大型代码库里会带来复利回报，他待过的最高效的组织都是从一开始就重视代码质量的。stymaar 说用几天 Claude Code 就知道答案了：他们完全接受烂代码，直接交给用户；munksbeer 则说他每天用 Claude Code 6 到 12 个小时，没遇到多少 bug。miken123 列举 Claude Code 每天的修复列表长到一屏放不下、问题追踪器里有 10 万个议题，troupo 吐槽他们花了一年才做出不闪烁的终端界面渲染器，上线三个月仍有怪 bug。cheema33 则认为这些工具的质量明显好于一般商业软件。aktau 担心 AI 技术债会随时间累积，而且它缺乏”意图”，让人难以判断某段代码为什么存在；TeMPOraL 说配置良好的智能体会在注释、提交信息和文档里写明理由。
那 3 万次合并到底在做什么？ netburst 问：支持如此高频的变更有什么好处？代码在解决什么问题？如果目标是写解决真实问题的软件，对代码的需求怎么会无限增长？ciconia 直言加速主义思维荒唐，这么多代码行数对现实世界有什么影响，软件变好了吗？jrflo 回应：这些”忙活”让公司三年内从零收入做到 500 亿美元。stephen_cagle 认为好代码是逐步积累出来的，而不是反复重写，需要发明一个系统来应对代码翻动，说明之前的重构都不够好。offsky 讽刺道：”每天 3 万次代码变更，我却还是改不了账号的邮箱地址。”smy20011、niek_pas、winfredJa 都疑惑他们的网站和命令行工具看起来没怎么变，代码都去哪了；Rudybega、arjie 猜测大部分是内部研究、评估和模型开发相关的代码，用户看不见。altcognito 算了一下：2500 万次检出对应 3 万次合并，平均每次合并 833 次检出；nickg-anthropic 解释说仓库这么大，测试和流水线很多，并行跑的每个测试分片都要检出代码。preommr 预言会有一个难看的阶段，大家怕错过都以为自己也需要这么做，最后才发现自己不是 Anthropic 或谷歌；eddythompson80 把它比作 2010 年代”每天部署几次”的攀比风潮。
为什么不用别的方案？ zmmmmm 问是否考虑过不全押单体仓库，从”单体仓库让合并更容易”直接跳到”合并太难了，重新设计版本控制”，中间少了一个问题。nickg-anthropic 回应：单体仓库提供了一致的工具基线，可以用一次原子提交完成全局性修改，而不必在成百上千个各有规范的仓库里搞运动式推进。tancop 说这就是一个设计更现代的 SVN/Perforce 式服务端版本控制，很像 Epic Games 的 Lore，只是没有外部生产使用、不支持非文本资源，还不开源。mey、orangecat、josephscott 等都觉得”这不就是重新发明了 Subversion”，stigi 补刀说命令名 scn 和 svn 也太像了。mike_hearn 指出 Piper 本身就是 Perforce 的重新实现，疑惑为什么不直接买授权；fg137 认为配置好的 Perforce 大概也能胜任。bob1029 说文章没能说服他 git 在技术上处理不了这种负载，从原生 git 到从零自研之间还有很多步，ragtagtag 说”他们有 CI/CD 问题，却去修了版本控制”。Eridrus 拿出 Cursor 关于扩展 git 的博客，认为 Cursor 达到的写入速率更高，Human-Cabbage 和 nickg-anthropic 都指出那是”每分钟推送”和”每天合并”，不可直接比较，Scion 要解决的远不止原始写入速度。rcleveng 回忆他在甲骨文时，主持自研版本控制项目的人提出过一条”定律”：每家大公司最终都会写自己的源代码管理系统；一年后他去了谷歌，几年内谷歌也这么做了。amluto 不喜欢所有提交都在服务器上进行，git 和 jj 的核心理念之一就是能在本地积累历史、随意改写或丢弃；nickg-anthropic 回应，立即上传的好处是能直接启动研究任务、跑 CI、在所有开发环境之间共享代码，”提交哈希在哪儿都能用”。
Mythos 重写的那段。 trnvll 认为内部拥有最强模型的优势再怎么强调都不为过。smy20011 问一次性的导入流水线快不快有什么关系，nickg-anthropic 解释说迁移期间两套系统并行，导入流水线循环跑了好几个月保持同步，所以性能提升很有意义。idk1 认为这仍说明需要人类的创造力来提出新想法，menaerus 反驳说他们只是让模型重写、没给任何提示，这恰恰反驳了”创造力”论。hollowturtle 觉得 Anthropic 的说法越来越像营销，”20 倍、4 倍”没有任何数据细节；khazhoux 说一年来总有人讲”一个提示词，走开一会儿，回来就完美了”，他用顶级模型却每 10 分钟就要纠正一次，”英语需要一个词来表达’我不认为你在撒谎，但我也不信你’“。
谁会受影响？ frangonf 半开玩笑地问：既然仓库永远在变、几乎没有人工监督，何必还要版本控制？让软件像赫拉克利特的河流一样流动好了。nater5000 回答说智能体同样需要版本控制来理解代码如何变化，避免陷入”改了又撤、撤了又改”的循环。mixedbit 问：既然智能体这么能干，Anthropic 为什么不自己开发高利润的服务（比如对标谷歌搜索），而要卖 token？zeroonetwothree 反问”投资经理那么会投资，为什么还要替别人理财”，Philpax 提到 OpenAI 因为不够聚焦而关停 Sora 的教训，ihumanable 回了一句：”不够聚焦，比如自己搞个源代码管理系统。”piker 问 Anthropic 的员工现在都在干什么，pjmlp 认为文章先说”小团队办大事”、紧接着用一段话强调工程师仍有价值，是为了避免预料中的反弹。kburman 和 eddythompson80 认为这正是大模型生产力的去向之一：写代码变便宜后，大家都会重新发明轮子，嫌 Grafana 不好用就自己生成一套仪表盘；至于维护这些定制软件是否同样便宜，是另一个问题。nickysielicki 问既然不开源，为什么要告诉我们；arxanas 认为这对碰到 git 扩展上限的大企业非常重要，相当于一份经过验证的配方。East River Source Control 的 steveklabnik（jj 的支持者，该公司 CTO 是 jj 的作者）表示，这印证了他们的判断：大团队加智能体在单体仓库里工作必然撞上 git 的上限，他们在做的是带 git 兼容层的过渡方案。Pijul 的作者 pmeunier 也现身说，他已经用 Pijul 让数百个 Claude 实例并行构建大型项目，几乎从未发生冲突。