5 月的时候，Anthropic 主代码库一天合并的变更大概是 2500 个，到 9 月涨到一天三万多，9 月 9 日那天合了 30401 个，多出来的这部分，按 Anthropic 自己的说法，主要是 agent 写的。代码一多，压力就落到了管代码的那套东西上：他们在 10 月 13 日的工程博客里写，现在的瓶颈已经不是写代码，而是当初按人的规模搭起来的开发基础设施，源码管理、构建和 CI 都在里面，而且合并代码的需求几乎没有上限，每拆掉一个瓶颈，代码量马上又会往上涨一截。
他们先拆的是源码管理。一个七人小组自己写了一套版本控制系统 Scion，花五个月把整个 monorepo 从 Git 迁了过去，同一时间还做了代码审查工具 Antique、代码搜索和权限系统。
Git 是给人设计的
Git 诞生于 2005 年，最早管的是 Linux 内核：成百上千个开发者散在世界各地，各写各的，再合到一起。所以它是分布式的，每人手里一份完整仓库，断网也能提交、看历史、切分支，坐飞机也能干活。
Anthropic 回头一看，自己和大多数公司一样，其实是把 Git 当集中式系统在用：只有一份权威仓库，连上来的几乎全是 agent 和各种任务，本来就一直在线。Git 为离线准备的那一整套，在他们这里只剩代价。
这个代价随着仓库变大越来越重。主干历史接近 100 GB，压缩后的工作副本超过 25 GB。光 CI 每天就要做大约 2500 万次代码检出，还没算开发环境、agent 沙箱和研究任务，按常规方式从 Git 拉，一天的流量会超过 600 PB。
内部镜像、仓库快照这些补救办法他们都用过，最多时同时跑着几百个 Git 镜像。合并越来越快，镜像越来越难运维，快照每次刷新之间离主干最新的提交也越落越远，diff、blame 这些依赖历史的操作，要在部分克隆上保持正常，得花的心思越来越多。
Scion 是怎么做的
在 Git 里，每个克隆自己就能算 diff、查 blame。Scion 把这些都收到了服务端：提交、合并、rebase、查历史、blame，全由服务端来做。客户端只管一份有上限的本地缓存，把工作区文件摆到磁盘上，再盯着文件有没有变。原文的说法是，客户端自己几乎算不了什么，换来的是本地要存的数据少得多。
既然提交、rebase、合并都发生在服务端，也就没有 push 这一步了。代价是这些操作必须够快，开销只能跟这次改动的大小挂钩，不能跟仓库大小挂钩，也不能加锁，不然服务端跟不上。服务端上同样没有一份完整展开的仓库，没有 packfile，也就不用做仓库维护。工作区是可选的，要用也只拉用得到的目录。
检出走三层缓存：每台机器上的守护进程、区域缓存服务器、背后接 Spanner 和云存储的权威服务器，每层命中率都在 99% 以上。
迁完以后，Scion 这套基础设施占用的 CPU 和内存只有原来 Git 镜像的两百分之一，CI 和研究任务检出代码的时间从几分钟降到几秒，CI 因此省下了 25% 的 CPU，客户端和缓存也都不用再做仓库维护。agent 环境里的变化更明显，新建一个工作树从 7.1 分钟降到 5.1 秒，一个变更在源码管理上花掉的总时间从 34 分钟降到 3.7 分钟，图上标的是每天大约 1.1 万个 agent 小时。
Anthropic 并不建议别人照搬。原文说 Scion 绝不是通用场景下 Git 的替代品，这套思路只对几万名工程师共用的超大 monorepo，或者大量 agent 同时写代码的仓库才有意义；另外他们自己内部花在 token 上的量，也远超一般公司愿意花的，这么花一是为了自己的研发需要，二是为了测试 Claude 的能力。
合并、审查、测试、运维
原来按人的速度设计的流程不止 Git 一个，合并队列就是另一个。业界通常给合并队列加一把全局锁，前一个变更测完、合进主干之后下一个才能进来，这样主干始终是可用的；可是一轮测试还没跑完，可能就已经有几百上千个变更合了进去，这种情况下 CI 到底该怎么定义，原文自己也打了个问号。他们没能复刻全局锁，改成在合并之后和部署之前跑自动化测试，并发的变更因此会冲突，但按他们的说法，Claude 修这些冲突通常比人发现冲突还快。
审查这一块，参与这个项目的工程师现在都觉得 Claude 写代码比自己强，不过系统之间怎么配合、设计上怎么取舍，还得靠人来判断，原文的说法是，很多时候工程师的工作就是对 Claude 说「不」。比如迁移过程中，好几个系统想知道一个变更什么时候合进了主干，做法是从头到尾线性地读提交日志，而不是去问代码审查工具；又比如一次对抗式审查对另一个内部服务过分不信任，Claude 就跟着加了一堆多余的校验，把系统搞复杂了。这些都需要有经验的工程师拦下来。审查工具 Antique 本身也能给审批加上语义层面的约束，只改注释的变更和改了关键逻辑的变更可以区别对待，人的精力就留给后一种。
测试方面，因为 Claude 写代码的速度远远快过人，团队在很紧的工期里还是给 Scion 补上了覆盖各种基础设施和源码管理交互的封闭模拟测试，再加上模糊测试和一套细致的限流，原文说这是他们做过的测试最充分的代码库之一。
运维用的是 Claude Tag。团队给每个组件单独开一个 Slack 频道，让一个 Claude 只盯这一个组件的健康状况，内部叫 superfan，scion-daemon、scion-cache 和 Antique 的合并队列各有一个。它们能看遥测和日志，原文把它们比作一个除了刷图表、找异常之外没别的事要做的资深工程师；传统告警也还保留着，但 superfan 能发现一些细小的新问题，相比之下告警就显得很单一。
七个人，五个月
整个项目是七个人做的，五个月里做完了 Scion、Antique 和另外大约六个相关系统，又把整个 monorepo 迁了过去，而这段时间合并量正好涨了十倍。Anthropic 的看法是，放在以前，这样的系统要更多工程师花好几年慢慢迁，以后这种小团队快速迁移会越来越常见。
Claude 在里面做了很多具体的工作。Git 导入 Scion 的管道最早是团队年初手写的原型，当时他们觉得质量还可以，后来拿到 Claude Mythos Preview 的一个早期内部快照，让它把整个管道重写，没有额外说明，结果新版本内存占用降到二十分之一，速度提高 4 倍，导入顺序和数据结构方面的隐含约束也都保留了下来。祖先查询漏用索引的问题也是 Claude 找到的，换成专家来分析和调优，要花几天甚至几周。
接下来轮到别人了
Scion 不会开源。它和 Git 差别很大，别的公司如果要用，整条研发链路都得跟着迁，还要配套的代码审查、代码搜索和 CI，而 Anthropic 内部这些组件都是高度定制的，他们也担心硬做一个想让所有人都满意的公开版本，效果不会好。所以他们分享的是思路：Git 平台可以保留 Git 的基本模型，同时换一种服务端架构、提供更完整的 RPC、改进稀疏检出和浅克隆。Anthropic 预计未来 6 到 12 个月会有更多团队遇到类似的问题，他们希望和 GitHub、GitLab 以及开源社区一起应对。
参考链接：
- Redesigning source control at Anthropic，Anthropic Engineering，2026-10-13
关于
关注我获取更多资讯
