Cloud Agent Capabilities
基於 Cursor 官方 Capabilities 文件解釋 computer use、artifacts、remote desktop、MCP HTTP/stdio、安全差異和 CI failure autofix。
Cloud Agent 的能力不只是“雲端寫程式碼”。它能在獨立 VM 裡執行軟體、控制 browser / desktop、生成 artifacts，並在某些條件下跟進自己 PR 的 CI failures。
閱讀目標：讀完本章，你應該能判斷 Cloud Agent 的驗證證據是否足夠，並能解釋 MCP HTTP 與 stdio 在雲端的安全差異。
1. Computer use
Computer use（計算機使用，讓 AI 像人一樣用滑鼠鍵盤操作桌面 / 瀏覽器的能力）是 Cloud Agents 區別於本地 Agent 的重要擴充套件。每個 Cloud Agent 執行在自己的 isolated VM，帶完整 desktop environment。Agent 可以用 mouse 和 keyboard 控制 desktop 和 browser。
這意味著它可以：
- 啟動 dev server。
- 開啟應用。
- 點選 UI flow。
- 驗證修改是否真的可用。
- 再 push PR。
商業級驗收要看它是否真的用 artifacts 或日誌證明了關鍵路徑，而不是隻寫“已完成”。
2. Demos 和 Artifacts
Cloud Agents 會生成 screenshots、videos、log references 等 artifacts，附到 PR 上，幫助你不用 checkout branch 就快速判斷變化。
如果在 Cloud Agents dashboard 裡開啟 Allow posting artifacts to GitHub，Cloud Agents 可以把 artifacts 嵌入 GitHub pull request description。
注意公開 URL 邊界：
- GitHub image proxy 要求 public URLs。
- PR 描述裡的 artifacts 使用 long, unguessable URLs。
- 這些 URL 無需 authentication 也可檢視。
所以 artifact 不要包含 secrets、後臺私密資料、客戶資料或不可公開截圖。
3. Remote desktop control
你可以接管 agent 的 remote desktop，在 agent 的 VM 中直接測試軟體。測試完後再把控制權交還給 agent，讓它繼續工作。
適合：
- 複雜 UI flow。
- 本地不方便 checkout 的 PR。
- 需要看瀏覽器真實狀態的改動。
- 需要確認 demo artifact 是否可信。
不適合：
- 輸入敏感憑據。
- 繞過正式 staging / review。
- 把 remote desktop 當生產環境。
4. MCP tools
Cloud Agents 可使用 team 配置的 MCP servers，透過 cursor.com/agents 的 MCP dropdown 新增和啟用。
它們可以訪問外部 tools 和 data sources，例如 databases、APIs、third-party services。
Cloud Agents 支援 OAuth。對 team-level shared MCP server 來說，OAuth 仍是 per-user。
5. HTTP vs stdio MCP
官方推薦儘量用 HTTP MCP。
| Transport | 行為 | 安全含義 |
|---|---|---|
| HTTP | tool calls 透過 backend proxy，server config 不出現在 VM 環境 | Agent 拿不到 refresh token、headers 等配置 |
| stdio | server 在 cloud agent VM 內執行 | Agent 能訪問 server config 和 env vars |
Custom MCP 支援 HTTP 或 stdio。SSE 和 mcp-remote 當前不支援。
敏感欄位會 encrypted at rest，並在儲存後無法被使用者讀回：
envheadersCLIENT_SECRET
如果使用 stdio MCP，必須確保 VM 環境能執行該 server。Cursor 無法在 agent 啟動前驗證 stdio server 一定可執行。
6. CI failure autofix
Cloud Agents 會自動嘗試修復它們自己 PR 中的 CI failures。目前官方說明支援 GitHub Actions。
會跳過自動跟進的情況：
- 你向該 branch push 了新 commit。
- 你給 agent 發了 follow-up message。
- 同一個 check 在 base commit 上已經失敗。
- PR 已經有 10 次 CI-failure follow-ups。
關閉方式：
- 個人 Cloud Agents：到 Dashboard 的 My Settings 關閉 Automatically fix CI Failures。
- 單個 PR：評論
@cursor autofix off。 - 重新開啟：評論
@cursor autofix on。
如果希望 Cloud Agent 修復你自己的 PR CI，也可以正常評論，例如 @cursor please fix the CI failures。
7. 驗收策略
| 能力 | 驗收證據 |
|---|---|
| Computer use | browser flow screenshot / video / logs |
| Artifacts | PR 中的截圖、影片和日誌引用 |
| Remote desktop | 人工接管後復現關鍵路徑 |
| MCP tools | 工具呼叫目標、許可權、結果和是否洩露敏感欄位 |
| CI autofix | CI runs、commit history、agent follow-up 次數 |
不要把 artifacts 當作最終合併依據。最終合併仍要看 diff、tests、security review 和產品驗收。
深讀：為什麼 HTTP MCP 更適合 Cloud Agent
Cloud Agent 是一臺雲端 VM。stdio MCP 執行在 VM 內，Agent 能接觸到 server 的 env 和配置，這和本地 IDE 的 stdio MCP 類似。
HTTP MCP 透過 backend proxy 呼叫，server configuration 不進入 VM 環境。對資料庫、內部 API、第三方服務這種高敏感工具，HTTP MCP 的許可權邊界更容易審計。
本章自檢
完成本章後，用這 3 個問題檢查自己是否真正理解：
- 為什麼 artifact URL 的公開可訪問性會影響截圖內容選擇？
- HTTP MCP 相比 stdio MCP 的安全邊界差異是什麼？
- Cloud Agent 什麼時候不會自動修復自己 PR 的 CI failure？
透過標準：你能為一個 Cloud Agent PR 寫驗收清單，包含 artifacts、remote desktop、MCP 許可權和 CI follow-up 檢查。
官方來源
- Cursor Cloud Agent Capabilities —— 官方 computer use、artifacts、remote desktop、MCP 和 CI autofix。
- Cursor MCP —— 官方 MCP 背景。
- GitHub image proxy —— GitHub 圖片代理公開 URL 背景。
- Cursor Cloud Agent Setup —— 官方環境和 stdio MCP 執行背景。