計算機操作¶
每個 cloud agent 都在自己隔離的虛擬機中運行，並配備完整的桌面環境。這些 Agent 可以使用鼠標和鍵盤控制桌面和瀏覽器，使它們能夠像人類開發者一樣與自己構建的軟件交互。
這意味着 Agent 可以啓動開發服務器，在瀏覽器中打開應用，逐步點擊完成 UI 流程，並在推送 PR 之前驗證其更改是否正常工作。更多內容請參見公告博文。
演示和工件¶
agents 會生成截圖、視頻和日誌引用等工件，用來展示其工作成果。這些工件會附加到 PR 上，這樣你無需在本地檢出該分支就可以快速驗證更改。
GitHub 中的工件¶
你可以通過在 雲端代理 儀表盤中啓用 Allow posting artifacts to GitHub 設置，選擇讓 雲端代理 將工件直接嵌入 GitHub PR 描述中。
GitHub 的圖片代理要求使用公共 URL，因此 PR 描述中的工件會使用較長且難以猜測、無需身份驗證即可訪問的 URL。作爲參考，在 2023 年 5 月之前，GitHub 對所有 issue 和 PR 附件都使用公共 URL。
遠程桌面控制¶
你可以接管智能體的遠程桌面，直接與智能體正在構建的軟件交互。你可以隨時將控制權交還給智能體，讓它繼續工作。
雲端代理運行在遠程 VM 中，並且可以完整配置你的倉庫、依賴項、工具鏈和設置腳本。這樣一來，無需在本地機器上檢出分支，你就能直接在智能體的 VM 中測試更改。
MCP 工具¶
Cloud agents 可以使用爲你的團隊配置的 MCP (Model Context Protocol) 服務器。這樣一來，agents 在運行時即可訪問外部工具和數據源，例如數據庫、API 和第三方服務。
在 cursor.com/agents 中通過 MCP 下拉菜單添加並啓用個人 MCP 服務器。團隊管理員可在 Dashboard -> Integrations & MCP 下配置共享服務器。
管理員可以將共享的團隊 MCP 服務器關聯到默認團隊 marketplace。關聯後，這些服務器會繼續對 雲端代理 可用，也可供團隊成員在代理窗口、IDE 和 CLI 中安裝和配置。
Cloud agents 支持需要 OAuth 的 MCP 服務器。OAuth 按用戶生效，即使是團隊級別共享的 MCP 服務器也如此。
自定義 MCP 服務器¶
可以使用 HTTP 或 stdio 傳輸方式添加自定義 MCP 服務器。不支持 SSE 和 mcp-remote。
MCP 配置在持久化存儲時會被加密。敏感字段會被隱藏，保存後任何用戶都無法再讀取其內容：
env— 用於 stdio 服務器的環境變量headers— 用於 HTTP 服務器的請求頭CLIENT_SECRET— 用於 HTTP 服務器的 OAuth 客戶端密鑰
HTTP vs stdio¶
- HTTP (推薦) — 服務器配置絕不會出現在雲端代理的 VM 環境中。該代理無法訪問刷新令牌、請求頭或其他憑證。工具調用會通過後端代理。
- Stdio — 服務器在雲端代理的 VM 內運行，因此該代理可以訪問服務器的配置和環境變量。這與 stdio MCP 在 Cursor IDE 中的工作方式類似。
Stdio 服務器依賴 VM 環境來執行。在啓動雲端代理之前，我們無法驗證 stdio 服務器是否能成功運行。我們建議儘可能使用 HTTP MCP；如果你使用 stdio 服務器，請正確配置你的 environment setup。
Cursor Cloud MCP¶
Cursor Cloud MCP 是一個內置的診斷服務器，可在雲端代理運行期間使用。智能體可以查看當前運行，瀏覽同一環境中的相關運行，並獲取會話記錄、diff 元數據、環境詳情、運行事件和設置日誌，而無需手動收集鏈接和文件。
團隊管理員可以在團隊設置的 MCP 配置 中爲其團隊禁用 Cursor Cloud MCP。有關 MCP 管理控制的更多信息，請參閱團隊儀表盤。
訪問和權限¶
雲端代理對話可能包含提示詞、代碼、工具輸出和機密信息。所有工具都會對每個請求執行訪問檢查。
| 角色 | 你可以訪問的內容 |
|---|---|
| 團隊管理員 | 對於其已擁有訪問權限的倉庫和環境，可列出並查看團隊內雲端代理運行的詳細信息 (包括會話記錄) |
| 非管理員 | 只能訪問你自己的運行和會話記錄。你無法通過此 MCP 查看其他團隊成員的對話 |
即使是在共享環境中列出運行時，非管理員也只能看到由自己啓動或擁有的智能體。服務賬戶遵循與其運行所在用戶或團隊上下文相同的規則。
可查看的內容¶
| 類別 | 示例 |
|---|---|
| 當前運行 | 運行 ID、URL、倉庫、分支、模型、所有者、生命週期狀態，以及運行的啓動位置 (Cursor、Slack、GitHub、API 等) |
| 事件 | 運行儀表盤中顯示的設置、PR、工件和 MCP 身份驗證結果。對於當前運行，請使用 get-events；對於其他運行，請使用帶有 include_events 的 batch-fetch-details。請參閱工具下的事件類型。 |
| 相關運行 | 同一環境中的其他雲端代理，或在未附加已保存環境時，同一代碼倉庫中的其他雲端代理 |
| 環境 | 環境版本、完整的環境配置、儀表盤 URL，以及生效的出站網絡策略 |
| 會話記錄 | 用戶與智能體的完整對話，包括可用時的工具調用 |
| diff 元數據 | 智能體是否修改了代碼、修改了多少，以及是否創建了 PR |
| 設置日誌 | 環境設置和鏡像構建步驟中的原始日誌 |
工具¶
根據你使用的 MCP 客戶端，工具名稱可能會包含服務器前綴 (例如 cursor-cloud-run-info) 。底層工具包括：
| 工具 | 用途 |
|---|---|
run-info |
獲取當前運行的標識信息、元數據和 URL。從這裏開始。 |
environment-info |
獲取當前運行的環境版本、配置、儀表盤 URL 以及生效的出站策略。 |
get-events |
列出當前運行儀表盤中的事件，按時間從早到晚排列。 |
list-cloud-agents |
瀏覽你在此環境中可見的雲端代理運行。可按來源、狀態、日期、代碼更改、PR 創建情況和歸檔狀態進行篩選。 |
batch-fetch-details |
獲取特定運行 ID (bcId) 的詳細信息。可選擇通過 include_events 包含會話記錄、diff 元數據、設置日誌、環境信息和運行事件 (每個運行寫入 events.json；每批最多 50 個運行) 。 |
get-automation |
通過其 ID 獲取自動化的詳細信息，例如名稱和所有者。 |
list-environment-builds |
列出當前環境最近的 構建，並查看其狀態。 |
environment-build-logs |
下載構建的安裝和設置日誌。 |
trigger-environment-build |
使用當前配置或建議的安裝和啓動命令運行測試構建。 |
propose-environment-json |
在保存環境前，展示安裝和啓動命令供你審覈。 |
take-environment-snapshot |
智能體驗證環境設置後，爲機器創建快照。 |
check-environment-snapshot |
檢查環境快照是否已就緒。 |
request-environment-setup-actions |
請求會阻塞環境設置的用戶操作，例如添加機密信息。 |
get-events 以及啓用 include_events 的 batch-fetch-details 返回的儀表盤事件 kind 值如下：
kind |
含義 |
|---|---|
setup_started |
環境設置已開始。 |
setup_completed |
環境設置已完成。 |
setup_failed |
環境設置失敗。 |
pr_created |
PR 已創建。 |
pr_creation_failed |
PR 創建失敗。 |
artifact_created |
演練工件已上傳。 |
mcp_auth_error |
MCP 服務器身份驗證失敗；其工具已跳過，運行繼續進行。 |
典型的診斷流程是 run-info → get-events → environment-info → list-cloud-agents → batch-fetch-details (需要其他運行的儀表盤事件時，設置 include_events) 。
訂閱¶
智能體任務很少會在最後一次提交後就結束。CI 必須通過。審閱人會留下評論。隊友可能需要在 Slack 中回答問題。訂閱功能讓雲端代理能夠等待這些事件，並在事件發生後繼續工作，無需你再次提供提示詞。
智能體訂閱事件源後，會結束當前輪次，並在收到匹配事件時被喚醒。事件會作爲同一對話中的後續消息送達，因此智能體可以在完整上下文中繼續工作：
- 創建 PR，然後響應評審評論和 CI 失敗，直到合併
- 在 Slack 中提問，並在有人回覆後繼續
- 使用計時器跟進長時間運行的任務
要訂閱，請在提示詞中說明等待條件。例如，“創建 PR 並保持 CI 通過，直到合併”或“在 #releases 中提問並等待批准”。你也可以調用內置的 /subscribe 技能，其工作方式相同：告訴它要監控什麼，智能體會選擇合適的訂閱。
智能體可以訂閱以下集成的事件：
| 集成 | 事件 |
|---|---|
| GitHub | 單個 PR、整個倉庫或某位作者的 PR 的 PR 活動 (評論、評審和生命週期更改) ，以及分支上的 CI 結果。使用 GitHub 集成。 |
| Slack | 線程中的回覆、頻道中的消息，以及新建的公開頻道。使用 Slack 集成。 |
| Linear | 新建的問題、狀態發生變化的問題，以及問題上的新評論。使用 Linear 集成。 |
| 計時器 | 某個時間點：延遲後的單次提醒，或定期執行的 cron 計劃。循環執行也可通過內置的 /loop 技能實現。 |
訂閱的工作方式¶
- 訂閱屬於單個智能體對話。事件會以後續消息的形式喚醒該智能體。
- 短時間內集中到達的多個事件會合並處理，可能只喚醒智能體一次；智能體會在執行操作前重新讀取來源 (PR、線程或 問題) 。
- 訂閱最多持續 180 天。等待結束後，智能體也會自行取消訂閱。
修復 CI 失敗¶
雲端代理會自動嘗試修復它們創建的 PR 中的 CI 失敗。目前僅支持 GitHub Actions。
如果出現以下情況，雲端代理會跳過自動 CI 後續處理：
- 你已向該分支推送了新的提交；雲端代理不會自動修復人工提交中的 CI 失敗。
- 你已向智能體發送了後續消息。
- 同一檢查在該 PR 的基準提交中已經失敗。
- 該 PR 已經有過 10 次 CI 失敗後續處理。
要在你所有個人 雲端代理 上禁用此功能，請前往 Cursor Dashboard → Cloud Agents → My Settings 並禁用 “Automatically fix CI Failures” 選項。
要在某個特定 雲端代理 PR 上禁用此功能，你可以在該 PR 中評論 @cursor autofix off。若要重新啓用，請評論 @cursor autofix on。
如果你希望 雲端代理 修復你自己 PR 中的 CI 失敗，只需像平常一樣在評論中 @Cursor 提出請求即可。例如，@cursor please fix the CI failures，或 @cursor fix the CI lint check failure。
自動修復 CI 失敗目前僅適用於 Teams；對非 Teams 賬戶的支持即將推出。
與此同時，如果你想要類似的行爲，可以明確要求 雲端代理 監控並修復該 PR 上的 CI
失敗。
OIDC 身份令牌¶
由 Cursor 管理的 雲端代理 VM 可通過本地套接字簽發短期有效的 OIDC JWT。agents 使用這些令牌來承擔雲端角色或調用內部 API，無需存儲長期密鑰。請參閱 OIDC 令牌。
智能體元數據¶
同一套接字還提供智能體元數據。agents、鉤子和腳本可以將智能體 ID、所有者、當前輪次和工作區作爲純文本讀取。
