一个月 4733 亿次 Git 事件，73.8 亿次 commit。

这不是某个云厂商在讲未来容量规划，而是 GitHub 刚刚披露的 2026 年 8 月和 9 月数据。更扎眼的是，一个最忙的仓库在一个月里收到了约 10 亿次请求。GitHub 说，它准备重建底层 Git 基础设施，目标不是让 clone 再快一点，而是为了扛住 Agent 参与开发以后持续发生的并发读写。

很多人看到这种消息，第一反应大概是，AI 写代码多了，服务器自然就得扩容。这句话没错，但它太轻了。真正麻烦的地方在于，Agent 改变的不是代码产量，而是变更抵达仓库的节奏。

一个人写完一段逻辑，可能隔十分钟才 push 一次。一个 Agent 会在搜索、修改、跑测试、修复、保存检查点之间不断提交。再乘上并行任务、PR、CI、代码扫描和自动合并队列，Git 不再只是人类下班前点一下的同步工具。它变成了整个自动化工厂的事件总线。

这篇文章想拆开聊聊 GitHub 这次重建到底在重建什么。对做 Java、Spring 服务，或者正在把 LangGraph、编码 Agent 接入工程的人来说，里面有一个很实用的提醒，别只盯着模型能不能生成代码。你最终会被变更系统的吞吐、治理和可观测性反噬。

最先坏掉的不是模型，而是提交路径

GitHub 给出的增长不是线性的。

从 2025 年 9 月到 2026 年 8 月，平台每月 Git 事件从 2182 亿次翻到 4733 亿次以上。push 从每月 6.9 亿次涨到 33.5 亿次，同比增长 4.9 倍。9 月的 73.8 亿次 commit，又比一年前高了五倍多。GitHub Actions 同月执行 32.6 亿次，也超过去年同期四倍。

这些数字放在一起，才看得出问题的形状。

以前，一次 push 通常是一个开发者阶段性完成工作后的结果。现在它更像一个中间状态。编码 Agent 每完成一个小动作都可能需要 checkpoint，避免上下文中断或任务失败后从头再来。一个 Agent 的体验就会被单次 push 的尾延迟卡住，哪怕这段延迟在人类眼里根本感觉不到。

而且 Agent 很少独自工作。一个需求会拆成多个 worktree 或分支，分别探索接口、补测试、改配置、修回归。每个分支还会触发构建、单测、依赖扫描和部署预览。于是一次写入，不是落库就结束，它会在下游放大成成百上千次读。

GitHub 的描述很直白，CI 和代码扫描可能会在每分钟内 clone 或 fetch 同一个分支尖端数千次。

这就是 Agent 时代和传统开发最大的区别。产能增加并不会均匀地落在所有组件上，它会先集中冲击那个所有人和所有自动化都绕不开的共享点。对 Git 而言，这个点就是 ref 更新、对象持久化和由此触发的读取洪峰。

你想想看，一个 Spring Boot 单体服务里，十个开发者一天合十几个 PR，和一百个 Agent 同时在几十个分支上试错，虽然都叫 Git 工作流，系统承受的根本不是同一种压力。

老架构并不差，它只是把两件事绑得太紧

这次技术细节里，我觉得最值得看的一段，是 GitHub 对既有 Spokes 架构的解释。

它过去会在多台文件服务器的本地磁盘上保留完整仓库副本，默认是五份。副本带来两个好处，低延迟的本地 Git 操作和冗余读能力。一次 push 更新 ref 时，系统会用三阶段提交和 quorum，让 CI、Web 页面和 API 看到一致的仓库状态。这套设计支撑了 GitHub 数十亿仓库，不能因为今天有了 Agent 就把它说成落后。

问题是，耐久性和读扩容复用了同一批副本。

想多接一些 fetch 流量，就得增加副本。可每一份副本又都要参与写入，于是一次 push 的完成时间会被最慢副本拉住。读副本越多，写路径上的协调越重。失去一个副本，读容量也跟着少。若失去 quorum，写入就得停。

这是一笔典型的分布式系统旧账。早期把存储副本同时当作服务副本，简单、稳定、好理解。流量还不极端时，它甚至很优雅。可当读和写都被自动化放大，这两个需求的资源曲线开始背道而驰。

读请求可以靠缓存、更多 worker、更多副本摊开。写请求不行，至少 ref 更新需要一个确定的顺序和一致的结果。你不能让两个 Agent 都以为自己成功更新了同一个分支尖端，然后等系统慢慢挑一个正确答案。

