Github 被自己養的東西壓垮了。

作者｜宇航猿

編輯｜靖宇

今年 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 的解釋把它們串成了同一個故事。他說，這些事故背后有三個共同的結構性原因：「快速的負載增長、服務之間的緊耦合導致局部故障擴散，以及系統缺乏對異?？蛻舳说牧髁勘Ｗo能力。」

用工程師的話說，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 的一次意外，而是整個軟件開發行業進入新時代的一聲響動。

*頭圖來源：Github

本文為極客公園原創文章，轉載請聯系極客君微信 geekparkGO

最近連微軟、Uber 這樣的大廠都在算 Token 的賬，甚至有公司一個月在這上面燒掉五個億。當大家都覺得大模型用不起的時候，行業里卻有人反著走，把文本、圖片、視頻三個模型的 API 全部免費開放了。

本期直播，極客公園對話 Agnes AI 創始人 Bruce Yang。我們不聊虛的，直接看現場 Demo 實測，聊聊「Token 免費」背后的商業和技術賬本。如果 AI 真的變便宜、變平民化了，中小團隊和普通人到底能怎么用起來？