git-ai 两天千星：开源复刻 Anthropic 的 Scion

10 月 13 日，Anthropic 发了一篇工程博客，第一次公开描述它内部的版本控制系统 Scion：为几百个同时读写、同时合代码的 coding agent 设计的服务器中心化系统，不开源。两天后的 10 月 15 日，开发者 feder-cr（Federico Elia）在 GitHub 创建了 git-ai 仓库，README 第一句话就是「Anthropic built Scion…So I built gitai: an open-source version of that design that anyone can run」。截至 10 月 17 日约 1,000★（GitHub search API 报 1057），两天冲上千星。MIT 许可，Go 语言。本文按老规矩拆六段。

一、它是谁

gitai 的身份要拆成两层看。

底座是 GitLab Gitaly 的 fork。Gitaly 是 GitLab 的 Git RPC 服务器，这个证据链在仓库里非常直白：NOTICE 文件开头写着「The following components are included in Gitaly:」，cmd/ 目录里是 gitaly、gitaly-backup、praefect 等全套原生命令，VERSION 文件写着 19.5.0-rc3（Gitaly 的版本号），LICENSE 有两行版权：「Copyright (c) 2026 Federico Elia and the gitai contributors (modifications and additions). / Copyright (c) 2016-present GitLab Inc.」。README 的说法是：Gitaly 提供底下的 Git plumbing，上游每一个 Gitaly RPC 都继续能用；上游非 MIT 的 ee/ 目录不在本仓库里。

新东西叫 graft。本地统计口径：全仓 2833 个 git-tracked 文件，Go 代码共约 57.6 万行（大头是 Gitaly 继承来的），其中 internal/graft 加 cmd/graft* 新目录约 7.5 万行，是这次开源的核心增量：graft CLI、graft-cache 缓存守护进程、graft-verify 验证器、graft-bench 压测工具，加上服务器侧的 land、changeset、derived data、resolver、review 一整套子系统。

还有一个要诚实交代的细节：仓库的 git 历史被 squash 过，浅 clone 只能看到 1 条 commit。7.5 万行新代码显然不是两天写出来的，但开发时长无从考证，只能按「长期准备后一次性公开」理解。README 里 Status 一节写的是 Version 0.1.0, the first public release。另外仓库带着 AGENTS.md 和 CLAUDE.md 这两个 agent 工作流文件，项目本身就是按「给 agent 用、也让 agent 参与开发」的路子组织的。

二、为什么是现在

gitai 出现的直接原因是 Anthropic 那篇《Redesigning source control at Anthropic》（10 月 13 日发布，10 月 15 日更新过一次）。博客把 agent 规模下源码管理的痛点第一次数字化了：2026 年 5 月日均约 2,500 次合并，9 月超过 30,000 次/日，四个月 12 倍；monorepo 主干历史近 100GB，压缩后的工作副本 25GB 起；每天约 2,500 万次 CI checkout，裸算 git 流量 600PB+/天，峰值要跑几百个内部 git mirror。传统 Git 托管是为「人 clone 一次、干几小时活、push 一次」设计的，全量 clone、合并队列、客户端历史遍历在这个量级全部变成瓶颈。Scion 的解法是把工作搬上服务器：客户端永远在线、按需取；历史类问题（blame、path history）在服务器算并缓存；落地走 compare-and-swap 不排队；服务器上没有完整仓库物化副本，一切水平扩展。Anthropic 用 5 个月完成迁移。

但 Scion 是内部的，公众拿不到。于是有了开源复刻这一波，gitai 不是唯一一个（更早的 10 月 13 日就有人开了 openscion，不过传播力小，HN 只有 7 个赞），但它是跑得最快的。

