Cursor Origin 上線，GitHub 的老玩法還夠用嗎？

代碼倉庫的主人，正在從人變成 Agent。作者丨鄭佳美 編輯丨岑 峰 8 月 17 日，GitHub 出現大範圍服務異常。Web、API、Actions、Pull Requests、Git Operations、Webhooks 等核心鏈路陸續受到影響，部分時段 Web 與 API 請求錯誤率接近 20%。同一天前後，Cursor 開始向全部付費計劃逐步開放 Origin early beta。

repository、PR、checks、review、merge 和 Automations 開始被放進同一套體系裡，Cursor 給出的定位也很明確：代碼託管要開始為 “agent scale” 設計。好玩的是，這兩件事都碰巧出現在同一個時間點，恰好把一個變化放大了出來：代碼倉庫正在接入越來越多持續運行的 Agent，而現有軟件協作基礎設施，長期適應的是人的工作節奏。人寫幾個小時代碼，可能只產生幾次 commit；Agent 可以在幾分鐘內連續修改、push、觸發 checks，再根據結果繼續下一輪。提交變快只是表面，更深的變化是整個軟件生產系統的時間尺度正在被壓縮。

GitHub 面對的很多新問題，Origin 想解決的很多問題，或許都會從這裡開始。01GitHub 沒有突然變老GitHub 誕生時，軟件協作有一個穩定的基本單位：人。工程師寫幾個小時代碼，提交一次 commit；一項功能開發幾天，形成一個 PR；評審可能半小時後出現，也可能第二天再進行；CI 跑幾分鐘通常可以接受，merge conflict 晚一點處理也不會讓整個系統失去意義。圍繞這種節奏，GitHub 建立了 Pull Request、Issue、Review、Actions、Webhook 和權限體系。

即便放到 Linux Kernel 這種長期保持高提交量的工程裡，這種節奏依然帶著明顯的人類時間尺度。LWN 統計，Linux 7.0 整個開發週期共有 14251 個 non-merge commits，來自 2362 名開發者。這些提交發生在持續數週的開發週期裡，中間還有郵件討論、維護者審核、子系統整合和 release cycle。Cursor 在 6 月 Origin 發佈演示中展示的則是另一種負載形態：單倉庫 22.6 commit/s。這個數字屬於現場 demo 數據，並非經過獨立復現的生產 benchmark，不能證明 Origin 在真實業務裡可以長期維持同等吞吐。

但它足以說明 Origin 面向什麼樣的 workload：大量 Agent 持續對同一個代碼狀態進行寫入。人類開發者天然存在限流。思考、寫代碼、開會和休息會在提交之間製造大量空白時間，因此圍繞人設計的 forge 可以把不少系統壓力交給時間吸收。Agent 沒有這層限制。幾十個 Agent 可以同時從同一個 base SHA 分叉，在相近時間修改關聯文件，然後一起 push、開 PR、調用檢查、讀取 review、修改代碼並再次 push。一次 commit 還可能繼續觸發索引更新、權限檢查、Webhook、CI、代碼掃描、review 狀態刷新和 mergeability 計算。

因此需要承受變化的並非 Git 對象模型本身，更關鍵的是 Git 上面的 forge control plane：API、認證、後臺任務、CI 調度、Webhook、branch protection、review state、merge queue，以及這些組件之間形成的級聯負載。7 月發表的一項針對 GitHub 上 Agent PR 的研究已經看到這種併發形態。研究分析了 2807 個倉庫中的 33596 個 Agent PR，40.2% 的倉庫出現過時間上重疊的 Agent PR。在被抽樣重放的併發修改中，跨 Agent PR 的文本 merge conflict 比例達到 41.

7%，同一 Agent 產生的併發 PR 則是 19.8%。多 Agent 協作因此會帶來新的併發控制問題。GitHub 這次故障無法證明 Agent traffic 已經擊穿現有基礎設施，但它恰好提供了一個觀察窗口：當軟件生產從低頻人類事件變成高頻機器事件，容量規劃、隊列設計、狀態傳播和一致性模型面對的是另一類 workload。Origin 的設計也從這裡展開。02Origin 重寫協作成本如果 Origin 只是增加一個 Git repository 託管入口，它很難撬動 GitHub 已經形成的開發者關係、開源生態、企業權限體系和工具鏈。它的機會來自 Agent 改變了協作成本。

