Cursor Self-Hosted Machines：哪些留在本地，什么时候值得用

Cursor Self-Hosted Machines 会把 Cloud Agent 的工具执行搬到你管理的机器上，但不会把整套 Cursor 服务部署到企业内网。Agent Loop（Agent 的运行循环）、模型推理和规划仍由 Cursor 云端处理；你的 Worker 则负责修改文件、运行命令和使用本地工具。

如果书面规则要求代码 Checkout 与工具执行留在组织边界内，任务需要访问托管环境无法到达的内部服务，或者你需要特殊硬件、操作系统和持久本地状态，可以考虑 Self-Hosted Machines。如果没有这些硬要求，而且团队不想维护 Worker 集群，Cursor 托管的 Cloud Agents 通常更直接。

本文只依据截至 2026 年 9 月 4 日核验的 Cursor 官方 Changelog 与文档，解释产品边界和选型条件；它不是安全审计、成本基准或性能实测。

Cursor 在 9 月 2 日更新了什么

Cursor 于 2026 年 9 月 2 日公布了 Self-Hosted Machines。这次更新扩展了 Cursor Cloud Agents 可以执行工具调用的位置，但没有改变 Cursor Agent 本身的运行位置。

现在可以区分三种 Runtime（运行位置）选择：

Cursor 托管的 Cloud Agents 在 Cursor 管理的虚拟机中执行。
My Machines 把一台笔记本、开发机或虚拟机连接到单个用户账号。
Team Pools 把团队请求分配给组织自主管理集群中的可用 Worker。

Cursor 同时公布了动态 Pool 调度、休眠与重新连接、多个基础设施和 Sandbox 服务商接入，以及 Linux 与 Mac Worker 上的 computer use。这些能力让它不再只是“某位开发者一直开着一台电脑”的个人方案，但并不会消除运行底层机器的责任。

所以这次更新的重点并不是“Cursor 终于能在本地运行”。Cursor 原本就有本地编辑器工作流。真正的变化是：Cloud Agent Session 可以继续使用 Cursor 的云端编排，同时把终端、文件、浏览器和其他工具操作发到你管理的基础设施执行。

到底哪部分是自托管，哪部分不是

Cursor 的 Self-Hosted Machines 官方文档描述的是一套拆层架构：

层级	在哪里运行	谁负责运维
Agent Loop、推理与规划	Cursor 云端	Cursor
Cloud Agent 客户端与 Session 界面	Cursor 桌面端、网页、手机端和受支持的集成	Cursor 与客户账号
文件修改、终端命令、本地 MCP Server 和可选 computer use	已连接的 Worker	你或你的基础设施服务商
Worker 镜像、操作系统、本地凭证、在线状态、磁盘和网络访问	你的基础设施	你

这是一种混合式执行模型，并不是完整的 Cursor 私有化部署。Worker 会通过 HTTPS 主动向外连接，Cursor 再通过这条连接发送工具调用。Cursor 表示，这条路径不需要开放入站端口、公共 IP 或 VPN Tunnel。

它也不等于自己运行整套 Agent SDK 与编排服务。托管 Agent 和自托管 Agent SDK 的比较讨论的是更完整的 Runtime 所有权问题；Cursor Self-Hosted Machines 保留 Cursor 的 Agent Loop 与产品体验，只移动范围更窄的执行层。

哪些留在自有机器，哪些仍会到达 Cursor

“工具执行留在自己的网络”不应该被理解为“没有任何内容离开自己的网络”。Cursor 官方文档给出了更准确的边界。

完整的代码 Checkout、Build Cache 和机器本地凭证会保留在 Worker 上。但在任务运行时，Worker 仍会把 Agent 规划和继续工作所需的内容发送给 Cursor。官方列出的例子包括文件内容、终端输出、Diff、截图、本地 MCP 结果和路由元数据。如果启用桌面共享，Worker 还会传输 Agent 的桌面画面。

截图、视频和日志引用等 Cloud Agent Artifact 会上传到 Cursor 管理的存储，以便显示在 Pull Request 和 Dashboard 中。Cursor 文档说明，可以通过阻止 Artifact Storage Endpoint 来停用这类上传，但代价是对应内容不再出现在这些产品界面中。

因此，真正有用的安全问题不是一句“它是不是自托管”，而是：

