新智元报道

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倍多。

GitHub各仓库的忙碌程度天差地别：2026年8月，最忙的单个仓库承受约10亿次请求。纵轴每往上一格，数量多10倍。

据The New Stack报道，GitHub把这波增长主要归于「智能体需求」：

一批前所未有的新用户来了。它们24小时不睡觉，最大的爱好就是按保存键。

为什么备份越多

存得越慢？

看懂了智能体的疯狂，就更加懂得GitHub老架构的难处。

为了防丢，也为了分流读代码的人，GitHub默认给每个仓库存5份完整备份，分摊在5台服务器上。

这套设计在人类时代十分稳定：丢一份不怕，读的人多了还能分流。

GitHub也是靠这套老架构，托住了10亿个代码仓库。

可到了智能体时代，死穴暴露了。

第一个堵点在「存档」。

按老规矩，每存一次新代码，5份备份都要参与，最终速度由最慢的那台服务器决定。

这就好比公司请了5个会计合记一本账，每笔新账都要等5个人签完字才算入账，最慢的那个签完才算数。

而且，一次只能记一笔，前一笔没签完，后一笔只能排队。一旦查账的人变多，公司就得多请会计，可会计越多，签字流程就越长。

在老架构里，读和写互相拖后腿。GitHub越想靠加备份来分担读的压力，存档就越慢。

智能体偏偏每分钟都在存档，每一次都得等会计们签完字。

更危险的是，备份坏得太多，存档会直接停下。就好比会计病倒太多，这本账就没法再记。

第二个堵点在「合并」。

所有代码改动，最终都要汇入同一个主分支。

一年间，GitHub上的合并量涨到原来的近4倍，这好比上千辆车挤向同一个收费站。

排队到底有多慢？GitHub工程师在博客里算过一笔账。

一个仓库的备份分在两地时，GitHub自家机房离微软云约1600公里，来回一趟约25毫秒，存一次档要来回好几趟。

更要命的是，整个仓库一次只放行一笔写入。前一笔没存完，后一笔只能干等。

25毫秒，人类程序员连眨眼都来不及。可对智能体来说，这就是锁死效率的天花板：智能体干活有多快，取决于一次推送多快完成。

多年来，GitHub最引以为傲的稳，到了智能体时代，却变成了堵。

先砸硬件

机房的电都用完了

面对流量洪峰，GitHub的第一反应是加机器。

截至8月，GitHub已新增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故障波及Cursor部分服务，包括自动化和云端智能体，持续6小时6分钟。

Cursor状态页：8月17日，GitHub故障波及其部分服务，持续6小时6分钟。

代码托管有了替代方案，智能体的工作流却还离不开GitHub。

那天下午，Hacker News上一个「有什么GitHub替代品」的帖子被顶到了649分。代码大本营也会掉链子，程序员们开始认真找备胎。

更魔幻的是，GitHub一边被智能体挤满，一边还在造更多智能体。

在10月28日的大会上，GitHub又推出了一批让智能体并行干活的新工具。

当AI把写代码的成本越打越低，瓶颈不会消失，只会向后移。

先是「写得出」，大模型解决了。现在是「存得进」，GitHub正在拆账本、换底座。

接下来是「合得上」。

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

编辑：元宇