Anthropic Scion 重做 Git：Agent 时代的版本管理系统

架构师（JiaGouX）

我们都是架构师！
架构未来，你来不来？

昨天，10月13日，Anthropic 公开了一套内部版本控制系统 Scion。

今年 5 月，Anthropic 平均每天合并约 2,500 次代码变更；到了 9 月，这个数字已经超过 30,000。它的主干历史接近 100 GB，压缩后的工作副本超过 25 GB，仅 CI 每天就要做约 2,500 万次 checkout。

五个月里，七名工程师完成了 Scion、代码审查工具 Antique 和多套配套系统，并把整个 monorepo 迁了过去。Anthropic 同期还上线了代码搜索和源码权限系统。

看到这些数字，很容易把 Scion 理解成“Anthropic 抛弃了 Git”。我更关心另一个变化：源码仓库的主要客户端，正在从长期存在的开发环境，变成随任务创建、始终在线、做完就销毁的 Agent 和 CI job。

客户端变了，版本控制系统里很多用了二十年的默认假设也不再成立。

Scion 重做的，是源码事实放在哪里、历史问题由谁回答，以及 Agent 要花多少成本才能看到代码。

客户端先变了

Git 的一个重要价值，是每个客户端都足够完整。

仓库 clone 到本地以后，即使离线，也能看历史、做 diff、查 blame、创建 commit、切换分支。人的开发环境会长期存在，会断网，也需要随时试验。把数据和计算能力放在本地，换来了很强的自治性。

Anthropic 面对的工作负载刚好相反。

Agent 沙箱和 CI job 本来就运行在在线基础设施里，生命周期往往只有几分钟。一个测试任务也许只需要三个目录；一个自动回滚工具只想知道两个变更的祖先关系；一次代码审查只需要 diff、作者和审批状态。

沿用原来的路径，这些任务仍要准备本地仓库，再从本地对象里算出答案。任务很短，准备仓库却很重。任务一多，同样的文件会在不同节点反复传输，同样的历史关系也会在不同工具里反复计算。

Anthropic 试过 shallow clone、sparse checkout、promisor remote、对象存储快照，也维护过数百个 Git 镜像。这些办法都能减少一部分传输和落盘，但主干变化一快，快照很快落后，镜像要不断追赶，依赖完整历史的工具也难维护。

Scion 改了这个假设：客户端始终在线，服务端掌握权威事实，客户端只为当前任务取需要的数据。

Scion 没有把 Git 命令原样搬到服务器，而是把数据写入、历史查询和文件分发拆成三条路径。

一次 Agent 任务怎么跑

假设一个 Agent 接到任务，要修改 monorepo 里的一个服务。

在 Scion 里，它不用先拿到完整仓库。客户端 scn 创建工作区，按目录请求需要的 tree 和 blob；文件没有被访问，就暂时不落盘。需要查历史、计算 merge base 或 blame 时，客户端直接调用服务端 API，不用为一个答案维护完整仓库。

Agent 改完文件以后，Scion 在服务端创建 changeset。

Changeset 记下变化

Changeset 类似 Git commit，但写法不同。它记录父 changeset、相对第一个父节点变化的文件清单，以及指向压缩 blob 的内容寻址指针。

这里有个容易说错的地方。Scion 不是“只存增量”，Git 也不是每次提交都复制整个仓库。Git 的 tree 和 blob 本来就会共享。两者的差别在写入路径和权威位置：Scion 的 changeset 在服务端创建，创建成本跟本次变化相关，也不用同时移动一个全局 ref。

主干和发布分支仍然存在，但移动 ref 是另一个动作。Scion 用 Spanner 单行 compare-and-swap 更新它：只有旧值符合预期，新的主干位置才会生效。

变更被保存，不等于它已经进入主干。

历史问题交给服务端

Changeset 只记“这次改了什么”，不能直接回答“这行最后是谁改的”“某个文件经历过哪些变化”“两个 changeset 是什么关系”。

Scion 为 blame、路径历史、提交图跳跃查询和根目录树建立派生数据。每种派生数据都从父 changeset 的结果递归计算，既能预先生成，也能在查询发生时再算。

写入事实和读取优化不再绑在一起。新增一种路径索引，不用改客户端协议；某个查询结构需要重算，也不会改写原始 changeset。

Changeset 记住发生了什么，派生数据让历史查询跑得足够快。

复杂度没有消失。惰性计算的首次延迟、热点回填、索引版本和失败恢复，都会成为服务端的新工作。Scion 把这些工作集中到服务端，不再让每个短命客户端各养一套仓库状态。

