Cursor 推出 Self-Hosted Machines，云智能体可在企业自有机器上执行

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 访问云端智能体。

Workers 将你的基础设施连接到 Cursor 智能体循环

使用自托管机器（Self-Hosted Machines）后，工具执行将从 Cursor 托管的虚拟机转移到你环境中的一台机器上。该机器持有仓库的工作副本、编辑文件并运行命令。一个 worker 将其连接到智能体系统的其余部分。

要注册一台机器，请通过安装 Cursor CLI 并运行 agent worker start 来启动一个 worker。这会与 Cursor 云建立一条长期存活的出站 HTTPS 连接。当会话开始时，Cursor 的智能体编排层（agent harness）负责推理和规划，然后将工具调用发送给专用的 worker 执行。worker 返回结果，供下一轮推理使用。Cursor 绝不会主动发起进入你网络的连接。

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

1. 我的机器（My Machines）。 此配置将单台笔记本电脑或虚拟机连接到你的账户，最适合个人工作流。
2. 资源池（Pools）。 资源池是一个命名的 worker 队列，可为团队或企业提供服务。容量会随着请求的到来而增加，并在 worker 断开连接后减少，让你现有的云基础设施能够随开发者需求弹性伸缩。

开发者应当拥有在最适合其工作流的平台上运行编码智能体的灵活性，而企业也不应在控制智能体运行位置及其可访问内容方面妥协。开发的未来将建立在强大的智能体之上，它们运行在安全、隔离的环境中。

Meagan Gamache

Cloudflare 开发者平台产品管理总监

云端智能体适配你的基础设施

Worker 池现在可以根据排队请求进行伸缩，并从任意代码仓库获取任务。我们还新增了对多个沙箱提供商的支持，以及除 Mac 之外的 Linux 上的计算机使用（computer use）功能。

池随需求伸缩，服务任意代码仓库

对云端智能体的需求往往是突发式的，Self-Hosted Machines 池会自动适应这些突发流量。这是通过一个控制器实现的，该控制器监控请求队列，并使用团队提供的生成脚本（spawn script）按需启动机器。

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

团队可以为每个 worker 连接设置空闲超时时间。超时后，机器可以重置并重新进入池中。团队还可以保留其工作区，以备智能体收到后续任务时使用。

Self-Hosted Machines 让团队掌控 Cursor 智能体的运行位置，而 Vercel Sandbox 让这一切变得轻而易举。每个任务都能按需获得一个隔离的沙箱，无需管理服务器集群，也不会让任何资源闲置。

Allen Zhou

Vercel 技术团队成员

让一台机器在智能体空闲时持续运行可能成本高昂。但如果释放机器，当后续任务到来时，智能体可能需要几分钟来重建其工作空间。借助休眠（hibernation）功能，团队可以对空闲机器进行快照并停止运行。如果在重连窗口期内收到后续任务，快照会被恢复，工作进程将以相同 ID 启动。否则，请求可以转移到新机器上。

资源池（Pool）不绑定单个代码仓库。请求只需指明资源池，任何可用的工作进程都可以认领该请求。这样，一个资源池就可以服务多个代码仓库。

工作进程可跨受支持的沙箱提供商运行

Self-Hosted Machines 无需从零构建自定义沙箱层。我们与 AWS Lambda、Cloudflare、Coder、Daytona、E2B、Modal、Namespace 以及 Vercel 合作，使得工作进程可以在团队现有沙箱运行的任何位置被启动和编排。

Cursor Self-Hosted Machines on Modal 为每个 Cloud Agent 会话提供一个 Modal Sandbox，因此你可以为其分配一台针对任务量身定制的机器。

Adam Azzam

Modal 产品团队成员

智能体可在 Linux 和 Mac 上控制浏览器

Linux worker 现在与 Mac 一样支持计算机使用（computer use）。只要安装了所需的 计算机使用依赖项（包括 Chrome 或 Chromium），智能体就可以点击、截图并控制浏览器。你可以观看其桌面，或直接从 Cursor 接管控制。

没有 Mac 就无法构建 iOS 或 macOS 应用。Namespace Devboxes 为每个 Cursor Cloud Agent 启动一台真实的 Mac，现在这些智能体可以在 Apple 芯片上完成此类工作。

Hugo Santos

Namespace 首席执行官

将云端智能体引入你的环境

团队多年来一直在围绕自己的软件构建方式来塑造基础设施。Self-Hosted Machines 让云端智能体能够更自然地融入其中，我们也很期待看到团队能将它们发挥到何种程度。

如需连接机器或配置资源池，请参阅文档开始使用。