所以 GitHub 遇到的不是传统意义上的存储不够，而是协调成本开始成为业务吞吐的上限。

这也解释了为什么单纯加机器往往治标不治本。对读路径有效的扩容，可能恰好让写路径更慢。很多团队把 CI 卡顿归因成 runner 不够、网络慢、缓存没命中，最后发现真正拖住全局的，是那个必须让所有人达成共识的小步骤。

先把关键路径缩到只剩必须一致的那一小段

GitHub 新架构的第一个原则叫最小化协调。翻译成工程语言，就是别让每个写入步骤都排队等同意。

一次 push 包含很多工作。Git 对象要存储，连通性要校验，secret scanning 要跑，策略要判断，最后才是 ref 从旧 commit 指向新 commit。这里面真正必须串行达成一致的，主要是最后那一下 ref 更新。其余工作很重要，但未必要把它们都塞进同一个全局临界区。

GitHub 的做法是把对象存储、连接校验、密钥扫描等尽量并行化，让 ref 更新保留必要协调。这样 push 的 acknowledgement 不再被一堆可并行工作拖住。

这听着像常识，但在工程里很容易被做反。我们常常把安全校验、审计写入、索引更新、通知分发都塞进一个同步事务，理由是看起来更安全。结果是每多一条规则，所有写入一起变慢。Agent 把提交频率提上来以后，这种设计会非常快地露出裂缝。

对自建 Agent 平台，我会建议把一次变更明确分成三层。

第一层是不可妥协的 commit point。比如分支保护、合并队列的版本判断、制品签名是否存在、谁有权更新目标 ref。这一层必须强一致，而且要短。

第二层是准入检查。比如测试是否通过、SAST 是否扫描完成、依赖许可证是否合规。它们很关键，但很多情况下可以由状态机驱动，在写入后异步推进，而不是和对象上传抢同一段关键路径。

第三层是派生工作。索引、向量检索、变更摘要、通知、指标聚合都应该是可重放的。哪怕消费失败，也不该让仓库的基本写入停在那里。

这套划分跟 Spring 里把核心事务和 @TransactionalEventListener 的后置处理分开，其实是同一种思路。不是所有事都要在一个事务里做完。事务越胖，吞吐越差，失败边界也越难看清。

当然，异步不是免死金牌。你得回答哪些检查失败会阻止 merge，哪些只会标红，状态如何回填，重复投递怎么幂等。没把这几件事定义清楚，所谓解耦只是在把复杂度藏到队列后面。

读和写分家，Agent 的突发流量才不必拖慢所有人

第二个原则更像一次底层换代，存储和计算解耦。

GitHub 计划把权威仓库数据放到 Azure Blob Storage，把请求服务交给更轻量的计算 worker。worker 缓存数据服务 fetch、clone 等读取，读取能力可以按流量独立扩展。GitHub 明确提到，面对 CI fan-out、Agent fleet 和大 clone 的读洪峰，不再需要为了扩读去新增每次写都要参与的耐久副本。

这不只是把本地盘换成对象存储。

旧模型里，一台机器既保存真相，又负责对外响应。机器挂了，容量和一部分耐久保证一起掉，恢复需要重建一个完整仓库副本。新模型里，权威数据在耐久层，worker 更接近可替换的服务层。worker 消失类似一次较重的 cache miss，新 worker 能很快开始服务，再按流量逐步补热缓存。

这种思路在服务端并不陌生。数据库主从、对象存储加 CDN、Kubernetes 无状态 Pod，都有相似的影子。但把它应用到 Git 仓库并不轻松，因为 Git 的内容寻址、packfile、ref 语义和客户端协议都要求性能与一致性同时在线。

这里有一个很现实的 trade-off。读写分家以后，系统确实更容易弹性扩容，但 cache 一致性、冷启动尾延迟、对象布局和后台 compaction 会变成新的难题。GitHub 也没有宣称魔法消失了。它选择把 compaction 和垃圾回收移出在线 serving path，交给直接操作耐久存储的独立 worker。繁忙仓库可以持续整理，而不该让维护任务挤占 push 和 fetch。

我很赞同这个取舍。一个业务系统最怕把打扫房间和接待客人安排在同一条走廊里。流量小的时候大家相安无事，流量大时，GC、索引重建和备份都可能变成用户看得见的抖动。

