背景：AI编程带来的版本控制危机

Anthropic在2024年经历了代码合并量的指数级增长。今年5月，他们平均每天往主仓库合并2500次代码变更；到了9月，这一数字飙升至每天超过3万次。4个月内增长了10倍以上，且官方明确表示短期内不会放缓。这种增速源于AI代理（Agent）对代码合并需求的无上限增长。为了应对这一挑战，Anthropic在10月13日发布了工程博客，介绍他们如何在5个月内由7人团队从零构建了内部版本控制系统Scion。同期上线的还有代码审查工具Antique、代码搜索及权限管理系统。这一事件在开发者社区引发了“RIP Git”的讨论，因为Git统治开发流程近20年，如今被一家AI公司用模型生成的系统替代。普通开发者无需恐慌，但需理解背后的技术逻辑。

瓶颈转移：从代码编写到基础设施负载

在Anthropic，写代码已不再是瓶颈。Claude可以自主迭代研究闭环、微调复杂程序并搭建新服务。真正的瓶颈转移到了版本控制、构建系统和CI流水线等按人类开发规模设计的基础设施上。其负载程度极高：仅主分支历史数据接近100GB，压缩后的工作副本超过25GB。CI系统每天需执行约2500万次代码检出，若直接通过Git拉取数据，日传输量将超过600PB。面对如此巨大的流量，传统的Git架构已无法硬扛。尽管业界有浅克隆、稀疏检出等局部优化手段，且Anthropic曾同时运行数百台Git镜像服务器来“续命”，但这些方法维护成本日益高昂。快照刷新间隔越长，与主分支的差距越大；部分克隆仓库在执行diff、blame等依赖历史的操作时，也需耗费大量精力维护。

核心错位：Git的去中心化假设与Agent的在线现实

Anthropic反思发现，关键问题在于使用场景与设计初衷的错位。他们实际将Git当作集中式系统来用，所有工作围绕一份权威仓库展开。然而，Git的底色是去中心化，它假设客户端可能离线工作，因此每次克隆都携带完整仓库。在Anthropic的场景中，客户端几乎全是Agent和自动化任务，永远在线。Git为分布式离线场景准备的优点（如本地完整副本），在仓库规模巨大时反而成为扩展障碍。于是，团队提出新设计原则：如果从一开始就按Agent始终在线的前提来设计版本控制，它该长什么样？ Scion的设计参考了Google Piper和Meta Sapling的经验，确立了五大原则：客户端始终在线、版本控制服务完整、组件横向扩展、提交轻量无锁、工作副本可选且默认稀疏。

Scion架构：服务端主导与变更集设计

Scion的基本工作单元是变更集（Changeset），它是预写日志中的一条记录。与Git提交存储指向整棵目录树的指针不同，变更集只保存相对第一个父提交发生变化的文件清单及内容寻址指针。这种结构使得变更集在服务端创建后全局立即可见，无需packfile压缩、无锁、无跨服务器协调。由于变更集仅记录变化本身，无法直接回答“这行代码最后谁改的”等问题，Scion基于变更集构建了派生数据（Derived Data）结构。这些派生数据包括用于查询blame和路径历史的数据、加速提交图查询的跳表等。每种派生数据都是递归定义的，从父变更集推导而来。系统允许选择提前计算或按需计算，从而避免生成无用数据。客户端看不到内部结构，服务端可自由优化扩展。

部署与性能：三层缓存架构的效率飞跃

Scion的客户端scn通过Socket与本机的scion-daemon通信，daemon管理对象并加载定期刷新的快照。部署分为三层：客户端、scion-daemon和缓存服务器。daemon只与同区域的scion-cache通信，后者直接从内存流式发送对象。缓存缺失时，请求才转发至权威的scion-server从Spanner或云存储读取。这种分层架构严格限定了访问关系以隔离故障。效果显著：每层缓存命中率超过99%。与之前的Git镜像基础设施相比，Scion在CPU和内存占用上缩小了200倍。CI和研究任务的检出速度提升了约两个数量级，从几分钟缩短至几秒钟。整个集群空出大量算力，仅CI部分就节省了25%的CPU容量。这种高效性得益于数据内容寻址和只写不更新的特性，使得任何服务器都能放心缓存。