哪些文件和命令只留在 Worker？
Agent 为了规划下一步，必须让 Cursor 接收哪些内容？
哪些工具输出可能含有 Secret？
哪些 Artifact 会被上传和保留？
哪些身份可以启动、查看或控制 Session？

可以使用 Coding Agent Workspace 安全检查清单，把隔离、成员角色、凭证、权限和恢复分别审查。无论是托管 VM 还是自托管 Worker，都不能自动证明每一条被允许的命令是安全的。

Cursor 托管 Cloud Agents 与 Self-Hosted Machines 怎么选

两种选择都使用 Cursor 的 Cloud Agent 体验。真正不同的是谁拥有执行环境，以及谁负责让执行环境稳定运行。

判断维度	Cursor 托管 Cloud Agents	Self-Hosted Machines
工具执行位置	Cursor 管理的隔离 VM	你的笔记本、VM、容器、集群或受支持的 Sandbox
Agent Loop 与推理	Cursor 云端	Cursor 云端
私有资源访问	托管网络控制与受支持的私有连接方式	Worker 使用你的基础设施已有的网络路径和凭证
环境生命周期	Cursor 管理 VM 创建和销毁	你管理镜像、Worker 进程、补丁、清理、容量和恢复
特殊硬件或系统	受限于托管环境支持的配置	可以使用合适的 Mac、GPU 机器、自定义镜像或现有主机
本地状态	托管环境与已配置资源	你的 Checkout、磁盘、Cache、凭证和进程状态
执行成本	托管路径中包含执行基础设施	还需要支付并运维自己的 Worker 基础设施
数据路径	任务内容通过托管服务处理	Checkout 留在本地，但 Agent 所需的任务内容与结果仍会传给 Cursor

Cursor 官方的 Runtime 选择文档建议多数团队优先使用托管 Cloud Agents。这个建议很重要，因为自托管不是技术成熟度的勋章。只有当执行位置能够解决托管网络、Secret 和环境控制无法满足的要求时，它才真正有价值。

这些情况更适合 Self-Hosted Machines

一般来说，下面四种情况更值得承担额外的基础设施工作。

规则要求 Checkout 和工具执行留在组织边界内

有些组织有明确的书面控制，要求代码 Checkout、Build Output 或命令执行只能发生在批准的硬件或网络中。Self-hosted Worker 可以满足其中“执行位置”这一部分要求。

但它不会自动满足整套规则。Agent 仍会通过 Cursor 云端接收内容，因此安全和合规审查者需要批准完整的数据路径，而不只是 Worker 的地址。

Agent 需要访问只在内部网络开放的资源

Worker 可以使用这台机器原本能够访问的内部 Package Registry、源码凭证、测试服务或本地 MCP Server。这可能比逐项把资源暴露给托管 VM 更简单。

Cursor 同时为托管 Cloud Agents 提供了私有连接方案。应该先比较这条路径。如果托管网络已经可以在不违反规则的前提下访问所需系统，那么维护自托管集群可能只增加成本，并没有增加真正的能力。

任务需要特殊硬件、操作系统或持久本地状态

iOS 开发所需的 Mac、GPU 主机、自定义系统镜像，或者很大的持久 Build Cache，都可能让自有 Worker 成为更自然的执行位置。如果每个托管 Session 都重建环境，速度或稳定性明显不如维护一个已知主机，也可以考虑这条路线。

但持久状态也会带来风险。重复使用的机器可能积累旧文件、凭证、进程，或者让不同任务相互污染。在把持久性当成优势之前，需要先定义清理与重置规则。

Platform Team 能够负责 Worker 生命周期

Team Pools 不只是安装一个 CLI。团队必须有人负责容量、Worker 更新、镜像加固、监控、失败任务、Secret、清理、Auto Scaling 和 Incident Response。只有当这块运维本来就是明确的平台职责时，自托管才更匹配。

这些情况更适合托管 Cloud Agents

如果托管环境已经可以访问代码库和服务，标准计算配置足够，而且团队没有必须拥有执行主机的要求，继续使用 Cursor 托管 Cloud Agents 通常更直接。

对于小团队尤其如此。Cursor 负责 VM 生命周期与执行容量，团队把注意力放在代码库访问、环境配置、Secret、网络规则、任务审查和产品层恢复上。这些责任仍然重要，但不包括维护一组 Worker。

