Anthropic 重构版本控制：Scion、智能体规模与工程师的新角色

摘要

随着 AI Agent 集群在研发全流程的深度介入，Anthropic 报告其内部单一代码库（Monorepo）的日均合并量从 2,500 次飙升至超过 30,000 次，使得原本为“人类规模”设计的 Git 分布式基础设施成为最大的研发瓶颈。为此，一个 7 人工程团队在 Claude Mythos Preview 和 Claude Tag 的协助下，仅用 5 个月便完成了自研集中式版本控制系统 Scion 与配套工具链（如代码审查工具 Antique）的构建与全量迁移，将基础设施资源占用降至原来的 1/200，检出速度提升了两个数量级。这一工程实践在 Hacker News 社区引发了激烈交锋：讨论焦点不仅涵盖集中式 VCS 选型与 Monorepo 架构的合理性，更深入到了 AI 时代版本控制的存废、日均三万次合并究竟是生产力奇迹还是“AI 垃圾代码（Slop）”的狂欢，以及人类工程师从“编写代码”向“意图审查与踩刹车”的角色嬗变。

导读

Scion 的设计起点是一个特殊的工作负载：客户端大多是持续在线的智能体和自动化任务，代码检出与合并的频率远超传统团队。理解这次重构，可以依次关注三个问题：哪些 Git 的设计前提发生了变化，集中式服务如何分担数据与计算，以及写代码变快之后，工程判断与审查应当如何调整。下文的规模与性能数字来自 Anthropic 对自身系统的报告，社区评论则提供了不同的工程与职业视角。

原文核心观点

在 Anthropic 的叙述中，编写代码本身已不再是构建系统或推进研究的瓶颈，真正的瓶颈在于那些为“人类规模”设计的底层开发者基础设施，尤其是版本控制、构建系统和持续集成（CI）。从 2026 年 5 月到 9 月，内部单一代码库每天合并的代码变更从 2,500 次激增至 30,000 次以上，主分支历史逼近 100 GB，压缩后的工作副本超过 25 GB，仅 CI 每天就要执行约 2,500 万次代码检出。Git 的核心设计初衷是服务于分布式的离线工作，要求每个克隆都是完整自包含的仓库；然而，当客户端几乎全部变成永远在线的 AI Agent 和自动化任务时，Git 的分布式特性反而成了扩展的绊脚石。即便动用数百个内部 Git 镜像、浅克隆、稀疏检出和对象存储快照，也越来越难以应付增长；若采用朴素的完整拉取方式，每天的流量需求会超过 600 PB，高频合并也加剧了同步压力。因此，面向 Agent 规模的版本控制必须重构底层假设：坚持“客户端永远在线”与“客户端—服务端非对称”原则，将历史追溯、Blame 计算、提交与合并移交服务端并开放 API，使本地工作副本成为纯粹按需拉取、稀疏甚至虚拟化的可选项。

基于上述原则构建的 Scion 摒弃了 Git 的打包文件（Packfiles）和相应的锁与协调开销，以写入预写式日志（WAL）的“变更集（Changeset）”作为基本工作单元，仅记录相对于父节点的变更文件列表及指向云端对象存储的内容寻址指针，并将全局分支引用（Refs）的更新简化为 Spanner 数据库单行上的比较并交换（CAS）操作。对于文件修改历史、Blame 和提交图跳表等高开销查询，系统通过一套通用的递归机制按需或提前计算“派生数据（Derived Data）”。在读取与检出链路上，scn 客户端不再与服务端协商本地已有对象，而是按需递归请求缺失的目录树与数据块；配合节点级守护进程（scion-daemon）、区域级内存缓存（scion-cache）与权威服务端（scion-server）构成的三级内容寻址缓存拓扑，每一层均实现了 99% 以上的缓存命中率。据团队报告，这套高度水平扩展的架构无需任何仓库维护操作，不仅将检出速度从分钟级压缩至秒级，释放了 25% 的 CI 算力，更将整体基础设施的 CPU 与内存开销缩减为原先 Git 镜像集群的 1/200。

这并非仅仅是一次基础设施迁移，更是“Agent 规模”软件工程范式的缩影。按团队的说法，正是 Claude 的编码能力制造了这场规模危机，也正是它帮助一个仅 7 人的小团队在 5 个月内完成了过去需要更多工程师耗费数年才能交付的 Scion、代码审查界面 Antique 及全套权限与搜索系统。例如，内部早期的 Claude Mythos Preview 在接到重写请求后，没有进一步指令便重写了手写的 Git-to-Scion 数据导入管道，在保留所有隐式不变量的同时将内存占用降低至原来的 1/20、速度提升至 4 倍，并在日常迭代中持续挖掘出复杂的算法级优化与完备的仿真测试。在这一新范式下，团队成员认为 Claude 在纯写代码上已强于自己，但人类工程师的核心价值并未贬值，而是转向了高层系统权衡、抑制对抗性审查带来的过度工程化，以及高频地对破坏系统约束的 Agent 说“不”。人类仍审查每项变更，但关注点转向变更的“意图（Intent）”，而非逐行阅读代码；运维模式也演进为由 Claude Tag 驱动的各组件专属“超级粉丝（Superfans）”全天候监控遥测数据。面对高频并发合并，传统的全局合并队列锁被淘汰，取而代之的是合并后、部署前的自动化测试；团队认为，即使发生语义冲突，Claude 也能够以超越人类察觉的速度识别并修复。

讨论区观点概述

一、在 AI 高频迭代时代，是否还需要版本控制？

