Cursor发布Self-Hosted Machines功能：开发者可将云代理的执行环境迁移至自己管理的机器池或AWS Lambda、Cloudflare等沙箱提供商，代理循环与推理仍在Cursor云端进行。
AI解读：Cursor这次更新的核心是把云代理的“执行环境”和“控制大脑”分离。以前，代理运行的虚拟机都在Cursor的云里；现在通过Self-Hosted Machines，你可以把执行部分放到自己内网的机器或AWS Lambda这类沙箱上，而规划、推理仍由Cursor处理。这解决了什么具体问题？如果你的代码库、内部服务或构建流程必须留在公司网络内，或者你需要GPU、Mac等特殊硬件，以前Cursor云代理难以接入；现在它可以作为代理的工作环境直接访问这些资源。对团队影响最直接的是：代理能碰到的数据和系统范围变了，安全边界从Cursor云端移到了你控制的基础设施上。但要注意，工具执行产生的代码和代理记录仍会传回Cursor处理，所以数据合规要求高的团队需要先确认这一点是否可接受。普通个人开发者如果只在自己的电脑上跑代理，用最基本的“我的机器”模式即可，不必立即调整。
Cursor于 2025 年宣布推出Self-Hosted Machines，允许其云代理在用户指定的动态机器池中执行工具操作，这些机器可位于用户自有网络内，或由多家沙箱提供商托管。Cursor称，机器由用户管理，代理仍从Cursor启动和控制；代理循环、推理与规划仍留在Cursor云中，只有执行环境移至用户侧。
工作原理与连接方式
要注册一台机器，用户需安装Cursor CLI并运行agent worker start，这会在机器与Cursor云之间建立一个长期向外的HTTPS连接。当会话开始时，Cursor的代理框架处理推理和规划，然后将工具调用发送给专用worker执行，worker将结果返回以进行下一轮推理。Cursor表示永远不会主动发起进入用户网络的连接。
机器可通过两种方式配置：My Machines将单个笔记本或虚拟机连接到账户，适用于个人工作流；Pools是可为团队或企业提供服务的命名worker队列，容量随请求而增加，并在worker断开后减少。
池扩展与休眠机制
根据Cursor的博客文章，池可以响应排队请求自动扩展，并由控制器监视请求队列，使用团队提供的生成脚本按需启动机器。如果池中有可用worker，则其认领请求；否则请求等待，直到更多容量可用。团队可以为每个worker连接设置空闲超时，超时后机器可以重置并重新进入池中，也可以保留其工作区以备后续跟进。
为了防止闲置机器成本过高，Self-Hosted Machines支持休眠功能：团队可以快照并停止空闲机器。如果在重新连接窗口内有后续请求到达，快照将被恢复，并以相同ID的worker启动；否则请求可以转移到新机器。池不限于单个仓库，任何可用worker均可认领请求，使得一个池能够服务多个仓库。
支持的平台与安全策略
Cursor表示，Self-Hosted Machines与多家沙箱提供商合作，包括AWS Lambda、Cloudflare、Coder、Daytona、E2B、Modal、Namespace和Vercel，因此用户可以在现有沙箱运行之处启动和编排worker。Cursor团队的工程副总裁还特别提到与AWS Lambda的合作，使用Lambda MicroVMs作为计算层；Lambda产品经理称机器可从快照近乎即时启动、空闲时挂起、恢复时保持完整状态。
在安全方面，Cursor保留了企业安全功能，包括每个代理的隔离、秘密编辑、出口控制和签名提交。工具输出会传回Cursor进行推理，可能包含代码；代理记录可能由Cursor处理和存储。用户可以从桌面应用、cursor.com、移动设备、Slack、GitHub和Linear继续访问云代理。
新增的沙箱支持与使用场景
根据公告，Linux worker现在支持计算机使用功能，允许代理像在Mac上一样操作浏览器——点击、截图并控制浏览器。Cursor还增加了对多种沙箱提供商的支持，并支持Linux和Mac系统。对于iOS或macOS开发，Namespace的Devboxes可为每个Cursor云代理提供真实的Mac环境。
Cursor在其博客文章中表示，当团队需要代理内部服务、源代码控制或代码仓库的直接访问权限，或需要定制硬件（如GPU或用于iOS的Mac），或操作系统/构建管线难以打包为云代理构建时，通常会使用Self-Hosted Machines。目前，Cursor托管的环境仍作为默认选项。
- 文件中的标题为“在您管理的机器上运行云代理”，来源为Cursor博客。
- 关注的重点是Cursor云代理现在可以执行在用户管理的机器池上。