Anthropic 自建了一套版本控制系统，因为 Git 跟不上 AI 写代码的速度

feder-cr/git-ai · ⭐ 2483 · 开源（MIT）· 5天 · Go

一句话

Anthropic 内部为了让 AI coding agent 高效协同时，自建了一套版本控制系统叫 Scion。现在有人把它完整开源了——任何人可以跑、研究、改进。

Git 诞生于人类写代码的时代：一个人 clone 一个大仓库，改几个小时，commit 一次，push 上去。这是合理的——Git 的设计目标就是让个体开发者能在离线的情况下完整管理项目历史。

但 coding agent 不是人。

Anthropic 发现，当他们让 AI agent 大规模写代码时，Git 成了最大的瓶颈。原因很简单：

Anthropic 的做法是：把版本控制从客户端工具变成服务端 API。

传统 Git：clone 整个仓库（可能几十 GB），本地计算 diff。

Scion：客户端保持在线，只请求它需要的那几个文件。仓库状态存在服务端数据库里，客户端不需要本地存完整历史。

效果：一个 agent 启动时只需要几百 KB，不是几百 MB。

传统 Git：git log、git blame、git grep 都是客户端本地计算。

Scion：这些查询全部在服务端跑，结果缓存好。历史问题由服务端回答，不用每个客户端都算一遍。

效果：服务端一次计算，所有 agent 共享缓存结果。

传统 Git：多个分支同时推，需要一个 merge queue 排队处理冲突。

Scion：每个 change 自带唯一的 id。服务端用 compare-and-swap（CAS）操作：只有当当前 tip 和 agent 记录的一致时，这个 change 才落库。不一致就自动 rebase，不用人工介入。

效果：多个 agent 同时改不同文件，互不阻塞；改同一文件，自动 rebase 重试。

传统 Git：commit 人是一个 human author。

Scion：每个 change 记录是哪个 agent 做的。你可以看到今天 Agent-A 做了 200 个变更，Agent-B 做了 150 个。

效果：协作可追溯，责任清晰。

这不是在升级 Git，而是在回答一个更基本的问题：当写代码的主要力量从人变成 AI agent 时，版本控制应该长什么样？

Git 的设计哲学是给个体开发者离线管理代码的工具。Scion 的设计哲学是给成百上千个 agent 实时协同一套服务端化的系统。

两者解决的是完全不同的问题。

feder-cr/git-ai 的价值在于：它把 Anthropic 内部的 Scion 设计完整实现了，而且是 MIT 许可、vendor-neutral（不绑定任何 LLM 提供商）。这意味着：

这是一个服务端系统，不是命令行工具。基本用法：

详细文档在 GitHub 仓库，README 里有完整的架构说明和部署指南。

这个项目不适合新手直接上手——它需要部署服务端 + 改造现有 agent 工作流。更适合已经跑多 agent 协作的团队参考其设计理念，或者想深入理解 agent 时代版本控制的人研究源码。

Git 发布至今 20 多年，一直是客户端工具的姿态。Scion 的出现（以及 git-ai 的开源实现）说明：当底层工作负载从人类变成 AI agent 时，基础设施需要重新设计，而不是打补丁。

这不只是版本控制的问题——数据库、消息队列、监控系统，可能在 agent 规模化之后都会遇到同样的问题人类工具不适应 agent 节奏。

有意思的是，这个设计思路和我们正在用的 Claude Code / Codex 是相反的：我们现在的体验是 agent 像人一样用 Git，而 Scion 的方向是让 Git 像为 agent 设计一样工作。

哪条路会赢？还在早期，但方向已经清晰了。