GitHub宕機七小時，代碼世界的“權威源”第一次有了挑戰者

AGI-Signal2026.08.18 13:48 · 來自海外全文4155字00:00 / 11:13Cursor上線代碼託管平臺Origin，以一鍵遷移爭奪開發者代碼的“中心節點”地位。全球程序員依賴的“水電煤”，在一天之內斷了一次電，又被另一個人重新接上了。美東時間8月17日上午9點40分，GitHub官方確認正在調查“影響部分服務的性能問題”。故障迅速擴散，API請求、Actions、Webhooks、Issues、Pull Requests接連報錯，負責登錄的SAML、OIDC、SCIM身份認證和Team Sync也受到波及，Copilot同樣未能倖免。

據GitHub狀態頁披露，當天Web與API流量的錯誤率一度接近20%，歸檔和原始倉庫下載的錯誤率逼近50%。整個故障持續約七小時，其中核心服務中斷約三小時，全球開發者無法拉取代碼、運行CI流水線，AI補全功能也無法使用。幾乎同一時間，Cursor正式宣佈代碼託管平臺Origin向所有付費用戶開放測試版。這個被Cursor定位為“為Agent時代設計”的代碼託管平臺，支持創建倉庫、執行標準git操作、發起PR、合併代碼、管理權限，還支持將GitHub倉庫整體鏡像過來。其中最受關注的是一個“Detach from GitHub”按鈕，點擊後即可將Origin設為權威數據源，完成主客易位。

當天微軟股價收跌3.04%，市值蒸發約1120億美元。不過，此次下跌發生在美股科技板塊整體回調的背景下，Meta同期跌幅也超過3%，微軟的下跌並非單一事件驅動。GitHub出了故障，Origin恰好同一天開放測試。據多家媒體報道，Origin的發佈屬於既定計劃，與GitHub故障在時間上的重合更可能是巧合。各自的細節GitHub這次故障的嚴重性，在於它近乎“全鏈路”失守。開發者最常用的幾條路徑（拉取代碼、運行流水線、提交Issue、發起PR）全部中斷，連登錄都受到影響。一家掌握“全球絕大多數團隊權威代碼源”十餘年的平臺，暴露出代碼世界中樞紐帶存在單點風險。

Origin方面，Cursor的定位顯示，這是一套“專為Agent時代設計”的git託管平臺，不是編輯器套了層雲殼。它把GitHub的核心操作重新實現了一遍，涵蓋建倉庫、clone、push、pull、瀏覽代碼、開PR、review、合併、管理權限，一整套都在。它和GitHub之間的關係設計更值得注意，同一份代碼可以存在多個位置，但總得有一份具有權威性，出現分歧時以誰為準、CI從哪裡拉取、上線部署認哪一份。過去十幾年，這份“權威源”的資格都在GitHub手中，如今Origin提供了一個按鈕，可以一鍵切換。

兩件事放在一起，GitHub的癱瘓只是一個導火索，Cursor真正要爭奪的是“權威數據源”這個位置。這個位置之所以現在能被挑戰，是因為底座的使用者群體正在發生變化。理解Origin，得先放下“這是Cursor版GitHub”這個印象。它的意圖藏在幾個面向Agent的設計中，雖然目前測試版只放出了第一批基礎功能。堆疊式PR。Agent傾向於大批量修改代碼，一次動數十個文件並不罕見，全部塞進一個PR，人工reviewer難以處理。Origin允許將一個大變更拆分為多個小PR，按依賴關係堆疊，用可視化依賴圖展示，從結構上緩解“人工審查負擔過重”的問題。合併隊列。

一個倉庫中十個Agent各自修改一批代碼、各自提交PR，CI全部通過。先合併哪個？合併一個之後，其餘九個的測試結果是否仍然有效？傳統GitHub處理這種場景相當吃力，合併衝突、CI重跑、反覆rebase。Origin的合併隊列支持自動排序和衝突檢測，保證主幹CI始終為綠，並在合併層內置AI引擎自動解決衝突，減少人工介入。機器可讀的審查狀態。GitHub的審查狀態本質上面向人類，表現為一個綠色勾選和一段評論文本。Agent要判斷一個PR是否可以合併，需要解析評論內容，存在不確定性。Origin將審查狀態設計為結構化API，Agent可以直接讀寫，無需推斷。

還有原生MCP支持，Agent可以像調用API一樣驅動整個平臺，不侷限於IDE內部。這幾項核心特性目前仍屬於官方路線圖中的“即將上線”功能，當天開放的測試版主要提供倉庫、PR、代碼瀏覽和GitHub雙向同步等基礎能力，Agent原生特性將稍後推出。Origin的方向很清楚，把代碼、PR和Agent放在同一個平臺中，讓機器不再遷就人類的工作節奏。GitHub追不上Agent的速度Cursor做Origin的根本理由，一句話概括，GitHub已經跟不上Agent的速度。

