导读：Claude写代码的速度，已经快到Anthropic原有的版本控制、构建和CI链路开始成为瓶颈。4个月里，内部日均代码合并量从约2500次冲到3万次以上。结果不是“Git突然不能用了”，而是Anthropic的极端Agent负载跨出了Git最擅长的设计区间，逼出一套名为Scion的新源码控制系统。
先说边界：Scion没有公开下载，Anthropic也不准备推出通用版本。它只适合真正庞大的单体仓库、数万名工程师或大量Agent持续写代码的极端环境，普通团队不需要抛弃Git。
01 / 4个月暴涨12倍：真正先被AI写代码压垮的是基础设施
2026年5月，Anthropic单体仓库平均每天合并约2500处代码变更；到9月，这个数字已经超过3万，4个月增长约12倍。官方判断，潜在的代码合并需求几乎没有上限：每消除一个瓶颈，新的代码产量就会立刻填满释放出来的容量。
Claude如今能够自主迭代研究流程、优化复杂程序并从零搭建服务。写代码本身不再是最慢的一环，真正开始吃紧的是为人类开发节奏设计的源码控制、构建、CI、代码审查和权限系统。
一个7人团队只用了5个月，就完成Scion、代码审查工具Antique和另外六个相关系统，并把Anthropic的单体仓库从Git完整迁移过去。Claude既是代码洪流的原因，也是这次高速迁移的重要生产力。
02 / 100GB历史、2500万次日检出，Git镜像为什么顶不住？
Anthropic的主分支历史接近100GB，压缩后的工作副本超过25GB。仅CI环境每天就要执行约2500万次代码检出，还没有计算开发环境、Agent沙箱和研究任务。若每次朴素抓取代码，理论流量每天会超过600PB。
Git当然不是毫无办法：浅克隆、稀疏检出、promisor remote、内部镜像和对象存储快照都能缓解压力。Anthropic也全部用过，高峰期维护过数百个Git镜像。
问题在于，合并速度越快，快照刷新后离主线最新提交越远；部分克隆还要保证diff、blame和提交历史查询正确。镜像自身的磁盘、内存、维护和故障隔离逐渐变成新的平台负担。
Anthropic发现，内部大多数客户端已经不是需要离线工作的工程师，而是始终在线的Agent和自动任务。Git为分布式离线开发保留的能力，在这种极端负载里反而增加了复制与维护成本。
03 / Scion的六个设计原则：围绕在线Agent重新开始
- 客户端始终在线：客户端围绕稳定可达的服务器设计，需要时再获取数据。
- 客户端与服务器不对称：历史、blame、提交、合并和变基由服务器负责；客户端只保留有界缓存、工作副本和文件变更监控。
- 所有源码控制查询都提供API：CI和内部工具可以直接问服务器，不必为了查一次历史维护完整仓库。
- 全部组件可水平扩展：数据分布式保存，服务器也没有完整仓库，不存在Git packfile式的集中维护负担。
- 提交增量、低成本、无锁：一次提交的成本随改动大小增长，而不是随整个仓库规模增长。
- 工作副本可选：能通过API完成的diff、查询和写入不落盘；确实需要文件时再稀疏、按需实例化。
这些原则并不是否定Git，而是承认“人类偶尔提交”和“数万个在线Agent高频提交”是两种不同工作负载。
04 / 变更集不是Git提交：Scion如何做到高吞吐无锁写入
Scion的基本工作单元叫变更集（changeset），它是预写式日志中的一条记录。Git提交指向一棵完整代码树；Scion变更集只保存相对第一个父级发生变化的文件，以及指向压缩文件内容的内容寻址指针。
变更集在服务器端创建，生成后立刻可在任何位置访问。它不需要接收packfile、不需要锁，也不用在创建时移动全局引用，因此能够高吞吐接收大量并发变更。
只记录变化会带来一个问题：无法立即回答“谁最后修改了这一行”或“哪些提交影响了这个文件”。Scion通过派生数据补上这些能力，包括文件blame、路径历史和提交图跳表。派生数据可以选择立即计算或延迟生成，服务端还能在不改客户端的情况下替换内部索引。
05 / 分层缓存：没有一台服务器保存完整仓库
少量Scion服务器提供变更集、diff、合并基和文件对象等源码控制API。代码内容采用不可变的内容寻址存储，任意节点都能放心缓存，不必反复确认对象是否被修改。
在计算集群中，任务先通过套接字连接每个节点的scion-daemon。同一节点的多个作业共享对象缓存；守护进程再访问区域内的树缓存和Blob缓存scion-cache。缓存缺失时才向权威scion-server请求，后者按需从Spanner或云存储读取。
三层使用同一套RPC，客户端不必知道缓存拓扑。每次请求都针对一个不可变对象，失败可以恢复，也不会出现单个数GB packfile必须从头重新传输的问题。
06 / 实测有多夸张？1/200资源、秒级检出、CI省下25% CPU
- 缓存：每一层命中率超过99%，且不依赖长期状态。
- 基础设施：按CPU与内存计算，占用约为原Git镜像系统的1/200。
- 检出：CI与研究任务由分钟级缩短到秒级。
- 容量：仅CI就获得约25%的CPU容量收益。
- Agent工作区：新建worktree从约7.1分钟缩到5.1秒，图中实测约84倍。
- 日常命令：拉取最新版本约25倍、状态查询最高超过200倍。
这些是Anthropic在自身硬件、仓库和工作负载下获得的内部数据，不应直接外推到普通公司。小型仓库克隆只需几秒时，重新建设整套版本控制系统几乎肯定得不偿失。
07 / Claude不仅制造压力，也把迁移速度推到过去难以想象的程度
Scion早期的Git导入管道主要由工程师手写。Claude Mythos Preview的内部早期快照在没有追加指导的情况下重写了整个管道，把内存占用降到原来的1/20，速度提高4倍，同时保留了导入顺序和数据结构里的隐含约束。
Anthropic表示，参与项目的工程师普遍认为Claude写代码已经比自己更强，但工程师的价值并没有消失，而是从逐行生产代码转向架构权衡、识别错误模式和告诉Claude“不要这样做”。
例如，一些Agent为了查询变更何时合入主线，会线性扫描提交日志，而不是调用Antique的结构化接口；对抗性Review还可能因为假设性风险引入过度校验和复杂度。Scion团队仍由人类审查每个变更请求，只是把重点从逐行代码转向变更意图与系统约束。
08 / Scion不是孤立工具，它连代码审查与CI逻辑都一起改了
Anthropic同步建设了Antique代码审查、代码搜索、源码控制身份权限、批量落地主线和新的测试流程。原因很简单：当版本控制模型改变，围绕Git构建的审查、搜索、构建、权限和部署都必须跟着迁移。
传统全局合并队列依赖仓库锁，测试运行时可能只有少量提交进入主线。但Agent规模下，一轮测试期间可能已经合入几百甚至几千个变更。Anthropic因此把更多投入放在合并后和部署前自动测试，并让Claude快速修复并发变更造成的冲突。
安全也被纳入底层设计：Scion支持仓库和目录级访问控制，Antique可表达更复杂的审批规则，让人类把精力留给敏感逻辑变更，而非注释或机械更新。
09 / 普通团队现在可以学什么？
| Scion思路 | 普通团队可落地做法 |
|---|---|
| 服务器提供完整源码控制RPC | 优先使用GitHub/GitLab API、GraphQL与服务端搜索，减少Agent反复克隆仓库 |
| 稀疏与虚拟化检出 | 为Agent按目录分配工作区，使用sparse-checkout、部分克隆与缓存镜像 |
| 内容寻址与分层缓存 | 缓存依赖、构建产物和只读仓库对象，按哈希复用而非每次重算 |
| 工作副本可选 | 检索、diff、blame和策略检查能走API就不落完整代码 |
| 语义审批与后合并测试 | 按风险分级Review，机械变更自动化，高风险目录强制人工审批 |
10 / 做视频网观点：AI编程的下一场竞争，不在模型，而在“承载模型”
Scion最值得关注的不是“Anthropic打败Git”，而是它提前展示了Agent规模的软件工厂会遇到什么：代码生成不再稀缺，稀缺的是检出速度、测试容量、Review注意力、权限边界和部署可靠性。
当AI把代码产量提高一个数量级，继续沿用人类开发节奏设计的流程，很快就会把收益消耗在排队、重复克隆、无效Review和测试拥堵里。真正能吃到AI编程红利的团队，需要同步升级规则、接口、缓存、测试、可观测性与责任边界。
但绝大多数公司离Anthropic的负载仍然很远。此时最理性的选择，是把Scion当作架构参考，用现成Git生态逐步优化，而不是为了追热点重造版本控制。
站内入口与延伸阅读
- Scion站内导航：https://www.zuoshipin.com/link/54161.html
- Anthropic站内导航：https://www.zuoshipin.com/link/1191.html
- Claude站内导航：https://www.zuoshipin.com/link/876.html
- Claude Code Desktop导航：https://www.zuoshipin.com/link/28144.html
- AI Agent Harness深度解析：https://www.zuoshipin.com/article/30587
- Anthropic代码性能优化案例：https://www.zuoshipin.com/article/45507
