AI 科技评论解析：Anthropic 自研 Scion 替代 Git，AI 编码反噬传统工具链

原创郑佳美 2026-10-14 20:50 广东

Anthropic 代码量暴涨，GitHub 密钥扫描又慢又贵，两家被迫改造系统。

作者丨郑佳美

编辑丨岑峰

Git 已经支撑软件开发二十多年，Anthropic 却决定把它换掉。

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

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

几乎同一时期，GitHub 用微调后的 ModernBERT 替换密钥扫描中的通用 LLM 判断。哥伦比亚大学与 Google DeepMind 等机构则通过 BTTF，把芯片仿真波形转换成 SQLite，让 Agent 使用 SQL 排查异常。

Scion 默认在线，BTTF 将波形变成查询接口，GitHub 把高频判断交给分类器。围绕人类开发节奏设计的系统，开始承受 Agent 带来的另一种负载。

Git 的离线能力，为什么成了负担

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 才能追查故障

芯片验证面对的是另一种障碍。RTL 仿真产生的 VCD、FSDB 波形记录大量信号随时间变化的状态，复杂设计的转储可能达到数十 GB，甚至 TB 级。

工程师可以在波形查看器里沿时间轴寻找异常，Agent 若把原始波形转换成文本，上下文很快便被时间戳、信号名和重复跳变占满。追查其他信号，还可能重复读取文件。

另外，人类习惯用眼睛在图表里“大海捞针”，但 Agent 再大的上下文也装不下几十 GB 的物理文件。因此，将这些“死文件”转化为可被 SQL 精准调用的“活接口”，是给 AI 喂数据的最优解。

BTTF 把数据访问交给 SQLite。signal_metadata 保存信号名称、类型和层级等静态信息，signal_changes 记录信号 ID、时间戳和变化后的值，两表通过 ID 关联。

查询某条信号在指定时刻的状态，SQL 找到该时刻之前最近的变化记录，要检查一段时间内的翻转，则按时间窗过滤与聚合。两次跳变之间状态不变，不能把没有新记录误当作未知。

模型只需处理问题与少量返回事件。比如某段握手协议超时，Agent 可以先检索请求与响应信号的变化，再缩小到异常区间，检查时序关系。数据库负责检索，模型决定下一步查什么。查询需对齐信号 ID、时间单位与 RTL 版本。

但把波形搬进数据库，并不会自动消除压力。高频时钟产生密集记录，逐行 INSERT 又有事务成本。BTTF 在摄取时建立波形标识到数据库 ID 的映射，统计信号跳变，结合时钟过滤、无跳变信号裁剪和批量插入。

未裁剪数据库占用 1420 MB，查询约耗时 410.5 毫秒，过滤时钟和无跳变信号后，规模降到 395 MB，耗时降至 94.8 毫秒。若继续删除跳变率低于平均水平的信号，数据库能缩至 185 MB，但活动覆盖率只剩 64.23%。

罕见故障可能恰好出现在几乎不翻转的控制信号上。数据在导入阶段被删除，后面的 Agent 就无法恢复证据。裁剪要服从断言与调试需求。

有了 SQL 接口，BTTF 再安排不同 Agent 分工：Orchestration Agent 拆解任务，Analysis Agent 生成查询，Verification Agent 检查断言并关联 RTL 源码，Evaluation Agent 核查时间范围、字段关系与结果完整性。

例如 ASSERT_KNOWN 发现信号出现 X/Z 未知状态，系统先锁定违规时刻，再向前检查相关操作数的状态，逐步定位可能的模块。SQL 出错还可以修正后继续。

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

为什么密钥扫描换回了分类器

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

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

难点在于 hard negatives：字符串很像密钥，却是无害示例。GitHub 将产品反馈及人工标注、真实仓库中的高召回候选、专门合成的困难负样本组合起来，并按仓库、候选值和关联关系划分训练与评估集，减少相似数据带来的评估偏差。否则模型可能记住文件名，却难以辨认陌生项目中的凭据。

部署时，模型导出为 ONNX 并进行 8 位量化，以降低推理资源开销。阈值还需要结合 Precision、Recall 与线上流量校准：太宽松会带来误报，过于严格则可能放过真实密钥。出现新密钥格式时，还需更新训练集和规则。

相较旧 LLM 管线，新方案的离线 Precision 提高 13%，Recall 提高 19%。线上 A/B 实验显示，Post-push 扫描执行时间中位数下降 86%，模型服务成本下降超过 98%，按仓库所有者加权的告警接受指标提高 11.5%。

这里 98% 指模型服务费用，并非整套安全系统的总成本。分类器也只能判断正则找到的候选，前置规则的覆盖范围仍限制漏报表现。

规则发现线索，分类器完成判断，开放式分析仍可交给通用 LLM，避免每次固定判断承担生成式推理成本。

接下来可能轮到 CI

GitHub 缩短了安全扫描的反馈时间，代码接下来仍要经过构建、测试和部署。Anthropic 在解决源码检出问题后，也遇到了新的麻烦：一轮测试尚未结束，主分支可能又合入数百甚至数千项修改。

继续依赖全局锁会让变更不断积压，放开并发又会带来新的风险，即便某次测试已经通过，它对应的代码状态也可能与准备部署的版本出现差异。

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

Anthropic 已经开始强化合并后测试与部署前验证。对普通团队而言，先完善依赖分析、增量测试和构建缓存，比直接重建版本控制系统更现实。

随着 Agent 持续提高代码产出，软件工程的瓶颈还会沿着交付链路向后移动。代码进入主分支的速度可以越来越快，但构建、测试与部署之间必须保留可靠的验证关系。

未来可能会有越来越多的例子说明，AI 写代码的狂飙突进，最终倒逼着整条软件工程流水线被迫“重做一遍”。工程基础设施的价值，也将更多体现在能否让高速变化的代码持续获得可信的交付依据。

参考链接：https://www.anthropic.com/engineering/redesigning-source-control

上车，带你看遍全球 AI 顶会精华

可独家畅览：

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

扫描上方二维码

或点击「阅读原文」关注专区。

未经「AI科技评论」授权，严禁以任何方式在网页、论坛、社区进行转载！
公众号转载请先在「AI科技评论」后台留言取得授权，转载时需标注来源并插入本公众号名片。

阅读原文

跳转微信打开