Cursor 上线了 Self-Hosted Machines，允许团队把云端编程智能体的工具执行环节放到自己管理的机器上运行。搬走的只有执行环境，智能体循环、推理和规划仍旧留在 Cursor 云端，任务的启动与调度也由 Cursor 负责。
连接方式反过来做：企业机器装上 Cursor CLI，运行 agent worker start，由这台机器向 Cursor 云端建立一条长期的出站 HTTPS 连接。Cursor 官方明确写着，平台不会主动向企业网络内部发起连接。对安全团队来说，这是一条只出不进的通道，防火墙策略不用为它开洞。
为什么要把执行搬回来
Cursor 列了三类场景。一是智能体干活时需要直连内网的源码仓库、内部服务和数据库，托管虚拟机够不着；二是需要特定硬件，比如跑训练要 GPU、编 iOS 应用要 Mac；三是操作系统或构建流水线本身太重，塞不进标准的云端镜像。
这三类拦住的都是大公司。中小团队用托管沙箱没什么障碍，而金融、医疗和大型制造业的合规要求往往写死了代码不落第三方基础设施，此前这类客户只能把智能体挡在门外。
两种形态与一串合作方
配置分两级：My Machines 把单台笔记本或虚拟机挂到个人账户下；Pools 是团队和企业级的命名队列，按请求量自动扩缩容量。后者对应的是几十上百人共用一批构建机的场景。
沙箱侧接了一批供应商，包括 AWS Lambda、Cloudflare、Coder、Daytona、E2B、Modal、Namespace 和 Vercel。这些名字凑在一起说明了这次发布的定位：Cursor 不打算自己造隔离运行时，把这一层交给已经在做的人，自己守住智能体调度和模型这两块。Namespace 提供的能力比较特别，能给每个云端智能体会话拉起一台真实的 Mac。
Linux 与 Mac worker 同时开放了浏览器控制，机器上装好 Chrome 或 Chromium 依赖即可，智能体可以自己点开页面验证改动。
一个能说明问题的数字
Cursor 在文中透露，其内部合并的拉取请求中已有超过 60% 由云端智能体创建。这个比例出现在一篇讲企业部署的文章里，用意很清楚——先证明自己在用，再谈让客户把机器交出来。
从产品线看，Cursor 这一年一直在往调度层走：先是把智能体搬上云，再解决启动速度，现在处理运行位置。编程工具的竞争重心从补全质量挪到了运行时归属，谁能同时满足”托管体验”和”代码不出网”，谁就拿得到大客户的预算。
参考来源：Cursor 官方博客、CocoLoop、各沙箱供应商公开说明；60% 的内部合并占比、连接方式与供应商名单以 Cursor 官方表述为准。