Cursor 云端智能体可以在你网络内部动态调度的机器池上执行。底层基础设施由你管理,而智能体仍从 Cursor 启动和管理。
这让团队对智能体的执行位置以及它们使用的基础设施拥有更多控制权。智能体可以在内部服务和源代码控制旁边工作,可以在定制硬件上运行,也可以使用难以打包成 Cloud Agent 构建的操作系统和构建流水线。
云端智能体现在为我们内部合并的拉取请求贡献了超过 60% 的比例,并且在我们合作的许多大型企业中承担着越来越多的软件工作。随着它们角色的扩展,它们所运行的机器也变得更重要。这些新能力使团队能够大规模地提供和管理这些基础设施。
借助 Lambda MicroVMs 作为 Cursor Cloud Agents 的计算层,开发者可以在自己的 AWS 账户中运行 AI 驱动的编程智能体。每台机器都能从快照近乎即时启动,空闲时挂起,并在恢复时保留完整状态。你的编程智能体受益于 Lambda 的快速启动、强隔离性和零集群管理,而 Cursor 负责编排整个工作流程。
Ayush Kulkarni
AWS Lambda 高级产品经理
控制智能体的执行位置
Cursor 托管的运行环境仍然是云端智能体的默认选择。每个会话都在 Cursor 云中的专用虚拟机上运行,并安装其依赖项、配备独立的网络控制。按智能体隔离、密钥脱敏、出口流量控制和签名提交,能够满足大多数团队的安全要求。
团队通常在以下情况使用自托管机器:
- 智能体的工具执行需要在其网络内部进行,以便直接访问源代码管理、内部服务和代码仓库。
- 智能体需要定制硬件,例如用于 iOS 开发的 GPU 或 Mac,或者需要 Kubernetes、沙箱或托管虚拟机等基础设施。
- 他们的操作系统或构建流水线难以打包成 Cloud Agent 构建。
使用自托管机器时,只有执行环境发生迁移,而智能体循环、推理和规划仍保留在 Cursor 云中。工具输出会回流到 Cursor 进行推理,其中可能包含代码,智能体的对话记录也可能由 Cursor 处理和存储。团队可以继续从桌面应用、cursor.com、移动端、Slack、GitHub 和 Linear 访问云端智能体。


Worker 将你的基础设施连接到 Cursor 智能体循环
使用自托管机器时,工具执行会从 Cursor 托管的虚拟机迁移到你环境中的一台机器上。该机器持有仓库的工作副本、编辑文件并运行命令。一个 worker 将其连接到智能体系统的其余部分。
要注册一台机器,请安装 Cursor CLI 并运行 `agent worker start` 来启动一个 worker。这会与 Cursor 云端建立一条长期存活的出站 HTTPS 连接。当会话开始时,Cursor 的 agent 执行框架负责推理和规划,然后将工具调用发送给专用 worker 执行。worker 返回结果供下一轮推理使用。Cursor 绝不会主动发起进入你网络的连接。




