Anthropic 之前发了一篇博客，讲了一套全新的源码管理架构——叫 Scion。核心 idea 很激进：别让人在本地克隆整个仓库了，让服务器持有完整历史，客户端只按需拉需要的东西。

当时很多人看了个热闹。现在有人真的用 Rust 从零实现了一套，开源了，项目名叫 Scion。

注意，这不是 Anthropic 官方做的，是网友独立复刻的。但恰恰是"独立"这件事，让它有意思——说明这套架构的思想已经超出了某个公司的范畴，开始被社区当作一种可行的方向来验证。

目前跑通的工作流挺完整：服务端提交、稀疏检出、远程历史查询、并发合并，一条链路都跑得通。

但真正值得聊的不是"它跑通了"，而是它为什么要这么设计。

传统的 Git 工作流是"本地优先"的——你 clone 一个仓库，本地就有完整的历史记录，commit、branch、merge 全在本地完成，最后 push 到远程。这设计是为人类开发者服务的：你经常需要离线工作，需要快速本地操作，需要随时查看任意历史版本。

但 Scion 面向的不是人，是持续在线的 Agent。

Agent 不需要离线操作，它需要的是一次只拿到当前任务相关的代码和状态。让它去 clone 一个几十 GB 的仓库去改三行代码？纯属浪费。

所以 Scion 把职责彻底倒过来了：服务器持有完整历史，负责 Commit、Rebase、Merge 这些重活；客户端轻得像个小尾巴，按需获取，用完就走。

这不是小修小补的优化，是从"面向人类开发者"到"面向持续在线 Agent"的范式切换。

性能数据也印证了这种设计方向的价值。作者在 Apple M4 Pro / 24GB 的机器上做了基准测试：

[微风]目录导入（Import）：1k 文件场景 Scion 比 Git 快 7.8 倍，10k 文件场景快 11.5 倍——把文件从磁盘灌进版本库，服务端批量处理确实碾压客户端逐个 stat

[送自己一朵花]完整检出（Full checkout）：10k 文件场景快约 1.4 倍——服务端预打包+客户端按需拉，比 Git 的 packfile 传输还是略优

[汤圆]但单文件提交：Scion 慢于 Git——客户端本地没有完整历史，每次 commit 都要扫描工作树+上传 blob，开销自然上来

[彩虹]10k 文件规模的稀疏检出：Scion 也略逊于 Git——Git 的 cone-mode sparse-index 优化得太狠了

也就是说，Scion 不是全面碾压 Git 的"下一代 Git"，它是在特定工作负载下找到了优势区间——批量导入、按需检出这类 Agent 高频操作。Git 在交互式提交、局部查询上依然很强。

这其实暗示了一个更深层的趋势：版本控制工具可能不再是一个通用工具了，而是会按使用场景分化——人类继续用 Git，Agent 用 Scion 这类服务端优先的系统。

作者也说了，当前 v1 只支持单 monorepo 和 Unix 客户端，还没到 Anthropic 那种规模。接下来要补的能力包括：区域缓存、Daemon 快照引导、虚拟化检出、文件系统 Watcher、复制检测等。

说白了，这还是一个正在成长中的实验性实现，但方向是对的——当 AI Agent 越来越深度地参与代码工程，版本控制的基础设施也得跟着变。

项目地址：github点com/CarterT27/scion