Cursor Origin：專為 AI 代理打造的 Git 代碼托管平台詳解

Cursor Origin 是 Cursor 自家的 git 代碼托管平台（git forge）——一個可以托管儲存庫、審查 Pull Request 並瀏覽程式碼的地方，並將 Cursor 的程式碼代理（coding agents）作為一等公民整合其中。它於 2026 年 8 月 17 日以早期測試版形式推出，僅限付費方案使用。本指南涵蓋實際推出的功能、GitHub 鏡像的運作方式、代理的能力，以及同樣重要的——目前仍缺少的功能。本文所有內容均以 Cursor 官方文件為依據。

Cursor Origin 是什麼？

Cursor 用一句話描述 Origin：專為代理時代打造的 git 代碼托管平台。簡單來說，它是一個真正的 git 代碼托管服務——而非 GitHub 的 UI 外殼。儲存庫存放在 Cursor 自己的遠端伺服器上，你可以使用標準 git 進行推送和拉取。

一家以編輯器聞名的公司突然開始托管程式碼，原因在於：儲存庫是代理工作成為真實、可審查、可合併的地方。透過 Origin，Cursor 正在進入儲存庫、Pull Request、程式碼瀏覽與代理共同運作的層次——更大的賭注不僅僅是打造另一個 GitHub，而是讓代碼托管平台本身成為代理工作流程的一部分，而非編輯器需要整合的外部系統。

Origin 由 Graphite（Cursor 收購的堆疊差異程式碼審查公司）背後的團隊打造，並在 GitHub 發生重大服務中斷的同一週推出——這放大了發布的聲量，但並非其初衷。

早期測試版推出的功能

測試版刻意保持精簡。以下是已包含與尚未包含的功能。

測試版已包含：

• 透過標準 git（HTTPS）托管儲存庫，支援內部（Internal）和私有（Private）可見性
• 具備行內審查、檢查和合併保護的 Pull Request
• 在 cursor.com/codebase 進行程式碼瀏覽、搜尋和提交歷史查看
• 支援雙向 PR 同步的 GitHub 鏡像
• Origin CLI、API 和 Webhook
• 三項整合：Vercel（預覽部署）、Depot 和 Buildkite（CI）

測試版尚未包含：

• GitHub Issues、專案、討論或 Wiki
• 公開儲存庫（目前尚無開源專案的容身之處）
• 原生 CI 執行器、套件倉庫或版本發布功能
• 安全掃描或相依性警示等功能
• 已公布的儲存空間限制、SLA 或測試版後的定價

第一天推出了三項整合：Vercel 為每個 Pull Request 建立預覽部署，並在合併時發布至正式環境；Depot 和 Buildkite 則執行持續整合——關鍵在於，兩者都能直接執行現有的 GitHub Actions 工作流程，無需任何修改。這個相容性層正是其策略的縮影：無需重寫建置系統即可試用 Origin。

誰可以使用

Origin 程式碼儲存功能適用於 Pro、Teams 和 Enterprise 方案——免費方案不包含。存取權限分階段開放，因此付費訂閱者可能無法立即看到此功能。透過申請**程式碼庫名稱（codebase name）**來啟用，這是所有儲存庫所在的命名空間。請謹慎選擇：在測試版期間，此名稱無法更改，且會出現在每個儲存庫的 URL 中。

Origin 能取代 GitHub 嗎？鏡像如何運作

目前還不能——Cursor 也不要求你這樣做。設計的路徑是鏡像，且以一種謹慎的方式進行。Cursor 不要求你離開 GitHub：連接一個 GitHub 組織，選擇儲存庫，它們就會與 Origin 原生儲存庫並排顯示。

鏡像會將完整的歷史記錄、分支和標籤複製到 Origin 並保持同步，Pull Request 的評論和審查也會雙向流通。關鍵細節是：開發者可以從 Origin 克隆並推送到 Origin 遠端，但這些推送會傳遞到 GitHub——Cursor 明確表示，對於最初在 GitHub 建立的儲存庫，GitHub 仍然是事實來源（source of truth）。