Worker 可以通过两种方式进行配置。
- 我的机器(My Machines)。此配置将单台笔记本电脑或虚拟机连接到你的账户,最适合个人工作流。
- 资源池(Pools)。资源池是一个命名的 worker 队列,可为团队或企业提供服务。容量会随着请求的到来而增加,并在 worker 断开连接后减少,让你现有的云基础设施能够随开发者需求弹性伸缩。
云端 agent 适配你的基础设施
Worker 资源池现在可以响应排队请求进行伸缩,并能处理来自任何代码仓库的工作。我们还新增了对多个沙箱提供商的支持,以及除 Mac 之外的 Linux 系统上的 computer use 功能。
资源池随需求伸缩并服务任何代码仓库
对云端 agent 的需求往往是突发性的,而 Self-Hosted Machines 资源池会自动适应这些突发流量。这是通过一个控制器实现的,该控制器监视请求队列,并使用团队提供的 spawn 脚本按需启动机器。
如果池中有可用的 worker,该 worker 就会认领请求。否则,请求会一直等待,直到有更多容量可用,这样团队就无需决定要保留多少台机器在运行。
团队可以为每个 worker 连接设置空闲超时时间。超时一旦到期,机器可以重置并重新进入池中。团队也可以保留其工作区,以备智能体收到后续任务时使用。
自托管机器让团队能够掌控 Cursor 智能体的运行位置,而 Vercel Sandbox 让这一切变得轻而易举。每个任务都能按需获得一个隔离的沙箱,无需管理机器集群,也不会有任何机器闲置。
Allen Zhou
Vercel 技术团队成员
让一台机器在智能体空闲时保持运行可能成本高昂。但如果释放机器,当后续任务到来时,智能体可能需要几分钟时间来重建其工作区。借助休眠功能,团队可以对空闲机器进行快照并停止运行。如果在重连窗口期内收到后续任务,快照会被恢复,worker 会以相同的 ID 启动。否则,请求可以转移到一台新机器上。
池并不绑定到单个代码仓库。请求只需指明池,任何可用的 worker 都可以认领它。这使得一个池可以为多个代码仓库提供服务。
Worker 在受支持的沙箱提供商上运行
自托管机器(Self-Hosted Machines)无需从头构建自定义沙箱层。我们与 AWS Lambda、Cloudflare、Coder、Daytona、E2B、Modal、Namespace 和 Vercel 合作,让工作进程可以在团队现有沙箱运行的任何地方启动和编排。
Cursor 在 Modal 上的自托管机器(Self-Hosted Machines)为每个 Cloud Agent 会话提供一个 Modal Sandbox,因此你可以为它分配一台为其任务量身定制的机器。
Adam Azzam
Modal 产品团队成员
智能体可在 Linux 和 Mac 上控制浏览器
Linux 工作进程现在与 Mac 一样支持计算机操作(computer use)。安装所需的计算机操作依赖项(包括 Chrome 或 Chromium)后,智能体即可点击、截图并控制浏览器。你可以观看其桌面,或直接从 Cursor 接管控制。
没有 Mac 就无法构建 iOS 或 macOS 应用。Namespace Devboxes 为每个 Cursor Cloud Agent 启动一台真实 Mac,现在可以在 Apple 芯片上执行此类工作。
Hugo Santos
Namespace 首席执行官
将云端智能体带入你的环境
多年来,团队一直在围绕自己的软件开发方式构建基础设施。自托管机器让云端智能体能更自然地融入其中,我们也很期待看到团队能把这些机器用到多远。
如需连接机器或配置资源池,请从文档开始上手。
相关文章
在您自己的基础设施中运行云端智能体
Katia Bazzi
借助构建缓存,云端智能体启动速度提升 3 倍
Cursor cloud agents can execute on dynamically scheduled pools of machines inside your network. You manage the underlying infrastructure, while agents are still started and managed from Cursor.
This gives teams more control over where agents execute and what infrastructure they use. Agents can work next to internal services and source control, run on custom hardware, or use operating systems and build pipelines that are difficult to package as a Cloud Agent build.
Cloud agents now create more than 60% of the pull requests we merge internally and are taking on a growing share of software work at many of the largest enterprises we work with. As their role expands, the machines they run on matter more too. These new capabilities make it practical for teams to provide and manage that infrastructure at scale.
With Lambda MicroVMs as the compute layer for Cursor Cloud Agents, developers can run AI-powered coding agents in their own AWS account. Each machine launches near-instantly from a snapshot, suspends when idle, and resumes with full state. Your coding agents benefit from Lambda's fast startup, strong isolation, and zero fleet management, while Cursor orchestrates the work.
Ayush Kulkarni
Senior Product Manager, AWS Lambda
Control where agents execute
Cursor-hosted environments remain the default for cloud agents. Each session runs on a dedicated VM inside the Cursor cloud, with its dependencies installed and its own network controls. Per-agent isolation, secret redaction, egress controls, and signed commits meet the security requirements of most teams.
Teams generally use Self-Hosted Machines when:
- Agent tool execution needs to happen inside their network, with direct access to source control, internal services, and code repositories.
- Agents require custom hardware, such as GPUs or Macs for iOS development, or infrastructure such as Kubernetes, sandboxes, or managed VMs.
- Their operating system or build pipeline is difficult to package as a Cloud Agent build.
With Self-Hosted Machines, only the execution environment moves while the agent loop, inference, and planning remain in the Cursor cloud. Tool outputs flow back to Cursor for inference and may contain code, and agent transcripts may be processed and stored by Cursor. Teams can continue to access cloud agents from the desktop app, cursor.com, mobile, Slack, GitHub, and Linear.


