Anthropic 自研 Scion 源码管理系统如何支撑每日三万次提交

Anthropic 在过去六个月里，代码合并量从每天约两千五百次激增至三万次以上，促使团队自行开发了叫 Scion 的源码管理工具，以应对巨大的检出流量和历史记录体积。

背景与动机

2026 年 5 月，Anthropic 的主干分支每天合并的代码变更大约只有 2,500 次。到 9 月时，这一数字已经突破 3 万次每天。图表显示，工作日的合并量在一月份起步约 1,000 次，慢慢爬升到五月底的 3,000 次左右。随后出现一种称为 “antique” 的新式变更请求，它在六月中开始超越传统的 pull request，到七月中几乎完全取代了后者，此时工作日的合并量已达到 6,000–8,000 次。七月底有一次“安静周”，日合并量一度跌回 1,000 次以下。八月中旬以后，增长曲线变得陡峭，八月中突破 1 万次，九月初约 1.7 万次，九月九日峰值甚至达到 30,401 次。图中还用虚线标记了当年几次模型公开发布的时间点，其中 Fable/Mythos 系列的出现被猜测为提升编码速度的重要推手。

系统设计与特点

Anthropic 没有继续使用传统的 Git，而是构建了一套名为 Scion 的内部源码管理系统。从描述来看，Scion 更像是一种集中式的方案，其思想来源于 Google 的 Piper 和 Meta 的 Sapling，尤其是 Sapling 中的“派生数据”概念，据说受到 Mononoke 服务端组件的启发。在这套体系里，代码审查流程被称作 “antique”，它与传统的 pull request 形成了并行的两条路径。总的目标是让每日的海量检出操作能够在可接受的带宽和存储成本下完成。

性能需求与挑战

文章给出了一些令人咋舌的规模数据：主干分支的完整历史接近 100 GB，即便经过压缩，一个工作拷贝也超过 25 GB。为了持续集成（CI），每天需要进行约 2,500 万次代码检出，这个数量尚未算上开发者本地环境、Agent 沙箱以及研究任务。如果采用最 naive 的方式从 Git 拉取，单日的流量将超过 600 PB，显然不可能靠现有的分布式方案撑住。因而 Scion 必须在存储压缩、增量传输以及服务端缓存上做出显著优化，才能让如此规模的并行检出变得可行。

迁移过程与团队规模

负责 Scion 的核心团队只有七个人。他们从最初的设想到把全部代码库从 Git 迁移到新系统，总共用了五个月时间。在这段时间里，团队不仅要实现基本的提交、检出和合并功能，还要确保与现有的代码审查、构建以及测试流程无缝对接。迁移完成后，日均三万次的合并量已经在新系统上稳运行，而之前的 Git 基础设施则被逐步退役。

离线支持与 adversarial review

在 Hacker News 的讨论中，有人询问 Scion 是否支持离线操作。系统工程师 Nick G 明确回答：因为公司内部使用最重的用户是 Claude 模型，而 Claude 必须保持在线状态，离线特性对整体工作流来说并不是优先考虑的点。此外，文章还提到 Anthropic 在内部广泛采用对抗性评审（adversarial review），即让模型互相挑挑毛病，虽然这种方式能够捕获很多问题，但也可能导致视野狭窄，因而需要有经验的工程师来引导和修正。

小结与思考

Anthropic 的经历表明，当代码量因模型迭代而爆炸式增长时，传统的分布式版本控制可能已经不再满足性能与成本需求。通过借鉴集中式系统的思想，并结合自派生数据的机制，Scion 能够在每天数千万次检出、百 GB 级历史记录的前提下保持可用规模。虽然牺牲了离线使用的灵活性，但在以大模型为核心驱动力的内部工作流里，这一取舍似乎是合理的。对于其他面临类似规模挑战的团队来说，这套方案提供了一个值得参考的思路：先明确瓶颈在哪里（这里是检出流量和历史体积），再看看是否可以从现有的集中式或派生数据系统中汲取设计灵感，最后用小规模、专注的团队快速验证和迁移。