30,000 次日合并之后：Anthropic 抛弃 Git，智能体开始逼迫工具链重建

10 月 13 日，Anthropic 在一篇工程博客里公开了一件不寻常的事：它用自研版本控制系统 Scion 替换了整个工程 monorepo 里的 Git。原因不是 Git 有 bug，而是一个 20 年都没变过的前提被打破了——写代码的主力，不再是人。

数字：从 2,500 到 30,000 的四个月

Anthropic 公布的数字来自它自己的工程统计：今年 5 月，日均合并约 2,500 次；到 9 月涨到 30,000 次以上，四个月翻了 12 倍。主干分支历史体积接近 100GB，CI 每天要执行约 2,500 万次 checkout——若全走原生 Git 协议，据测算一天需要 600PB 以上的传输量。

Anthropic 承认这都是自报数据，外部无法独立核验。但另一点是公开的行业共识：Claude 写下了 Anthropic 绝大多数生产代码；公司曾运营几百个内部 Git 镜像分担压力，"这帮我们撑了一段时间"，但镜像越来越难维护，种子镜像与主干尖端的落差不断扩大。5 个月前，一个 7 人小组开始动手；5 个月后，迁移完成。

Scion 的核心设计：假设客户端永远在线

Scion 的设计哲学一句话概括：抛弃 Git 的分布式假设，默认客户端永远在线。

Git 的一切都围绕"本地优先"。Scion 反其道而行：所有 commit、rebase、merge 都发生在服务器端，客户端只保留有界的本地缓存；blame、history、diff 以 API 形式暴露，CI 作业常常连一次克隆都不需要；工作单元从"带 ref 的提交"变成预写日志里的"变更集"，除了主干和发布分支，ref 被有意弱化。

真正值得琢磨的是它放弃了什么。据 Anthropic 自报：相比 Git 镜像集群，Scion 占用缩小约 200 倍，checkout 从分钟级变成秒级，CI 单独腾出 25% 的 CPU 容量。但代价是真实的：传统合并队列"在智能体规模下没什么意义"，它无法复刻有效的全局仓库锁，于是把赌注押在"合并后测试 + 部署前测试"上，坦然接受并发修改可能冲突——因为 Claude 修复冲突的速度，通常比人类发现冲突还快。这不是免费午餐，而是一次用正确性前置换取吞吐量的权衡。

不止是 VCS：整个"检查—存储—合并"管道都在被重写

Scion 只是这周故事的一部分。把镜头拉远，过去两周里整个开发工具链的"管道层"都在动：

• GitHub Agentic Autofix 正式 GA：开发者把代码扫描告警指派给 Copilot，它自动起草修复、反复运行 CodeQL 直到告警关闭，再开一个草稿 PR 等人复核。审查和合并的入口，正在从人手交给智能体。
• Cursor 的 Origin：从代码托管侧切入，开放应用市场，Cloudflare、Vercel、Linear、Sentry、CodeRabbit、Semgrep 等 21 个应用首批入驻，凑齐的正是 GitHub 在卖的那一套组件。
• Google 的例子最有画面感：Chrome 团队用 Gemini 4 Argon 完成了一次横跨 Chromium 数百个文件的重构，"用了几周而不是几个月"。
• GitLab 则代表另一条路线：同一周发布《为智能体软件工厂扩展 Git》，主张在 Git 架构内吸收智能体负载。

两条路线会共存很久，但方向一致：本地克隆这个"工作单元"假设正在松动。

工程师的新工作：对 Claude 说"不"

这篇博客里最耐人寻味的一句，与架构无关。Anthropic 说，工程师们的主要工作之一，是经常对 Claude 说"不"——模型面对假想问题会过度工程化，而人需要按住它。

这揭示了真正的重心转移：审查从"逐行读代码"变成了"审查变更的意图"；公司内部用名为"superfans"的智能体监控各组件；甚至 Scion 那条内存降到 1/20、速度提到 4 倍的历史迁移流水线，本身也是内部模型 Claude Mythos Preview 重写的。工具在写工具，审查者在审查审查者。

观点：生成便宜之后，集成成为成本中心

Anthropic 工程博客里那句最该被记住的话是："写代码不再是瓶颈，而为人类规模设计的开发者基础设施——版本控制、构建和 CI——才是。"

这句话对绝大多数团队不适用：你大概率没有 30,000 次的日合并，Anthropic 自己也强调 Scion"绝不是 Git 的通用替代品"。Hacker News 上的质疑值得记住——把所有提交集中到服务器，等于放弃了 Git 最核心的自由：本地攒历史、随意改、随时扔。

但方向很难否认：当生成接近免费，成本就从"写"转移到了"集成"——checkout、合并、测试、评审、部署。模型每强一点，管道上的压力就重一分。

对普通团队的建议是务实的：先量一量自己的 agent checkout 时间。如果它是秒级的，Scion 的故事与你无关；如果并行智能体频繁撞上合并冲突，先用 Git 已有的工具——sparse checkout 配每个智能体一个 worktree，能解决大部分问题。

本周的真正新闻不是某个模型，而是"模型之后"的那一整层：代码已经是智能体写的了，现在轮到承载它们的管道被重写了。