stacked PR 是一個典型例子。人類開發者通常傾向於把一項功能整理成相對完整的 PR。每拆出一個 PR，就增加一份上下文、一輪 review 和一組 branch 依賴。如果一次修改被拆成幾十個 PR，人很容易把大量精力花在維護這些關係上。Agent 的成本結構不同。一個修改橫跨幾十個文件時，任何一步失敗，Agent 可能需要重新理解大範圍上下文。拆成較小的 change set 後，schema、service、UI 等修改可以形成明確依賴，每個節點分別驗證，失敗時只處理相關部分。小 PR 因此可以成為 Agent 的 checkpoint，讓任務具備局部驗證、局部重試和依賴追蹤能力。

Cursor 收購 Graphite 也可以放在這裡理解。Origin 當前的 early beta 尚未完整承接 Graphite 的 stacked workflow，但 Graphite 長期投入的 stacked PR 和 stack-aware merge queue，正好對應 Agent 提高代碼產生速度以後出現的後續瓶頸。PR 數量增加以後，merge queue 的職責也會變重。Agent A 和 Agent B 可以從同一個 base SHA 同時工作，兩邊分別通過測試。A 先進入 main 後，B 的測試結果只能證明代碼在舊狀態成立，無法證明進入新的 main 後依然安全。

因此 queue 需要根據不斷變化的 main 重建候選狀態、重新執行 checks，並處理 PR 之間的依賴。衝突也可以從人工中斷逐漸變成流水線中的可恢復 failure state。Cursor 已經提供 /babysit 一類能力，持續處理 PR 反饋、失敗 checks 和衝突。候選 merge 出現問題後，相關上下文可以重新交給 Agent，在隔離環境中修正並再次驗證。review 也會隨之結構化。人類協作大量依賴自然語言和團隊經驗，Agent 長時間運行則需要明確讀取哪個 check 失敗、哪些 thread 尚未解決、哪條 policy 沒滿足、當前 head SHA 是什麼。

Origin 已經通過 API 暴露 repository、commit、checks、PR 等對象，並區分 formal review 與普通 discussion。這些結構化狀態隨後可以直接被 Automations 消費。push、PR opened 或 PR pushed 觸發 cloud agent，執行結果寫回 checks 和 PR，失敗再進入處理流程。MCP、hooks 和 Agent API 則允許外部工具加入同一條事件鏈。“Detach from GitHub” 解決的是遷移路徑。

團隊可以先 mirror GitHub repository，讓 GitHub 保持 source of truth，同時把 Agent 工作流遷到 Origin；運行穩定後再切斷同步，由 Origin 獨立管理倉庫。這讓 Cursor 可以先承接 Agent、PR、review、checks 和 Automation，再逐漸把更多工程狀態留在自己的系統裡。Origin 的產品邏輯因此很明確：Git 繼續承擔版本控制，Origin 想重做的是 Git 上方那套圍繞高頻 Agent 協作運轉的控制層。

03老馬在收攏一條 AI 生產鏈過去一年多，xAI、X、SpaceX 和 Cursor 之間的一系列動作逐漸形成了更完整的上下游關係。xAI 收購 X，隨後進入 SpaceX 體系；Cursor 獲得 Colossus 計算資源，之後也進入 SpaceX 體系。與此同時，Grok 4.6 發佈，Origin 開始開放。這種路徑與馬斯克過去在 Tesla 上採用的垂直整合思路相似：當外部環節開始增加迭代摩擦，就繼續向上下游延伸，把關鍵接口納入同一體系。Agent 當前面臨的正是這種問題。

模型可以完成 reasoning，但一項軟件任務還需要訪問倉庫、修改文件、運行測試、處理 CI、接收 review、解決衝突，並在失敗後恢復執行。如果這些環節分散在多套系統裡，每一輪任務需要反覆同步權限、上下文和狀態，接口成本會在持續運行的 Agent loop 中不斷累積。Colossus、Grok、Cursor 和 Origin 可以分別對應這條鏈上的不同層級：Colossus 提供算力，Grok 提供模型能力，Cursor 提供代碼 Agent 和執行環境，Origin 保存 repository、PR、checks 和 review 狀態。