激进派的“代码流体论”：如果每天有 3 万次合并且缺乏人类逐行监管，软件已处于永恒流动的构建中，传统版本控制系统（VCS）失去了意义，不如直接对生产环境做按小时的快照（Checkpoints）。甚至有人类比“移动目标防御（MTD）”，认为如果代码每秒都在被 Agent 重写，安全漏洞在被黑客利用前就已经被重构消失了。
务实派：Agent 比人类更需要 VCS：Agent 极易陷入“修改—报错—回滚—再次错误修改”的死循环，极度依赖提交历史、git blame 和架构决策记录（ADR）来获取上下文并节省加载完整大文件的 Token。此外，多 Agent 并发写入必须依赖分支隔离，且 Agent 频繁把代码改崩，必须依靠确定性的回滚机制与 git bisect 排查根因。
架构演进视角：部分开发者指出，当前的 Agent 框架（Harness）已经在底层数据库高频保存状态快照，再套一层 Git 确实存在状态冗余，未来或将诞生专为 Agent 设计的原生状态与冲突协调底座。

二、技术选型之争：自研 Scion、Perforce，还是拆分 Monorepo？

“重新发明 Perforce”的质疑：不少资深工程师指出，Scion 的纯在线集中式架构本质上就是 Perforce（P4）或 SVN 的翻版，并认为日均 3 万次提交，约合几秒一次，对配置得当的 Perforce 而言完全可控。但前 Google 工程师反驳称，Google 当年正是因为 Perforce 扩展性见顶，需要依赖配有一百多万美元 DRAM 的天价定制主机，才被迫自研 Piper，且 P4 许可证昂贵、生态封闭。
Monorepo 是否属于自找麻烦：许多评论认为，100 GB 历史和高频合并冲突完全是执着于 Monorepo 导致的，拆分为微服务与独立包即可迎刃而解。
官方团队回应：Anthropic 工程师 nickg-anthropic 在评论区解释，保留 Monorepo 的核心价值在于统一工具链底座与 跨项目的原子级提交（Atomic Commits），避免跨数百个子仓库的漫长迁移。对于并发冲突，系统严禁任何 文本冲突（Textual Conflicts），而语义冲突（Semantic Conflicts）则交由 Claude 以超越人类察觉的速度自动识别并修复。

三、日均 30,000 次合并：生产力奇迹，还是“AI 垃圾代码”的狂欢？

代码抖动（Code Churn）批评：传统工程派强烈质疑一家千人规模的公司日均合并 3 万次代码的合理性，认为这并非创造了等量的业务价值，而是失控的代码抖动，相当于用无休止的暴力穷举和局部梯度下降代替深思熟虑的架构设计：“前 6 次重构都是错的。”
“挖掘机理论”反驳架构无用论：针对“AI 重构几乎免费，因此无需考虑长期架构，只要今天能跑就行”的观点，反对者比喻道：挖掘机挖坑比 10 个拿铲子的人快得多，但如果用挖掘机把土堆错了地方整整一周，哪怕再用挖掘机去清理那座大山，依然要消耗海量的 Token 和时间。
外部产品体验的反差讽刺：不少用户吐槽这种“内部基建狂魔”与“外部产品粗糙”的割裂感，例如每天合并 3 万次代码，但 Claude 网页端依然缺乏修改绑定邮箱等基础功能；也有人吐槽 Claude Code 内存占用高达数百 MB 乃至 GB 级，而同类轻量工具仅需 20 MB。
海量代码的真实去向：有前大厂 RL/Evals 工程师解释，大模型公司海量的新增代码并非都在客户端或前端，绝大多数是每天为强化学习（RL）生成的全新虚拟环境、成千上万个定制化评测基准（Evals），以及训练与推理底座的微调脚本。

四、“造轮子时代”的全面到来与开源生态的萎缩

自研替代复用的经济学逆转：评论区感叹，LLM 带来的生产力提升很大一部分被消耗在了“重写基础设施”上。当写代码的边际成本趋近于零，“购买、复用开源方案还是自研”的天平彻底倾斜，团队对现有工具，如 Git、Grafana 等，稍有不满，第一反应便是让 AI 结合内部环境重写一套专属系统。
不开源的深层逻辑：评论者据此解释 Scion 不开源的选择：在 AI 时代，软件高度耦合内部基础设施且处于极高频的动态演进中，将其抽离、泛化并维护成通用开源项目的收益可能为负。

五、人类工程师的角色焦虑与细节花絮

从创造者到“踩刹车的人”：部分程序员对“7 个保姆看着一群 Agent 干活、核心工作变成对 Claude 说不”的现状感到幻灭，自嘲人类正在退化为只负责按确认键的“肉体木偶（Meat Puppets）”。但也有人观察文章图表指出，周末的提交量依然会出现规律性的断崖下跌，并据此推测，目前至少一半以上的研发驱动力仍需人类在线发起。
全员隐去姓氏的防挖角、防社工细节：网友注意到文章致谢名单中的工程师全部采用“名字 + 姓氏首字母”，如 Nick G.，署名。评论区推测，这既是为了防止竞争对手按图索骥精准挖角（Poaching），也是为了防范针对 AI 实验室员工日益猖獗的精准网络钓鱼与社工攻击。

基本信息

原文标题：Redesigning source control at Anthropic
发布机构：Anthropic
原文发布日期：2026年10月13日
文章链接：Redesigning source control at Anthropic
HN 讨论区链接：Hacker News 讨论串：Redesigning source control at Anthropic
整理日期：2026年10月14日