Workers connect your infrastructure to the Cursor agent loop
With Self-Hosted Machines, tool execution moves from a Cursor-hosted VM to a machine in your environment. That machine holds the working copy of the repository, edits files, and runs commands. A worker connects it to the rest of the agent system.
To register a machine, run a worker by installing the Cursor CLI and running agent worker start. This opens a long-lived outbound HTTPS connection to the Cursor cloud. When a session begins, Cursor's agent harness handles inference and planning, then sends tool calls to a dedicated worker for execution. The worker returns the results for the next round of inference. Cursor never initiates a connection into your network.




Workers can be configured in two ways.
- My Machines. This configuration connects a single laptop or VM to your account and is best suited to personal workflows.
- Pools. A pool is a named queue of workers that can serve a team or enterprise. Capacity increases as requests arrive and decreases after workers disconnect, letting your existing cloud infrastructure scale with developer demand.
Cloud agents adapt to your infrastructure
Worker pools can now scale in response to queued requests and serve work from any repository. We have also added support for several sandbox providers and computer use on Linux alongside Mac.
Pools scale with demand and serve any repository
Demand for cloud agents often arrives in bursts and Self-Hosted Machines pools adjust to those bursts automatically. This happens through a controller which watches the request queue and uses a spawn script supplied by the team to start machines as needed.
If a pool has an available worker, that worker claims the request. Otherwise, the request waits until more capacity becomes available, so teams do not have to decide how many machines to leave running.
Teams can set an idle timeout for each worker connection. Once it expires, the machine can reset and re-enter the pool. Teams can also preserve its workspace in case the agent receives a follow-up.
Self-Hosted Machines put teams in control of where Cursor agents run, and Vercel Sandbox makes it effortless. Every task gets an isolated sandbox on demand, no fleet to manage, and nothing sitting idle.
Allen Zhou
Member of Technical Staff, Vercel
Leaving a machine running while its agent is idle can be expensive. But if the machine is released, the agent may need several minutes to reconstruct its workspace when a follow-up arrives. With hibernation, teams can snapshot and stop an idle machine instead. If a follow-up arrives within the reconnect window, the snapshot is restored and a worker starts with the same ID. Otherwise, the request can move to a new machine.
Pools are not tied to individual repositories. A request only needs to identify the pool, and any available worker can claim it. This lets one pool serve many repositories.
Workers run across supported sandbox providers
Self-Hosted Machines does not require building a custom sandbox layer from scratch. We partner with AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, and Vercel, allowing workers to be started and orchestrated wherever a team's sandboxes already run.
Cursor Self-Hosted Machines on Modal gives each Cloud Agent session a Modal Sandbox, so you can hand it a machine tailor-made for its task.
Adam Azzam
Member of Product Staff, Modal
Agents control browsers on Linux and Mac
Linux workers now support computer use alongside Macs. With the required computer use dependencies installed, including Chrome or Chromium, an agent can click, take screenshots, and control the browser. You can watch its desktop or take control directly from Cursor.
You can't build iOS or macOS apps without a Mac. Namespace Devboxes spin up a real Mac for each Cursor Cloud Agent, which can now perform that work on Apple silicon.
Hugo Santos
CEO, Namespace
Bring cloud agents into your environment
Teams have spent years shaping their infrastructure around how they build software. Self-Hosted Machines lets cloud agents fit more naturally into it, and we're excited to see how far teams take them.
To connect a machine or configure a pool, get started in the docs.
Related posts
Run cloud agents in your own infrastructure
Katia Bazzi
Cloud agents start 3x faster with builds