本文要点
- Cloud Agent从只用Cursor托管VM，变成可选客户机器和Team Pools。
- 工具调用迁移到worker，agent loop、推理和规划仍在Cursor云端。
- worker通过出站HTTPS连云端，无需客户开放入站端口。
阅读辅助
先看数字、证据和来源，再读正文。
9月2日新增事实是Self-Hosted Machines正式发布。
此前 · Cursor Cloud Agents以Cursor托管的隔离Ubuntu环境和Build快照为默认路径。
Cursor在9月2日发布Self-Hosted Machines，把Cloud Agents的工具执行放到客户管理的机器、公共云账户或企业worker池里。这条新闻的重点是Cloud Agent的执行位置开始被正式产品化：文件编辑、终端命令、浏览器动作和本地MCP进程可以在客户环境里跑，agent loop、推理和规划仍由Cursor云端处理。
官方给出的动因很直接。Cursor称Cloud agents现在创建了其内部合并PR的60%以上，并正在很多大型企业客户中承担更多软件工作。随着Agent接手的任务变重，运行机器是否能访问内网源码、私有包、构建缓存、Mac硬件和GPU资源，就从便利问题变成部署问题。
这次发布有几条可以确认的边界。worker通过agent worker start建立一条长连接，连接方式是出站HTTPS；Cursor称不会主动连入客户网络。Self-Hosted Machines只移动执行环境，Cloud Agent的推理、规划和调度没有搬到客户内网。工具执行结果仍会回传给Cursor用于下一轮推理，相关转录、artifact和会话数据也可能按Cursor的Cloud Agent数据政策处理。
对企业工程团队来说，这是一条实际可用的新路径。它能让Agent在已有devbox、远程VM、Kubernetes集群、AWS Lambda MicroVM、Cloudflare、Namespace、Modal、Daytona、E2B、Vercel或Coder这类环境里工作。但安全团队不能把它理解成“代码永不离开本地”。更准确的结论是：仓库副本、构建缓存、机器本地凭据和执行权限留在客户侧，推理所需的文件片段、终端输出、diff、截图、本地MCP结果和路由元数据仍可能离开客户网络。
新增的是执行边界
Cursor博客标题是“Run cloud agents on machines you manage”，页面日期为Sep 2, 2026。对应中文应写成“让云Agent在你管理的机器上运行工具执行”，不应扩写为“Cursor把Agent完全私有化”。博客正文对架构限制写得很清楚：在Self-Hosted Machines中，only the execution environment moves while the agent loop, inference, and planning remain in the Cursor cloud。也就是说，模型调用和任务规划还在Cursor云端，客户侧worker接收工具调用并返回结果。
这个拆分很重要。传统Cloud Agent默认在Cursor托管的隔离Ubuntu机器上运行，企业需要把仓库、依赖、密钥、网络访问和启动脚本配置到这个环境里。Cloud Environment Setup文档强调，Agent如果不能运行测试、查询服务或访问API，就很难闭环完成工程任务。Builds文档进一步说明，Cursor会把依赖安装、代码生成、编译产物和缓存提前做成可启动快照，让新Agent从准备好的机器开始。
Self-Hosted Machines改变的是这层“机器”。worker可以是个人开发机、devbox、远程VM，也可以是团队集中管理的worker池。它持有工作区，执行文件编辑、终端命令、浏览器动作和本地MCP server。Cloud端继续处理agent loop、模型访问、编排和用户体验。企业因此得到的是执行面控制，而不是模型私有部署。
官方文档把运行选择分成三类：Cursor-managed Cloud Agents、My Machines和Team Pools。前者仍是多数团队的推荐路径；后两者才属于Self-Hosted Machines。My Machines适合个人或小规模工作流，要求某个用户已经有带仓库、工具、凭据和私网访问的机器。Team Pools面向Enterprise团队，由管理员维护一组worker，用服务账号、pool标签、Kubernetes、autoscaling和监控来承接组织级请求。
| 运行方式 | 工具调用在哪里执行 | 谁管理机器生命周期 | 适合场景 | 关键边界 |
|---|---|---|---|---|
| Cursor-managed Cloud Agents | Cursor托管隔离VM | Cursor负责VM、隔离、快照和启动 | 大多数团队和常规仓库 | 仍需配置密钥、仓库和网络策略 |
| My Machines | 用户自己的机器 | 个人用户维护机器和工作区 | 单人devbox、远程VM、特定repo | 不是组织级fleet，每台机器绑定用户和repo |
| Team Pools | 企业worker或worker池 | 企业团队维护镜像、容量和监控 | 企业集中容量、专用硬件、内网执行 | 每个会话claim一个worker，仍由Cursor云端编排 |
这张表解释了为什么这条新闻值得放进今天的深度页。模型公司过去一年一直在强调长上下文、工具调用和代码生成分数；Cursor这次把产品重点落在“运行在哪里”。当Agent开始创建大量PR，企业采购不会只问模型能否写代码，还会问它能不能触达真实构建系统，能不能跑在审计可控的网络里，失败时谁排障，截图和日志流向哪里。
数据和网络边界必须逐项拆开
Self-Hosted Machines最容易被误读为“数据完全不离开企业”。官方文档没有这样承诺。Self-Hosted Machines overview写明，full checkout、build cache和machine-local credentials会留在客户机器上；但在一次run中，worker会把Agent需要的内容发送给Cursor，例如file contents、terminal output、diffs、screenshots、local MCP results和routing metadata。Cloud Agent artifacts，例如截图、视频和日志引用，也会上传到Cursor托管存储，以便出现在PR和dashboard中。
这并不等于功能没有安全价值。真正的变化在于入站面和执行面。worker需要的网络连接是出站HTTPS，文档列出的核心域名包括api2.cursor.sh、api2direct.cursor.sh，以及artifact上传用的cloud-agent-artifacts.s3.us-east-1.amazonaws.com。客户不需要给Cursor开入站端口、公共IP或VPN隧道。若要禁用artifact上传，文档建议阻断对应S3主机；这会让PR嵌入、dashboard预览和通知附件缺失，但Agent会话和其他工具调用仍可继续。
还有一层边界来自Privacy Mode。Cursor安全文档称Cloud Agents支持Privacy Mode，开启后代码不会被Cursor或模型供应商用于训练。但同一页也写明，Cloud Agents需要在运行期间存储代码和环境数据；conversation history默认无限期保留，环境快照在不活跃后最多保留90天。企业可申请更短的Cloud Agent数据保留策略，早期访问里可把团队数据保留上限设为90天。因此，合规评估需要把“训练使用”“运行期传输”“会话转录”“artifact存储”和“环境快照”分开审查。
Cursor博客里“tool outputs flow back to Cursor for inference and may contain code, and agent transcripts may be processed and stored by Cursor”这句话决定了产品边界。中文里不能把它淡化成“输出用于推理”。更完整的表述应该是：工具输出会回传给Cursor用于推理，可能包含代码；Agent转录也可能被Cursor处理和存储。Self-Hosted Machines降低了仓库全量托管和内网暴露的压力，但没有消除所有数据外流。
| 边界问题 | 官方确认 | 不能外推 |
|---|---|---|
| 执行位置 | 工具调用在客户机器或worker上运行 | Agent loop、推理和规划也迁到客户内网 |
| 网络连接 | worker通过出站HTTPS连Cursor云端 | Cursor可以主动连入客户网络 |
| 本地资产 | checkout、build cache、本地凭据留在客户机器 | 所有文件内容和输出都永不离开 |
| 工具结果 | 结果返回Cursor用于下一轮推理 | 返回内容不含代码或敏感日志 |
| artifact | 截图、视频、日志引用可上传到Cursor存储 | artifact默认完全本地保存 |
| 隐私模式 | 开启后代码不用于训练 | 会话数据不存储或不被风险检测处理 |
企业为什么会需要这条路径
Cursor文档给了三个主要理由。第一类是网络要求：代码或服务无法从外部网络访问。Cursor仍建议许多团队优先使用托管Cloud Agents加网络控制、Tailscale、Cloudflare Tunnel、AWS PrivateLink或私有连接；只有这些路径不能满足约束时，再把执行环境搬到客户机器。这个排序说明Cursor并没有把自托管包装成默认最佳实践，官方仍把它看成更重的基础设施选择。
第二类是硬件要求。iOS和macOS应用构建离不开Mac，部分机器学习、仿真或大型编译任务可能需要GPU、高内存或企业已有的特殊镜像。Computer use文档还说明，Self-Hosted Machines上的worker可以通过--computer-use让Agent点击、输入、截图并驱动应用；macOS需要Cursor Computer Use helper app，并由用户授予Accessibility和Screen Recording权限；Linux需要X11显示和一组桌面依赖。这类场景不是普通云VM可以轻松替代的。
第三类是组织级调度。Team Pools允许Enterprise团队用服务账号启动pool worker，用pool name和labels把任务路由到合适环境。Pool请求会等待可用worker；每个Cloud Agent会话一次claim一个worker。文档还给了待处理请求列表、SSE watch、claim、release、worker summary和metrics等接口，说明Self-Hosted Machines已经覆盖企业控制器和扩缩容系统，而不只面向个人开发机。
但这些收益都有运维代价。Team Pools文档明确说，客户团队需要运行fleet，维持足够worker，修补和刷新镜像，在run之间重置VM，管理容量，轮换凭据，监控健康并处理主机故障。Cursor-managed Cloud Agents把这些工作隐藏在平台里；Self-Hosted Machines把控制权交回来，也把责任交回来。对大企业来说，这可能是必要成本；对中小团队来说，可能反而不如继续使用托管环境加私网连接。
从Cloud Agent到企业执行面
这次发布和8月的Builds文档可以连起来看。Builds让Cloud Agent从准备好的快照启动，省掉每次clone和依赖安装。Self-Hosted Machines把快照和worker的所有权开放给客户。前者解决启动速度和可重复性，后者解决网络、硬件和合规边界。两者共同说明，编码Agent的瓶颈正在从“模型能不能改代码”转向“执行环境能不能代表真实工程现场”。
Cursor把Cloud Agent包装成一个跨终端入口：用户可以从桌面、网页、移动端、Slack、GitHub、Linear或API触发任务。API文档里env对象已经把执行目标抽象成cloud、pool或machine，并且说明pool和machine会路由到客户自有worker。这意味着自托管已经进入Cloud Agents的正式控制面，不再只是附属运维脚本。
这个抽象也会改变企业内部的权限设计。过去给开发者一台devbox，就是把权限给了一个人；现在给Agent一个worker，就是把某些终端命令、文件编辑、浏览器操作和MCP工具调用交给一个自动化主体。要让这件事可控，企业需要重新设计worker镜像、repo标签、pool标签、密钥注入、日志留存、artifact上传和sessionStart、sessionEnd hooks。Cursor文档说明Self-Hosted Machines worker会运行项目级.cursor/hooks.json，Enterprise场景还会运行团队和企业托管hook，这给了组织做准入、审计和清理的入口。
更细的安全分工可以这样理解：Cursor负责Cloud Agent产品层、模型访问和云端编排；企业负责worker主机、镜像、密钥、网络访问、监控和事故处理；模型供应商仍会参与推理链路，受Privacy Mode、ZDR协议和模型选择影响。只要三者没有被放到同一个责任矩阵里，自托管就容易被误卖成“私有部署”。这篇稿件应该把它讲成“执行面自托管”，避免写成“Agent全栈自托管”。
早报判断是，Self-Hosted Machines把编码Agent的竞争变量从模型能力推进到运行边界。企业现在面对的问题已经转向：Agent写完代码后，能不能在真实依赖、真实网络和真实硬件上验证。只要测试、构建、内网API和安全扫描还在企业侧，Agent就必须接近这些执行资源。
这条路径对Cursor也有战略意义。云端Agent如果一直跑在厂商管理的VM里，安全团队会反复要求例外、隧道、白名单和审计说明。把工具执行拆到客户worker，可以减少“把内网暴露给外部执行环境”的阻力，同时保留Cursor对模型、规划、协作界面和PR流程的控制。这不是放弃云端，而是把云端Agent拆成更适合企业采购的两层。
当前最需要警惕的是话术过度。Self-Hosted Machines并不等于代码和上下文完全不出企业网络。工具输出、文件片段、diff、截图、artifact和转录仍可能回传或存储；Privacy Mode解决训练使用边界，不自动解决所有运行期留存边界。企业如果只看“self-hosted”四个字，容易低估审计和数据分类工作。
更长期看，编码Agent的基础设施会越来越像CI runner和远程开发环境的结合体。谁能提供可控worker、可解释路由、可复现环境、可审计日志和低摩擦触发入口，谁就更容易进入大公司研发流程。Cursor这次发布把这条路摆到台面上，但真正的考验会发生在生产事故、权限误配、artifact泄露和峰值排队时。
需要继续观察的信号
接下来最值得看的是Cursor会不会把数据留存边界进一步产品化。今天的文档已经说明哪些东西会离开客户网络，但企业通常还需要更细的控制项：哪些tool output可以进入转录，截图和视频是否默认上传，artifact是否能按仓库或pool关闭，敏感日志是否会被自动脱敏，管理员能否导出每次会话的文件读取清单。没有这些能力，自托管只能解决一部分安全问题。
第二个观察点是Team Pools的真实运维表现。文档里的机制已经覆盖pending queue、claim、release、offline reconnect、worker metrics和controller loop，但这些接口在生产里的关键指标还没有公开案例：请求高峰时排队多久，worker镜像多大，冷启动成本多少，失败worker如何隔离，多个repo和any-repo pool如何防止凭据串用。对大型组织来说，这些指标会决定它能否替代内部CI runner和专用devbox流程。
第三个观察点是第三方sandbox生态。Cursor列出的集成包括AWS Lambda、Cloudflare、Namespace、Modal、Daytona、E2B、Vercel和Coder，官方还提供AWS Lambda MicroVMs、Cloudflare Containers和Kubernetes参考模板。它们把“自托管worker”从静态机器扩展成按需沙盒，但每家平台的隔离、冷启动、镜像更新、日志和网络模型都不同。早期采用者需要按自己的安全边界逐项验证，不能因为挂了Cursor官方集成名录就默认可上线。
最后是Mac和GUI工作负载。Computer use文档显示，macOS worker需要登录桌面会话，并授予Accessibility和Screen Recording；Linux worker需要X11、VNC、xdotool、ffmpeg和可用浏览器。这意味着iOS构建、桌面端测试和浏览器验收可以进入Cloud Agent流程，但它们也带来更复杂的权限和录屏数据治理。Self-Hosted Machines把这些能力打开了，企业是否愿意规模化使用，要看Cursor后续能否把权限、审计和失败恢复做得像CI一样清楚。