Anthropic 用 Scion 替换 Git：应对 Agent 规模合并

当 AI Agent 开始以机器速度提交代码，传统的 Git 工作流正在成为瓶颈。据 Hacker News 和 RSS 源报道，Anthropic 的日均代码合并量从约 2,500 次飙升到超过 30,000 次，迫使他们用自研系统 Scion 替代了 Git。

为什么 Git 不够用了

Git 诞生于人类开发者协作的时代。它的分支模型、合并冲突解决机制以及基于 PR 的审查流程，默认假设每次合并背后都有一个耐心且会思考的人。

当 Anthropic 的 AI Agent 大规模参与代码生产后，这个假设失效了。30,000 次日合并意味着平均每 3 秒就有一次合并发生。人类审查者根本无法跟上这种节奏，而 Git 本身在处理高并发分支合并时也暴露出性能瓶颈——每次合并都需要完整的树对象计算和冲突检测。

Scion 的出现不是对 Git 的否定，而是对一种新现实的承认：代码的生产者已经不只是人类了。

Git 的树对象与合并开销：Git 仓库本质上是一个有向无环图，每次提交都指向一棵完整的树对象（tree object），记录该时刻全部文件的目录结构与内容哈希。合并两个分支时，Git 需要找到共同祖先，对双方树对象逐层比较，生成合并树，并对文本文件做行级三方 diff 以检测冲突。这一流程虽然经过了大量优化，但其时间复杂度仍与变更文件数、仓库规模正相关。当合并频率达到每秒多次、且分支数量庞大时，反复的树对象计算、索引重建和锁竞争会迅速累积成可观的延迟。此外，PR 审查流程依赖人类在合并前介入，天然无法匹配机器级提交速度。因此瓶颈并非 Git 的某个具体命令，而是其“先审查、后合并”的保守模型与 Agent 高并发生产之间的根本错配。

Scion 做了什么不同的事

根据 Anthropic 官方帖子的说法，Scion 并非从零发明版本控制，而是针对 Agent 场景重新设计了合并层。核心改动包括：

• 乐观合并优先：假设大多数 Agent 提交不会冲突，先合并再验证，而不是先检测再合并
• 语义级冲突解决：利用 LLM 理解代码意图，而非单纯依赖行级 diff
• 批量操作：将多个 Agent 的提交打包处理，减少协调开销

这种设计思路的核心是承认：Agent 生成的代码修改通常比人类更“局部化”和“可预测”，因此传统 Git 的保守策略反而是过度设计。

乐观合并与语义冲突解决：传统版本控制采用悲观策略，合并前先做完整冲突检测，有冲突则阻塞，待人工解决。乐观合并则假设大多数提交不会真正冲突，直接应用变更，再进行验证；若验证失败则回滚或触发补偿流程。这种策略在 Agent 提交高度局部化、变动范围可预测时收益显著。语义级冲突解决进一步引入大语言模型理解代码意图，而非仅比较文本行。例如，两个 Agent 分别重命名同一函数的不同调用点，行级 diff 会报冲突，但语义上可能完全兼容。不过，语义合并依赖模型对代码上下文的理解，在跨文件重构、隐式依赖或类型系统复杂时仍可能误判。因此，乐观合并必须搭配快速回滚与可审计日志，才能在速度与正确性之间取得平衡。

HN 上的争议：安全性与可审计性

Hacker News 的讨论并不全是掌声。多个高赞评论指出，去掉 Git 意味着失去了一套经过数十年验证的审计追踪机制。

一位评论者直言：“Git 的历史本身就是一种安全边界。当合并速度达到每秒多次，你如何保证每次变更都可追溯？”

也有人质疑 Scion 的语义合并是否足够可靠——LLM 理解代码意图的能力在复杂重构场景下仍有限，而一次错误的自动合并可能比十次冲突更危险。

不过，支持者认为这正是 Agent 原生工具链必须经历的阵痛。一位曾参与类似项目的开发者表示：“你不能用为人类设计的安全模型去约束 Agent，你需要为 Agent 设计新的安全模型。”

可审计性与供应链安全：在软件供应链安全中，可审计性意味着每一次代码变更都能追溯到明确的作者、时间、意图和审查记录。Git 通过提交哈希、签名和不可变历史提供了强追溯能力，这也是 SLSA 等框架推荐的基础。当合并频率达到每秒多次，且部分变更由 LLM 自动生成时，传统的人工审查日志不再适用。Scion 若要满足同等安全要求，需要为每次自动合并生成机器可读的意图说明、变更影响范围以及回滚点，并保证这些记录不可篡改。否则，一旦出现恶意注入或模型幻觉导致的错误合并，团队将难以定位根因。因此，讨论的核心不是“要不要审计”，而是“如何为 Agent 原生工作流设计新的审计原语”。

对你的仓库意味着什么

如果你的团队还没有到每天上千次合并的规模，直接替换 Git 显然不现实。但 Anthropic 的实践提供了几个值得提前思考的方向：

第一，关注合并瓶颈的早期信号。 当 CI 排队时间超过代码编写时间，或者合并冲突开始频繁打断 Agent 工作流时，就是需要重新审视版本控制策略的节点。

第二，考虑分层策略。 可以在 Git 之上增加一层 Agent 专用的快速合并通道，而非完全替换。例如让 Agent 在轻量分支上操作，定期批量同步回主仓库。

第三，把可审计性作为硬约束。 无论采用什么方案，确保每次 Agent 合并都有清晰的来源、意图和回滚路径。速度可以妥协，追溯性不能。

Scion 目前仍是 Anthropic 的内部系统，没有开源计划。但它指出的方向——版本控制需要为 Agent 时代重新设计——值得每个正在扩大 AI 编码规模的团队认真对待。