Cursor Origin App Marketplace 實戰：讓 coding agent 自己讀 CodeRabbit、Socket、Cloudflare 的結果再修 code

瀏覽次數: 1

你叫 coding agent 開了一個 PR，接著就得自己去 CI 頁面看哪裡紅、去 review 工具看它留了什麼、去部署平台拿 preview 網址，再把這些貼回對話框請 agent 修。agent 寫 code 很快，但「看結果、再修」這一圈還是你在手動搬運。

Cursor 在 2026-10-13 的 changelog 公布 Origin App Marketplace：Origin（Cursor 自家的 git forge）現在能接 20 多個 app，涵蓋部署、CI、code review、資安、監控、專案管理，而且 marketplace 開放任何開發工具團隊投稿。這篇不談「Cursor 要不要挑戰 GitHub」，只談一件事：這些 app 把結果寫回 PR 之後，你怎麼讓 agent 自己讀、自己修，把那一圈搬運交出去。

本文大綱

先搞清楚 Origin 是什麼

Origin 是 Cursor 的 git forge，2026 年 8 月以 early beta 推出，開給付費方案（Start、Pro、Pro+、Ultra、Teams、Enterprise）。它有兩種 repo，這個區分會決定你能不能用 marketplace 的 app：

原生 Origin repo：Origin 是 source of truth，PR、review、check 都在 Origin 上。
從 GitHub mirror 過來的 repo：GitHub 仍是 source of truth，Origin 只是鏡像。cloud agent 在這種 repo 上開的是 GitHub PR。

20+ 個 app 有哪些

依 changelog 的分類：

類別	App
部署	Cloudflare、Netlify、Render、Spacelift、Vercel
CI	Buildkite、CircleCI、CloudBees、Depot、EngFlow、Namespace、RWX
Code review	CodeRabbit、Greptile、Tenki
資安	Artemis Security、Semgrep、Socket Security、Upwind
監控	Sentry
專案管理	Linear

8 月剛上線時只有 Vercel、Depot、Buildkite 三家，這次一口氣補齊。安裝入口在 cursor.com/codebase/apps，由 workspace admin 選擇 owner、核可 scope，再決定開放「全部 repo」還是「指定 repo」。

運作原理：app 寫回 PR，agent 讀回來

整個機制可以拆成四步：

事件推出去：PR 開啟、push、review 等事件，Origin 以簽章 webhook 推給有訂閱的 app。新 app 預設不訂閱任何 repo 事件，要自己勾。
app 寫回來：app 用 installation access token 呼叫 Origin API，寫回三種東西：check run（CI、部署、掃描結果）、PR comment／inline comment、review（含 request changes）。
agent 讀進去：Origin MCP server（https://api.origin.cursor.com/mcp）提供 checks_read、pull_request_read（可選 summary、files、reviews、comments、threads 等 view）這類工具，agent 不用離開對話就讀得到上一步的結果。
agent 修完再 push：新 commit 觸發新一輪 check，agent 再回覆或 resolve review thread。

關鍵在第 2 步的資料形狀。check run 不是一段自由文字，而是有 key（例如某個 CI job 名稱）、狀態（queued、in_progress、failing、completed）、結論（success、failure、timed_out 等）和 annotation 的結構化物件；review thread 也有 resolved 與否的狀態。agent 讀結構化資料，比讀你貼進來的一大段截圖或 log 準確得多，也能自己判斷「還有哪幾項沒過」。這就是為什麼 app 寫回 PR 這件事，對 agent 的價值大於對人。人看 PR 頁面上的紅綠燈就懂，agent 需要的是能逐項查詢的狀態。

以官方文件寫得最完整的 Cloudflare 為例：Cloudflare 的 Workers Builds 在 PR 的每個 commit 留言附上建置狀態與連結；有跑 wrangler preview 時附 Preview URL，每次 build 也建一個 Origin check run（queued、in progress、complete）。也就是說，agent 讀 checks 就能拿到部署結果和 preview 網址，不必你去 dashboard 複製。

