GitHub 重建 Git 底座：月度 4733 亿次事件，基础设施要重新算账

结论：智能体把 Git 从「人类协作工具」推成了「机器吞吐系统」

GitHub 宣布重建 Git 基础设施，以支撑智能体规模开发带来的高并发读写负载。给出的数字很直接：2026 年 8 月 GitHub 月度 Git 事件量达 4733 亿次，一年翻倍以上；2026 年 9 月智能体与开发者共产生 73.8 亿次 commit，超过一年前的 5 倍；push 同比增长 4.9 倍。

这几个数字放在一起，说明的不是「用的人多了」，而是单个使用者产生的操作量在数量级上跳变。

三个要点

• 负载结构变了。 人类的节奏是「改一次、提交一次、偶尔推送」，天然自带节流。智能体的节奏是持续生成分支、频繁提交、反复试错，而且可以并行。原来按人头估算的容量规划假设已经失效。
• 瓶颈从存储转向请求。 仓库体积增长是线性可预期的，但每秒的对象读写在智能体场景下是超线性的。GitHub 选择重建基础设施而不是单纯扩容磁盘，说明压力主要在协议层与并发层。
• 平台重构会反向影响你的工作流。 当平台为「高频小提交」做优化，大仓库、超长历史、巨型 monorepo 的代价可能被重新定价；同时，这类改动通常伴随限流策略调整。

对你意味着什么

• 把仓库卫生当成工程问题。 分支数量、历史深度、大文件残留，这些以前「忍一忍就过去了」的问题，在智能体高频操作下会放大成实际的限流与等待。定期清理已合并分支、控制仓库体积，会越来越像必须做的事。
• 给智能体设提交预算。 允许无限试错等于允许无限请求。建议给自动化流程设定提交频率上限和分支存活时间，避免一个跑飞的智能体把配额耗光。
• 监控 API 配额，别等报错。 平台侧重构期往往伴随策略微调，提前观测响应头里的限流指标，比事后排查更省事。
• 别把智能体当「更快的开发者」。 它更像一个高并发客户端。用这个心智模型去设计 CI 缓存、并发限制和权限，会少踩很多坑。

需要说明的边界：以上是平台侧的公开数字，具体到你的组织是否会被限流、限到什么程度，取决于仓库特征，不能从总量数据直接外推。

一句话：基础设施的度量单位，正在从「多少人用」变成「每秒多少次操作」。

参考来源

• GitHub Blog：Building Git infrastructure for agent-scale development — https://github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development/