AI 程式開發工具 Cursor 發表了自家的程式碼託管服務 Origin。從儲存庫的存放、Pull Request 的審查與合併，到 CI（持續整合）的串接，全都在編輯器內部完成，目前以早期測試版向付費方案的使用者逐步開放。發表當天正好碰上 GitHub 大規模故障，也因此受到不少關注。
儲存庫與 Pull Request 都搬進編輯器
Origin 從 Cursor 桌面版新增的分頁開啟。官方另外準備了專用的命令列工具，建立或複製儲存庫等操作也可以在終端機上處理。
底層採用的是 Linux 之父 Linus Torvalds 開發的版本控制系統 Git。開發者各自持有儲存庫副本、分頭修改後再合併回來的分支機制，正是 Git 被廣泛採用的理由之一。由於 GitHub 同樣建立在這套基礎上，既有的工作流程可以直接沿用。
放在 Origin 上的儲存庫具備完整的 Pull Request 流程，包含差異比對、留言討論與合併。程式碼、審查與 AI 代理位於同一個畫面，開發者可以針對正在瀏覽的儲存庫直接提問，接著讓 Cursor 修改內容，或是開新分支推送出去，過程不會被打斷。讀程式碼的地方、寫程式碼的地方與提問的地方不再分開，這是它與既有託管服務最容易看出來的差異。
從 GitHub 搬過來只要幾次點擊，同步是雙向的
對於已經在 GitHub 上運作的專案，官方提供了專屬的整合功能。幾次點擊就能複製到 Origin，原本的 GitHub 儲存庫更新後也會反映到 Origin。反方向的同步同樣有效，因此團隊可以在完全轉移之前先讓兩邊並行一段時間。
CI 方面，發表時就備妥了串接 Vercel、Depot 與 Buildkite 的連接器。搭配 Vercel 可以快速架起測試環境，確認應用程式更新後的運作狀況。以 GitHub Actions 寫好的既有工作流程也能繼續執行，因此為了轉移而重寫建置設定的工作量降到最低。
目標是撐住代理的數量，而不是人數
Cursor 反覆使用的說法，是為代理規模打造的程式碼託管。也就是說，這並非再做一個 GitHub，而是以大量 AI 代理同時運作為前提所設計的。
Cursor 的代理分成兩種：一種在使用者的電腦上執行，另一種在雲端沙箱（隔離的執行環境）中執行。差異在長時間的作業上最明顯，雲端代理在工作站關機之後仍能繼續處理。考慮到代理每次執行都得抓取儲存庫，把程式碼的存放位置掌握在自己手上，意義並不小。
該公司表示今後會再增加串接對象，並推出以代理為前提的新功能。具體內容尚未公開，目前能確定的只有方向。
發表當天 GitHub 發生大規模故障
Origin 登場的 8 月 17 日，正好也是 GitHub 發生大規模故障的日子，Pull Request、Issues、Webhooks 與 Actions 都受到影響。封存檔與原始檔案下載的錯誤率一度達到 50%，據報導受影響的使用者達到數百萬人規模。
替代服務正好在這一天出現，網路上不少人拿時機開玩笑。不過這類產品發表通常要提前數週準備，從部落格素材到分階段的測試版投放都需要時間，很難認為是看到故障之後才臨時動作。與其說是刻意挑時間，不如說是巧合湊在一起。
背後是 SpaceX 的收購
Origin 是 Cursor 營運方 Anysphere 併入 SpaceX 之後的首個重要產品更新。這樁收購於 2026 年 6 月 16 日宣布，屬於全股票交易，總額 600 億美元（約 9.5 兆日圓），並於 8 月 14 日完成。Anysphere 被編入新設立的 SpaceXAI 部門。
據稱 Cursor 在不到 4 年的時間內達成年化 40 億美元（約 6,400 億日圓）規模的營收，其中約 26 億美元（約 4,100 億日圓）來自企業客戶。連程式碼的存放都自己扛下來，可以視為把開發流程從入口到出口都收進同一家公司這個趨勢的延伸。
※1 美元 = 159 日圓換算（截至 2026 年 8 月 18 日）
總結
Cursor 推出的 Origin，是把儲存庫存放、Pull Request 與 CI 串接整合到編輯器內部的程式碼託管服務。它提供與 GitHub 的雙向同步以及 Vercel 等整合，並從付費方案的使用者開始以早期測試版開放。與 GitHub 大規模故障同一天登場提高了話題性，但真正的重點在於，它試圖以 AI 代理大規模運作為前提，重新打造開發基礎。
