前幾天 Mitchell Hashimoto 突然在個人的 Blog 宣布 Ghostty 會離開 GitHub，嚇到了不少人，畢竟 Github 幾乎是現在 AI 時代最紅的選擇，而且他也不是那種剛用 GitHub 沒幾年，服務稍微不穩就想搬家的新手，他是 GitHub user 1299，2008 年 2 月註冊，他用了 18 年的 Github，幾乎每天打開它，但他在文章裡寫他現在真的很氣，過了 18 年，該走了。
Mitchell 的抱怨其實只有一件事
我找到源頭文章完整看了一次，因為透過轉貼的摘要多半說的是他的情緒，是那種「他也受不了了」的字眼，但我更想知道的是他的判斷跟原因。
他抱怨的不是介面，不是 Copilot，也不是那些大家常罵的 product decision，他抱怨的只有一件事，GitHub 的穩定度正在影響他每天的基本工作，GitHub Actions 跟周邊基礎設施的不穩，讓他連 PR review 都做不了，他做了一份很手工但很誠實的紀錄，每天早上在日誌上看一下，這天如果有 GitHub outage 影響到他的工作，他就劃一個 X，沒有 dashboard，沒有漂亮圖表，也沒有自動化監控，一個工程師每天打開工具，每天被工具擋住，然後留下來的是一排 X。
「不是好玩的地方了，我想留下來但他不想要我留下來」，他這樣寫，這句話看起來很情緒化，但我對這句話很有感覺，他寫過 Vagrant、Terraform、Vault，會讓他把一個技術平台寫到 irrationally personal 的程度，背後已經不是單純的情緒問題了，我了解。
不是只有他一個人這樣覺得
隔天 Jonas Hietala 寫了一篇文章，也宣布要從 GitHub 離開搬到 Codeberg/Forgejo[12]，再往前翻，byteiota 整理了 2 到 3 月之間 GitHub 的 8 次重大 outage，SLA 根本不達標[11]，Aakash Gupta 在 X 上講得更直接，光 2 月就有 37 件 incidents，出事頻率比以往高了 23%。
GitHub 自己 3 月份的 availability report 更清楚的標示出 3 月 5 日從 16:24 到 19:30 UTC，有 95% 的 GitHub Actions workflow 沒辦法在 5 分鐘內啟動，平均延遲 30 分鐘，另有 10% 的 run 直接因為 infrastructure error 失敗(當時我前公司也是經歷一場混亂)[3]，當一個 CI/CD 平台的 workflow 大半個下午動不了，這已經不是「等一下就好」，而是 PR 被整段卡住，那天我們都開玩笑要提早下班了。
Solomon Neas 在他的獨立分析[2]裡又補了兩件事，4 月 23 日 merge queue 出了一個 correctness 缺陷，影響 658 個 repo、2,092 個 PR，被 squash merge 出來的 commit 是錯的，甚至可能蓋掉預設分支上的工作，4 月 27 日，也就是 Mitchell 寫文那天，Elasticsearch 過載 6 小時 15 分，所有 search-backed 的 UI，包括 PR 清單，都有可能直接變成空白頁，換句話說，狀態頁綠色不代表一切沒問題。
為什麼是「現在」？
GitHub 不是第一天有 Actions，也不是第一天有大型開源專案，為什麼會在這個時間點突然被這麼多人感覺到不穩？回頭看 2 月的 availability report[4]，裡頭寫了一句話，後來也被 InfoQ 的報導引用[5]，Github 說現在的 Loading 成長太快，他們需要設計出 30 倍於當下規模的容量，而這波加速主要來自 agentic development workflows，從 2025 年 12 月中以來一路陡升，當然，GitHub 並不會說「AI 的大躍進把我們打掛了」，他們說的是 scaling challenges、architectural coupling、limitations in handling load，這些聽起來很工程，也很公關的用字，但你把其他數字放上去一起看，就會看到一個合理的輪廓。
HUMAN Security 在 2026 年的 AI traffic benchmark[6]裡提到，2025 整年 AI 驅動的網路流量翻了三倍，其中 AI scrapers 流量成長 597%，agentic AI 流量成長 7,851%，OpenAI 一家就佔所有 AI bot 流量約 69%，Meta 16%、Anthropic 11%，這些流量雖然遍佈了網路上的每一個角落，但是他們有很大一部分會流向 GitHub，而這讓 Github 變成承接這些流量的瓶頸，因為訓練資料、即時搜尋、agent 互動，都需要 Code，而 Github 是大多數人的選擇，甚至是上面這些 AI 平台的預設推薦。
更尷尬的一點是，GitHub 2 月才推出 Agentic Workflows[7]，讓 AI agent 可以在 GitHub Actions 裡由 issue、PR、CI events 觸發，自動 triage bug、寫 fix、跑 test、開 PR，然後現在這件事情似乎變成了他們掛掉的元兇。
我不會把這件事定調成「AI 導致 GitHub outage」，這有點無腦也省略了太多 Context (AI 的時代我們都要注意 Context~ ha)，但至少幾件事情是確定的，一個是外部 AI 流量開始把 Github 推成高壓區，另一個是 GitHub 自己也把更多 agent 工作放進 Actions 這條 Pipeline 裡，而原本的 10X capacity 的計畫也被修正成 30X，原本以為要追上的車，突然又開的更遠了。
AI 自動化?
Mitchell 他被 Actions 中斷卡住兩個小時時，他知道自己正在等，他可以先去喝杯咖啡，可以去做別的事，也可以坐下來寫一篇道別信，但綁在 GitHub Actions 上的 AI agent 通常沒這種判斷力。
現在主流 AI agent 的 PR 流程大致長這樣，agent 看到 issue 或人類的指令，生 fix，開 branch，push，開 PR，等 GitHub Actions 跑 CI，看結果，必要時改 code，再 push，再等 CI，這條 Pipeline 每一步都倚賴 Actions 能在合理時間內回 signal，當 Actions queue 被塞到 30 分鐘以上，agent timeout 之後又 retry，retry 之後重新進入新的 workflow run，這個停不下來的迴圈又會回頭加重 Actions 的 Loading。
更尷尬的是，當 search-backed UI 變成空白頁，agent 的 list/inspect 動作，比如查 PR 狀態、找相關 issue，也會拿到空結果，這時候 agent 不一定知道自己是「沒有結果」，還是「拿不到結果」，而這種差別對自動化 pipeline 來說很要命，人會在當機時停下做別的事，agent 會在當機時產生更多壓垮系統的調查跟請求。
我在自己的 Agent Team 裡也碰過類似情況，但當系統開始降級，Agent 還是照著流程持續發 Request、Child Process，一但進入這個 pattern，被壓垮的通常不是系統，而是自動化流程，因為它開始拿不到訊號，開始誤判，開始重試，最後把自己卡在一個看起來很努力、實際上沒有前進的迴圈裡，而對倚賴 GitHub Actions 跑 CI、跑 agentic workflow、跑 PR 自動化的團隊來說，GitHub 已經不只是一個 git host，它已經變成 Pipeline 裡頭的一條窄單行道，而且在這條單行道裡，人類塞車時會抱怨、暫停，但 AI agent 塞車時會繼續踩油門。
接下來會？
GitHub 已經公開道歉，他們 CCO 那句「I’m sorry. The team is going to keep working to make GitHub something you can come back to with real proof」[10]表現出 Github 的誠意，他們也宣布要往 Azure 基礎設施搬遷來提升容量(你認真？Azure？)，但 Solomon Neas 的判斷說得沒錯，這已經不是 capacity 問題了，這更是技術債(engineering debt)爆發的狀況，feature flag 沒蓋好，讓未發布 code path 進了 prod，test coverage 漏掉 multi-PR squash merge，merge correctness 沒監控，Elasticsearch 沒做 load shedding，這些問題不是多加幾台機器就會不見的，你把容量補上去只是延後發生的時間，等到系統更大、流量更高、AI 更聰明之後，你要還的利息就更多、下一個結構性瓶頸還是會撞到。
Mitchell 是個人開發者，他可以離開，可以慢慢拆 dependencies，慢慢搬 issues，但綁在 GitHub Actions 上的企業 CI、AI agent 工具鏈、agentic workflow 沒辦法說走就走，這也是為什麼他的宣告會引發這麼大的迴響，因為很多人看完之後問的下一個問題不是「他要去哪」，而是「我能去哪」(對，我能去哪？)。
或許接下來幾個月會有更多開源計畫跟著走，Codeberg、Forgejo、自架 Gitea 這些方案的能見度會升高，但對重度倚賴 AI 自動化的團隊，更實際的問題不是要不要搬家，而是當你的 PR 流程跟 GitHub Actions 綁在同一條鋼索上，你有沒有 Plan B？你有足夠的框架跟方法論來應對這些變化？還是你追求的只是現在能動的 Working System？Mitchell 的日記、GitHub 自己的 30X 數字、Solomon 算出來的 Actions 90 天 99.38% uptime，這些數據都在告訴我們，這條鋼索短期內大概不會突然變穩，甚至有可能再斷一次。
我想大家也不會想到，這波 AI 浪潮第一個提早交卷的不是 GPU，不是模型，不是那些我們每天掛在嘴上的 Token 成本，而是大家以為理所當然、每天早上打開就會在那裡的 git host，回頭看看：「我想留下來，但他不想要我留下來」，我想是很多人面對的問題，感受大家都不一樣，但同樣的都還是要問「我能去哪？」。
參考資料
[1] Mitchell Hashimoto — Ghostty Is Leaving GitHub
https://mitchellh.com/writing/ghostty-leaving-github
[2] Solomon Neas — GitHub Availability in April 2026: Merge Queue Corruption, Search Collapse, and What the Status Page Misses
https://solomonneas.dev/blog/github-availability-agentic-load-report
[3] GitHub Blog — March 2026 availability report
https://github.blog/news-insights/company-news/github-availability-report-march-2026/
[4] GitHub Blog — February 2026 availability report
https://github.blog/news-insights/company-news/github-availability-report-february-2026/
[5] InfoQ — GitHub Acknowledges Recent Outages, Cites Scaling Challenges and Architectural Weaknesses
https://www.infoq.com/news/2026/04/github-outages-scaling/
[6] HUMAN Security — 2026 State of AI Traffic & Cyberthreat Benchmark Report
https://www.humansecurity.com/learn/resources/2026-state-of-ai-traffic-cyberthreat-benchmarks/
[7] GitHub Blog — Automate repository tasks with GitHub Agentic Workflows
https://github.blog/ai-and-ml/automate-repository-tasks-with-github-agentic-workflows/
[8] InfoQ — GitHub Agentic Workflows Unleash AI-Driven Repository Automation
https://www.infoq.com/news/2026/02/github-agentic-workflows/
[9] The Register — Hashicorp co-founder Mitchell Hashimoto says GitHub ‘no longer a place for serious work’
https://www.theregister.com/2026/04/29/mitchell_hashimoto_ghostty_quitting_github/
[10] The Register — GitHub says sorry and says it will do better as uptime slips
https://www.theregister.com/2026/04/29/github_says_sorry_and_says/
[11] byteiota — GitHub’s Reliability Crisis: 8 Outages in 2 Months
https://byteiota.com/github-reliability-crisis-three-nines/
[12] Jonas Hietala — From GitHub to Codeberg/Forgejo
https://www.jonashietala.se/blog/2026/04/28/from_github_to_codebergforgejo/
支持這個系列
如果這系列文章對你有幫助，考慮請我喝杯咖啡
請我喝杯咖啡