这波热度的另一半来自一场争议。10 月 14 日，前 Meta 源码控制团队成员 sunshowers 发文（HN 425▲）指 Scion「heavily inspired by Mononoke」（Meta 的开源版控系统）：derived data、Bonsai changeset 等概念和术语级雷同，连「Scion」这个名字都是「Bonsai」音节倒转再去掉 B；而 Anthropic 博客当时只致谢了 Google Piper 和 Meta Sapling。10 月 15 日他追加第二篇（HN 251▲），称私下获确认 Scion 是「intentionally and blatantly ripped off Mononoke」且存在人员重叠（此为 sunshowers 自述，未经独立核实）。随后据报道 Anthropic 的 Nick G. 在 HN 回应，博客补上了归属说明，页面顶部也多了一条官方措辞的 Update：「Updated October 15 to include more detail on the projects that pioneered many of the techniques we use in Scion」。主博客的 HN story 有 889▲，是当周工程圈的头部话题。

这场争议对拆解对象的意义是：它把「Scion 的设计思路其实早有开源先例（Mononoke）」变成了公共话题，等于替所有复刻项目做了市场教育。gitai 踩中的正是这个窗口。

三、机制拆解

graft 把 Scion 博客里描述的设计逐条落成了能跑的东西，挑四个最关键的讲。

第一个是落地不排队。传统托管平台的合并队列是串行瓶颈，graft 的 UserLand 做法是把变更 rebase 到当前分支 tip，然后用 compare-and-swap 更新引用：CAS 失败说明有人抢先落地，自动重试，默认最多 20 次；同一分支上的并发落地还会被批量合并成单次引用更新。文档里的基线数据很说明问题：20 个 agent 往同一分支落地，每个变更平均要试约 10 次，p99 延迟 26 秒。

第二个是 changeset 日志。每次被接受的引用更新都记进一个每仓库一份的 changesets.jsonl，写入用 flock 串行追加加 fsync，崩溃撕裂的末行会在下次追加时截断，序号从 1 开始稠密递增。agent 可以订阅这个流实时看仓库在发生什么，README 里管这类监控 agent 叫 superfans，还能把要事报到 Slack。

第三个是服务器端派生数据。blame、路径历史、祖先关系、代码搜索全部在服务器算，按内容寻址缓存，key 是 SHA-256(kind, commit, path)，写入走临时文件加 rename 的原子替换，每个 commit 只算一次。客户端因此不需要完整历史，graft clone 和 graft sparse 只物化你要的路径。

第四个是冲突解决的可插拔 resolver。协议是版本化、厂商中立的：可以配一个本地命令（stdin 收 JSON）或一个 HTTP 端点，配路径白名单黑名单、actor 白名单、超时和文件数上限。AI resolver 跑在服务器外面，服务器本身从不给任何大模型打电话，这是 README 反复强调的 vendor neutral 底线。AI 解决出来的 commit 会打上 Graft-Resolved-By 尾注，事后能审计。

安全模型上有一条值得点名：每个 agent 有自己的 token，身份不能被内部用户 ID 冒充，有 e2e 测试钉死这一点；agent 能调哪些 RPC 是写死在代码里的 allowlist，从快照建仓库这类危险 RPC 对 agent 永远关闭。

还有两个配套机制。一是落地后验证：graft-verify 维护一个绿色引用，落地后测试失败就二分定位肇事变更，自动 revert 并打上 Graft-Auto-Revert 尾注，每小时有 revert 上限防止连环误伤。这把「先合并再测试」从口号变成了有回滚保障的流程。二是语义化的 review 规则：审批要求可以按变更的性质配置，比如纯注释变更比逻辑变更要更少的 approval，这对 agent 海量提交场景是刚需，人类 reviewer 的注意力本来就是稀缺品。缓存层单独有个 graft-cache 守护进程，区域层缓存不可变对象，每个对象存取前重算 ID（类型加长度加内容）不匹配就拒绝，一批 miss 合并成一次上游调用。

四、数字与验证

仓库自带的 bench 文档给了 100 个 agent 同时往一个分支落地的实测（机器是 Intel Core Ultra 7 255H 加 WSL2，文档自己声明了噪声）：关掉批量落地，平均每变更尝试 56.94 次，500 个变更只有 115 个落地成功，277 个放弃，吞吐每分钟 126.6 次；打开批量落地，尝试次数降到平均每变更 1.00 次，落地 392 个，吞吐每分钟 257.6 次。