AI辅助开发：Claude在系统构建中的角色变化

Scion的开发过程得益于Claude Mythos Preview和Claude Tag的内部开放。团队曾手写Git到Scion的数据导入流水线原型，后让Claude重写该程序。结果内存消耗降低20倍，运行速度快4倍，且未丢失任何隐含约束。整个项目由7人团队在5个月内完成Scion、Antique及6个相关系统的开发与迁移。工程师的角色并未廉价化，而是发生了位置转移。他们提供的是对系统间整体关系的理解及设计取舍的判断。工程师的工作很多时候是对Claude说不，因为Agent可能为满足局部代码模式而违反系统核心约束。例如，在迁移过程中，Claude曾建议线性扫描提交日志来查询变更合并时间，而正确做法是直接查代码审查工具。团队现在主要关注修改意图而非逐行读码，并利用Claude进行对抗性代码审查和模糊测试。Claude甚至能在一天内发现并修复一个漏用索引的算法优化点，而专家可能需要数周。

运维与流程重构：超级粉丝与合并队列变革

在安全合规方面，Scion支持细化到单个目录的仓库访问控制。配套的审查工具能表达复杂的语义化审批约束，如区分仅改注释的变更与涉及敏感逻辑的修改。运维上引入了“超级粉丝（Superfans）”概念：团队重度使用Claude Tag监控组件，并为每个关键组件建立专门的Slack频道及对应的Claude实例。这些“超级粉丝”能访问遥测数据和日志，像经验丰富的工程师一样不断刷新图表寻找异常。相比传统告警的迟钝，超级粉丝能捕捉到细微且从未出现过的问题。此外，团队重新检视了按人类规模设计的流程。在Agent规模下，全局仓库锁已失效。他们放弃全局排队，转而依赖合并后和部署前的自动化测试。虽然并发变更可能冲突，但Claude修复冲突的速度比人类发现冲突还快。这种流程重构适应了AI编程的高并发特性。

边界与未来：Scion并非Git的通用替代品

Anthropic明确强调，Scion绝不是Git的通用替代品。其设计仅适用于真正庞大的单体仓库（数万工程师共用或大量Agent持续编写代码）。Anthropic拥有远超普通公司的内部任务Token烧录能力，这是其测试Claude能力及满足自身需求的基础。将Scion做成通用产品不现实，因为它与Git差异太大，迁移需伴随整个开发生命周期及配套工具。Anthropic担心公开讨好所有人的版本最终无用。但他们判断，未来6到12个月这类问题将越来越普遍。与其让每家公司独自撞墙，不如公开思路。他们建议Git服务端不必与客户端用同一种工作方式，托管平台可提供完整的服务端RPC接口并标准化。Git社区花近20年服务数百万开发者，Anthropic的贡献虽窄，但提前看到了AI编程与系统相撞的样子。他们希望与GitHub、GitLab及开源社区共同应对这一趋势。

结论

“Git被取代”更多是一个吸引眼球的噱头，而非现实。真正值得关注的信号是：当AI写代码的速度指数级上升时，那些围绕人类节奏设计的工具链将接连触及天花板。今天是版本控制，明天可能是CI或代码审查。Anthropic通过公开其撞墙的过程，展示了在Agent时代重构基础设施的必要性与可行性。对于其他团队而言，这堵墙大概率也会在路上到来。开发者无需恐慌Git的消亡，但需意识到工具链底层假设正在发生根本性变化。Anthropic的实践表明，服务端主导、数据内容寻址及AI辅助开发与运维是应对大规模自动化代码生成的有效方向。这一变革不仅关乎技术架构，更涉及工程师角色、流程规范及安全合规的全面重构。未来软件工程的核心竞争力，将在于如何高效整合AI代理与可扩展的基础设施。