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 的一次意外，而是整个软件开发行业进入新时代的一声响动。

本文来自微信公众号 “极客公园”（ID：geekpark），作者：宇航猿，36氪经授权发布。