10月13日，Anthropic 公开了一套内部版本控制系统 Scion。
没想到，Anthropic 已经把内部的版本控制系统，从 Git 迁移到了自己开发的 Scion。
看到这个消息，我非常震惊。因为 Git 几乎已经成了整个软件开发行业的标配，绝大多数程序员每天都在用。
刚毕业那会，我用的还是 SVN，后来切换到了 Git，一用就是十几年。哎，我以前还真没想过，有一天连 Git 都会被颠覆掉。
【事件来龙去脉】今年 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 要花多少成本才能看到代码。
简单讲，Claude 写代码的能力越来越强，Anthropic 的代码产出速度已经远远超过了传统软件开发的水平。结果，写代码不再是主要瓶颈，反倒是 Git 这些原本为人类程序员设计的基础设施，开始拖慢整个开发流程。
客户端先变了
Git 的一个重要价值，是每个客户端都足够完整。
仓库 clone 到本地以后，即使离线，也能看历史、做 diff、查 blame、创建 commit、切换分支。人的开发环境会长期存在，会断网，也需要随时试验。把数据和计算能力放在本地，换来了很强的自治性。
Anthropic 面对的工作负载刚好相反。
Agent 沙箱和 CI job 本来就运行在在线基础设施里，生命周期往往只有几分钟。一个测试任务也许只需要三个目录；一个自动回滚工具只想知道两个变更的祖先关系；一次代码审查只需要 diff、作者和审批状态。
沿用原来的路径，这些任务仍要准备本地仓库，再从本地对象里算出答案。任务很短，准备仓库却很重。任务一多，同样的文件会在不同节点反复传输，同样的历史关系也会在不同工具里反复计算。
Anthropic 试过 shallow clone、sparse checkout、promisor remote、对象存储快照，也维护过数百个 Git 镜像。这些办法都能减少一部分传输和落盘，但主干变化一快，快照很快落后，镜像要不断追赶，依赖完整历史的工具也难维护。
Scion 改了这个假设：客户端始终在线，服务端掌握权威事实，客户端只为当前任务取需要的数据。
Scion 没有把 Git 命令原样搬到服务器，而是把数据写入、历史查询和文件分发拆成三条路径。
Scion 服务端架构：事实、查询和分发路径分离
一次 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 更新它：只有旧值符合预期，新的主干位置才会生效。
变更被保存，不等于它已经进入主干。
一次 Agent 任务：从按需 checkout 到主干 CAS
历史问题交给服务端
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 和后台维护减少大仓库成本，但调整空间受现有协议和工具行为约束。
Scion、Origin 和 Git 渐进优化：三条路线改的不是同一层
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 也不得不重排第三层。普通团队暂时用不上它，但版本控制的设计前提也在变化。
等新系统上线之后，又进一步提高了 Agent 的工作效率。整个过程就这样循环起来了。服了，这才是真正的 Loop Engineering。
当然，Anthropic 也明确说了，Scion 并不适合绝大多数公司。毕竟，很少有公司像他们这样，每天运行如此大规模的 Agent，产生几万次代码变更。
但 Anthropic 预计，未来 6 到 12 个月，越来越多使用 AI 编程的公司，可能会开始遇到类似的问题。
过去几十年，几乎所有的软件开发工具，都是围绕人类程序员的工作习惯设计的。
人需要离线开发，需要在本地保存代码，需要自己完成大量版本管理操作。这些需求影响了 Git，也影响了整个软件开发流程。
但现在，越来越多的代码开始由 Agent 编写。它们的工作方式、并发规模，以及对工具的需求，都和人类程序员有很大差别。
原来那些看起来非常合理的设计，可能都需要重新考虑了。耳边又响起那句话，AI 时代，所有的软件都会重新做一遍。今天是 Git，接下来可能就是 CI、代码审查、软件测试.....
当写代码越来越便宜，整个软件工程中那些原本不太起眼的环节，可能会一个接一个地成为新的瓶颈。
这些变化也才刚刚开始！！！