Anthropic开发Scion替代Git工作流

Anthropic 放弃行业通用的代码管理工具 Git，转而自己开发了一套名为 Scion 的新系统。 在 Anthropic 内部，AI（Claude）承担了大量的编程工作，写代码的速度远超人类。这导致每天需要合并保存的代码量暴增，从 5 月份的每天 2,500 次猛增到 9 月份的每天 30,000 次以上。传统软件开发中常用的 Git，原本是为人类工作习惯设计的，默认每个人都把整座代码仓库完整下载到自己的电脑上离线操作。随着代码库体积膨胀到几十吉字节（GB），数万次频繁操作让原有的网络和服务器彻底不堪重负。 面对这种瓶颈，Anthropic 决定彻底重构底层机制。他们只用了五个月时间，开发出专为 AI 时代设计的系统 Scion。这套新系统的核心逻辑主要有三点： · 按需索取： 工作的大多是始终联网的 AI 智能体，不需要每次都把全部历史记录下载下来。系统只在需要某些文件时，才去服务器调取对应内容。 · 服务器挑大梁： 复杂、繁重的计算全部放在云端服务器完成，客户端只负责展示和简单缓存，极大地节省了本地机器的资源消耗。 · 更轻便的记录方式： 每次保存修改时，系统只记录改动的增量，不给整个代码库加锁，让上万个任务可以同时提交而互不堵塞。 这个项目本身也是 Anthropic 团队借助 AI 共同完成的。一支仅有 7 人的工程师团队，借助内部的 Claude 模型快速重写核心架构、自动排查漏洞，完成了以往大公司需要几倍人手和数年才能做完的工程。 Anthropic 的工程师认为，随着 AI 编程越来越普及，传统的软件协作工具都会面临类似的性能瓶颈。他们公开这些经验，是为了给整个软件行业提供参考，帮助大家提前做好应对海量 AI 代码的准备。

曝光 123257 · 评论 53 · 点赞 941 · 书签 740

Anthropic 公司的代码量太大，目前一天 merge 次数达到 3000 次。代码库一个分支的代码量就有 100 GB。代码管理系统 git 已经没法用了，自己做了一个全新的代码管理系统，叫 Scion。 评：科技大爆炸。

曝光 31385 · 评论 6 · 点赞 108 · 书签 28

