多 agent 并发写同一仓库：Git 存储架构要先兑现哪些写入假设

多 agent 并发写同一个仓库时，最先遇到的问题通常不是“服务器扛不扛得住”，而是 Git 存储层是否兑现了一组写入假设：对象写完能不能被引用安全切换，引用更新冲突能不能被判定，失败之后能不能回滚，读到的历史是否一致。GitHub 在 2026 年 11 月 5 日发布了一篇题为 Inside GitHub’s new Git storage architecture 的博客，摘要称其新 Git 存储架构“built so thousands of agents can push to a single repository at once”。本次材料只包含标题与摘要，正文实现细节未提供，因此下面讨论的是“要先兑现哪些假设”的分析框架，而不是对 GitHub 具体实现的描述。

一、先把两种写入分开：对象与引用#

在 Git 协议里，一次 push 大致分两段：客户端把提交、树、blob 等对象打包上传，服务端校验并落盘；然后客户端请求把某个引用（ref，如 refs/heads/main）从旧值切换到新值。对象按内容寻址，相同内容得到相同对象；引用则是可变的，需要带旧值校验。

这两段的并发特征不同：对象写入是“追加”，引用写入是“覆盖”。多 agent 同时 push 时，冲突主要发生在引用更新这一层，而不是对象上传本身。

二、存储层要先兑现的六个写入假设#

1. 对象写入可幂等。 内容寻址意味着重复上传同一对象不应产生歧义，这为 agent 重试提供了基础。
2. 引用更新是原子的。 更新应带旧值校验（compare-and-swap 语义），远端引用已被别人推进时拒绝，而不是静默覆盖。
3. 失败可回滚。 对象已上传但引用未更新时，应留下可回收的悬空对象，而不是半更新状态。
4. 读一致性。 agent 拿到引用后读到的对象，应与该引用指向的提交一致。
5. 冲突可判定、可反馈。 拒绝要能说明是 non-fast-forward 还是校验失败，agent 才能决定合并、重试还是换分支。
6. 可追溯。 谁在何时把引用从哪个值推到哪个值，需要留痕，否则并发问题难以复盘。

三、agent 的重试会放大冲突#

agent 与人类不同：它们更容易并发起多条分支、批量 push、失败后立即重试。如果多个 agent 都直接写同一个受保护分支，引用层的 CAS 冲突会被重试进一步放大。一个务实的做法是让每个 agent 写独立分支，再通过合并请求收敛，从源头减少对同一引用的争用。下面的命令只是示意 CAS 语义，未执行，具体版本与行为待核实：

# 未执行示例：只在远端引用仍等于预期旧值时才更新
# 环境：Git 2.x，具体版本待核实
git push --force-with-lease=refs/heads/main:<expected-oid> origin HEAD:refs/heads/main

四、能核对什么，不能假设什么#

材料能确认的只有：GitHub 在 2026 年 11 月 5 日发布了该博客，且摘要把它描述为支持“数千个 agent 同时 push 到单一仓库”。以下问题本次材料无法回答，应标为待核实：引用更新用的是集中式协调还是分区后的本地 CAS；对象上传与引用切换是否在同一事务边界内；冲突反馈的具体形态；以及“数千”对应的是并发连接数、请求数还是活跃 agent 数。

结论：多 agent 并发写同一仓库，存储架构首先要兑现的是引用层的原子更新、失败回滚与可判定冲突，而不是单点吞吐数字。把这些假设逐条核对清楚，再谈扩容与压测。