如果没有任何人明确负责共享主机的补丁和重置，托管执行也可能是更稳妥的组织选择。“运行在我们自己的机器上”本身不是一项控制；只有机器有负责人、加固镜像、有限凭证、日志、容量限制和恢复方案时，它才算真正的控制。

My Machines 还是 Team Pools

如果自托管执行确实有必要，应该选择能够满足需求的最小运维模式。

选项	更适合谁	认证与路由	主要责任
My Machines	单个用户的一台开发机、笔记本、Mac 或远程 VM	浏览器登录或个人 API Key；Session 路由到该用户账号下的机器	保持机器在线、干净、安全并正确连接
Team Pools	共享组织容量、Kubernetes、GPU 或集中管理的镜像	Enterprise Plan 与 Service Account Key；请求在命名 Pool 中等待可用 Worker	负责集群容量、镜像、凭证、伸缩、监控和 Incident Response

如果只是一位工程师和一个低风险代码库，My Machines 更适合作为概念验证。Team Pools 则相当于组织内部的一项基础设施产品。Cursor 可以分配请求并保留 Cloud Agent 界面，但让这个 Pool 真正运行起来的机器仍由你的团队负责。

从一台机器扩大到 Pool 之前，应该记录启动时间、任务耗时、失败率、磁盘增长、Worker 利用率、清理时间，以及恢复失败 Session 所需的人力。这些数据比“支持多少家部署服务商”更能说明真实运维成本。

不要把三个不同的问题混在一起

Cursor Self-Hosted Machines 回答的是：Cursor Cloud Agent 的工具在哪里执行。它并不能单独回答团队应该选择哪一个 Coding Agent 产品、Runtime 架构或协作 Workspace。

如果你是在 Cursor 与其他 Coding Agent 或编辑器工作流之间做选择，可以阅读 Codex 与 Cursor 对比，比较完整任务循环。
如果你在判断是否应该自己搭建和维护 Agent Runtime，需要比较托管 Agent 服务与自托管 SDK，而不是把 Cursor Worker 当成通用 Runtime。
如果你需要的是一个托管位置，让受支持的 Agent harness 围绕持久项目文件工作，可以把 Agent.Space 的工作方式作为一条独立产品路径评估。

Agent.Space 不声称提供 Cursor Self-Hosted Machines、Cursor Worker Pool 或完全自托管的等价功能。当基础设施控制不是目标时，托管 Workspace 可能更简单；当执行位置是硬性要求时，自托管 Worker 可能更正确。两种结论都不能证明某一方在安全、性能或价格上普遍获胜。

连接 Worker 之前的检查清单

在把生产代码库接入 Worker 之前，由安全、平台和开发负责人一起回答这些问题：

**边界：**规则只要求工具执行留在本地，还是 Prompt、文件内容、输出和推理也必须留在组织内部？
**身份：**由哪个用户或 Service Account 注册 Worker？它的本地凭证可以访问哪些代码库与服务？
**隔离：**每个任务是否获得干净环境，还是一个 Session 能看到另一个 Session 留下的文件与进程？
**出网：**哪些 Cursor Endpoint 与 Artifact Upload 被允许、记录或阻止？
**Secret：**终端输出、截图、Diff 或本地 MCP 结果会不会把凭证暴露到 Session 记录？
**容量：**所有 Worker 都在忙、断线、休眠或不健康时会发生什么？
**恢复：**失败或取消的任务会不会让代码库、数据库或外部服务停在不完整状态？
**成本：**估算是否包含 Worker 算力、存储、网络、补丁、监控和 On-call 人力，而不只是模型用量？
**审查：**哪些修改在影响共享系统或生产环境之前必须获得人工批准？

先使用一个边界清楚、可以撤销的任务和非生产凭证进行验证。检查网络路径、Session 记录、工具输出、Artifact、清理与恢复，不要只看代码修改是否完成。

最终选择很直接：只有当你拥有执行位置能够解决具体要求时，才使用 Self-Hosted Machines；如果自己运维只是在重复搭建基础设施，就使用托管 Cloud Agents。如果你的真实目标是先在托管项目 Workspace 中尝试受支持的 Coding Agents，可以从 Agent.Space 的一个任务开始，再单独评估这条工作流的产品边界。