Why Anthropic replaced Git, and whether you’ll need to

Anthropic Scion 与 Git：AI 编码代理带来了哪些改变

我知道，我知道，我似乎养成了发布“X 是否已死？”这类文章的习惯，但这一次贝特里奇定律不适用：答案不是“不”，而是“可能，对某些人来说是这样”。

过去 7 天内的一则重大新闻是 Anthropic 在其巨型单体仓库中用名为 Scion 的全新源代码控制系统替换了 Git，该系统由一个小团队（以及大量 Claude）开发。他们花了大约五个月时间构建并迁移至 Scion。他们声明更换 Git 的原因是 Git 无法扩展。他们的单体仓库在 5 月每天有 2500 次合并，到 9 月已增长至每天超过 30000 次，而 Git 无法跟上这一增长。

这在软件开发界引发了巨大反响，因为几乎所有开发者都使用 Git 来处理所有工作，而 Anthropic 被认为是软件开发新世界前沿的代表，该世界的工作主要由代理完成。他们是否遇到了我们即将面临的瓶颈？如果是，我们将需要构建新的解决方案，因为 Scion 并非开源。

在本文中，我将深入探讨 Scion 究竟是什么，它与 Git 有何不同、为何不同，其他处于前沿的开发者正在做什么，以及你是否也需要 Scion 这样的工具。

尝试 Arize AX

使用 Arize 构建更优秀的代理

追踪、评估和学习。通过 Arize AX 构建代理，立即开始追踪你的运行。

开始使用

查看 AX 文档

更喜欢开源？尝试 Arize Phoenix，这是用于自托管开源代理可观测性的解决方案。

Scion 与 Git：Anthropic 为何更换源代码控制系统

首先快速回顾一下 Git 的工作原理：每次克隆仓库时，你都会创建一个完整的仓库副本及其全部历史记录。这使你可以在完全离线的情况下对仓库进行任何操作。你可以本地提交代码，确保一切准备就绪，然后推送到服务器进行审核。这需要一定前期工作（下载仓库可能需要很长时间，每个人都有过这种体验），但之后可以带来非常流畅的本地体验。这对于在笔记本电脑上工作的开发人员来说非常有效，因为他们的网络连接可能并不总是在线。

Scion 并不是为人类设计的，而是为一个由代理主导的世界设计的，这些代理以与人类截然不同的方式和速度工作。更重要的是，Scion 特别为 Anthropic 使用的巨型单体仓库而构建，而这并不是所有人的工作方式。

他们的单体仓库引发了第一个问题：在 CI 规模下，代码检出变得昂贵。主分支的历史记录几乎达到 100GB，而压缩后的工作副本也超过 25GB。Anthropic 每天运行约 2500 万次 CI 检出，如果每次检出都完整获取该工作副本，每天将产生超过 600 拍字节的 Git 流量。

他们尝试了浅层克隆，尝试了稀疏检出，尝试了运行数百个 Git 服务器镜像，但这些方法都无法跟上需求。因此 Scion 采用了不同的方式：

• Scion 是服务端处理的。诸如“谁最后修改了一行代码”或“两个提交之间的差异是什么”等问题由服务端回答，而不是每个客户端从自己的副本中计算得出。这些问题可以通过 API 调用来回答，因此客户端根本不需要获取完整的树结构。

• 提交操作也由服务端完成。所有与源代码历史相关的更改都在服务端完成，因此你无需推送任何内容。

• 检出操作是部分的。当某个任务确实需要访问磁盘上的文件时，它只会获取请求的目录，文件在被读取时才会下载。

• 不建议使用分支。每个分支都是所有服务器必须达成一致的共享状态，随着数据量增长会成为扩展性问题，因此Scion主要使用主分支和发布分支。

这些特性与Git存在显著差异。Anthropic表示其新架构能够满足当前的数据量需求，相比之前使用的Git镜像集群，CPU和内存消耗降低了200倍。该架构包含一个名为Antique的新代码审查系统，这一点稍后会再详细讨论。

Anthropic并非第一家遇到这些问题的公司，Scion中的理念也并非全新。Google的Piper和Meta的Sapling系统多年来一直在处理超大规模单体仓库，采用过类似的权衡方案。但Google和Meta需要数万名工程师花费数年时间才达到这个瓶颈；而Anthropic的规模和成立时间都小得多。

那么，所有大量使用智能体编写代码的公司是否都需要这种方案？

Perplexity和GitSwarm如何利用Git协调智能体

Anthropic认为这个问题将在未来6到12个月内成为普遍性难题。但该领域还有其他公司通过保留Git解决了类似问题。

Perplexity在Anthropic发布文章的前一天公布了其项目功能的存储设计，将其描述为面向智能体的Git托管平台。需要明确的是，这用于存储知识工作相关的项目文件，而非Perplexity自身的源代码，但面临的问题相同：大量智能体（有些交互式，有些按计划运行）同时向同一个仓库提交代码。

每个智能体在独立的临时沙箱中运行，拥有文件的本地副本，并将提交发送到基于S3的Git服务。如果两个智能体发生冲突，基于旧版本构建的那个会被拒绝，然后在其新版本基础上重放变更并重试。Perplexity表示，这类冲突提交占比不到2%。

这是针对大量智能体同时运行的解决方案。但并未解决巨型仓库的问题：为此Perplexity刻意保持每个仓库体积较小，仅在需要时下载文件。他们还限制历史记录长度：当历史记录过长时，旧提交会被压缩成单个快照。