Checkout 按需取对象

文件要落到工作区时，scn 从根 tree 开始检查本地缺少哪些对象，只请求需要的子 tree 和 blob。

每个请求都指向一个内容确定、不会变化的对象。请求可以缓存、重试，也可以在中断后继续。客户端不用等巨大的 packfile 生成、传完再开工。

Anthropic 的分发链路大致是：

scn → scion-daemon → scion-cache →  scion-server → Spanner / 对象存储

节点上的 scion-daemon 让同一台机器里的任务复用对象；区域 scion-cache 直接从内存返回数据；缓存未命中时，权威服务才访问持久存储或计算派生数据。

这几层使用同一套 RPC，但流量不能越级。区域缓存故障时，客户端不能一窝蜂打到权威服务。协议可以相同，流量拓扑还得把故障限制在局部。

官方给出的内部数据是：每一层缓存的命中率都超过 99%；源码管理基础设施使用的 CPU 和内存，约为旧 Git 镜像体系的 1/200；CI 和研究任务的 checkout 从分钟级缩短到秒级，仅 CI 就释放了约 25% 的 CPU 容量。

这些收益带着很强的 Anthropic 特征：它的仓库、热点分布和任务形态都很特殊。换掉 Git，不会自动得到同样的结果。

Scion 和 Origin 改的不是一层

Cursor 也在做类似的事，但落点不同。它介绍了源码托管平台 Origin，以及底层 Git 存储系统 Continuity。

两套系统都面对更多 Agent、更多 PR、更多 CI 带来的压力，却选择了不同的边界。

Scion 可以更换数据模型、客户端和传输协议。它把历史查询做成服务，把工作区改成按需视图，也不再要求服务端围绕 Git packfile 运行。代价是整个研发链路都要迁移，代码审查、搜索、权限和 CI 也要一起重做。

Origin 选择保留 Git 协议。开发者仍然可以 clone、push 和 pull，服务端也运行普通 Git 仓库。Continuity 把 S3 上的写前日志作为持久化依据，本地 NVMe 仓库则更像可以重建的热副本。Push 先把 packfile 写进日志，ref 事务准备完成、WAL 索引通过原子 compare-and-swap 更新后，变更才对外可见。

Scion 重做版本控制模型；Origin 重做 Git 服务端的持久化、复制和扩容。

三条路线的取舍不同：

• Scion
   保留 changeset、历史、工作区这些版本控制概念，但更换数据模型、客户端、协议和源码服务。它换来的是更大的设计空间，代价是迁移完整研发工具链。
• Origin / Continuity
   保留标准 Git 协议和现有客户端，改造服务端日志、复制、恢复和仓库调度。兼容性更好，但还要承担 Git 对象和 packfile 的语义。
• Git 的渐进优化
   不改现有仓库和流程，通过 partial clone、sparse checkout、sparse index 和后台维护减少大仓库成本，但调整空间受现有协议和工具行为约束。

Cursor 公布的压测是读取随副本数近似线性扩展，以及不同 S3 类型下的 push 吞吐；Anthropic 公布的是每日合并量、checkout 耗时和基础设施占用。两组数字的单位、路径和目标都不同，不能直接排成性能榜。

Hacker News 上有人拿 Origin 的写入数字和 Scion 比较，Scion 工程师 Nick G. 回应说：这是两类不同系统，Scion 处理的问题不止写入速度。Origin 更靠近服务端复制和持久化；Scion 连历史查询、工作区准备和变更进入主干的路径也改了。

合并之后，还要验证

Anthropic 同期建设 Antique、代码搜索和源码 IAM。原因不复杂：源码模型一变，审查、测试、权限和发布都要重新回答同一组问题。审查针对哪个不可变变更？CI 通过时验证的是哪个快照？测试运行期间主干又进入几百次变化，这份结果还覆盖什么？敏感目录的对象进入缓存后，读取权限怎样继续生效？

传统合并队列在 Agent 规模下也遇到了麻烦。Anthropic 没能有效复现全局锁式合并队列，于是把更多自动测试放到了合并后、部署前。

自动测试后移，没有消除并发冲突。测试跑完以前，主干可能已经变化；两个改动在文本上能合并，也可能一起破坏接口或运行行为。Claude 能更快修复冲突，缩短的是恢复时间，不是把组合风险变没了。

在这条链路里，一次变更有四种状态：

Scion 公开文章没有声称已经把这四种状态做成一套通用模型。这四种状态是我从源码、审查和验证链路里拆出来的。变更密度越高，“代码已经提交”能说明的事就越少。

