Cursor Live Apps 上線：雲端代理把內部工具做成可分享的網址

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

代理把寫程式變便宜之後，下一個卡住人的環節換成了交付。工具在自己的筆電上跑得起來，要交給同事用時，還得找主機、接資料庫、處理登入、想辦法發出去，很多自己寫的小工具就這樣停在 localhost。Cursor 在 2026 年 11 月 5 日的 changelog 裡用同樣的觀察開場：代理降低了寫程式的成本，但大多數人做出的 app 從沒離開過 localhost。

這次發布的 Live Apps 把交付這一段接進雲端代理（cloud agent，不在本機執行的雲端代理工作階段）。公告給出的承諾是：描述你想建的東西，Cursor 會把 app 建起來、設好資料庫與登入，部署前再執行確定性與代理式兩種安全檢查。官方 X 帳號的示範貼文在台北時間 11 月 6 日清晨 5 點 41 分發出，changelog 的日期是 11 月 5 日，公告也提醒要先更新 Cursor 才看得到功能。

把它讀成一個訊號就好：內部工具的生產單位，從一份要自己想辦法部署的程式碼，換成了一個直接可用的網址。代價也寫在同一份文件裡，app 的生死從此多了兩個握有否決權的角色，平台方與團隊管理員。

從一句描述到一個網址，中間發生什麼

入口在雲端代理。官方文件的提醒寫得很直白：要明確告訴代理「我要建一個 app」，而且這項功能只支援雲端代理，本機代理跑不了，想在功能選單裡找部署按鈕的人會撲空。這與 Cursor 今年下半年把重心往雲端搬的方向一致，九月的 Projects 把工作單位換成一專案一常駐協調代理，七天後 Anthropic 也把 Claude Projects 改成會自己開分支的對話，Live Apps 再把「發出去給別人用」這一步接上。

流程在 changelog 裡拆成幾步。代理先把網頁 app 的骨架建起來；需要儲存資料時，配置一套 Postgres 資料庫，這是常見的關聯式資料庫，表單、工作紀錄、應用狀態這類資料放進去，網頁關掉再打開還取得到；登入掛在 Cursor SSO 後面，用 Cursor 帳號本身當身分來源，私人 app 因此認得出誰是誰；代管環境一併準備好，每個團隊或個人拿到的是獨立的代管帳戶，官方文件強調各帳戶之間相互隔離。

app 若要接公司內部系統，文件舉的例子是資料倉儲，Cursor 會向使用者索取需要的 secrets。官方文件標明代理本身看不到這些值，多數情況下由團隊管理員在 Apps dashboard 統一建立團隊 secrets；有權限的人也可以自建個人 secrets。換句話說，連外部服務的金鑰這一層，設計上就放在代理的工作範圍之外。

Pin

程式碼來源有兩條路。從無到有，Cursor 會在 Origin（它自家的程式碼託管服務）開一個新儲存庫；或者直接部署既有的 GitHub 專案。GitLab 支援列在 coming soon，沒有給日期，程式碼放在 GitLab 的團隊這次先用不了，既有的 GitHub 專案倒是現成可以當起點。

對照之前的做法，差別在責任範圍。代理寫完程式後，主機、資料庫與登入這幾件事原本要自己分別找服務接，出狀況也是分開除錯；Live Apps 把這幾段收進同一條流程，交付的介面從多個服務的設定頁，收斂成一個預覽區與一個發布鈕。沒變的部分也要說清楚：app 的資料欄位、業務邏輯與錯誤處理，仍然取決於程式本身，平台接手的是跑起來與分享出去的環節。

代理準備好之後，畫面會出現預覽區，先看成果再決定要不要發布。發布時自己選網址，之後還能改；因為連結會成為同事進入 app 的入口，網址一旦寫進內部文件或流程，改網址時記得跟著更新引用。官方文件給的示範說法包括：把每週註冊人數做成可依方案篩選的 dashboard、讓團隊提交並追蹤 bug 狀態的內部系統、蒐集報名 email 的產品 microsite，或一句「把這個 repo 部署成 app」。changelog 另外點名 Cursor 內部業務、營運、法務、財務與工程五個部門都在用，實際案例有活動報名、帳號分配、座位安排的內部營運工具，給客戶看的多媒體簡報，新人訓練教材，銷售團隊盯 pipeline 的即時 dashboard，管理工程服務的入口頁。這份清單的共通點很明顯：都是「資料量小、使用者少、錯了重來成本低」的場合，正式對外的生產系統不在其中。

發布前的四道固定檢查，關不掉

安全這層的設計值得單獨看。每次發布前，Cursor 固定跑四項確定性檢查，文件寫明它們永遠開啟，就算把安全審查功能整個關掉也照跑。頭兩項擋的是最常見的兩種外洩：app 檔案裡寫死的 API key 或存取權杖，發布直接中止；私鑰、服務帳號金鑰這類憑證檔，同樣中止。後兩項管的是部署內容本身：.env 檔（放連線字串與金鑰的環境設定檔）不會跟著部署出去；source map 檔直接移除，那是打包工具產生的對照檔，訪客拿著它能還原你壓縮前的原始程式碼，所以不該上線。

在這四項之上，另有 AI 安全審查會讀整個 app 的檔案，攔下它判斷為嚴重的問題。兩層設計的分工可以這樣理解：確定性檢查是規則比對，命中特定模式就擋，結果可預期；AI 審查是讓模型讀檔案找規則之外的問題，涵蓋面廣，但帶有判斷成分，這也是設計上只讓管理員加規則、不開放關閉內建檢查的原因。治理底線不在個別團隊手裡。

Pin