不过别误会，这并不等于每个团队都该把 Git 装进对象存储。绝大多数公司没有 GitHub 这种量级，也不该为了追逐架构感引入一堆服务。GitHub 的新方案是为月度千亿级事件和最热仓库的极端并发准备的。对几十人的团队，先管好大仓库、二进制文件、CI 缓存和无意义的重复流水线，收益会大得多。

真正危险的不是写得太快，而是没人知道谁改了什么

Agent 带来的另一个错觉是，既然代码可以批量生成，那就让它们尽量并发干活。站在产能的角度这很诱人，站在软件治理的角度却有点吓人。

GitHub 在文章里反复强调，分支保护、强制 review、审计日志和可观测性不能因为要提高吞吐就被牺牲。这个姿态是对的。一个能在几分钟内开出几百个 PR 的 Agent，如果没有清晰的授权边界和审查机制，制造的不是研发效率，而是需要人类慢慢排雷的变更债务。

很多朋友可能遇到过这种情况。Agent 一口气把测试补齐了，PR 看上去绿油油，合并后才发现它把错误假设复制进了十几个模块。单个改动都小，连起来却很难回滚，因为每个改动都在另一个改动上继续生成。

所以 Agent 平台的治理单位，不该只是一段 prompt 或一次模型调用，而应是一条可追溯的变更链路。至少要能回答四个问题。

  • 这个分支由哪个任务创建，任务的输入和工具权限是什么
  • 它基于哪个 commit 开始工作，中途读过或改过哪些关键文件
  • 哪些自动化检查给了它绿灯，检查用的规则版本是什么
  • 最后是谁批准它进入主干，出了问题如何把影响范围收回来

这四个问题看上去偏管理，最后都会落到工程数据面。没有稳定的 commit、PR、构建和审计事件，LangGraph 再漂亮的编排图也只是一个会调用工具的聊天机器人。

我自己的判断是，未来两年里，成熟团队的竞争差异不会只在模型选型。更关键的是能否把 Agent 的高速试错关进一个低摩擦、可审计、可回放的变更系统。你要让它跑得快，也要让它撞墙时留下刹车痕迹。

给正在做 Agent 工程化的团队，一份不浪漫的检查表

如果你现在还没到需要重建 Git 基础设施的规模，也完全可以从这次 GitHub 的思路里拿走几件很具体的事。

别把 Agent 的成功率只算成任务完成率。 再加四个数，单次变更从开始到可审查的时间、每次变更触发的 CI 成本、失败任务的可重放率、人工 review 的平均等待时间。前两个告诉你系统有没有被高频小提交拖住，后两个告诉你自动化到底是在省人，还是在转嫁工作。

把分支当作隔离单元，不是临时垃圾桶。 一个 Agent 一个任务分支，限制它能碰的目录和权限。大任务先拆成可以独立验证的小变更。这样即使 Agent 走偏，影响也停在一条明确的链路里，而不是污染一个谁都说不清的共享工作区。

让 CI 对 Agent 友好，但别纵容重复劳动。 代码格式化、轻量静态检查可以快速反馈。全量集成测试、镜像构建和安全扫描要通过依赖关系、内容 hash 或合并队列做去重。否则 Agent 每次保存都触发整套流水线，GitHub 的 32.6 亿次 Actions 只是一个提前到来的账单。

把异步事件做成可回放的事实记录。 变更摘要、知识库索引、通知和指标，都不要只存在某个 Agent 的上下文窗口里。用持久事件和幂等 consumer 保存过程。人要接手时，看到的应该是一条可复原的任务轨迹，不是一句「我已经完成了」。

保留一个慢下来的人类闸门。 这话听着有点扫兴，但默认分支、生产配置、权限变更和数据迁移，仍然值得更慢的 review。不是说 Agent 不可靠，而是高频自动化扩大了错误的传播半径。刹车系统平时显得多余，出事那一分钟才知道它有多值钱。

GitHub 把新架构概括成，读写能独立扩展，失败后可以优雅恢复。其内部 benchmark 已经做到最高 35 倍的写吞吐提升。这个数字当然来自特定负载，不能直接搬到任何团队的容量表里。但方向已经很清楚，Agent 规模开发的底座，不会是更多 CPU 和更大的模型，而是更少不必要的协调、更清晰的权威数据边界，以及更严格的变更治理。

一开始那 73.8 亿次 commit 看上去只是个很夸张的数字。读完 GitHub 的设计，它更像一次提前响起的报警。

当代码生成越来越便宜，能安全地接住变化，才会变成真正稀缺的能力。

参考资料