每天3万次合并，Anthropic把Git换掉了

Anthropic 把 Git 换掉了。为了让 Claude 持续生成的代码顺利进入开发流程，7 名工程师花了 5 个月，开发出版本控制系统 Scion，并将核心代码仓库迁移过去。

推动这次改造的是一组快速膨胀的数字。今年 5 月，Anthropic 每天平均合并约 2500 项代码变更，到 9 月已超过 3 万项，仅 CI 系统每天就要执行约 2500 万次代码检出。写代码的速度上来了，准备仓库、同步对象和查询历史却越来越费机器。

Git 的分布式设计让工程师克隆仓库后，即使断网也能提交、合并、查看历史。但 Anthropic 大量读取代码的任务是始终联网的 CI 作业和 Agent 沙箱，运行几分钟便销毁，可能只需要几个文件、一份 diff，或确认两个提交的祖先关系。为了这些操作准备本地仓库，重复成本越来越高。

规模压力可以用具体数字衡量：Anthropic 主分支历史接近 100 GB，压缩工作副本超过 25 GB。若每天 2500 万次检出分别获取完整副本，理论流量会超过 600 PB。公司虽用浅克隆、稀疏检出、快照和数百台 Git 镜像，但镜像仍要同步、快照会过期，历史查询还需补齐对象。仓库越活跃，维护成本越高。

Scion 的思路是把客户端缩成轻量入口。提交创建、合并、变基与历史查询放到中心服务，本地仅监测文件变化、维护少量缓存，需要工作目录时按需展开。CI 若只想计算 diff，可以直接调用 API，无须完整检出。这牺牲了离线自治，却减少重复初始化。

提交格式也随之改变。Git commit 指向描述仓库状态的目录树，Scion 的 changeset 则以预写日志条目记录相对首个父提交修改过的文件，通过内容寻址指针引用数据。创建 changeset 无须生成 Git packfile，也不用立即移动共享分支，只有 main 等引用更新时，系统才对 Spanner 中的单行记录执行 compare-and-swap。Agent 可以并发生成变更，竞争集中到分支引用移动时。

历史查询仍有难题：增量记录无法直接回答某行是谁改的、文件经历过什么。Scion 为 blame、路径历史与提交图跳表维护 derived data，按父提交关系预计算，或等查询发生后再生成。写入与历史分析可以独立扩展。

检出时，scn 客户端从目标目录树开始，只请求缺失的 tree 和 blob。请求依次经过节点上的 scion-daemon、区域 scion-cache，再由 scion-server 回源到 Spanner 或对象存储。对象写入后不可变，缓存能够跨任务复用，减少协商、压缩及反复传输。Anthropic 称缓存命中率超过 99%，并限制故障时的回源流量。

迁移后的收益体现在资源账上：Scion 相较旧 Git 镜像体系的 CPU 和内存需求约缩小 200 倍，检出从分钟级降至秒级，CI 释放约 25% 的 CPU 容量。这里的 200 倍说的是基础设施资源占用，并非 Git 操作整体提速。Anthropic 还同步建设 Antique 代码评审、源码搜索、IAM 和批量合并工具，以适配新协议。在线服务的维护也成了新成本。

同一时期，另外两个系统也在为 Agent 的负载改造自己。GitHub 用微调后的 ModernBERT 替换密钥扫描中的通用 LLM 判断；哥伦比亚大学与 Google DeepMind 等机构则通过 BTTF，把芯片仿真波形转换成 SQLite，让 Agent 使用 SQL 排查异常。

芯片验证面对的是另一种障碍。RTL 仿真产生的 VCD、FSDB 波形记录大量信号随时间变化的状态，复杂设计的转储可能达到数十 GB，甚至 TB 级。工程师可以在波形查看器里沿时间轴寻找异常，Agent 若把原始波形转换成文本，上下文很快便被时间戳、信号名和重复跳变占满。

BTTF 把数据访问交给 SQLite。signal_metadata 保存信号名称、类型和层级等静态信息，signal_changes 记录信号 ID、时间戳和变化后的值，两表通过 ID 关联。查询某条信号在指定时刻的状态，SQL 找到该时刻之前最近的变化记录；要检查一段时间内的翻转，则按时间窗过滤与聚合。两次跳变之间状态不变，不能把没有新记录误当作未知。

把波形搬进数据库，并不会自动消除压力。高频时钟产生密集记录，逐行 INSERT 又有事务成本。BTTF 在摄取时建立波形标识到数据库 ID 的映射，统计信号跳变，结合时钟过滤、无跳变信号裁剪和批量插入。未裁剪数据库占用 1420 MB，查询约耗时 410.5 毫秒；过滤时钟和无跳变信号后，规模降到 395 MB，耗时降至 94.8 毫秒。若继续删除跳变率低于平均水平的信号，数据库能缩至 185 MB，但活动覆盖率只剩 64.23%。罕见故障可能恰好出现在几乎不翻转的控制信号上，数据在导入阶段被删除，后面的 Agent 就无法恢复证据。

研究团队在 4.2 GB 波形、18450 个信号和 150 条专家标注查询的实验中，取得 95.33% 的执行准确率。Multi-Agent 质量评分比单 Agent 提高 17.3%，平均延迟也增至约 1.96 倍，静态 SVA 检查准确率为 84.62%。方案可支持后仿真分析，但持续摄取与复杂归因仍需验证。

GitHub 的改造对象是高熵字符串——它可能是真实凭据，也可能是测试数据、占位符或校验和。正则表达式能快速找到可疑格式，却不擅长判断代码上下文；通用 LLM 可以帮助区分，但候选越多，推理费用和延迟便不断累积。对于需要在代码提交被接受前给出结果的 Push Protection，这种等待会直接影响开发体验。

GitHub 保留正则作为候选入口，将后续判断交给微调后的 ModernBERT。它读取候选字符串、密钥类型、变量名、文件路径和附近代码，输出风险分类得分，再由阈值决定是否告警。编码器经过前向计算就能返回类别，不需要像生成式 LLM 那样逐 token 输出解释，适合批量处理同类请求。部署时，模型导出为 ONNX 并进行 8 位量化，以降低推理资源开销。

相较旧 LLM 管线，新方案的离线 Precision 提高 13%，Recall 提高 19%。线上 A/B 实验显示，Post-push 扫描执行时间中位数下降 86%，模型服务成本下降超过 98%，按仓库所有者加权的告警接受指标提高 11.5%。这里 98% 指模型服务费用，并非整套安全系统的总成本。分类器也只能判断正则找到的候选，前置规则的覆盖范围仍限制漏报表现。

Anthropic 在解决源码检出问题后，也遇到了新的麻烦：一轮测试尚未结束，主分支可能又合入数百甚至数千项修改。继续依赖全局锁会让变更不断积压，放开并发又会带来新的风险，即便某次测试已经通过，它对应的代码状态也可能与准备部署的版本出现差异。

这意味着 CI 接下来要处理的，是验证结果如何在高频变更中保持有效。构建缓存需要识别源码与依赖关系的变化，测试记录必须关联具体提交和构建产物，系统还要判断哪些结果能够复用、哪些修改会使此前的验证失效。对于依赖关系复杂的 Monorepo，仅仅增加测试机器，很难解决并发修改带来的版本一致性问题。

Anthropic 已经开始强化合并后测试与部署前验证。对普通团队而言，先完善依赖分析、增量测试和构建缓存，比直接重建版本控制系统更现实。随着 Agent 持续提高代码产出，软件工程的瓶颈还会沿着交付链路向后移动——代码进入主分支的速度可以越来越快，但构建、测试与部署之间必须保留可靠的验证关系。