一个仓库的读取压力太大，增加副本是很自然的办法。但在 GitHub 现有的 Git 架构里，多一份副本，写入就多一份负担，推送也会变慢。
GitHub 工程师 Brian Celenza 在 2026 年 10 月 6 日发表的工程文章中解释了这个矛盾：同一批副本既要可靠地保存仓库，又要承接读取请求。读写共用，在大量 Agent 同时工作的场景里开始吃力。
我关心的是，AI 把代码写出来之后，团队要花多少工作才能接纳这些修改。多个 Agent 可以同时准备代码，但默认分支最后接受哪个版本、这个版本有没有通过验证，仍然需要明确的规则。这次基础设施改造，实际上是在重新划分：哪些工作可以并行，哪些引用更新必须取得一致。
提交变多，压力不只来自仓库大小
GitHub 报告，2026 年 9 月，开发者与 Agent 合计产生了 73.8 亿次提交，是 2025 年 9 月的五倍以上。这是平台自己报告的活动量，包含人和 Agent，不能全部算在 AI 头上，更不能当成交付价值的增长。
提交、推送和合并也不是同一个指标。一次推送可以带上多个提交，一次提交又可能触发若干检查。提交数不能直接换算成推送次数。
原文描述的高负载仓库里，大型工程团队、繁忙的 CI 和越来越多的 Agent 同时活动。Agent 在紧密的工作循环中反复提交，或者把进度保存成检查点，每一次推送的等待时间，都会累加进它完成任务的总时间。同一个分支的新版本，还会被 CI、代码扫描和其他自动化反复拉取。
这与“仓库里存了多少代码”是两个问题。一个改动很小、却频繁更新的仓库，同样会不断制造写入和验证工作。分支越开越多，而最终要合入的目标分支并没有跟着增加。
所以我不会只拿代码体积判断团队能开多少个 Agent。提交频率、同时更新的分支数量，以及每次变更会启动多少后续任务，也都要看。
读取副本为什么会拖慢写入
现有架构叫 Spokes。按原文介绍，它默认在若干文件服务器的本地磁盘上保留五份完整仓库，既提供冗余，也分担读取。推送更新引用时，系统用一套需要足够多副本达成一致的协议，让 CI、网页和 API 看到一致的仓库状态。
这里的副本不是随时可以丢弃的缓存。每一份都保存着权威数据，所以多加一份副本，写入和一致性协调的工作就跟着多一份。GitHub 在文章里直接指出：为吸收读取压力而增加副本，会让写入变慢。
维护工作也挤在同一批机器上。压缩整理仓库数据、清理不再需要的对象，都可能与正在进行的推送和拉取争用资源。某台机器丢失之后，恢复要重建一份完整副本，不是补起一个处理请求的进程就够了。
这套设计并非一开始就不合理。本地磁盘读取快，完整副本一次解决了可靠保存和分担请求两件事，原文也承认它对多数仓库仍然有效。这种安排的问题，集中出现在活动特别密集的仓库。
存储可以分开，分支更新仍要协调
GitHub 给出的新方向，是把权威仓库数据放进 Azure Blob Storage，由处理 Git 请求的计算节点缓存所需的数据。读取压力增加时，可以增加这些计算节点，不必再为每个节点建一份参与写入的完整持久副本。
仓库压缩整理和垃圾回收，则交给单独的后台工作进程。计算节点发生故障时，替代节点可以从持久存储读取数据，并逐步填充缓存。恢复服务不必等整份仓库复制完成。
对象存储只回答数据存在哪里。分支应指向哪次提交，还需要另外决定。
举一个简化的例子：两个 Agent 都从提交 A 开始工作，分别生成 B 和 C。B、C 对应的数据都保存成功了，默认分支也不能因此在两者之间随意切换。一旦分支已经从 A 更新到 B，另一个仍以 A 为前提的更新就不能直接接受，需要重新检查分支状态，并决定如何处理两份修改。
Git 的引用更新文档提供了一个直观的参照：更新引用时可以给出预期的旧值，只有当前值仍与之匹配，更新才会成功。它说明了“新对象已经写好”和“分支已经接受修改”是两件事。这个参照并不代表 GitHub 新架构的内部实现。
原文的思路，正是尽量缩小必须统一协调的部分。引用更新需要一致的决定；而对象存储、对象连通性校验、秘密扫描等大量工作，可以和其他写入并行处理。这些检查需要并行处理，并非被删除。至于某项检查失败后怎样阻止或撤销引用更新，原文没有给出完整协议。团队不能据此省掉分支保护与必要审查。
我认为值得借鉴的是这种具体的职责划分。对象是否已经保存、分支指向哪里、修改是否满足团队的合并要求，回答的是三个不同的问题。这些职责分开之后，团队仍要验证几项修改合在一起能否正常工作。
合并队列为组合后的代码触发必要检查
假设两个 Agent 修改同一个服务：一个调整接口的返回值，另一个更新调用方的重试逻辑。它们各自基于旧版本跑测试，都通过了，合在一起却可能不兼容。这是作者构造的工程场景，不是 GitHub 披露的事故。
引用更新保证分支状态按规则变化，却不能证明业务行为正确。哪些检查必须针对准备合入的组合来执行，要由团队自己决定。
GitHub 的合并队列文档说明，队列会结合目标分支的最新版本和排在前面的修改，验证将要合入的代码。这里有一个容易漏掉的配置：如果必要检查由 GitHub Actions 执行，工作流还需要接收 merge_group 事件。只保留原来的 pull_request 触发条件，队列所需的检查不会自动运行，合并会因缺少检查结果而失败。
这类细节，比一句“团队已经启用合并队列”更能说明问题。开关打开了，不等于验证覆盖了新的工作方式；队列也不会替团队判断，哪些测试足以证明两项修改彼此兼容。
对于准备增加 Agent 并发量的团队，我会先做下面几项小范围检查。它们是我基于原文机制提出的建议，不是 GitHub 的统一配置方案。
| 场景 | 可以先调整什么 | 怎么判断是否有效 |
|---|---|---|
| Agent 频繁保存工作进度 | 区分只供自己恢复的本地检查点，与需要协作、备份的远端提交 | 推送等待是否减少，恢复和协作需求是否仍满足 |
| CI 反复拉取或构建同一版本 | 按仓库、提交、依赖锁定文件、构建配置和运行环境等输入，复用隔离的缓存或产物 | 重复下载和构建是否减少，有没有复用到错误版本 |
| 多个修改等待合入 | 为合并组合运行必要检查，再调整队列构建并发 | 排队时间、重跑次数和合并后故障是否改善 |
缓存还要遵守权限和隔离要求。同一个版本可以共享，并不代表不同仓库、不同信任来源之间可以随意共享产物。合并队列同样消耗构建资源：测试执行能力没有增加，却只提高同时运行的 Agent 数量，等待可能从提交之前挪到合并之前。
这些检查不要求团队先重写 Git 存储。可以先把一次修改从提交到合并的等待时间分段记录，看它到底卡在推送、读取、测试还是重新验证，再决定增加哪一种资源。
三十五倍是内部基准，还不是交付承诺
原文报告，新架构在内部基准中实现了最高 35 倍的写入吞吐，读取能力也能独立扩展。但它仍是一篇介绍建设方向的文章：新架构还在建设中，并没有宣布所有仓库已经迁移完成，也没有给出足以让外部团队复现实验的全部负载条件。
所以，这个数字能说明 GitHub 为什么愿意做这次改造，却不能直接用来估算普通团队引入 Agent 之后能快多少。真实的工作流里还有缓存冷启动、网络访问、测试耗时和合并冲突，瓶颈会随任务不同而转移。
原文同时要求保留分支保护、必要审查、审计记录等既有控制，我赞同这一点。写入能力再高，如果换来的只是更多无人处理的分支和等待检查的修改，对交付的帮助依然有限。
判断是否继续增加 Agent，我会看通过验证并完成合并的修改数量、每项修改的等待时间，以及合并后的故障，而不只看一天生成了多少提交。 当推送已经很快、队列却越来越长，下一笔投入应该先用来弄清队列为什么长。
留言