AI Agent 排队提交太慢？Scion 开源复刻版 gitai 重造版本控制

让 AI Agent 干活的人多半撞过这堵墙：三五个 agent 并行开工，每个都 clone 一份完整仓库，改几个文件就要提交一次，merge queue 排起长队，仓库历史越滚越大，最后整个流水线堵成一团。传统 Git 是为"人类每天 push 一两次"设计的，而 agent 的作业模式是"成千上万个短任务、秒级落地、全挤在同一条分支上"——底层数据结构从根上就不匹配。

Anthropic 内部的答案，如今有了开源复刻

Anthropic 在工程博客里公开过他们内部版本控制系统 Scion 的设计：一个以服务器为中心的系统，专为数百个 agent 同时读写代码打造。但 Scion 本身不对外提供，外界只能看看思路过过眼瘾。

现在情况变了。独立开发者以 Scion 公开描述的设计为蓝本，用 Go 语言写出了一个开源实现 gitai，首个版本 0.1.0 已发布，MIT 协议，仓库地址：github.com/feder-cr/git-ai。项目基于 GitLab 的 Gitaly（MIT 部分）改造，底层仍是标准 Git 仓库——这意味着现有的 Git 生态不用推倒重来。

它到底改了什么

对照传统 Git 的痛点，gitai 的核心机制可以归纳成六条：

1. 按需抓取，不再全量 clone：客户端常驻在线，只拉取需要的对象和路径，几秒钟就能开工；
2. 历史查询搬到服务端：blame、路径历史、代码搜索在服务器上计算并缓存，客户端不用自己翻历史；
3. 对比交换取代合并队列：变更落码靠 compare-and-swap 完成，同分支的并发落地自动合并为一次引用更新，不用排队；
4. 冲突自动解决可插拔：冲突交给"解决器"处理，可以接任何大模型、确定性工具，或者干脆不用；
5. 变更日志完整可查：每次引用更新都记录操作者和内容，哪个 agent 改了什么一目了然，还能实时监听变更流；
6. 落地后验证自动回退：合并后自动跑测试，失败就用二分定位并回退闯祸的那次变更。

细看这套设计，安全模型是真正下功夫的地方：每个 agent 拿到的是独立 token，配合 RPC 白名单和分支策略，能精确规定某个 agent 只能读哪些路径、能不能落码——代码库里跑着几十个 agent 时，这种按 agent 粒度的权限控制比"一人一个账号"精细得多。项目里还有个有意思的设计叫 superfans：专门派 agent 订阅变更流，各自盯着自己负责的组件，发现相关变更就主动评估上报，甚至能直接接进 Slack 通知团队。

存储层采用数据库加对象存储的设计（SQLite 或 PostgreSQL 存变更日志，内容寻址的包放对象存储），服务节点无状态、任何节点都能重建，扩容就是加机器。用熟 GitHub 的可以把 compare-and-swap 理解成"没有队列的 merge queue"：不是排着队一个个合并，而是每次提交都对着分支最新状态做原子校验，落不上去就自动重放，从机制上消灭了排队这个环节。

四步跑起来

环境要求：Linux 或 macOS、Go 1.26、C 工具链、Meson 和 Ninja（构建过程会编译一个内置 Git）。上手共四步：

1. 拉取仓库：git clone https://github.com/feder-cr/git-ai.git
2. 进入目录：cd git-ai
3. 编译构建：make build，产物输出到 _build/bin；
4. 运行演示：执行 examples/graft/quickstart.sh，一键起一个服务器加缓存守护进程、两个 agent 和一次完整落码的演示环境。

跑完 quickstart 就能看到 agent 落码、变更日志和冲突处理的完整流程。想搭自己的服务，复制 examples/graft/config.toml 改配置，用 _build/bin/gitaly serve config.toml 启动即可；要上生产，文档里给出了 SQLite/PostgreSQL 加对象存储（本地、S3、GCS、Azure 均可）的完整方案，还提供 shadow 模式先导入存量仓库再切换到权威模式的迁移路径，架构细节可以翻仓库里的 ARCHITECTURE.md 和 STORAGE.md 两份设计文档，写得相当扎实。

冷静看待：它适合谁

说实话，0.1.0 的 gitai 离"替换日常 Git"还有距离——已知短板（比如存储层的垃圾回收）官方都在 LIMITATIONS.md 里如实列出，接口在 1.0 前也可能变动。个人开发者继续用 Git + 常规工作流完全没问题。

但它真正的价值在于示范了一个方向：当"写代码的主体"从人变成 agent，围绕人设计的工具链迟早要重造。多 agent 并发落码、按 agent 粒度做权限、变更自动溯源，这些需求在 agent 工作流普及后只会越来越刚性。与其等大厂把方案锁进自家平台，不如关注这类社区驱动的开源实现——现在给它提的每个 issue，都可能变成未来基础设施的一部分。

唯一需要提醒的是：让 AI 改你的代码库之前，先把备份和分支策略理清楚，任何新工具都别在生产仓库上首跑。