這個橋接有其邊界。GitHub Issues 不會被遷移。Actions 密鑰或執行時設定也不會——鏡像儲存庫的 CI 仍保留在 GitHub 上。當團隊決定讓 Origin 成為權威來源時，需要**解除（detach）**鏡像：同步停止，Origin 的副本變為獨立，而原始的 GitHub 儲存庫保持不變。解除鏡像才是真正的遷移時刻；在此之前的一切都是工作流程的免費試用。

代理作為一等公民

上述功能清單可能適用於任何新興的代碼托管平台。策略體現在代理的整合方式上。Cursor 的雲端代理可以端到端地建立 Origin 儲存庫，然後克隆、建立分支、提交、推送並針對其開啟 Pull Request。

自動化功能將代理與儲存庫事件綁定——推送到 main 分支、開啟或更新 PR，或按排程執行。自 2026 年 8 月 19 日的更新日誌起，雲端代理會自動訂閱它們所建立的 PR：訂閱的代理會監控 CI、修復失敗的檢查、回應審查意見，並在 PR 發生變化時喚醒，持續追蹤目標直到工作真正完成。

這形成了任何第三方代碼托管平台都無法為 Cursor 提供的閉環：儲存庫事件 → 代理在隔離的虛擬機中執行 → 程式碼變更 → PR 更新 → CI 結果 → 代理再次喚醒。擁有代碼托管平台意味著掌控每一個環節。不過需要精確說明：PR 審查模式本身仍然是傳統的人工審查。賭注在於這個閉環從此處開始收緊的速度。

誠實的限制

Cursor 自己的文件坦誠地說明了這些問題，如果你正在評估是否遷移，這些差距至關重要：

• 沒有 Issues 或工作追蹤。 甚至不會鏡像——你的追蹤工具仍留在原處。
• 沒有公開儲存庫。 開源專案目前還沒有容身之處。
• 沒有原生 CI、套件倉庫或安全工具。 CI 來自合作夥伴；目前沒有相當於密鑰掃描或相依性警示的功能文件。
• 沒有已公布的限制、SLA 或測試版後定價。 儲存空間、頻寬和正常運行時間承諾在測試版期間尚未明確。
• 推出是分階段且由管理員控制的。 舊版隱私模式會完全封鎖此功能，且團隊管理員可以停用它。

這些都不是對一個剛推出幾天的測試版的批評——這只是對邊界所在的誠實描述。如需更全面了解企業層面的考量，VentureBeat 的發布分析詳細說明了平台團隊應提出的安全審查問題。

現在應該遷移你的儲存庫嗎？

低風險的路徑就是設計好的路徑：在 GitHub 保持權威的同時鏡像幾個儲存庫，使用 Origin 進行瀏覽、審查和代理工作流程，只有在驗證了 CI、存取控制以及你可能失去的協作功能之後，才考慮解除鏡像。測試版在現有 Cursor 方案之外不需要額外費用，因此這是一個低成本預覽代理時代基礎設施感受的機會。

如果你對 Cursor 如何走到今天感到好奇，我們的 Cursor 起源故事追溯了這家公司從一個 CAD 構想到成為最廣泛使用的 AI 程式碼工具之一的歷程——這是理解它為何現在要打造自己的代碼托管平台的有用背景。

按你的方式打造自己的代理工作流程

Origin 真正的論點是：有趣的工作單元是一個從事件到合併 PR 全程負責任務的持久代理，而非一個聊天視窗。這與 Eigent 的賭注相同——只不過 Eigent 在本地運行整個多代理工作團隊，基於你掌控的程式碼和工作流程，沒有供應商鎖定。如果審查代理撰寫的 Pull Request 是你的瓶頸，我們的審查 GitHub PR 工作流程可以直接讓代理承擔這項工作。下載 Eigent，將真正的多步驟任務交給你自己的 AI 工作團隊。