CodeRabbit、Greptile、Tenki 屬於 review 類，Socket Security、Semgrep 屬於資安類。它們在 Origin 上具體是寫 review、comment 還是 check run，changelog 沒有逐一說明，以各家文件為準；但不論哪種，都落在上面這三種 agent 讀得到的物件裡。

手把手：讓 agent 自己跑完修正迴圈

1. 確認 repo 是原生 Origin repo

這一步最容易踩空，也是 changelog 沒寫、要翻 API 文件才看得到的細節。Origin API 文件寫得很明白：在 mirrored repo 上，installation 只剩 metadata、contents 讀取、mirror 同步等五個 scope，PR、review、comment、checks 和所有寫入都回 403。Origin 的 Apps 文件也點名 Depot 和 Buildkite 只支援原生 Origin repo，mirror 的 repo 請繼續用 GitHub 上的 CI。

換句話說，repo 還以 GitHub 為主的話，marketplace 的 review、資安 app 寫不進 Origin 的 PR，你該繼續用它們的 GitHub 版本。想體驗完整迴圈，挑一個新專案或內部工具直接開在 Origin：

curl -fsSL https://downloads.cursor.com/origin/install.sh | sh
origin auth login
origin repo create acme/checkout   # 不帶斜線則建在個人 namespace
git remote add origin https://origin.cursor.com/acme/checkout.git
git push -u origin main

2. 只裝「會寫回 PR」的 app，scope 從嚴

安裝時 admin 會看到 app 要求的 scope。幾個值得盯的：

repository:checks:write：寫 check run，CI、部署、掃描類 app 需要。
repository:pull_requests:reviews:write：寫 comment、review，review 類 app 需要。
repository:contents:write：可以 push、merge PR，review 類 app 通常不該需要，看到要多問一句。

repo 範圍選「指定 repo」，Cloudflare 的文件也建議只開放要接 Workers Builds 的 repo。之後要調整 repo，用 Origin Apps 裡的 Manage；它只改 repo，不改 scope。

3. 給 agent 一個明確的「讀結果」指令

Origin MCP 目前只在 Cursor 和 Grok Bot 可用，文件寫其他 harness「coming soon」。在 Cursor 裡，可以直接把迴圈寫進 prompt：

PR #42 已開。請依序：
1. 用 checks_read（target.type 指向這個 PR）列出所有未通過的 check run。
2. 用 pull_request_read 的 threads view 讀出未解決的 review thread，
   只處理 CodeRabbit 標成需要修改、以及 Socket Security 標記的項目。
3. 每個問題先說明你判斷是否該修、理由一句話，再修改。
4. 修完 push，等 checks 跑完再讀一次；仍失敗就停下來回報，最多兩輪。
5. 不要呼叫 merge_pull_request，不要 dismiss 任何 review。

第 5 點不是多餘的保險。Origin MCP 對 merge、dismiss review 這類破壞性工具會標 requiresConfirmation，Cursor 每次都會跳確認；把界線寫進 prompt，可以少掉 agent 一直問你的來回。

4. Claude Code、Codex 怎麼用：走 Origin CLI

MCP 還沒開放給其他 harness，但 Origin CLI 本身就是 agent 可呼叫的工具。在 AGENTS.md 或 CLAUDE.md 加一段：

## Origin PR 流程
- 開 PR：`origin pr create --fill --push`（預設為 draft）
- 看 CI：`origin pr checks --watch`，結束後用 `origin pr checks --json` 取結構化結果
- 看 review：`origin pr view -c` 讀 comment 與 thread 狀態
- 回覆 thread：`origin pr thread` 子指令
- 禁止：merge、`origin pr review --approve`

--json 很關鍵：agent 解析結構化輸出比解析終端機排版穩定得多。

5. 用 Automations 讓迴圈自動開跑

Cursor Automations 可以在 PR opened、pushed 等事件觸發 cloud agent，目標選 Origin repo 的方式和選 GitHub repo 一樣，可在 cursor.com/automations 或用 /automate skill 建立。一個實用的配置：PR 有新 push 時觸發，prompt 用上面第 3 步的內容，但把第 4 點的「最多兩輪」改成一輪，避免 agent 和 review bot 互相對話停不下來。

6. 三個常見的坑

