通过您管理的机器或通过 AWS Lambda、Coder、Cloudflare、Daytona、E2B、Modal、Namespace 和 Vercel 等受支持的沙盒提供商来运行代理。

https://t.co/rXltJ3fgD3

在您管理的机器上运行云代理

来源：https://cursor.com/blog/self-hosted-machines Cursor 云代理可以在您网络内动态调度的机器池上执行。您管理底层基础设施，而代理仍由 Cursor 启动和管理。

这让团队对代理的执行位置及其使用的基础设施拥有更多控制权。代理可以在内部服务和源代码管理旁边工作，运行在定制硬件上，或使用难以打包为云代理构建包的操作系统和构建流水线。

云代理目前在我们内部合并的拉取请求中占比超过 60%，并且在我们合作的许多最大企业中，承担着日益增长的软件工作份额。随着其角色的扩展，它们运行的机器也变得愈发重要。这些新功能使得团队能够大规模提供和管理该基础设施成为可能。

以 Lambda MicroVMs 作为 Cursor 云代理的计算层，开发者可以在自己的 AWS 账户中运行 AI 驱动的编码代理。每台机器从快照近乎即时启动，空闲时挂起，恢复时保持完整状态。您的编码代理受益于 Lambda 的快速启动、强隔离和零集群管理，而 Cursor 则负责编排工作。

Ayush Kulkarni 高级产品经理 , AWS Lambda

控制代理的执行位置

Cursor 托管环境仍然是云代理的默认选择。每个会话在 Cursor 云内的专用虚拟机上运行，安装其依赖项并拥有自己的网络控制。每个代理的隔离、密钥掩码、出口控制和签名提交满足大多数团队的安全要求。

团队通常在以下情况下使用自托管机器：

• 代理工具执行需要在他们的网络内进行，直接访问源代码管理、内部服务和代码仓库。
• 代理需要定制硬件，例如用于 iOS 开发的 GPU 或 Mac，或基础设施，如 Kubernetes、沙盒或托管虚拟机。
• 其操作系统或构建流水线难以打包为云代理构建包 (https://cursor.com/docs/cloud-agent/builds)。

使用自托管机器时，只有执行环境会转移，而代理循环、推理和规划仍保留在 Cursor 云中。工具输出会流回 Cursor 用于推理，可能包含代码，代理记录可能会被 Cursor 处理和存储。团队可以继续通过桌面应用、cursor.com (https://cursor.com/)、移动端、Slack、GitHub 和 Linear 访问云代理。

何时使用自托管机器与 Cursor 托管云代理的决策指南

Worker 将您的基础设施连接到 Cursor 代理循环

使用自托管机器时，工具执行从 Cursor 托管的虚拟机转移到您环境中的机器上。该机器持有仓库的工作副本，编辑文件并运行命令。一个 worker 将它连接到代理系统的其余部分。

要注册一台机器，请通过安装 Cursor CLI 并运行 agent worker start 来启动一个 worker。这会打开一个到 Cursor 云的长期传出 HTTPS 连接。当会话开始时，Cursor 的代理管理器处理推理和规划，然后将工具调用发送到专用的 worker 进行执行。worker 返回结果用于下一轮推理。Cursor 永远不会主动连接到您的网络。

架构图：显示云端的 Cursor 代理循环和您网络中 worker 上的工具执行

云代理的部署选项：Cursor 托管的机器或您服务器和公共云上的 worker

Worker 可以通过两种方式配置。

1. 我的机器：此配置将单台笔记本电脑或虚拟机连接到您的账户，最适合个人工作流。
2. 池：池是一个命名的 worker 队列，可为团队或企业服务。随着请求到达容量增加，在 worker 断开连接后容量减少，让您的现有云基础设施能够根据开发人员的需求进行扩展。

开发人员应该灵活地在最适合其工作流的平台上运行编码代理，公司不应该在代理的运行位置和其可访问的内容的控制上做出妥协。开发的未来将建立在强大的代理之上，运行在安全、隔离的环境中。

Meagan Gamache 开发平台产品管理总监 , Cloudflare

云代理适应您的基础设施

Worker 池现在可以根据排队的请求进行扩展，并为任何仓库提供服务。我们还增加了对 Linux 以及 Mac 上多个沙盒提供商和计算机使用的支持。

池随需求扩展并服务于任何仓库

对云代理的需求通常是突发性的，自托管机器池会自动适应这些突发情况。这是通过一个控制器实现的，该控制器监视请求队列，并使用团队提供的启动脚本按需启动机器。

如果池中有一个可用的 worker，该 worker 会认领请求。否则，请求会等待直到有更多容量可用，因此团队不必决定保留多少台机器运行。

团队可以为每个 worker 连接设置空闲超时。一旦超时，机器可以重置并重新进入池中。团队也可以保留其工作区，以防代理收到后续请求。

自托管机器让团队掌控 Cursor 代理的运行位置，而 Vercel Sandbox 使其变得毫不费力。每个任务都按需获得一个隔离的沙盒，无需管理集群，也不会有任何资源闲置。

Allen Zhou 技术员工 , Vercel

在代理空闲时让机器保持运行可能很昂贵。但如果释放了机器，当后续请求到达时，代理可能需要几分钟来重建其工作区。通过休眠，团队可以快照并停止空闲的机器。如果在重新连接窗口内收到后续请求，则会恢复快照，并使用相同的 ID 启动 worker。否则，请求可以转移到一台新机器。

池并不绑定到单个仓库。请求只需要标识池，任何可用的 worker 都可以认领它。这让一个池可以服务于多个仓库。

Worker 可在受支持的沙盒提供商上运行

自托管机器不需要从头开始构建定制的沙盒层。我们与 AWS Lambda (https://docs.aws.amazon.com/lambda/latest/dg/microvms-integrations-cursor-self-hosted-machines.html)、Cloudflare (https://developers.cloudflare.com/sandbox/tutorials/cursor-cloud-agents/)、Coder (https://coder.com/docs/ai-coder/agent-relay/cursor)、Daytona (https://daytona.io/docs/en/guides/cursor/cursor-self-hosted-machines)、E2B (https://docs.e2b.dev/agents/cursor)、Modal (https://modal.com/docs/cursor)、Namespace (https://namespace.so/docs/integrations/cursor) 和 Vercel (https://vercel.com/kb/guide/cursor-vercel-sandbox) 合作，允许在团队沙盒已运行的任何地方启动和编排 worker。

在 Modal 上运行的 Cursor 自托管机器为每个云代理会话提供一个 Modal Sandbox，因此您可以为其分配一台为其任务量身定制的机器。

Adam Azzam 产品员工 , Modal

代理在 Linux 和 Mac 上控制浏览器

Linux worker 现在支持与 Mac 相同的计算机使用。安装所需的计算机使用 (https://cursor.com/docs/cloud-agent/self-hosted/computer-use) 依赖项（包括 Chrome 或 Chromium）后，代理可以点击、截屏并控制浏览器。您可以直接从 Cursor 观看其桌面或进行控制。

没有 Mac 就无法构建 iOS 或 macOS 应用。Namespace Devboxes 为每个 Cursor 云代理启动一台真正的 Mac，现在它可以在 Apple 芯片上执行这项工作。

将云代理引入您的环境

团队多年来一直在围绕他们构建软件的方式来塑造其基础设施。自托管机器让云代理更自然地融入其中，我们期待看到团队能将它们应用到何种程度。

要连接机器或配置池，请从文档 (https://cursor.com/docs/cloud-agent/self-hosted) 开始。