摘要： Cursor 於 2026 年 8 月 17 日推出 Origin code hosting early beta，提供 repos、PR、程式碼瀏覽與 GitHub sync。GitHub repo 可同步試用而不必遷移，Vercel、Depot 與 Buildkite 則接上 preview 與 CI。文章把 Origin、Builds 和 SpaceX 收購視為為 agent 工作鏈重新設計基礎設施的三層布局。
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——就會發現這並非單一功能上線，而是三層同時到位：程式碼存放的位置、執行環境如何預備、算力又從哪裡來。
首波內容：以 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，或推一個新 branch 上去。對人類來說這叫順手，對 agent 來說這則是它原生的作業場所：讀碼、審查、執行、交付這四件事，不必再橫跨三個系統完成。
Codebase tab：Origin repo 的樣子
Origin repos 收在新的 Codebase tab 底下。按加號開一個 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——只要 repo 的源頭是 GitHub，GitHub 就繼續當 source of truth，而且隨時可以 disconnect。
Pull requests 同樣是雙向的：synced repo 的 PR 具備 timeline、commits、checks 與 files changed，你可以在 Cursor 裡審 diff、留評論、merge；在 Cursor 寫下的評論會同步出現在 GitHub，GitHub 端的回覆與反應則在幾秒內回到 Cursor，在 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 工作流的意義甚至大於對人類的意義：當每個 PR 都掛著 preview deployment，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 重新設計，這個市場的下一輪競爭已經開打了。