Anthropic自建Scion替代Git，GitHub用分类器取代LLM：AI编码倒逼工具链重构

事件概述

随着大语言模型（LLM）和AI Agent在软件开发中的深度应用，代码产出速度呈指数级增长，导致依赖人类开发节奏设计的传统工具链出现严重性能瓶颈。近期，头部企业 Anthropic 和 GitHub 以及学术研究机构分别针对版本控制、安全扫描和芯片验证环节进行了系统级改造，旨在适应 AI 编码带来的高并发、高吞吐负载。

核心信息

1. Anthropic 弃用 Git，自研 Scion 应对海量代码合并

背景与挑战：
Anthropic 的 CI 系统和 Agent 沙箱需要极高的代码读取频率。2026年9月，其日均代码合并量从5月的约2,500项激增至超过30,000项，CI 系统每日需执行约2,500万次代码检出。传统的 Git 分布式设计虽支持离线操作，但在始终联网的自动化场景中，克隆完整仓库、同步对象和查询历史带来了巨大的计算和存储开销。主分支历史接近100GB，若每次检出都获取完整副本，理论流量将超过600PB。

解决方案 - Scion：
Anthropic 投入7名工程师历时5个月开发了新的版本控制系统 Scion，并于今年完成核心仓库迁移。Scion 的核心设计哲学是牺牲离线自治以换取在线高性能：

• 架构转变： 将提交创建、合并、变基及历史查询移至中心服务，客户端仅作为轻量入口监测文件变化和维护缓存。CI 作业可直接调用 API 计算 diff，无需完整检出。
• 数据模型： 采用基于预写日志的 changeset 记录文件修改，通过内容寻址指针引用数据。竞争集中到分支引用移动时的 compare-and-swap 操作，允许 Agent 并发生成变更。
• 性能提升： 引入 Spanner 数据库和对象存储，配合高命中率（>99%）的缓存机制。迁移后，CPU 和内存需求缩小约200倍，检出时间从分钟级降至秒级，CI 释放了约25%的 CPU 容量。

2. GitHub 密钥扫描：从 LLM 回归高效分类器

背景与挑战：
GitHub 原有的 Push Protection 功能使用通用 LLM 判断高熵字符串是否为真实凭据。然而，随着候选字符串数量增加，LLM 的推理费用和延迟急剧上升，严重影响开发体验。此外，区分“真实密钥”与“测试数据/占位符”存在大量 Hard Negatives，通用 LLM 在此类批量分类任务中效率低下。

解决方案 - ModernBERT 分类器：
GitHub 保留了正则表达式作为初步筛选入口，将后续判断交给微调后的 ModernBERT 模型：

• 模型优化： 使用包含产品反馈、人工标注及合成困难负样本的数据集进行训练，确保模型能泛化到新项目。模型导出为 ONNX 格式并进行8位量化，以降低推理资源开销。
• 效果显著： 相比旧管线，新方案离线 Precision 提高13%，Recall 提高19%。线上 A/B 实验显示，Post-push 扫描执行时间中位数下降86%，模型服务成本下降超过98%，告警接受指标提高11.5%。

3. 学术研究 BTTF：将芯片波形转化为 SQL 接口

背景与挑战：
芯片仿真产生的 VCD/FSDB 波形文件体积庞大（可达 TB 级），且包含大量随时间变化的信号状态。传统的人工查看方式难以被 AI Agent 直接利用，因为原始文本上下文会迅速耗尽模型的窗口限制，且缺乏结构化索引。

解决方案 - BTTF (Binary Trace to Table Format)：
哥伦比亚大学与 Google DeepMind 等机构提出 BTTF 技术，将波形数据转换为 SQLite 数据库：

• 数据结构： signal_metadata 存储静态信息，signal_changes 记录信号 ID、时间戳和值的变化。通过 SQL 查询即可精准定位特定时刻的信号状态或时序异常。
• 数据裁剪： 为平衡查询速度与覆盖率，BTTF 结合时钟过滤和无跳变信号裁剪技术。在保留关键活动信号的前提下，可将数据库规模从1420MB压缩至185MB，查询耗时从410.5ms降至94.8ms。
• Agent 协作： 构建多 Agent 系统（Orchestration, Analysis, Verification, Evaluation），由分析 Agent 生成 SQL 查询，验证 Agent 检查断言。在实验中取得95.33%的执行准确率，比单 Agent 质量评分提高17.3%。

值得关注

CI/CD 流水线成为下一个瓶颈：
随着源码管理工具的升级，软件工程的瓶颈正向后转移。Anthropic 发现，在主分支高频合并的背景下，全局锁会导致变更积压，而放开并发则可能引发版本不一致风险。未来的 CI 系统需要解决如何在高频变更中保持构建缓存的有效性、关联测试结果与具体提交，并确保部署版本的验证状态可信。这预示着整个软件工程交付链路可能需要像版本控制系统一样，经历一次彻底的“重做”。