代碼生產由此形成一條連續鏈路：模型作出判斷，Cursor 把判斷轉化為實際修改，Origin 保存工程狀態並負責後續協作控制。這也改變了評價 Grok 4.6 的尺度。模型能力仍然重要，但 Agent 系統的產出還取決於執行環境和工程基礎設施。一段代碼即使生成質量不錯，如果後續仍需要人工複製、執行、檢查和重新提交，模型能力很難持續放大。當模型已經達到可用水平以後，代碼能否快速進入執行、驗證和合並流程，會越來越影響整套系統的產出。X 在這條鏈裡的位置目前仍然較模糊。

它擁有實時內容、用戶關係、身份和分發網絡，未來可能成為任務來源和分發入口；現階段，Grok Bot 在產品形態上更接近持續任務執行這一層，而非大家想象中的只是一個“被動等待提問的純粹聊天機器人”。Cursor 為什麼需要 Origin，也可以由此解釋：代碼生成之後，需要一個系統長期保存工程狀態、協調修改、驗證結果，並連接後續執行。這個位置如果始終位於外部，Agent 軟件生產鏈就存在一段關鍵依賴。而 Origin 補的正是這一層。

04GitHub 和 Origin 的分歧GitHub 已經擁有 stacked PR、merge queue、REST API，也在持續把 Copilot coding agent 接入 Issue、Actions、PR 和 code review。單看功能列表，兩邊未來會出現越來越多重疊。差異主要來自設計前提。GitHub 建立在成熟的人類開發者網絡之上，因此更自然的路徑，是讓 Agent 進入現有 Issue、PR、Actions 和 branch protection 體系。Cursor 可以從高密度 Agent 協作重新設計這些組件。

如果一個 repository 里長期運行幾十個 Agent，PR 數量增加、修改粒度縮小、狀態變化加快，那麼 review、checks、merge 和權限體系就需要圍繞機器行為重新組織。PR 的角色也可能隨之擴展。它可以從一份主要供人閱讀的代碼修改，逐漸變成包含 diff、依賴關係、測試證據、來源、風險級別和審批狀態的工程事務單元。人的職責則會更多進入規則層：哪些目錄允許自動修改，依賴升級允許跨越多大版本，數據庫 migration 需要哪些驗證，認證和支付相關代碼需要經過哪些審批，出現什麼情況時 Agent 必須停止。相應地，Agent-native forge 的指標也會改變。22.

6 commit/s 很醒目，但 commit 數本身無法代表軟件生產效率。更有意義的指標會是任務進入系統到 merge 的耗時、失敗後的局部恢復能力、policy 內自動完成的修改比例、accepted change 的計算成本，以及高風險修改消耗的人工注意力。Origin 想控制的，正是 repository、checks、review、權限與 events 匯合之後形成的軟件生產控制面。GitHub 和 Origin 的競爭因此會逐漸落到兩種路徑上：GitHub 從成熟的人類協作體系向 Agent 擴展，Cursor 則嘗試按照 Agent 的工作負載重新設計 forge。

05老馬已在下一層話說回來，其實在Grok 4.6 發佈以後，外界很容易繼續圍繞 benchmark 討論代碼能力、推理分數和價格。但把 Colossus、Grok、Cursor 和 Origin 放在一起看，其實這套佈局已經延伸到模型之後的軟件生產鏈。Colossus 提供算力，Grok 負責推理，Cursor 把模型能力變成代碼修改，Origin 接住後續的倉庫狀態、PR、checks 和 review。模型能力提升以後，增益可以沿著執行鏈直接傳遞；即使單代模型沒有明顯拉開差距，後面的基礎設施依然可以繼續積累。所以，Grok 4.6 今天在某張榜單上排在什麼位置，可能只是階段性的結果。

更長期的問題，是誰能夠把模型、執行環境和軟件工程狀態組織成一套持續運行的生產系統。當大家還在爭這一輪模型誰更聰明時，殊不知老馬已經到了一下層。參考鏈接：https://cursor.com/cn/changelog/origin-code-hostinghttps://www.learncursor.dev/learn/cursor-origin/commits-per-secondhttps://arxiv.org/pdf/2607.04697https://cursor.

com/cn/blog/graphite上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。