閘門的順序是：檢查沒過，代理會列出要修什麼，修完再發一次；在你明確按下發布之前，什麼都不會上線。管理員的權限同樣定義清楚：看得到團隊裡每一個 app 與每一個 secret；可以核可被審查擋下的發布，但惡意程式碼、寫死的 secrets、外洩的憑證三類不在核可範圍，這三類是硬底線；可以整個關閉團隊的 Apps 功能；可以直接下架任何 app。這些設定變更全部記進團隊的 audit log，事後追溯有依據。

不過檢查通過只代表常見的洩漏途徑都擋下了，app 本身做得對不對，還是要自己驗收：表單存不存得進資料庫、一般帳號看得到哪些畫面、出錯時訊息清不清楚，這些都不在 Cursor 的檢查範圍裡。驗收的對象向來是最終成果，不該是代理的回報，這個原則在 Live Apps 這種「代理建置、平台代管」的組合裡只會更重要。

三種分享對象，兩種預設

文件把分享分成三層：只給受邀的特定人或群組、給整個 Cursor 團隊、公開給任何拿到連結的人。前兩層都在 Cursor 登入後面，公開那一層不需要登入，連結本身就是存取控制，外流等於開門。

預設值分成兩種世界。個人方案可以選擇公開分享，等於一個人也發得出對外分享的小工具；Teams 與 Enterprise 預設關閉公開分享，管理員要到 Apps dashboard 才能打開。換句話說，公司帳號拿到的 Live Apps 一開始是純內部工具，要不要對外開是管理層的決定，且這個決定可以事後反悔：管理員停用公開分享時，既有的公開 app 會自動退回團隊可見的狀態，原本散出去的連結從失效到回歸內部，不需要逐一回收。

管理的中樞是 Apps dashboard 這一頁。文件說明它會列出你自己建的 app 與別人分享給你的 app，管理員看到的則是全團隊每一個 app 與 secret；前面提過的關閉公開分享、停用 API key、自訂審查規則、下架 app，全部在同一頁操作。對要導入的團隊來說，這一頁的設計本身就是治理成本的一部分：權限集中在管理員，好處是政策統一，代價是對外的開口：公開分享、API key、被安全審查擋下的發布能不能放行，都握在管理員手裡。

讓 Grok Bot 和腳本也能打開 app

私人和團隊 app 擋在登入後面，自動化工具過不了這一關，所以 Cursor 配了 app 專用的 API key。個人金鑰能打開其擁有者本來就能開的 app；團隊金鑰只開被授權的團隊 app；公開 app 則兩種金鑰都進得去。沒有權限的金鑰會像未登入的使用者一樣收到登入頁轉址，與其說是錯誤，系統更像把這把金鑰當成一位沒有存取權的訪客對待。

技術上有個設計細節：金鑰只接受放在 x-cursor-app-token 這個 HTTP header 裡，沒有 query 參數可用，也不能塞 cookie，工具端每次請求都要自帶 header。這個限制對安全是好事，金鑰不會跟著網址一起複製進 log 或聊天訊息裡。系統會把用金鑰發出的請求標記為 automated，紀錄上識別的是金鑰而非某個真人，事後看紀錄分得出哪些流量來自自動化；所有綁在 app 上的金鑰，同樣集中在 Apps dashboard 管理。文件點名這條路是給 Grok Bot、腳本與 CI 工作用的，讓自動化流程像一個已登入使用者那樣操作 app。要把代理放進工作流程的團隊，可以對照先前整理過的雲端代理管理指南一起看。

付費不等於有雲端代理：方案範圍實查

文件寫的適用範圍是「所有可使用雲端代理的付費方案」。這句話不能直讀成「所有付費方案」。對照 11 月 7 日凌晨核對的定價頁對照表，Cloud agents & automations 這一欄在 Free 與 Plus 方案是空的，從 Premium（每月 30 美元）起才打勾，Super（每月 100 美元）、Ultra（每月 200 美元）、Teams（每人每月 30 美元起）、Enterprise 都在內。月付 8 美元的 Plus 是付費方案，這次的功能卻用不了，續約或升級前值得把自己的方案對清楚，別看到「付費方案」四個字就預設可用。定價頁自己也標了價格可能變動，長期預算抓數字時以官網當下為準。

同一張表上，Origin 的程式碼託管也是同一個範圍。Live Apps 從無到有建 app 時預設就落在 Origin，程式碼放哪裡這件事，這套流程已經替你決定了一半。

hosting 條款裡寫了什麼

文件末段有一段容易被略過的文字。Cursor 說明自己只提供技術與工具，對使用者做出的 app 不提供保證或背書，發布一個 app 不代表 Cursor 認可它。代管與 Cursor 本身的服務是分開的，以現狀提供。

更關鍵的是存續權。條款寫明：子網域、關聯帳號或已發布的 app，若違反條款、可接受使用政策，或基於商業、財務、法律理由，可能被撤銷、終止、移除或暫停。對內部工具來說，這個條件多半可以接受，工具壞了重建就是；要把對外的正式服務整個押在這個代管上，這段就是該先想清楚的邊界，正式上線前留一條自己搬走的路。

入口、起手式與三個未知數

入口明確：更新 Cursor，開雲端代理，說清楚要建 app。起手式照官方給的範例走最穩，先挑一個使用者與資料邊界都單純的內部工具，讓真正的使用者跑完一輪，再回頭看修改、權限與維護順不順。團隊管理者則可以先進 Apps dashboard，把公開分享、API key 與安全審查的自訂規則一次看完，那一頁就是之後所有治理動作的入口。

還沒有答案的三件事：代管費用怎麼計，changelog 與文件都沒寫，實際成本要回工作區的計費條件查；app 數量或用量有沒有上限，文件未載明；GitLab 支援何時上線，官方只給了 coming soon。定價結構與這三項，建議兩週內回官網核對一次再做長期規劃。