Anthropic 为智能体重做源代码管理：Git 架构为何开始承压

导语

当代码由少数开发者维护时，Git 的本地优先模型非常高效：开发者拥有完整或近乎完整的仓库，在本地完成提交、历史查询和检出。但在智能体、研究任务和 CI 同时大规模运行的环境中，同一份代码会被反复检出、传输和解析，传统架构的优势开始转化为基础设施成本。

Anthropic 近期披露了 Scion 的设计。该系统并非简单地给 Git 增加一层代理，而是重新定义了变更集、对象获取和历史查询的执行位置。

核心要点

• 变更量快速上升。 Anthropic 表示，单日合并变更数从 5 月约 2500 个增至 9 月的 3 万多个；CI 每天约执行 2500 万次检出。其单体仓库历史记录接近 100GB，压缩后的工作副本也超过 25GB。
• 服务器端承担主要操作。 Scion 将提交、合并、变基、历史记录和代码追溯查询放到服务器端。客户端只保留容量受限的对象缓存，虚拟化检出则按需获取实际需要的文件。
• 数据模型改为内容寻址。 变更集记录相对第一个父变更集发生变化的文件，并通过内容寻址指针引用 Blob 存储中的压缩内容。变更集创建与引用更新相互分离，减少了接收变更时的跨服务器协调。
• 缓存被设计成基础设施的一部分。 节点守护进程在任务之间共享对象缓存，区域缓存再向权威服务器请求数据。客户端不再协商生成定制 Packfile，而是直接获取缺失的不可变树和 Blob。
• 结果高度依赖内部场景。 Anthropic 称各层缓存命中率超过 99%，CPU 和内存基础设施占用约为此前 Git 镜像的二百分之一，CI 与研究任务的检出速度提升了两个数量级。不过，这些数据来自其内部工作负载，并非 Git 的通用对照测试。

意义与影响

Scion 的关键变化，不只是“把 Git 放到服务器上”，而是重新思考代码仓库中哪些工作必须在客户端完成。历史查询、差异分析和部分写入操作可以通过 API 执行，任务也不必先获得完整工作副本。对于大量使用代码智能体的团队，这意味着可以减少重复检出、重复压缩和重复缓存带来的浪费。

不过，这种收益建立在较强的系统整合能力之上。Scion 需要与定制的代码审查、代码搜索和 CI 系统协同，客户端离线独立性也有所牺牲。服务器、区域缓存和权威存储一旦出现可用性问题，影响范围可能大于单个开发者的本地仓库。

因此，Scion 更值得被看作一组面向高并发代码工作负载的架构方案，而不是所有团队都应采用的新 Git。Anthropic 也提到，Mononoke 及其 Bonsai 数据模型已经率先采用了其中许多技术。对现有 Git 平台而言，更现实的借鉴方向包括完善服务器端 API、改进对象获取协议，以及让不可变数据在任务之间安全共享。

InfoQ 中文