GitHub 重建 Git 基础设施的消息由 GitHub 在 2026 年 10 月 6 日通过官方博客宣布。触发这次重建的不是普通用户增长，而是智能体开发带来的并发读写：开发者和智能体同时在同一仓库里高频提交，旧架构开始吃不消。
先看数据涨到了什么程度
GitHub 公布的数字很直观：月度 Git 事件量在一年间翻了一倍多，2026 年 8 月达到 4733 亿次；2026 年 9 月，开发者和智能体合计产生了 73.8 亿次提交，是一年前的五倍多，推动量同比涨 4.9 倍，合并请求量接近四倍，GitHub Actions 在 9 月运行了 32.6 亿次。最忙的单个仓库在 8 月收到约十亿次请求。对单台智能体而言，每做一步就提交或打检查点，推送延迟这种人几乎无感的开销，直接变成它的速度上限。
旧架构卡在哪里，新架构怎么拆
现有架构把每个仓库在多台文件服务器上存完整副本，副本既管持久保存又管读请求，扩读能力就得加副本，而每次写入又要等最慢的副本确认，读扩得越多写越慢。GitHub 的新思路是两条：一是把协调压到最小，只让引用更新这一步走一致性确认，对象存储、连通性校验、安全扫描等重活并行处理，仓库维护也挪到独立机器后台做；二是把存储和计算分开，权威数据放进 Azure Blob Storage，读请求由可增减的轻量缓存节点承接，节点挂掉更接近一次缓存未命中，而不是丢一份仓库副本。
对团队意味着什么
GitHub 称内部基准里新架构写吞吐最高提升到 35 倍，读 capacity 可独立扩展，且不需要用户改工作流，分支保护、必审、审计日志等既有控制会保留。这次重建还在进行中，后续还有专门讲新架构的文章。对正在铺开多智能体并行开发的团队，眼下能做的判断是：瓶颈已经从模型能力转到代码基础设施，选平台时要开始问并发推送、合并队列和 CI 扇出读的上限，而不是只比模型榜单。