来自Meta和多所大学研究人员的GitSwarm采用了不同的协调方式。这是一个研究系统而非生产基础设施：一组相同的智能体通过贡献到一个共享的分支Git仓库来协作解决复杂问题。没有任务分配器来派发工作，每个智能体查看仓库中已有内容，决定下一步操作并提交结果，后续智能体则基于早期提交继续开发。仓库本身即是协调机制，使用的是标准Git。

换句话说：Scion解决的问题不是大量智能体同时运行时产生的问题，而是当它们在一个巨型单体仓库中运行时产生的问题。如果你没有这种情况，Git仍然能正常工作。

但Scion的作用仅限于此吗？不是，因为Scion并非他们构建的唯一系统。

AI代码审查如何改变源代码控制

我之前写过关于智能体编程如何改变代码审查的文章，并做过一场名为《代码审查的终结》的完整演讲：一旦代码的生成变得廉价，人工审查就会成为瓶颈。因此，从另一个角度来看，Scion 是解决代码审查问题之后下一个瓶颈的解决方案。

Anthropic 在关于 Scion 的公告文章开头提到，编写代码对他们来说已不再是瓶颈。他们实现这一点的部分原因是 Scion，但另一部分原因是 Antique——这是他们在开发 Scion 同时构建的代码审查系统。Antique 能够识别出仅涉及敏感逻辑变更的评论，因此人类只需审查那些值得他们投入时间的变更。在 Scion 的代码库中，工程师现在审查的是每个变更的意图，而不是逐行阅读代码。这在 Anthropic 的单体仓库中显著减少了传统代码审查的使用。

在我看来，即使他们没有庞大的代码树，Anthropic 在 Git 上的扩展问题本来就会出现。随着传统代码审查的消失，合并代码变得极其频繁，这无论如何都会压垮他们的基础设施。

他们还不得不改变合并代码的方式。在智能体规模下，数百个变更可以在测试仍在运行时合并。Anthropic 无法让传统的全局合并队列锁正常工作，因此他们改为在合并后、部署前进行测试，并接受并发变更有时会产生冲突的事实，因为 Claude 能够比人类更快地解决这些冲突。

有趣的是，Perplexity 最终也走到了相似的境地：他们根本不使用拉取请求，因为没有人类会审查每个变更。他们依赖于提交时的自动化检查。

AI 编码智能体是否需要 Git 的替代方案？

如果你打算部署由智能体编写代码的团队，并使用自动化进行代码审查，这似乎就是行业的发展方向，那么这意味着你是否需要 Scion，或者只有在使用单体仓库时才需要？这才是关键问题。

Anthropic 表示 Scion 并不是 Git 的通用替代方案。他们不会将其作为开源项目发布，部分原因就在于此，部分原因在于采用 Scion 意味着同时替换你的代码审查、代码搜索和 CI 系统。他们表示，只有在拥有与他们一样庞大的单体仓库时，Scion 才是真正必要的（感谢上帝，这并不是大多数人的情况）。

相反，Anthropic 希望将这些理念带回 Git。他们表示愿意与 GitHub、GitLab 以及开源社区合作，开发 Git 客户端可以学习使用的服务器端 API，例如用于历史记录和差异的接口。

GitHub 和 Cursor 如何为 AI 智能体扩展 Git

GitHub 已经遇到了 Scion 解决的类似问题，并且（虽然有些迟缓）正在采取行动。他们发布了重建面向智能体的 Git 基础设施的计划。GitHub 的推送量在一年内增长了 4.9 倍，GitHub 指出智能体在紧密循环中几乎每次操作后都会提交，因此单次推送的完成速度就成为了该智能体的速度限制。他们的解决方案保持 Git 对用户完全不变，但将服务器上的存储与计算分离：仓库数据存储在 Azure Blob Storage 中，轻量级工作线程则从缓存中响应请求。在内部基准测试中，他们看到了高达 35 倍的写入吞吐量提升。Cursor 的 Git 主机 Origin 在 8 月就采取了类似的措施，将每次推送存储在 S3 的日志中，并将磁盘上的仓库视为缓存。

但请注意 GitHub 并未采取的措施：他们没有将提交迁移到服务器，也没有要求客户端放弃完整副本。他们只是让服务器更快地接受推送。Git 托管服务是否会进一步采用 Anthropic 的服务器端提交和历史查询功能仍是个开放问题，且尚不清楚这是否必要。

在替换 Git 之前识别你的瓶颈

• 如果你仍卡在代码审查环节，首先要解决这个问题。Scion 和 Antique 展示的未来愿景并非单体仓库世界，而是代码审查已解决、新瓶颈开始的世界。

• 如果你的 Git 推送速率是瓶颈，你需要的是已经在进行中的改进。这需要更多人参与，且人数增长速度可能远超单体仓库用户的增速。GitHub 的方案可能足够应对，但你真正需要的可能是 Antique 而非 Scion。

• 如果你有一个巨型单体仓库，天可怜见。Scion 不是开源的，你将需要复现它的功能（Meta 的 Sapling 是开源的，这可能是你该开始的地方）。

Anthropic 今天可复制的另一项成果与 Git 完全无关。他们的团队设置了 Claude 实例，每个实例监控单个 Scion 组件的遥测和日志，寻找任何异常之处。Anthropic 表示他们能发现传统告警系统遗漏的细微问题。当变更以代理速度落地时，你需要代理实时读取发生了什么，因为人类查看仪表板无法跟上节奏，这正是我们开发 Arize AX 的初衷。

因此 Anthropic 已经淘汰了 Git，但仅限于那些拥有大量代理的巨型单体仓库团队。对其他人而言，Git 正在你脚下被重新构建。不要贸然移除它。把精力放在解决代码审查问题上，这样你才能面对下一个瓶颈带来的良性挑战。