check 一直停在舊 commit：agent push 之後立刻讀，可能讀到上一版結果。Origin CLI 文件說 push 會自動產生 PR 新版本，只有 origin pr view 或 origin pr checks 仍顯示舊 head commit 時才需要 origin pr refresh。在指令裡要求 agent 比對 check 對應的 commit SHA 和自己剛 push 的 SHA，不一致就等。
讀不到外部 log：checks_read 的說明寫明「不抓外部供應商的 log」。check run 告訴 agent 哪裡失敗、附上連結和 annotation，但完整 build log 還在 CircleCI、Buildkite 那邊。CI 類 app 寫回的 annotation 越完整，agent 越不需要你幫忙貼 log；挑 app 時這是值得實測的點。
review thread 修了但沒關：agent 修完不 resolve thread，人類 reviewer 回來看到一堆 open thread 會很痛苦。在 prompt 裡要求「每修完一個 thread 就回覆修改內容的 commit，再 resolve」，Origin MCP 的 reply_pull_request_review_thread、update_pull_request_review_thread 正好對應這兩個動作。

想自己寫 app？先看這幾個規格

marketplace 開放投稿，內部工具也能做成 private app。從 Origin API 文件整理的重點：

金鑰只收 Ed25519：openssl genpkey -algorithm ED25519 產生，只上傳公鑰，一個 app 最多 10 把有效簽章金鑰。
App JWT 約 5 分鐘：iss 和 kid 都填 app ID（app_…），aud 是 origin-apps。
Installation token 最長 15 分鐘：以 oit_ 開頭，且不會晚於簽發它的 JWT 到期。文件特別提醒，比 GitHub App 的 token 短，沿用 GitHub 的快取週期會失敗。
Webhook 驗簽不能用 Standard Webhooks 函式庫：header 名稱沿用，但 Origin 簽的是 webhook-id.timestamp.body 的 SHA-256 hex digest，標籤是 v1ed。官方附了 Node 範例。
Check run 用 key 加 externalId 定位：每次重試換一個新的 externalId，更新時遞增 externalUpdatedAt；舊時間戳的寫入會回 200 但 outcome 為 ignored_stale，要讀 outcome 才知道有沒有寫進去。
Rate limit：installation token 每分鐘 3,000 點、app JWT 6,000 點，多數讀取 1 點、一般寫入 5 點。

投稿流程是：在 cursor.com/codebase/settings/apps 建 private app，改成 Public 測安裝，錄 5 到 10 分鐘的 demo 影片（必須涵蓋安裝、解除安裝與核心流程），送審通過後才會 Listed。

已經有 GitHub App 的團隊，Cursor 在 cursor/plugins repo 放了 Origin Apps plugin，內含 origin-api 和 port-github-app-to-origin 兩個 skill。後者會讀你的 app 原始碼，產出 ORIGIN-PORTING-BRIEF.md，列出哪些能搬、哪些不能、要申請哪些 scope；預設只規劃不寫 code。它是純 Agent Skills 格式，Claude Code 也能裝：

/plugin marketplace add cursor/plugins
/plugin install origin-apps@cursor-plugins

限制與 trade-off

還在 early beta：文件每頁都標「subject to change」，部分 API 欄位標為 preview。上正式專案前先接受 schema 會變。
mirror repo 拿不到完整好處：這是目前最大的門檻。主 repo 還在 GitHub 的團隊，短期內 GitHub 上原有的 app 整合仍是主力。
MCP 綁 Cursor：其他 agent 只能走 CLI，功能夠用，但少了 MCP 的工具描述與確認機制。
app 品質由各家負責：Cursor 審的是安裝流程、demo 影片與品牌規範，不保證 review 意見的品質。agent 照單全收 review bot 的建議，可能修出更多問題，所以 prompt 裡要求「先判斷該不該修」。

什麼時候值得用？新專案、內部工具、或你已經大量用 Cursor cloud agent 開 PR 的 repo，把 review、資安、部署 app 接上後，agent 自己讀 check 修 code 的迴圈最順。主力 repo 在 GitHub、CI 很重的團隊，先觀望 mirror 的支援範圍再說。