更难得的是它没有只报喜。同一份文档写明 phase 4a 的验收标准未达成：50 和 100 个 agent 规模下，开批量的 p99 延迟反而高于不开。README 的 Status 一节也直说这是 Version 0.1.0 首个公开版本，1.0 之前接口可能变，端到端测试只在单机跑过，多节点行为未测。doc/graft 下的 LIMITATIONS 文档列了四条自我定位：不是托管产品，不是 GitLab 替代品，不是 Scion 的实现，本身不构成安全边界。

对照一下行业常态：多数两天冲千星的项目，README 只有愿景图。这个项目带着六份阶段设计文档、fuzz 和崩溃恢复测试声明、以及一份如实写着「验收未达成」的 bench 报告开源出来，工程成色在同波复刻里是最扎实的。

五、判断

先说结论：gitai 值得关注，但它现在解决的是「Anthropic 规模的问题」，而 Anthropic 自己在博客里都说，不指望多数组织近期遇到这些问题。

三个观察。其一，它踩中的窗口一半是技术，一半是叙事。Mononoke 归属争议把「这套设计早有开源先例」变成了公共话题，等于替所有复刻项目做了市场教育，gitai 是这波里跑得最快的，两天约 1,000 星，比 10 月 13 日就出现的 openscion（HN 只有 7 个赞）声量大得多。热度里有相当一部分是对 Anthropic 争议的转移支付，不全是产品本身的。

其二，Gitaly fork 这个底座选择很聪明也很沉重。聪明在 Git RPC、仓库管理、备份这些脏活直接继承，MIT 许可加声明也做得干净；沉重在它从此背着 GitLab 生态的复杂度，构建要 Meson、Ninja 加编译捆绑 Git，上手门槛决定了它短期不会是大众工具。

其三，真正值得偷师的是几个设计判断而非代码本身：落地用 CAS 加批量而不是队列、日志用追加式 JSONL 加 fsync、AI 能力全部做成服务器外的可插拔 resolver、agent 身份和权限在协议层写死。这四条对任何要做多 agent 协作基建的团队都是现成的参考答案。

风险也说清楚：单人主导、历史被 squash 看不到开发过程、0.1.0 接口随时会变、bench 自己的验收都没过。按「设计参考价值高、生产可用性存疑」来定位比较公允。

六、谁能用怎么用

多 agent 并行写同一仓库、已经开始被合并冲突和队列卡住的团队，这是它的第一受众，quickstart 脚本一键起 server 加缓存守护进程加两个 agent 加一次落地，半天能摸完主流程。平台工程团队可以只读 doc/graft 下的 ARCHITECTURE、STORAGE、RESOLVE、LIMITATIONS 四份文档，把设计判断抄进自己的方案，不必引入代码。普通单体仓库团队继续用 Git 没有任何问题，这个仓库自己也是这么说的。

想上手的记住三条：存储核心默认关闭，从 shadow 模式导入再切 authoritative；resolver 先配确定性工具，AI resolver 放在最后加；别把它当安全边界，LIMITATIONS 写得明白。

信息来源

• 仓库本体：github.com/feder-cr/git-ai（README、NOTICE、LICENSE、go.mod、VERSION，10-17 本地 clone 核验；doc/graft 下 ARCHITECTURE/STORAGE/RESOLVE/LIMITATIONS/BENCH/LAND-BATCHING 各文档）
• Anthropic 官方博客《Redesigning source control at Anthropic》（10-13 发布、10-15 更新，Scion 全部数字出处）
• sunshowers.io 两篇 Mononoke 归属争议文章（10-14、10-15）及 HN 讨论（889▲/425▲/251▲/7▲，10-17 晨快照）
• 星数与创建时间：GitHub search API 与仓库页 createdAt（10-17 晨快照，星数仍在变动）