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

事件核心：发生了什么

Cursor 官方博客宣布上线 Self-Hosted Machines 功能。过去，Cursor 的 Cloud Agents（云智能体）默认运行在 Cursor 托管的云端虚拟机中，每个会话独立隔离，并配有依赖安装、密钥脱敏和出口流量控制。但很多企业有更高要求——代理需要直连内部代码库、访问自建服务、使用 GPU 或 Mac 等特殊硬件，或者操作系统和构建流程无法打包成 Cloud Agent 的标准镜像。

现在，团队可以通过在自有机器上运行 Cursor CLI 并执行 agent worker start 命令注册工作节点，这些节点会与 Cursor 云端建立一条常驻的 HTTPS 出站连接。智能体的推理和规划仍在 Cursor 云中完成，但文件操作、命令执行等工具调用会落到企业内部机器上执行，结果再回流至云端做下一轮推理——Cursor 不会主动向企业网络发起连接。配置方式分为“My Machines”（个人电脑/单台 VM）和“Pools”（命名的可动态扩缩容的 Worker 队列）两种，后者可配合团队自备的 spawn 脚本按请求队列自动扩容。

此外，Cursor 宣布与 AWS Lambda 合作，以 Lambda MicroVMs 作为运行层，开发者可以在自己的 AWS 账户内启动编码智能体。同时，平台扩展了对多种沙箱提供方的支持，并加入了 Linux 和 Mac 上的 computer use（计算机操作）能力。Cursor 内部数据显示，目前云智能体已生成其内部合并 Pull Request 的 60% 以上。

为什么重要

这一功能本质上是把 AI 编程智能体从“云端黑盒”变成“可放进企业围墙内的执行单元”，有两点行业意义。第一，它打破了智能体只能运行在模型厂商基础设施上的默认假设——企业可以继续用 Cursor 的智能体编排和推理能力，但把执行环境拉到自己的 VPC、本地机房或自有 AWS 账号里。对于金融、医疗、政企等受合规约束、对代码出域高度敏感的行业，这可能是采用 AI 编码助手的先决条件。

第二，Cursor 正在从单一 IDE 插件演进为“智能体调度层”。通过 Pools 模式和 spawn 脚本，代理可以像 Kubernetes 工作负载一样按需扩缩容，并能调用 GPU、Mac、特定 OS 等异构资源，这补上了云智能体在复杂构建链路上的短板。与 AWS Lambda 的集成也表明，Cursor 希望嵌进企业已有的云资源体系，而不是替代它。Cloudflare 开发者平台产品管理总监 Meagan Gamache 在博客中表态支持这种“代理跑在安全隔离环境中”的方向，侧面反映生态方对这一路径的认可。

对用户/开发者/创作者的影响

对普通开发者：如果你的日常工作需要直连公司内网服务（比如内部 npm 源、私有 Git 仓库），Self-Hosted Machines 可以让你用上云智能体而不必担心把敏感代码带到外部 VM 上。My Machines 模式还能把一台闲置电脑变成编码智能体的执行节点，适合个人深度调试。

对企业技术负责人：可控性是核心收益。团队可以保留对执行机器、网络策略和数据留存的管理权，同时获得 Cursor 的智能体规划与编排能力；当任务突发时，Pools 会按请求量自动拉起机器，避免预先购置大量算力闲置。需要为 iOS 构建准备 macOS 环境、或需要 GPU 跑测试的企业，也不再受限于 Cursor 托管的机器规格。

对平台型开发者：这一机制实际上开放了一个“基础设施接入层”——只要你的机器能跑 Cursor CLI，就能作为执行节点接入智能体生态，这意味着未来可能有更多企业将自己的 CI/CD 流水线或沙箱产品与 Cursor 对接。

值得关注的后续

其一，执行与推理分离的安全边界是否经得住实战检验。工具执行的输出会回传至 Cursor 云端做推理，且代理记录可能被 Cursor 处理或存储，这在严格合规场景（如涉密代码）中如何满足要求，仍有待观察。

其二，Pools 的扩缩容成熟度。虽然官方称能响应突发请求，但 spawn 脚本、idle timeout 和 workspace 保留机制的稳定性，将决定这一功能能否真正支撑企业级规模的并行编码任务，而不仅是小团队试用。

其三，竞品会否跟进。GitHub Copilot Workspace、Devin 等同类产品均在探索云端智能体的部署边界，若 Cursor 这套模式在企业侧跑通，可能推动整个行业从“只卖托管服务”转向“开放执行环境”的混合架构。

来源：Cursor Blog