本文来自微信公众号： 极客公园 ，作者：宇航猿，编辑：靖宇，原文标题：《GitHub，被 AI 打穿了》
今年2月9日，北京时间深夜，全球数以千万计的开发者打开GitHub，看到了同一个页面。
不是404，比404更让人焦虑——是那个让所有工程师后背发凉的黄色警告条，加上状态页上一排排从绿色变成红色的指示灯。
github.com挂了。
API挂了。
GitHub Actions挂了。
Git操作挂了——就连Copilot也没能幸免。
那一晚，有人的CI/CD流水线在最关键的节点停摆，有人的自动化部署卡在了半空中，还有人在等待一个迟迟无法合并的PR——背后是一个等待上线的功能，等待的是真实用户。
事后GitHub发布了事故报告。根本原因，用技术语言说，是「一个负责认证和用户管理的，核心数据库集群过载」。但这几个字背后藏着一条触目惊心的触发链——
两天前，工程团队为了尽快给用户推送一个新模型，把一个「用户设置缓存」的刷新时间从12小时改成了2小时。就是这一个配置数字的改动。
结果，本来分散在12小时内完成的缓存重写，被压缩进了2小时，形成了一次密集的「缓存重写风暴」，异步任务队列被瞬间打爆，共享基础设施组件崩溃，连锁反应蔓延到了负责代理HTTPS Git操作的服务，最终导致整个平台的连接耗尽。
一个数字，从12改到2。
GitHub，是被自己改的一个配置打穿的。
但如果你只看到这一个配置改动，那你大概错过了这个故事最重要的部分。
01
不是一次意外，是十次意外
2月9日的事故，不是一个孤立事件。
事实上，2026年的前三个月，GitHub经历了至少8次重大事故。2月份单月就有37次大大小小的故障记录。GitHub的CTO Vlad Fedorov后来在博客里承认，这两个月GitHub没能维持它向企业客户承诺的「三个九」——99.9%可用性。
翻开这两个月的故障档案，你会发现一个奇特的规律：每一次事故，看起来都是不同的原因。
2月2日：Azure计算提供商出问题，GitHub Actions停摆近4小时，Copilot编码代理、CodeQL、Dependabot全部受牵连。
2月9日：缓存重写风暴，认证数据库过载。
3月5日：Redis集群故障，GitHub Actions 95%的工作流无法在5分钟内启动，平均延迟30分钟。
3月18日：Webhook延迟飙升到正常水平的32倍。
每一次看起来都是「意外」，每一次的直接原因都不一样。但Fedorov的解释把它们串成了同一个故事。他说，这些事故背后有三个共同的结构性原因：「快速的负载增长、服务之间的紧耦合导致局部故障扩散，以及系统缺乏对异常客户端的流量保护能力。」
用工程师的话说，GitHub的地基，已经开始在新负载的重压下出现裂缝。
而这个「新负载」，有一个具体的名字。
02
每周2.75亿次提交
📊关键数据
2025年全年commit总量：约10亿次
2026年单周commit量：2.75亿次
按此速度，2026年全年预计：140亿次（同比增长14倍）
GitHub Actions计算量：2023年每周5亿分钟→2025年10亿→2026年初某周21亿分钟
如果你是GitHub的基础设施工程师，2025年和2026年的监控仪表盘对比，大概会让你目瞪口呆。
2025年全年，GitHub处理了大约10亿次代码提交。这个数字本身已经很大了，是GitHub平台多年积累的结果。但到了2026年，单周的提交量就达到了2.75亿次。换算一下——如果按这个速度走完全年，2026年的总提交量将接近140亿次，是2025年全年的整整14倍。
这不是一条平滑增长的曲线，而是一道陡坡。GitHub的Actions计算量变化更能说明问题：2023年每周消耗5亿分钟，2025年翻倍到10亿，然后在2026年初的某一周，直接飙到了21亿分钟。
是什么在疯狂提交代码？
不是人类开发者。
GitHub的数据显示，AI Agent正在成为这个平台上最活跃的「用户」。Claude Code单独一个工具，现在贡献了GitHub所有公开仓库提交量的4.5%。每周260万次提交，而在2025年9月底，这个数字还只有10万——三个月内增长了25倍。
AI Agent开启的PR数量同样在爆炸。2025年9月，AI生成的PR大约是每月400万个，到2026年3月，这个数字跳到了1700万——四倍多，半年内。
有一个画面可以帮你理解这意味着什么。
以前，GitHub的「用户」主要是人类程序员。他们白天工作，晚上睡觉，周末休息，每次提交会思考，会犹豫，手速有上限。系统的负载跟着人类的作息走，有峰谷，可以预测。
现在，越来越多的「用户」是AI Agent。它们不睡觉，不休息，不犹豫，一个任务可以同时开多个并行的Agent，每个Agent每小时的提交量，轻松超过一个真实工程师一周的工作量。更重要的是，它们不只是在提交代码，还在不断创建新仓库——把仓库当成工作流的「输出产物」，而不是人类的「工作空间」。
GitHub的基础设施工程师们，面对的已经不是一个流量更大的同类问题，而是一个性质完全不同的问题。
03
Copilot的钱不够烧了
故障频发只是问题的一面，GitHub还有另一个更让人头疼的麻烦——算账的时候发现亏了。
Copilot最初的定价逻辑，建立在一个合理的假设上：用户主要是「辅助补全」式的使用，每次交互是短暂的，计算量可预测。个人版每月10美元，商业版每月19美元，按座位收费，这个模型在过去几年里运转良好。
然后，Agentic AI来了。
Agentic工作流和传统补全是两个物种。标准的代码补全，请求是线性的、可预测的，计算周期短暂。而一个Agentic编码session，可能运行几个小时，同时启动多个并行线程，进行多步推理、自我纠错、跨仓库重构——一个session消耗的token量，轻松超过一个普通用户一整月的订阅费用。
GitHub面对的局面是，少数重度Agentic用户，正在用几美元的月费消耗相当于几百美元的计算资源。
面对这个局面，GitHub的反应很直接——先控流，再改价。
今年年初开始，GitHub对Copilot启动了两套并行限流机制：session时长上限和每周使用量上限，两个维度都按照token消耗量乘以模型计算权重来算。与此同时，部分个人Copilot套餐暂停了新用户注册。
6月1日，GitHub完成了更根本的定价改革：Copilot全面切换按用量计费，用「AI Credits」取代原来的套餐费用，1个AI Credit等于1美分，使用量按token消耗实时计算。
按座位收费的时代，在Agentic AI面前，走到了终点。
这个转变不只是GitHub的烦恼。这是整个AI工具行业在2026年正在经历的一次集体定价危机——当AI开始替代人类执行完整的工作流，而不只是「辅助」人类工作时，所有基于「每人每月」的订阅逻辑都会失效。
04
30倍，不是10倍
回到基础设施问题。GitHub到底准备怎么应对这个「14倍增长」？
这里有一个细节，能说明问题的严峻程度：
2025年12月下旬，Agentic工作流突然开始加速。GitHub的工程师们意识到，10倍不够。到2026年2月，也就是那次严重停机之后，GitHub宣布需要按照今天规模的30倍重新设计架构。
不是扩容，是重新设计。
这两个词的区别很大。扩容是把现有的机器变多、把现有的数据库加内存——方向不变，只是规模变大。重新设计意味着，现有的架构假设在30倍规模下会系统性失效，必须从底层重新思考服务拆分、数据流、故障隔离的方式。
GitHub披露的具体方向包括，解耦关键服务以防止级联失败、引入背压机制和流量降级能力、为热点服务部署独立主机、消除单点故障，以及更完善的变更管理——避免「把缓存TTL从12小时改到2小时」这种操作在没有充分压测的情况下直接上线。
值得注意的是，GitHub并不孤单。
Stripe已经遇到了AI Agent批量创建账户的问题，AWS正在构建Agent专用的身份系统、日志系统和生产控制机制。这些动作不是未雨绸缪，而是监控仪表盘上已经出现了它们不得不解决的信号。
GitHub只是第一个被打穿的——因为它在AI工具链的最核心。
05
代码仓库，正在变成AI的排气管
停下来想一想这整件事的性质。
GitHub是什么？最直观的回答是，它是程序员存代码的地方。但更深一层，它是人类软件协作的基础设施——提交记录是协作的轨迹，PR是讨论的容器，Issues是意图的留存，Action是执行的管道。整套系统，是为人类的工作节奏、思维方式和协作模式设计的。
AI Agent改变了这一切。
当一个AI Agent一天可以提交几百次代码，每一次「提交」背后没有人类的思考和权衡，只有一个任务循环的进度步骤——代码仓库还是「协作的容器」吗？
当AI工具自动生成仓库、自动开PR、自动跑CI、自动merge——开发者还是这个流程的主体，还是说他们已经退化成了「审核者」甚至「旁观者」？
GitHub CTO在描述这次危机时，用了「负载快速增长」这个词。但这个词很可能低估了问题的本质——这不只是量的增长，是使用方式的质变。在旧模型里，GitHub是「开发者的工具」；在新模型里，GitHub正在变成「AI的排气管」，一个自动化工作流的输出管道。
这对GitHub意味着什么，其实还没有答案。30倍扩容能解决流量问题，但解决不了商业模式的再定义，也解决不了「谁是我的真正用户」这个身份问题。
最近有一个颇为意味深长的现象：GitHub在停机之后开了大量工程博客，非常详细地描述了每一次事故的根本原因，几乎达到了令人意外的透明程度。有人认为这是GitHub在主动建立信任，也有人认为这是在以透明度换取开发者社区的耐心——因为接下来的重构期，还会有更多不稳定。
一个平台，在被自己的成功打穿之后，需要把自己拆开重建——而这个过程本身，也是一次能不能撑住的考验。
2月9日那晚，那个等待PR合并的工程师，大概最终还是等来了绿灯。但他可能没有意识到，让他等待的那次宕机，不是GitHub的一次意外，而是整个软件开发行业进入新时代的一声响动。