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 代码的准备。

曝光 132520 · 评论 59 · 点赞 991 · 书签 779

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

曝光 58951 · 评论 9 · 点赞 163 · 书签 42

Claude 写代码太快了，Anthropic 干脆把自家 monorepo 从 git 迁走了。5 月每天合并约 2,500 个改动，9 月超过 30,000 个。7 个人花 5 个月自研了 Scion 来接手。 这怎么没人质疑 Claude 是全自动化质量堪忧了🤣

曝光 31094 · 评论 23 · 点赞 111 · 书签 25

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

曝光 30663 · 评论 94 · 点赞 185 · 书签 121

Anthropic把自己内部的Git换掉了，原因是Claude写代码太快，传统版本控制系统已经跟不上Agent的产出速度 5月份Anthropic每天合并约2500次代码变更，9月突破3 万次，4个月增长12倍，Git逐渐成为最大的开发瓶颈 于是Anthropic自研了一套版本控制系统：Scion，7人团队用Claude5个月完成了系统开发、配套代码审查工具 Antique，以及整个Monorepo从Git到Scion的迁移，目前属于Anthropic内部系统 效果： 基础设施CPU和内存占用降至原来的1/200； CI和研究任务的代码检出速度提升100倍，从分钟级缩短到秒级 CI节省约25%的CPU容量 Scion的核心设计：不再要求Agent把整个仓库及其历史搬到本地，而是假设客户端始终在线，由服务端负责提交、合并、历史查询，客户端按需获取代码 底层采用增量Changeset、内容寻址存储、分布式缓存和按需检出，服务端可水平扩展，许多CI操作甚至不需要真正检出代码 这条路线与Google Piper、Meta Sapling等大规模代码管理系统有相似之处，不同的是它从一开始就针对AI Agent 高并发、始终在线、海量代码变更的工作负载设计的 这也说明了AI Coding的瓶颈在从代码生成，转向代码合并、测试、审查、权限治理、部署等 过去软件工程基础设施围绕人类开发者的工作速度设计；未来可能需要围绕成千上万个并行工作的Agent重新设计 #代码理管 #git #Scion

曝光 29933 · 评论 31 · 点赞 85 · 书签 70

💥代码量爆炸！Claude距离RSI递归自我改进已经很近！ 看Anthropic内部仓库提交曲线，8月短暂低谷之后直接爆发，单日合并变更突破3万条。 官方口径：Claude已经可以自主迭代研究流程、调优复杂代码、从零搭建服务。 完整的RSI递归自我改进还没有完全实现，但已经非常接近。 不少观点判断2027年会是AI发生剧烈变革的关键年份。

曝光 26128 · 评论 6 · 点赞 10 · 书签 1

围绕 Pull Request 和代码 review 的一切，都是最初设计给人用的： 所以现阶段非常别扭，实际上是 Agent 完成了一切，人在整个过程中的假装 review ，复制黏贴，甚至 PR 政治斗争，完全拖慢了 Agent 的节奏。 事实上，对于 Agent 来说，拥有对代码 diff 的上帝视角，它不需要 PR 来停下脚步展示做了什么，为什么这样做。 成千上万个 Opus 5.5 subagent，不需要可怜的人类。 所以 Anthorpic 重塑了 git，这几十年来为人类开发者做的整套 infra 一定也会迅速改变。

曝光 20209 · 评论 13 · 点赞 82 · 书签 20