企业想让 Cloud Agent 访问内网代码、私有服务、GPU 或 Mac，却不一定愿意把完整执行环境搬到供应商云端。Cursor 的 Self-Hosted Machines 给出一种混合架构：Agent 的推理、规划和会话管理继续由 Cursor 托管，工具执行面 则发生在企业控制的机器上。
Cursor 称 Cloud Agent 已生成其内部合并 PR 的 60% 以上。随着 Agent 承担更多工作，运行位置不再只是部署细节，而是权限、安全和成本模型的一部分。
#Worker 只建立出站连接
企业在机器上安装 Cursor CLI 并运行 agent worker start。Worker 通过长期出站 HTTPS 连接到 Cursor 云端；当任务开始时，云端 Harness 产生工具调用，指定 Worker 执行，再把结果送回下一轮推理。Cursor 不需要主动连接企业内网。
Cursor 云端负责 Agent 循环，企业网络中的 Worker 负责工具执行
这个边界能让工作副本、构建环境和内部服务留在现有基础设施中，但并不等于所有数据都留在本地。工具输出会回传用于推理，其中可能包含代码；Agent 轨迹也可能由 Cursor 处理和保存。官方文章明确提示了这一点。
#从一台机器扩展到弹性 Pool
My Machines 适合把个人电脑或单台 VM 接入账户；Pools 则把一组 Worker 变成团队队列。控制器观察待处理请求，调用企业提供的 spawn 脚本启动新机器；空闲 Worker 领取任务，没有容量时请求排队。
Cloud Agent 可使用 Cursor 托管环境，也可调度企业服务器或公共云中的 Worker
Worker 可以设置空闲超时。直接释放机器最省钱，却会让后续任务重新构建环境；休眠与快照则在成本和恢复速度之间折中。Pool 不绑定单个仓库，一组容量可以服务多个代码库。
Cursor 同时接入 AWS Lambda、Cloudflare、Coder、Daytona、E2B、Modal、Namespace 和 Vercel 等执行环境。Linux Worker 支持浏览器控制，Mac Worker 则覆盖 iOS 和 macOS 构建等必须使用 Apple 硬件的任务。
#需要审计的是完整数据平面
这种架构适合三类场景：任务必须访问内网资源，需要 GPU 或 Mac 等特殊硬件，或者现有构建链难以封装进标准云环境。它把执行位置交给企业，却保留了托管 Agent 的入口与编排体验。
托管机器与 Self-Hosted Machines 的适用边界
真正上线前仍需确认至少四件事：哪些命令和路径可访问、哪些工具输出会离开网络、快照和工作区保存多久，以及 Worker 身份如何与仓库权限绑定。出站连接降低了网络暴露面，但不能替代最小权限和可追踪审计。
Cursor 的方案说明 Coding Agent 基础设施正在拆成两个平面：云端控制面负责推理和调度，客户执行面负责靠近代码与硬件。未来企业比较 Agent 平台时，部署问题不再是“云端还是本地”二选一，而是每一层究竟由谁控制。