GitHub一个月收73.8亿次提交：AI写代码，卡在存与合
AI写代码狂挤GitHub，其基建正被迫重修。
8月17日，全球程序员集体遇上了一次宕机。
代码写完点推送，进度条纹丝不动；自动测试卡住不动，合并请求提交不了，AI编程助手Copilot同样掉线。
这一停就是7个多小时。那天，全世界的开发者都在等它缓过来。
三天之后，GitHub首席技术官Vlad Fedorov发文致歉：
如果你那天正准备发布软件，是我们让你失望了。
他解释的原因是这样：流量创下新高，美国中部数据中心有一个关键组件没有同步扩容，压力随之蔓延，多项服务接连瘫痪。
GitHub把这起事故定性为「容量失败」。这已经是他们8月里第二次出大事故。
GitHub官方图表显示：8月17日故障期间，入口处的请求失败率一度超过50%。
其实早在3月和4月，Fedorov就发过文章，谈提升GitHub可靠性的做法。他在推文里说，这些工作到现在还在推进。
GitHub上的流量究竟涨到了什么地步？
今年9月，开发者和AI智能体在GitHub上共提交73.8亿次代码，比一年前多了四倍还不止。
人们还在惊叹AI写代码的速度，GitHub宕机却把一个问题摆上了台面：写出来的代码，往哪儿放？
答案就藏在GitHub这半年碰到的难题里：AI写代码的瓶颈，已经从「写得出」挪到了「存得进、合得上」。
谁在把GitHub挤爆？
先把程序员写代码的两个动作分开看：
提交（commit），是在本地给代码存个档；
推送（push），是把这份存档传到GitHub上。
人类程序员通常是写完一段才存一次档。AI智能体不一样，它是个「保存狂魔」。
GitHub工程师在官方博客里写道：智能体几乎每走一步，就要存一次档。推送次数也随之猛涨，达到原来的4.9倍，从每月6.9亿次冲到33.5亿次。
8月的时候，Hacker News上就有网友提出质疑：提交次数再多，GitHub真正要处理的还是推送，这个指标有水分。
很快就有人回击：「一次推送带100次提交，比只带1次提交更耗资源。」
这话的意思是，提交得推送了才会到GitHub，但一次推送里装的提交越多，GitHub要干的活就越重。
Hacker News网友围绕「提交次数算不算数」争论了起来。
这句回击正好点中GitHub的痛处：智能体偏偏最喜欢「碎碎存」。存得越碎，次数越多，压力就越大。
更麻烦的是，代码一上传，自动测试和代码扫描就一拥而上，同一份代码被反复拉取，推送之后跟着的是一连串「连环Call」。繁忙仓库每分钟的拉取量能到上千次。这场景有点像你刚交卷，几千个机器人同时扑上来批改。
9月，GitHub自动化流水线（Actions）执行了32.6亿次，比一年前多出4倍还不止。
各个仓库的忙闲差距也大得离谱：2026年8月，最忙的那个仓库独自扛下约10亿次请求。纵轴每升高一格，数量就翻10倍。
The New Stack的报道提到，GitHub把这轮增长主要算在「智能体需求」头上：
涌进来一批以前没见过的用户。它们不睡觉，一天24小时在线，最热衷的事就是按保存键。
为什么备份越多，存得反而越慢？
弄明白智能体有多能折腾，就更容易理解GitHub老架构卡在哪儿。
默认情况下，GitHub给每个仓库留5份完整备份，分放在5台服务器上，一是防丢，二是给读代码的人分流。
人类时代这套办法很稳：坏掉一份不慌，读的人多也能摊开。
10亿个代码仓库，就是靠这套老架构撑住的。
换成智能体时代，软肋就露出来了。
头一个堵点在「存档」。
老规矩是每存一次新代码，5份备份全都得动，最后快慢取决于最慢的那台机器。
打个比方，公司让5个会计合记一本账，每笔新账得5个人都签完字才算入账，谁签得最慢就以谁为准。
并且一次只记一笔，前一笔没签完，后一笔只能干等。查账的人一多，公司就得加会计，可会计越多，签字这道流程反而拖得越久。
老架构里读写互相绊脚。GitHub越想多加备份来分担读的压力，存档就越慢。
智能体却每分钟都在存档，每一笔都得等会计们签完字。
更险的是，坏掉的备份一多，存档会直接停摆。好比会计病倒太多，这本账就记不下去了。
第二个堵点在「合并」。
代码改动不管从哪儿来，最后都得汇进同一个主分支。
一年下来，GitHub上的合并量涨到原来的近4倍。上千辆车挤向同一个收费站，大概就是这个画面。
排队能慢到什么程度？GitHub工程师在博客里算过。
仓库的备份分处两地时，GitHub自家机房到微软云大约1600公里，来回一趟约25毫秒，而存一次档要来回好几趟。
更棘手的是，一个仓库同一时间只允许一笔写入通过。上一笔没存完，下一笔就得干等着。25毫秒对程序员来说连眨眼都嫌短，可智能体就卡在这个上限上：它干活能有多快，全看一次推送多快能走完。
过去这些年，GitHub最拿得出手的就是稳。到了智能体时代，这份稳反倒成了堵点。
先砸硬件，机房的电都用完了
流量涌上来，GitHub最先想到的办法是加机器。到8月为止，平台已经多出300多万个CPU核心和120PB存储。
尴尬的是，电跟不上了。Fedorov在复盘里写道：老机房的电力能撑多少硬件，他们就装了多少。
不只是机房自己的电用光了，整个机房所在地区的电力也到了顶。插座插满之后还想加机器，那就只能搬家。
于是GitHub加快了往微软云平台（Azure）迁移的脚步：5月时微软云只承担12%的工作量，8月这个数字已经涨到约58%。
从2026年初到8月，GitHub Actions每天完成的运行量由约1500万—3000万攀升到约1.15亿。
10月28日的GitHub年度大会上，基建数据又被刷新：今年累计新增400万个CPU核心、160PB存储（大约1.6亿GB），网络带宽多了每秒50Tb。
可微软高管Jay Parikh当天在博文里还是交了底：只靠加容量不够，架构也得动。砸钱堆硬件买来的只是喘口气的时间，底层架构的老毛病治不好。
换底座，把账本和柜台拆开
架构这把手术该怎么动？还是回到前面那5个会计的比喻。老办法是每个会计守一个柜台，怀里抱一本完整账本，一边接待查账的客人，一边低头记账。
新办法把账本收进总库，柜台只负责接待。代码统一存到微软云的大仓库里，防丢和备份都由仓库兜底，前面的服务器卸下包袱，专心处理请求。
这样一拆有三点好处。头一条是读写分开。来读代码的人再多，也拖不慢存代码的速度。前台柜台能随开随关，流量大了多开几个，流量走了就关掉，哪台坏了换一台马上顶上去。
第二条，多余的签字也砍了。一次推送里真正需要所有人点头的，只剩下「更新分支指针」这一步。往仓库里搬货、检查完整性、扫描泄露的密钥，各干各的，不用排队干等。
第三件事，是把后台的活儿挪出去。过去清理旧数据，是在接待客人的机器上顺手做，免不了跟正常请求抢资源。如今这类活儿交给专门的「清洁工」机器，在后台对着仓库慢慢收拾。
内部测试给出的结果是：新架构每秒能吞下的写入次数，最高提升35倍。
难的地方在于，这场伤筋动骨的大手术，得在GitHub照常开门的情况下做完。相当于一架客机正在万米高空飞着，还得把发动机换掉。
GitHub掉线，你的智能体也得停
有人可能会想，GitHub扩不扩容，跟普通开发者能有什么关系？
关系大了。
其实不管你用哪家大模型、套哪个智能体外壳，它写出来的代码，很多最后还是要推到GitHub上去。
8月17日GitHub宕机那天，Cursor发布了自家的代码托管平台Origin，外界把它看作GitHub的替代品。
可同一天，Cursor状态页也挂出了公告：GitHub故障波及其部分服务，包括自动化和云端智能体，持续6小时6分钟。
Cursor状态页的记录是：8月17日，GitHub故障波及其部分服务，持续6小时6分钟。
代码托管有了备选，智能体的工作流却还是绕不开GitHub。
那天下午，Hacker News上一个问「有什么GitHub替代品」的帖子被顶到649分。代码大本营也会掉链子，程序员们开始认真找备胎了。
更魔幻的一点是，GitHub一边被智能体挤满，一边还在造更多智能体。10月28日的大会上，它又推出一批新工具，让智能体并行干活。
AI把写代码的成本越压越低，瓶颈不会消失，只会往后移。先是「写得出」，大模型已经解决了；眼下是「存得进」，GitHub正在拆账本、换底座。
再往下是「合得上」。
GitHub的工程师自己也承认，下一道坎还是写入能力。把那套老办法带到10亿个仓库就到头了，下一个10亿带不过去。
再往后，是「谁来签字」。
GitHub在博客里写过一条原则：智能体干的活越多，代码的主人越要能审、能懂、能拍板，没审过的改动，不能进主分支。
在通往ASI的路上，这一步很关键。
AI已经会写代码了。可要让它真正把软件交付出来，整套按人类手速造的基建，都得重修一遍。
被逼到墙角的，不会只有GitHub一家。
微软高管Jay Parikh此前给出过一个相当大胆的判断：
人类有史以来写下的全部软件，加起来或许都占不到未来五年软件总量的1%。
就算这个判断只对了一半，等代码多到审都审不过来的时候，比CPU更紧俏的东西，会是一个随时点得下去的提交按钮，以及一个敢拍板按下合并的人。
参考资料：
https://github.blog/news-insights/company-news/github-universe-2026-evolving-every-layer-of-the-stack/
https://github.blog/engineering/building-git-infrastructure-for-agent-scale-development/
https://thenewstack.io/github-7-4b-commits-september/
https://thenextweb.com/news/github-universe-copilot-fusion-octoverse-agents
