在你管理的機器上執行雲端代理
Cursor 雲端代理可以在你網路內動態排程的機器池上執行。底層基礎架構由你管理，而代理仍由 Cursor 啟動與管理。
這讓團隊能更好地掌控代理在何處執行、使用哪些基礎架構。代理可以緊鄰內部服務與版本控制運作、在自訂硬體上執行，或使用難以封裝成 Cloud Agent build 的作業系統與建置流程。
在我們內部合併的 PR (拉取請求) 中，現已有超過 60% 由雲端代理建立；在我們合作的許多大型企業中，它們也承擔了越來越多的軟體開發工作。隨著角色日益吃重，它們所執行的機器同樣變得更加關鍵。這些新能力讓團隊得以務實地大規模提供並管理相關基礎架構。
以 Lambda MicroVMs 作為 Cursor 雲端代理的運算層，開發者就能在自己的 AWS 帳戶中執行 AI 驅動的程式設計代理。每台機器都能從快照近乎即時啟動、閒置時暫停，並在恢復時保留完整狀態。你的程式設計代理可享有 Lambda 的快速啟動、強力隔離與零機群管理，同時由 Cursor 負責調度工作。
控制 代理 在何處執行
Cursor 託管的環境仍是雲端代理的預設選項。每個工作階段都在 Cursor 雲端中的專屬 VM 上執行，已預先安裝所需相依套件，並具備獨立的網路控制。各 代理 之間的隔離、密鑰遮蔽、出站控制與簽署提交，足以滿足多數團隊的安全需求。
團隊通常會在以下情況使用 Self-Hosted Machines：
- 代理 的工具執行必須在自家網路內進行，並直接存取版本控制、內部服務與程式碼儲存庫。
- 代理 需要自訂硬體，例如 GPU 或用於 iOS 開發的 Mac，或是 Kubernetes、沙箱、受管 VM 等基礎架構。
- 其作業系統或建置流程難以封裝成 Cloud Agent build。
使用 Self-Hosted Machines 時，只有執行環境會移轉，代理 loop、推論與規劃仍留在 Cursor 雲端。工具輸出會回傳至 Cursor 進行推論，其中可能包含程式碼；代理 對話記錄也可能由 Cursor 處理並儲存。團隊仍可從桌面應用程式、cursor.com、行動裝置、Slack、GitHub 與 Linear 存取雲端代理。
Worker 將你的基礎架構連接到 Cursor 代理 loop
有了 Self-Hosted Machines，工具執行 會從 Cursor 託管的 VM 轉移到你環境中的機器上。該機器保存 儲存庫 的工作副本、編輯 files 並執行 commands，而 worker 則負責將它連接到 代理 系統的其他部分。
若要註冊一台機器，請安裝 Cursor CLI 並執行 agent worker start 來啟動 worker。這會開啟一條長時間存在、通往 Cursor 雲端 的對外 HTTPS 連線。當 工作階段 開始時，Cursor 的 代理 harness 會負責 推論 與 規劃，接著將 tool calls 傳送給專屬的 worker 執行，worker 再將結果回傳，供下一輪 推論 使用。Cursor 絕不會主動向你的網路發起連線。
Worker 有兩種設定方式。
- My Machines. 此組態會將單一筆電或 VM 連接到你的帳戶，最適合個人 workflows。
- Pools. 池 是一個具名的 worker 佇列，可供 team 或企業使用。容量會隨著 請求 湧入而增加，並在 workers 中斷連線後縮減，讓你現有的 cloud 基礎架構能隨開發者需求彈性 scale。
開發者應該能自由選擇最適合其工作流程的平台來執行 coding agents，企業也不該在代理執行位置與可存取範圍的掌控上有所妥協。開發的未來，將建立在安全、隔離環境中執行的強大代理之上。
雲端代理適應你的基礎架構
Worker 池現在可依據排隊中的請求自動擴縮，並執行來自任何儲存庫的工作。我們也新增了對多家沙箱供應商的支援，並讓電腦使用功能除了 Mac 之外也支援 Linux。
池隨需求擴展，並可服務任何儲存庫
雲端代理的需求往往一次湧現，而 Self-Hosted Machines 池會自動因應這類尖峰。其運作方式是透過一個 controller 監看請求佇列，並使用團隊提供的 spawn 腳本，視需要啟動機器。
如果池中有可使用的 worker，該 worker 就會接下這個請求；否則請求會持續等待，直到有更多容量釋出，因此團隊不必自行決定要讓多少台機器持續運行。
團隊可以為每個 worker 連線設定閒置逾時。逾時後，該機器即可重設並重新加入池中。團隊也可以保留其工作區，以備 代理 收到後續內容時使用。
Self-Hosted Machines 讓團隊掌控 Cursor 代理的執行位置，而 Vercel Sandbox 讓這一切毫不費力。每個任務都能隨需取得一個隔離的沙箱，不必管理機器群，也不會有任何資源閒置。
在 代理 閒置時仍讓機器持續運行可能所費不貲；但若釋放機器，當後續內容抵達時，代理 可能需要好幾分鐘才能重建工作區。透過休眠機制，團隊可以改為對閒置機器建立快照後將其停止。若後續內容在重新連線的時間範圍內抵達，系統會還原快照，並以相同的 ID 啟動一個 worker；否則該請求可轉移到新的機器上。
池並未綁定個別儲存庫。請求只需指明所屬的池，任何可使用的 worker 都能接下它。如此一來，單一個池就能服務許多儲存庫。
Workers 可在支援的沙箱供應商上執行
Self-Hosted Machines 不需要從零打造自訂的沙箱層。我們與 AWS Lambda、Cloudflare、Coder、Daytona、E2B、Modal、Namespace 及 Vercel 合作夥伴關係，讓 workers 能在團隊現有沙箱運行之處啟動並進行調度。
在 Modal 上執行 Cursor Self-Hosted Machines，可為每個 Cloud Agent 工作階段配置一個 Modal Sandbox，等於為每項任務量身打造一台專屬機器。
代理 可在 Linux 與 Mac 上控制瀏覽器
繼 Mac 之後，Linux worker 現在也支援電腦使用。只要安裝必要的電腦使用相依套件 (包含 Chrome 或 Chromium) ，代理 就能按一下、擷取螢幕截圖並操作瀏覽器。你可以觀看它的桌面畫面，或直接從 Cursor 接手控制。
沒有 Mac 就無法打造 iOS 或 macOS 應用程式。Namespace Devboxes 會為每個 Cursor Cloud Agent 啟動一台真正的 Mac，現在它就能在 Apple 晶片上完成這些工作。
將雲端代理帶入你的環境
多年來，各團隊都圍繞著自己打造軟體的方式來形塑基礎架構。Self-Hosted Machines 讓雲端代理能更自然地融入其中，我們也很期待看到各團隊能把它發揮到什麼程度。
若要連接機器或設定機器池，請參閱文件開始使用。