今年3月，Cursor聯合創始人Michael Truell公開了一組數據，Cursor內部合併的PR中，35%由運行在雲端虛擬機上的自主Agent完成。Agent自己開分支、自己提交、自己發起PR。GitHub這套工作流設計於2008年，核心面向“人”。一個人寫完代碼，找一兩個人審查，排隊等待合併，節奏以小時和天計算。Agent不遵循這個節奏，十幾個Agent同時湧入一個倉庫，時間尺度是秒。Origin在發佈會上公佈的性能數據指向的就是這個場景，每小時29.6萬次clone、8.1萬次push，單個倉庫每秒22.6次commit，全球同步延遲低於400毫秒，自動故障轉移10毫秒。

每秒22次commit聽起來偏高，但對成規模的Agent集群而言，這恰好是其工作模式所需要的吞吐能力。GitHub的瓶頸從來不是容量不夠，問題出在併發使用者從幾十個人變成成百上千個隨時開分支、隨時合併的Agent時，原有架構難以承載。在為人類設計的系統中，合併衝突是偶發事件；Agent主導的場景下，合併衝突變成高頻操作。Origin就是針對這個現實構建的。如果只是Cursor一家做代碼託管，市場只會把它當作又一個GitLab或Bitbucket。但2026年的Cursor已經不再是那個“AI版VS Code”，它手裡握著幾樣其他競爭者難以複製的資源。資金和算力。

6月16日，SpaceX在納斯達克IPO後行使收購選擇權，以600億美元全股票交易收購Cursor母公司Anysphere，這是風投支持的創業公司有史以來最大規模的收購案。交易於8月14日正式完成，Cursor成為SpaceX全資子公司，併入SpaceXAI部門，與Grok團隊同屬一個體系。與收購同期推進的，還有一款1.5萬億參數的自研模型，該模型在Colossus超算上使用超過十萬張GPU從零訓練，此前已在Cursor Compile大會上發佈。同時擁有模型、算力和資本，才有條件重新構建代碼基礎設施。垂直整合。

Cursor起步於編輯器，成長為一個獨立的AI IDE，現在進一步向下延伸，自建代碼託管和協作層。“編輯器—模型—託管—Agent”全線貫通的路徑，與GitHub Copilot橫向接入的模式截然不同。橫向整合求廣度，垂直整合求控制和優化深度，Origin可以為Agent吞吐量把每一層都做針對性優化。團隊。2025年12月，Cursor收購了代碼審查初創公司Graphite，Origin正是由Graphite團隊主導開發。堆疊式PR、合併隊列這些概念，Graphite已經實踐了數年，在“下一代代碼協作”領域有深厚積累。如今他們依託SpaceXAI的資金和算力，將此前的理念重新實現。

護城河真的那麼深嗎GitHub最大的護城河，說到底是沉澱了十幾年的生態，幾乎每一個開源項目、每一套CI配置、每一個開發者的使用習慣，都紮根在GitHub上。託管功能本身反倒在其次。短期內，沒有哪個團隊會將核心項目從GitHub整體遷移。Origin自身也清楚這一點，因此設計了“鏡像+雙向同步+一鍵Detach”的方案，將遷移成本降至極低，讓用戶先試用、後遷移。Origin的進攻策略可以概括為“寄生”，先以GitHub為權威源鏡像倉庫，讓用戶在Cursor中自然使用起來，等用戶習慣了、Agent也開始在上面運行之後，再提供“Detach from GitHub”的選項，完成權威源的切換。

漸進式策略比正面硬剛要有效得多。但Origin遠非無懈可擊。目前開放的仍是測試版，堆疊式PR、合併隊列等核心差異化功能尚未正式上線。生態方面，Vercel、Depot、Buildkite只是第一批接入方，與GitHub龐大的Actions市場相比差距明顯。微軟也不是旁觀者，它手裡有Azure、有Copilot、有全球最大的開發者關係網絡，一旦感受到實質性威脅，反應速度和資源體量都不容低估。底座之爭，才剛剛開始。代碼世界的“權威數據源”，第一次有了一個具備實質競爭力的挑戰者。GitHub的癱瘓暴露了它的單點脆弱性，Origin的開放證明這個位置可以被重新爭奪。

過去十幾年，開發者默認代碼存放在GitHub，這件事不需要思考。現在，它開始需要思考了。對開發者來說，眼下合理的做法是去試用Origin，尤其是已經在使用Cursor雲端Agent運行後臺任務的團隊。遷移成本幾乎為零，試一下“為Agent設計的底座”和“為人類設計的底座”之間到底差在哪，沒有什麼風險。對微軟和GitHub來說，真正的警報在於競爭對手開始從編輯器層向下滲透，直接觸及GitHub賴以存在的地基。對手同時握著模型、算力、資本和頂尖的代碼協作團隊。護城河再深，也架不住持續抽水。下一次GitHub再出故障，開發者可能已經不需要等它恢復了。

（本文首發APP，作者 | AGI-Signal，編輯 |秦聰慧 ）