2026 年 8 月 17 日，Cursor 在 changelog 上只放了一句話：Cursor can now host your code。Origin code hosting 以 early beta 之姿上線，一家以編輯器起家的公司，正式把腳踏進 GitHub 經營多年的核心地盤。把它跟同一週的幾件事放在一起看——8 月 13 日的 Cloud Agent Builds、8 月 14 日的 SpaceX 收購完成公告、8 月 12 日發表的 Grok 4.6——這不是一次功能更新，而是三層堆疊：程式碼住在哪裡、執行環境怎麼預備、模型算力從哪裡來。
Origin 的首波功能：為 agent 規模設計的 essentials
Origin 即日起向所有付費方案推出 early beta，enterprise 組織由管理員決定是否 opt-out。首波給的是 essentials：repos、pull requests、code browsing 與 GitHub sync，agent-native 功能明言即將推出。
表面上是多了一個 code hosting 選項，但重點在設計起點。這些功能是為 agent scale 而設計，真正的差異在於程式碼、PR 與 agent 第一次住在同一個介面裡。你在瀏覽某個 repo 的當下直接問 Cursor，它可以回答問題、修改程式碼、更新既有的 PR，或 push 一個新 branch。對人類來說這叫方便，對 agent 來說這是原生的作業環境：讀碼、審查、執行、交付不再橫跨三個系統。
Codebase tab：Origin repo 的長相
新的 Codebase tab 是 Origin repos 的家。按加號新增 repo、命名，頁面會給你 CLI 的安裝與 push 指令，把本地專案推上去就完成託管。第一次建立 repo 時要替 codebase 命名，這個名字會成為每個 repo URL 的一部分，例如 cursor.com/codebase/acme-corp。URL 結構本身很平淡，但留意它背後的意圖：Cursor 打算讓 codebase 成為一級概念，而不是某個倉庫清單頁。
GitHub 雙軌設計：遷移成本的政治學
多數團隊聽到「新的 code hosting」的第一個反應是：我的歷史紀錄、我的 CI、我的權限怎麼辦。Origin 的回答是雙軌並行。GitHub repo 可以同步進 Origin，與 Cursor 自家託管的 repo 並列；同步的 repo 即時更新，瀏覽與搜尋走 Origin 上的副本，但 push 仍然送回 GitHub——對源自 GitHub 的 repo 而言，GitHub 保持 source of truth，而且任何時候都可以 disconnect。
Pull requests 也做了雙向：synced repo 的 PR 有 timeline、commits、checks 與 files changed，可以在 Cursor 裡審查 diff、留言、merge；你在 Cursor 留的評論會出現在 GitHub，在 GitHub 的回覆與反應數秒內同步回來，GitHub 上指派給你的 review 也能直接在 Cursor 完成。
對團隊的實務意義：這是一個零遷移成本的試用設計。你不需要搬家，先把 GitHub 接上，看看 agent 在有 PR 上下文的環境裡表現如何，再決定新專案要不要直接生在 Origin。反過來說，這也代表 Cursor 沒有逼任何人選邊站——競爭發生在體驗層，不是資料層。
App extensions：把 CI 與 preview 直接接上
Origin 同時發布了 app 生態：Vercel、Depot 與 Buildkite 已經可用，還有更多整合在路上。從 repo 的 Apps tab 連結 Vercel 之後，每個 PR 自動拿到 preview deployment，可以直接在預覽上測試與留言，merge 即上 production。CI 由 Depot 或 Buildkite 接手，兩者都能執行你既有的 GitHub Actions workflows，Buildkite 另外支援原生 pipelines。
這一步把「換 hosting 就要重搞 CI」的顧慮拆掉大半：workflows 是相容的，差別只在執行環境由誰供應。對 agent 工作流的意義其實比對人類更大：當 preview deployment 掛在每個 PR 上，agent 產生的每一次變更都有可以實際操作的驗收環境，人類審查時看的是跑起來的結果，而不是只憑 diff 想像。
背景：Builds 解決執行環境，SpaceX 解決算力
Origin 之所以選在此時推出，跟另外兩件事互為因果。第一件是 8 月 13 日的 Builds：Cursor 在背景持續預備開發環境副本，不額外收費；預設每小時產生新 build，成功的 build 成為後續 agent 的起始環境，新 agent 是 fork 一台活著的機器，而不是從磁碟還原。Cloud agents 一律從最新成功 build 啟動，失敗的 build 不會啟用並主動通知，除錯在背景進行。使用者的體感是：agent 起於 ready 環境，回應最快可快三倍。Cursor 內部的數字則是環境開機時間快十倍；time to first token 快三倍；Faire 每週執行超過兩千個全自動 agent runs；最大最複雜的 repo 數秒內啟動。8 月 17 日起，所有新舊環境預設使用 builds，不額外付費。技術上它靠 filesystem snapshots 運作，而使用者層級的 secrets 不進 build，是 agent 啟動時才注入。
第二件是 8 月 14 日：Cursor 正式完成被 SpaceX 收購的程序，這段收購從 4 月與 SpaceXAI 的模型訓練夥伴關係開始。Cursor 稱，公司將可使用全球最大的 GPU 機隊，打造更強而且更經濟的模型；依該公司的說法，客戶未來能以更低成本拿到更有能力的模型。8 月 12 日發表的 Grok 4.6，被他們定位為雙方合作的早期預覽。
把三件事疊起來看：Origin 管 code，Builds 管 environment，SpaceX 管 compute。每一層單獨看都像功能更新，疊起來看是同一個命題：當 agent 成為執行主力，圍繞它的每一層基礎設施都得重新設計一次。這是一條把 agent 工作鏈垂直整合的路線圖。
誰該現在進場，誰該再等等
如果你或團隊已經在 Cursor 上大量使用 cloud agents，值得今天就開 Origin：付費方案即有，GitHub 同步零風險，Builds 又已預設啟用，體驗是完整的。另一個判斷維度是 CI 依賴深度：Buildkite 與 Depot 能直接執行你既有的 GitHub Actions workflows，代表移植風險主要落在執行環境而非流程定義，對 CI 步數多、歷史包袱重的團隊是明確的好消息。如果你的 repo 綁著複雜的合規、權限或企業審計要求，early beta 還不是你的階段，enterprise 用戶適合等管理員治理功能更完整、agent-native 功能落地後再評估。至於旁觀者，真正該盯的不是 Origin 本身，而是 GitHub 的回應：當 code hosting 開始為 agent 重新設計，這個市場的下一輪競爭已經開局。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。