前面聊 AI 原生研发时，我们谈过同一个问题：代码生成变快了，需求、评审、发布和生产维护也要跟上。Scion 把问题压到了源码层：源码事实跑得越快，验证结果越要对应到明确版本。

人盯的是意图

Anthropic 也承认：参与 Scion 的工程师都认为 Claude 已经比自己更擅长写代码，但人仍要决定系统边界、规模假设和迁移取舍。人的工作之一，是告诉 Claude“不”。

有的实现为了查询一次变更何时进入主干，线性扫描整个提交历史。代码也许能运行，但在这套系统里，答案属于代码审查服务，查询入口从一开始就选错了。

一次对抗式评审围绕假想风险增加了大量防御性校验，反而把系统做复杂了。Simon Willison 在自己的项目中也有类似感受：对抗式评审很有用，却可能短视，容易围着局部担忧不断加码。

Scion 团队会审查每个 change request，但重点是变更意图，不是逐行过代码。

代码可以越写越多，人的时间要留给主路径：这个变更为什么存在，它依赖哪个权威事实，破坏了什么约束，失败后怎样停下和恢复。

Agent 提高实现吞吐，人守住系统边界和变更意图。

Scion 还不是 Git 的替代品

Scion 不适合作为普通团队的 Git 替代品。Anthropic 自己说得很明确：这套设计只适合超大 monorepo、数万名工程师，或大量 Agent 不断写代码的环境。它还依赖自研的审查、搜索、CI 和权限体系，目前也不是一套可以直接安装的产品。

不过，客户端形态的变化并不只发生在 Anthropic。

当仓库的主要客户端是人，完整本地副本、离线操作和强客户端很自然；当主要客户端变成在线、短命、并行的 Agent，服务端查询、按需工作区和共享缓存就会变得更重要。再往后，代码生成速度继续上升，系统还要区分变更事实、主干位置、验证结果和部署资格。

把 Scion、Origin 和 Git 自身的演进放在一起，Agent 时代的版本管理可以拆成三个问题：源码事实怎么保存，任务怎样拿到需要的代码，一次变化凭什么继续进入生产。

Scion 改了前两层，Anthropic 也不得不重排第三层。普通团队暂时用不上它，但版本控制的设计前提也在变化。

往期相关推文

• 《Anthropic 公开了 AI 原生开发实践：规划、设计一直谈到部署和生产维护》
• 《代码越来越快，架构工作变在哪里？从吴恩达 AI 工程技能图谱说起》
• 《Claude Code 写得越快，越要把错误控制在可回滚范围内》
• 《Claude Code 团队的真实难题：20 个 Agent 之后，谁来验证和接手》

参考资料

• Anthropic，Redesigning source control at Anthropic（https://www.anthropic.com/engineering/redesigning-source-control）
• Cursor，Git at any scale（https://cursor.com/blog/git-at-any-scale）
• Cursor Docs，Clone, Push & Pull（https://cursor.com/docs/origin/git）
• Simon Willison，Redesigning source control at Anthropic（https://simonwillison.net/2026/Oct/13/redesigning-source-control-at-anthropic/）
• Meta，Sapling: Source control that’s user-friendly and scalable（https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/）
• Git，Partial Clone Design Notes（https://git-scm.com/docs/partial-clone）
• Git，git-sparse-checkout（https://git-scm.com/docs/git-sparse-checkout）
• Git，Scalar（https://git-scm.com/docs/scalar）
• Google，Software Engineering at Google：Version Control and Branch Management（https://abseil.io/resources/swe-book/html/ch16.html）
• Hacker News，Redesigning source control at Anthropic（https://news.ycombinator.com/item?id=50073633）
• Anthropic 官方 X（https://x.com/AnthropicAI/status/2110047081414987957）
  
  

如喜欢本文，请点击右上角，把文章分享到朋友圈

如有想了解学习的技术点，请留言给若飞安排分享

因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享

·END·

相关阅读：

• 从 LLM 到 Agent 到 Harness：真正复杂的是运转起来之后
• Claude 做方案，Codex 写代码：多模型协作怎么交接才稳
• CLAUDE.md 拆解：Agent 进仓库前的上下文入口
• Loop Engineering，应该赞成还是反对？
• 架构排熵：Loop Engineering 的持续清理系统
• 设计 Self-Harness 架构：会自我改进的Harness

版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!

架构师

我们都是架构师！

关注架构师(JiaGouX)，添加“星标”

获取每天技术干货，一起成为牛逼架构师

技术群请加若飞：1321113940 进架构师群

投稿、合作、版权等邮箱：admin@137x.com