在基礎設施合作伙伴的平臺上運行團隊用量池 worker，或從參考模板入手，克隆後自行調整。無論哪種選項，運行的都是同一個 worker：Cursor 命令行界面向 Cursor 發起一條出站 HTTPS 連接，Cursor 通過該連接發送智能體工具調用。
合作伙伴指南和模板均爲參考架構。worker 鏡像、基礎設施、機密信息、伸縮策略以及生產環境驗證均由你負責。
合作伙伴指南¶
各合作伙伴均維護自己的指南，介紹如何在其平臺上運行自託管機器 worker：
- AWS Lambda. Cursor Self-Hosted Machines on Lambda MicroVMs
- Cloudflare. Cursor Cloud Agents on Cloudflare Sandbox
- Namespace. Cursor integration
- Modal. Cursor on Modal
- Daytona. Cursor Self-Hosted Machines on Daytona
- E2B. Cursor agents on E2B
- Vercel. Cursor with Vercel Sandbox
- Coder. Agent Relay for Cursor
參考模板¶
克隆以下任一倉庫，即可基於已可運行的 worker 部署開始。每個倉庫都會運行一個 worker controller，用於認領待處理用量池請求，併爲每次認領啓動一個 worker：
- AWS Lambda MicroVMs. anysphere/aws-lambda-workers：
--spawn鉤子會爲每個 claimed request 啓動一個由 Firecracker 隔離的 Lambda MicroVM。 - Cloudflare Containers. anysphere/cloudflare-workers：由 Cloudflare Worker 充當 controller，爲每個 claimed request 啓動一個 Cloudflare Container。
- Kubernetes. anysphere/k8s-workers：一個 Helm 示例，在你的 cluster 中運行
agent worker controller --spawn，無需 CRD 即可爲每個 claimed request 創建一個 Pod，或通過--warm-idle保持若干空閒的熱備 Pod。新部署請採用這一 Kubernetes 方式。
Cursor Kubernetes operator 和 WorkerDeployment Helm chart 已棄用。已在運行
operator 的 cluster 可繼續使用；operator 參考
仍會爲其保留。請不要在其上開始新的部署。
每個 integration 都需要什麼¶
平臺各不相同，但對 worker 的要求始終一致：
- 一個 Cursor 企業版方案，並由 team admin 在 Cloud Agents 儀表盤中啓用 自託管機器。
- 在
CURSOR_API_KEY中配置 service account API key。參見認證 worker。 - 可向
api2.cursor.sh、api2direct.cursor.sh和cloud-agent-artifacts.s3.us-east-1.amazonaws.com發起出站 HTTPS 連接。參見網絡。 - 一個 用量池 名稱或若干 labels，以便 Cursor 將相應的 requests route 到該平臺上的 worker。
如果只有一臺個人 machine，而非由平臺 managed 的 fleet，請使用我的機器。
後續步驟¶
- 團隊用量池：在平臺上實現自動化之前，先手動啓動一個 團隊用量池 worker。
- Worker controller：所有 參考模板 都基於的
--spawn鉤子模型。 - Kubernetes operator (已棄用) ：適用於已運行
WorkerDeploymentoperator 的 cluster 的參考內容。 - API 參考文檔：worker、團隊用量池、待處理請求隊列和 worker token 相關的端點。
