没想到，Anthropic 已经把内部的版本控制系统，从 Git 迁移到了自己开发的 Scion。
看到这个消息，我非常震惊。因为 Git 几乎已经成了整个软件开发行业的标配，绝大多数程序员每天都在用。
刚毕业那会，我用的还是 SVN，后来切换到了 Git，一用就是十几年。哎，我以前还真没想过，有一天连 Git 都会被颠覆掉。
这周，Anthropic 专门写了一篇技术博客，详细解释了这件事情的来龙去脉。
简单讲，Claude 写代码的能力越来越强，Anthropic 的代码产出速度已经远远超过了传统软件开发的水平。
结果，写代码不再是主要瓶颈，反倒是 Git 这些原本为人类程序员设计的基础设施，开始拖慢整个开发流程。
今年 5 月，Anthropic 平均每天合并大约 2500 次代码变更。到了 9 月，这个数字已经超过了 3 万次。
短短四个月，增长了 12 倍以上。
这背后的原因我们都知道，越来越多的 Coding 任务已经交给 AI 完成。大量 Agent 可以同时修改代码、修复 Bug、运行测试，所以整个公司的代码产出速度都在快速增长。
但问题来了。
过去，一个程序员一天能提交多少次代码，终究是有上限的。现在，大量 Agent 可以同时工作，一天产生成千上万次代码变更。
每一次变更，都需要获取代码、查看历史、比较差异、进行合并，还可能触发一系列自动化测试。
当这些操作的规模增长十几倍，原来习以为常的几秒钟、几十秒钟的等待，累积起来就成了巨大的时间和计算资源消耗。
而且 Anthropic 的代码仓库本身也大得惊人。
他们的 Monorepo，光是主分支的历史记录就接近 100GB，压缩后的工作副本也超过了 25GB。每天光是在 CI 环境里，就需要执行大约 2500 万次代码检出操作。
这还不包括开发环境、Agent 沙箱和研究任务。
如果每次都完整获取代码，理论上每天需要传输超过 600PB 的数据。
Anthropic 之前已经使用了 Git 的各种优化方案，包括浅克隆、稀疏检出、内部镜像、仓库快照等等。最多的时候，甚至维护了几百台 Git 镜像服务器。
但随着代码变更越来越频繁，这套系统也越来越难维护。
仓库快照经常跟不上最新代码，客户端需要补充获取的数据越来越多，很多依赖历史记录的操作也变得麻烦无比。
继续增加服务器，已经很难从根子上解决问题。治标不治本。
所以，Anthropic 开始重新回到问题的原点。如果今天从头设计一套版本控制系统，主要给 AI Agent 使用，还需要遵循 Git 当年的设计吗？
这里我解释一下 Git 的设计。
Git 是一个分布式版本控制系统。相比上一代的 SVN，它有个非常重要的特点，就是程序员可以在自己的电脑上保存一份完整的代码仓库，包括历史记录。
这样，即使在家里，没有连公司的远端仓库，也可以查看历史、修改代码、提交版本，很多操作都能在本地完成。
放在过去，这肯定是非常好的设计。
但 Anthropic 发现，现在访问他们代码仓库的，绝大多数已经是 Agent 和各种自动化任务。而这些客户端基本上始终联网。
既然这样，为什么还需要让每个 Agent 都在本地维护大量代码和历史数据？
比如，一个 Agent 只是想修改某个文件里的几行代码，它可能得先准备工作副本，获取相关代码和历史信息，然后才能开始干活。
但它真正需要的，可能就那么几个文件。
还有一些任务，甚至连代码文件本身都不需要。比如查询某个文件是谁修改的、两次提交之间有什么区别，这些完全可以让服务端直接返回结果。
这就是 Anthropic 开发 Scion 时，非常重要的设计变化。让客户端尽可能轻量，然后把大量版本控制操作交给服务端完成。
比如一个 Agent 想修改某个目录里的代码，Scion 就只需要给它提供相关的文件。其他不需要的代码，不用下载。
如果 Agent 想查询代码历史、比较两个版本，直接调用服务端 API 就可以了。包括 Commit、Merge、Rebase 这些操作，也都可以由服务端完成。
这样一来，每个 Agent 就不用重复维护庞大的仓库，也省去了大量本地计算。
但这又带来了新的问题。
如果成千上万的 Agent 都去请求服务端，服务器岂不是很容易被压垮？
所以，Anthropic 又重新设计了整套存储和缓存架构。简单讲，Scion 每次提交只记录发生变化的文件，文件内容单独存储，通过哈希进行识别和复用。
同时，它还使用了多级缓存。
同一台机器上的 Agent，可以共享本地缓存。如果本地没有需要的数据，就向区域缓存请求。区域缓存也没有，才会继续向后面的服务请求。
这套架构的每一层缓存，命中率都超过了 99%。
而且，Scion 的整个仓库是分布式存储的，即使是服务端，也不需要在某台机器上保存一份完整的代码仓库。需要增加处理能力时，就可以通过增加服务器来扩容。
最终效果非常夸张。原来在 Agent 环境下，创建一个新的 Worktree，需要 7.1 分钟，现在只需要 5.1 秒，提速 84 倍。拉取最新代码，从 3 分钟降低到了 9 秒。
一次代码变更中，Agent 花在版本控制上的总时间，从 34 分钟降低到了 3.7 分钟。整个 Scion 基础设施的 CPU 和内存需求，相比之前的 Git 镜像系统，缩小了 200 倍。
Anthropic 估算，光是 Agent 的版本控制操作，每天就能节省大约 1.1 万个 Agent 小时。
以前，一个 Agent 开始工作之前，可能需要花几分钟准备环境、同步代码。现在，很多操作几秒钟就完成了。这是为 Agent 原生设计的版本控制系统。
还有一个特别有意思的细节。
Anthropic 完成 Scion 的开发和整个仓库的迁移，只用了 5 个月，团队一共只有 7 个人。
而且，这 7 个人他们还重新开发了一个叫 Antique 的代码审查工具，以及代码搜索、权限管理等一系列配套系统。
Anthropic 说，如果放在过去，这样一套复杂的基础设施，可能需要更多工程师，花几年时间才能完成。
但这次，他们大量使用了 Claude 参与开发。
比如他们原本有一套工程师手写的 Git 到 Scion 的数据导入程序，大家觉得已经写得很好了。
后来，团队让 Claude Mythos Preview 重新实现了一遍，结果内存占用降低了 20 倍，运行速度提升了 4 倍，而且还保留了原来代码中很多隐含的约束。
Claude 写代码越来越快，导致 Git 这样的基础设施开始出现瓶颈。然后 Anthropic 又借助 Claude 的能力，用 7 个人、5 个月的时间，重新开发了一整套基础设施。
等新系统上线之后，又进一步提高了 Agent 的工作效率。整个过程就这样循环起来了。服了，这才是真正的 Loop Engineering。
当然，Anthropic 也明确说了，Scion 并不适合绝大多数公司。毕竟，很少有公司像他们这样，每天运行如此大规模的 Agent，产生几万次代码变更。
但 Anthropic 预计，未来 6 到 12 个月，越来越多使用 AI 编程的公司，可能会开始遇到类似的问题。
过去几十年，几乎所有的软件开发工具，都是围绕人类程序员的工作习惯设计的。
人需要离线开发，需要在本地保存代码，需要自己完成大量版本管理操作。这些需求影响了 Git，也影响了整个软件开发流程。
但现在，越来越多的代码开始由 Agent 编写。它们的工作方式、并发规模，以及对工具的需求，都和人类程序员有很大差别。
原来那些看起来非常合理的设计，可能都需要重新考虑了。耳边又响起那句话，AI 时代，所有的软件都会重新做一遍。今天是 Git，接下来可能就是 CI、代码审查、软件测试.....
当写代码越来越便宜，整个软件工程中那些原本不太起眼的环节，可能会一个接一个地成为新的瓶颈。
这些变化也才刚刚开始。
最后，向大家推荐我们年底的 AI Maker Summit 大会。
一天 33 个 Talk，会聚焦在 Agent 创业产品、Harness Engineering、FDE、Jev 决策模型、GEO、Personal Agent、AI Coding、AI 视频等等重点方向上，给大家带来最干货的分享。
2026 年，还剩下不到 3 个月的时间。这一年，想必大家每个人都是忙忙碌碌的。昨天我和同事还感慨，怎么感觉夏天还没过够，突然就秋天了，秋高气爽的。
也许年底，我们该给自己一天放空的时间，让自己了解下目前这个行业里真正的 Maker 都在讨论什么，都在做什么。