AI 写代码太快，git 扛不住了：Anthropic 为什么自己造了 Scion？ 视频1: 英文版 视频2: 中文版 这一年，GitHub 隔三岔五就出故障。GitHub 在自己的可用性报告里说，流量涨得飞快，很大一块来自 AI：AI 帮人写代码，AI 智能体自己提交修改。他们四个月里把有效容量翻了一倍多，还是扛得很吃力。 Anthropic 自己的代码库更夸张：今年五月平均每天合并约 2500 次修改，到了九月，一天超过 3 万次，涨了十倍以上。 全世界程序员都在用的 git，扛不住了。Anthropic 干脆自己造了一个版本控制系统，叫 Scion，五个月就把整个代码库从 git 换了过去。git 为什么扛不住？Scion 到底改了什么？ git 是干什么的 你可以把 git 想成一个带时光机的共享文件夹。每改一次，就存成一个版本，叫一次提交。谁改了哪一行、什么时候改的，都查得到，改坏了还能退回去。 GitHub，就是全世界最大的、帮大家存放 git 仓库的网站。 很多大公司会把所有项目的代码放进同一个大仓库，这叫单体仓库（monorepo）。Anthropic 用的就是这种。 每人一整座图书馆 git 有个特点：每个人拿到的，都是一整份完整的仓库，连全部历史一起。打个比方，就像借书的时候，顺手把整座图书馆复印一份搬回了家。好处是断了网也能翻历史、查记录。 仓库小的时候，这没问题。可 Anthropic 的仓库，光主分支的历史就接近 100 GB，压缩后的一份工作副本也超过 25 GB。 搬不动了 再看要搬多少次。光是自动构建和测试（CI）这一个环节，每天就要把代码检出到机器上大约 2500 万次，这还没算开发环境、AI 智能体的沙盒和研究任务。要是每次都老老实实整份拉取，一天的流量会超过 600 PB。换算一下，差不多是 60 万块 1 TB 的硬盘。 原来的补丁架构：层层加缓存 他们想过各种办法：浅克隆、稀疏检出这类只拉一部分的功能都试过。原来的架构，是层层加缓存：机器要代码，先找本地的打包缓存（packfile cache）；没有，再找镜像服务器（mirror replicas）；镜像再去找镜像主库，最后才是最上游的那份仓库。每个集群都有一套。新机器启动时，还会先从云存储拷一份仓库快照，省得从零开始拉。 最多的时候，同时开着几百台 git 镜像服务器。可修改越来越多，快照一拷下来就落后一大截，镜像也越来越难养。 换一个问题 后来他们发现，git 那些为离线工作准备的本事，自己几乎用不上。 这里说的“在线”，不是指能不能上网，而是随时能连上公司的代码服务器。你带着笔记本上飞机，没有网也想写代码、翻历史，git 那套“每人一整份”的本事才派得上用场。可在 Anthropic，用代码的几乎都是 AI 智能体和后台任务，它们本来就跑在公司的机器上，跟代码服务器之间的网一直是通的。 于是他们换了个问题：如果从一开始就假设，用的人永远在线、随时连得上服务器，代码管理该长什么样？ 要哪页，取哪页 答案是：别再搬图书馆了，改成去前台借。 Scion 的客户端不存整份仓库，只留一个容量有限的本地缓存。需要哪个目录、哪个文件，再去服务器取。查历史、查某一行是谁写的、合并和变基，这些重活全交给服务器。这些查询能力都通过接口开放出来，很多任务连代码都不用拉，直接问服务器就行。 提交就在服务器上 在 git 里，你先在自己电脑上提交，再推送给大家。在 Scion 里，提交直接发生在服务器上，一提交，所有人马上能看到，根本没有“推送”这一步。 每次提交只记下这次改了哪几个文件，像一张修改清单，不用把整个目录重抄一遍。清单上每个文件只记一个编号，真正的内容存在云存储里，一模一样的内容只存一份。所以仓库再大，一次提交的成本只跟这次改了多少有关。 一层层的分馆 那么多机器同时来借，服务器忙得过来吗？靠的是一层层缓存：每台机器上有个“小管家” scion-daemon，每个区域有个“分馆” scion-cache，最后才是“总馆” scion-server，它背后连着数据库和云存储。 每份文件都按内容算出一个编号，存进去就再也不会变，所以哪一层都能放心缓存，不用跟别人核对。结果，每一层的缓存命中率都超过 99%，绝大多数请求在家门口就解决了。 Scion 的整张架构图 把这些拼起来，就是原文配图里的 Scion 架构。请求分两条路走： 一条是“问事”（控制面）：查历史、看差异、提交修改，所有客户端，包括代码审查工具 Antique、开发者电脑、集群里的任务，都直接找总馆 scion-server。 另一条是“取货”（数据面）：目录和文件内容走缓存。开发者的电脑直接找区域分馆 scion-cache；集群里的任务先找本机的小管家 scion-daemon，没命中再一层层往上找。 总馆背后，修改记录、分支和目录结构存在 Spanner 数据库里，文件内容存在云存储里。新机器上线，小管家先拷一份定期快照，省得从头拉。 效果 整套设施占用的 CPU 和内存，比原来的 git 镜像集群小了 200 倍。测试和研究任务拉代码，从几分钟缩短到几秒钟，光 CI 这一项就省出了 25% 的 CPU。原文配图里还有一组数字：AI 智能体新开一个工作区，中位耗时从 7.1 分钟降到 5.1 秒，快了 84 倍。 这么大的系统，得多少人做？ 一个七个人的团队，用五个月做完了 Scion 和配套的代码审查工具 Antique，还顺手做了五六个周边系统，并把整个仓库迁了过去。而且这期间每天合并的修改量涨了十倍。放在过去，这种迁移往往要大得多的团队花上好几年。 一个例子：他们手写的第一版数据导入程序，交给 Claude 一个早期的内部版本（Claude Mythos Preview 的早期快照）重写，没加任何额外要求，新版本内存降了 20 倍，速度快了 4 倍，原有的约束条件也都保住了。 AI 写代码这么强，工程师还干什么？ 参与的工程师都承认，单论写代码，Claude 已经比他们强了。但工程师的活变了：把握各个系统怎么配合，权衡架构上的取舍，围绕要解决的问题和预期的规模做决定。很多时候，他们的工作是对 Claude 说“不”。 比如，有好几个系统想一条条扫提交记录，去找某次修改是什么时候合进主分支的，其实直接问代码审查工具就行。现在团队成员依然审查每一个变更，但审的是修改背后的意图，不再逐行读代码。 大家都该扔掉 git 吗？ 不用。Anthropic 自己说，Scion 不是 git 的通用替代品，只有极其庞大的单体仓库才用得上：背后要么有几万名工程师，要么有成群不知疲倦写代码的智能体。 它和 git 差别太大，想用就得把代码审查、代码搜索、CI 这整条工具链重做一遍，所以他们没打算做成通用产品。他们更希望这些思路被借进 git 生态：服务器多干活、提供更完整的查询接口，客户端按需取。他们预计，未来 6 到 12 个月，这类扩展问题会在业界越来越常见。 记住三句话 第一，git 让每个人拿一整份仓库，AI 把修改量推高十倍以上，就搬不动了。 第二，Scion 假设用的人永远在线、随时连得上服务器：要什么取什么，重活交给服务器，一层层缓存兜底。 第三，AI 写代码越快，瓶颈就越会跑到别处：代码管理、构建、测试，都得按 AI 的规模重新设计。 以前，是每人搬回一座图书馆；现在，楼下就有分馆，要哪页，借哪页。 资料来源：Anthropic 工程博客《Redesigning source control at Anthropic》（2026 年 10 月），https://www.anthropic.com/engineering/redesigning-source-control

曝光 23975 · 评论 80 · 点赞 146 · 书签 91