Cursor My Machines 怎么用？自托管四步教程+隐私边界解读（2026）

Cursor 自托管机器（Self-Hosted Machines）是 Cursor 在 2026 年 9 月 2 日上线的新功能：云端智能体的"大脑"仍在 Cursor 云端做规划与推理，但"手脚"——文件编辑、终端命令、浏览器操作这些工具调用——可以改在你自己的电脑或服务器上执行。代码检出、构建缓存、本地凭据全程留在你的机器里，只需一条出站 HTTPS 连接，无需开放任何入站端口。

这个功能解决的是很多团队接入 AI 编程智能体时最大的顾虑：代码不能出内网。Cursor 官方同日发布的 changelog 和博客确认，个人可以用 My Machines 模式把一台笔记本或 devbox 接入账号，企业可以用团队池管理整批机器。

本文带你搞清楚四件事：它到底怎么运作、和 Cursor 托管环境怎么选、My Machines 怎么四步上手、以及最重要的——哪些数据会留在你机器上，哪些仍会传给 Cursor。文末整理了上线一周内用户问得最多的几个问题。

目录

1. Cursor 自托管机器是什么
2. 运行原理：大脑在云端，手脚在你机器
3. 三种运行方式怎么选
4. My Machines 四步上手教程
5. 从 Slack、GitHub、Linear 指定机器
6. 隐私边界：什么留下，什么上传
7. 一周内的真实踩坑
8. 常见问题 FAQ

Cursor 自托管机器是什么

一句话定义：Self-Hosted Machines 把 Cloud Agent（云端智能体）的工具执行环节，从 Cursor 管理的云虚拟机搬到你自己管理的机器上。你可以接入笔记本、devbox、内网服务器、云主机，也可以接入带 GPU 的机器或做 iOS 开发的 Mac。

它不是突然冒出来的功能。2026 年 3 月底，Cursor 就推出过 worker 模型的早期版本，让部分企业把云端智能体跑在自己的基础设施里；9 月 2 日这波更新补齐了让它真正能上生产的拼图：按请求自动扩缩的机器池、空闲休眠与快速恢复、不绑定单一仓库的池路由，以及对 AWS Lambda、Cloudflare、Daytona、Modal、Namespace、Vercel、E2B、Coder 八家沙箱/云厂商的官方集成。

背景数据也值得一看：Cursor 官方博客提到，其内部合并的 PR 中超过 60% 由云端智能体创建。当智能体承担的工程工作越来越多，"它到底在哪台机器上干活"就从技术细节变成了安全与采购问题——这也是自托管机器出现的直接原因。

运行原理：大脑在云端，手脚在你机器

理解这个功能只需要分清两层：

• Cursor 云端负责“想”：智能体循环、模型推理（背后是 GPT-6 Astra、Claude Fable 5.1 这类大模型）、任务规划、会话管理，仍在 Cursor 云端运行。你在桌面端、cursor.com、移动端用智能体的体验完全不变。
• 你的机器负责"做"：一个叫 worker 的进程跑在你的机器上，负责实际编辑文件、执行终端命令、驱动浏览器、运行本地 MCP 服务器。

两层之间靠一条由你的机器主动发起的出站 HTTPS 长连接通信。Cursor 先把工具调用从云端下发到 worker，worker 在本地执行完，再把结果回传给云端做下一轮推理。官方文档原话是 "Cursor never connects into your network"——Cursor 永远不会反向连进你的网络，所以不需要开放入站端口、公网 IP，也不需要 VPN 隧道。

如果网络走代理，在 worker 环境里设置 HTTPS_PROXY 或 https_proxy 即可。

三种运行方式怎么选

自托管机器分两种配置，加上默认的 Cursor 托管环境，一共三种选择：

官方文档给了一个明确的决策树：超过 80% 的客户用托管云端智能体就够了，托管模式本身就提供每智能体隔离 VM、出站域名白名单、AWS PrivateLink / Cloudflare Tunnel 私有连接等控制。

什么情况下才值得切到自托管？官方列出三类场景：

• 严格的网络要求：源码或内部服务在私有网络里，外部根本访问不到。
• 特殊硬件：GPU 机器、跑 iOS 构建的 Mac，或已经在用的 Kubernetes、沙箱平台。
• 难以打包的环境：操作系统或构建流水线太定制，塞不进云端智能体的环境快照。

如果你只是想访问私有代码仓库和内网包源，官方建议先试托管模式加私有连接，别急着自建机器池。

My Machines 四步上手教程

My Machines 是自托管机器的个人版：把一台你已经在用的机器连到自己的 Cursor 账号。整个过程不到五分钟。

第一步：安装 Cursor CLI

# macOS、Linux、WSL
curl https://cursor.com/install -fsS | bash

# Windows PowerShell
irm 'https://cursor.com/install?win32=true' | iex

装完用 agent --version 确认可用。

第二步：登录

agent login

会拉起浏览器完成登录。devbox 这类没有浏览器的机器，改用个人 API key（在 Cursor Dashboard → API Keys 生成）：

agent worker start --api-key "你的个人API密钥"

注意一个常见的坑：My Machines 只认个人凭证。服务账号 API key 只能启动团队池 worker，团队管理员的 key 和组织级 key 则完全不能启动 worker。

第三步：启动 worker

在代码仓库目录里执行：

agent worker start --name "my-devbox"

保持这个进程运行。My Machines 的 worker 默认是长生命周期的，不关就一直在线，可以反复服务后续的智能体会话。

第四步：派任务

打开 cursor.com/agents 或桌面端，环境下拉框里会出现你的机器，选中它、发送任务即可。

几个马上会用到的选项：

• --name：给机器起名。同一仓库接多台机器时必填，也方便后面从 Slack 指定机器。
• --worker-dir /path/to/repo：指定仓库目录，可重复传多个路径（最多 20 个），一台机器服务多个仓库。
• --computer-use：放在 start 前面，允许智能体操作这台机器的屏幕（点击、输入、截屏）。macOS 首次使用会安装辅助应用，需要在系统设置里授予辅助功能与屏幕录制权限。

遇到机器不出现在下拉框的问题，先跑一条官方预检命令：

agent worker debug

它会检查认证、隐私路由、仓库标签，以及 Cursor 后端能不能看到你的 worker。

从 Slack、GitHub、Linear 指定机器

机器起了名字之后，可以让消息渠道的任务直接落到指定机器上。做法是在请求里带上 worker=机器名 或 machine=机器名：

• Slack：@Cursor worker=my-devbox 修复这个偶现测试
• GitHub：在 PR 或 issue 里评论 @cursoragent worker=my-devbox 修复这个偶现测试（需要是仓库的可信评论者，且目标机器属于你 GitHub 账号绑定的 Cursor 用户）
• Linear：在 issue 描述里写 worker=my-devbox

一个容易被忽略的安全细节：如果名字对得上、但那台机器注册的是另一个仓库，Cursor 会直接拒绝请求，而不是让任务跑错检出目录。匹配必须同时满足三个条件：机器属于触发请求的用户、名字匹配、机器注册的仓库与请求目标仓库一致。

隐私边界：什么留下，什么上传

这是全文最重要的一节。"自托管"不等于"数据完全不出网"，功能发布后 X 上一条两百多人点赞的评论说得很直白："只要模型在外网，数据就不是真正的隔离。"官方文档其实把边界写得非常清楚：

始终留在你机器上的：

• 完整的代码检出（working copy）
• 构建缓存
• 机器本地的凭据

执行期间会传给 Cursor 的（用于推理）：

• 文件内容片段
• 终端输出
• 代码 diff
• 截图（桌面共享开启时）、本地 MCP 的执行结果

需要出站放行的域名：

不想让截图、录屏上传到 Cursor 托管的存储？直接在防火墙上封掉 S3 那个域名即可——智能体会话和所有工具调用照常工作，只是产物不再出现在 PR 和仪表盘里。同理，封掉 downloads.cursor.com 只影响 CLI 更新，已经装好的 worker 继续跑。

两个补充说明：其一，Privacy Mode 对自托管机器同样生效，开启后回传的代码不会用于训练 Cursor 或模型提供商的模型；其二，智能体的产物（截图、日志引用等）会上传到 Cursor 托管的存储，用于 PR 展示和仪表盘，密钥不要出现在工具输出里。

一句话总结：自托管机器守住的是"源码和构建产物不出内网"，守住不了"任何字节都不碰外部服务"。如果你的合规要求是后者（完全气隙隔离），这个功能不适用；如果是前者——这已经是绝大多数企业的真实要求——它是对症的药。

一周内的真实踩坑

自托管机器上线还不到一周，Cursor 官方论坛上已经沉淀了一批真实故障报告。接入前先看这几条，能省不少排查时间（以下均来自论坛一手帖子，链接见文末）：

1. Windows worker 启动崩溃：better-sqlite3 的 NODE_MODULE_VERSION 不匹配（127 vs 137）。本质是机器上的 Node 版本与 Cursor CLI 期望的不一致，Windows 远程控制 worker 和 My Machines worker 都有同类报告。遇到启动即崩先查 Node 版本。
2. macOS 开 --computer-use 后 worker 崩溃：签名 SEA 可执行文件下载后报 createRequire 错误，CUA.app 显示 Ready 但 worker 无法宣告 computer-use 能力。这是 9 月 5 日、6 日两个新帖反馈的问题，如果你在同一版本踩到，建议先不开 computer-use，等官方修复。
3. 内网 MCP 打不通？查传输方式：命令行（stdio）类型的 MCP 进程跑在你的机器上、共享本机网络，能访问内网 API；HTTP/SSE 类型的 MCP 连接由 Cursor 后端发起，根本看不到你的内网。要让智能体够到内网服务，MCP 必须用 stdio 传输。
4. 机器不出现在环境下拉框：按顺序检查四件事——worker 进程还活着吗、Cursor 桌面端和 CLI 是不是同一个账号、worker 目录有没有正确的 Git remote、上面三个出站域名放行了没有。
5. Plan 模式偶发空计划并提示 "Unable to reconnect workspace"：论坛有相关报告，重启 worker 会话可绕过。

规模上限也提前知道：官方文档写明每个用户最多连 200 台 worker，每个团队最多 1000 台，更大的公司级部署要联系 Cursor 销售。

常见问题 FAQ

Cursor 自托管机器收费吗？

功能本身不单独收费，但使用前提是付费 Cursor 计划。模型用量按所选模型的 API 价格计费（消耗速度比普通对话快得多，建议先看懂Cursor Pro 额度重置规则），首次使用云端智能体时会要求设置消费上限；团队池（Team Pools）需要 Enterprise 计划。My Machines 用个人凭证即可启动，适合先低成本试用。

用了自托管机器，代码就完全不出内网了吗？

不完全是。代码检出、构建缓存、本地凭据确实留在你的机器上，但工具执行产生的文件片段、终端输出、diff 会回传给 Cursor 用于模型推理，开启桌面共享时还会传输屏幕画面。它守住的是"源码不出内网"，不是完全离线隔离。

需要开放防火墙入站端口或架设 VPN 吗？

不需要。worker 由你的机器主动向 Cursor 发起一条出站 HTTPS 长连接，工具调用经这条连接下发，Cursor 不会反向连入你的网络。只需放行 api2.cursor.sh、api2direct.cursor.sh 等出站域名，走代理的话设置 HTTPS_PROXY 环境变量即可。

没有 GPU 的普通电脑，接进 My Machines 有什么用？

智能体的推理不消耗你机器的算力（那部分在 Cursor 云端），所以普通电脑也能用。接入的价值在于执行环境：这台机器上已经配好的依赖、构建缓存、登录态、内网访问权限，云端虚拟机要么没有、要么每次都要重建。注意它和在本地跑开源模型是两条路线——本地部署模型（参考Qwen3.8-27B 本地部署指南）解决的是“模型自己跑”，自托管机器解决的是“智能体的工具在哪执行”。

My Machines 和 Team Pools 应该先试哪个？

个人先用 My Machines，官方文档也是这么建议的——花五分钟接一台机器，把"任务落到自己机器上执行"的模型跑通，再评估要不要投入团队池。团队池需要 Enterprise 计划、服务账号认证和专人运维机器池，属于组织级决策，别一上来就建池。

自托管机器和 Claude Code 的自托管方案是一回事吗？

思路相似——都是"模型大脑在云端、工具执行在本地"，但产品形态不同。Cursor 的方案深度绑定了它的云端智能体体系：任务可以从 Slack、GitHub、Linear 发起，机器可按 GPU、iOS 等硬件分池路由。如果你在选型，建议同时看我们此前的 Claude Code 订阅与使用攻略，按自己的网络约束和工作流习惯来定。

总结

Cursor 自托管机器把云端智能体的执行环节交还给你：推理和规划留在 Cursor 云端，文件编辑和终端命令跑在你自己的机器上。My Machines 让个人五分钟接入一台现成机器，团队池让企业把智能体调度进自己的基础设施，还支持自动扩缩和空闲休眠。

要不要用，取决于一个问题的答案：你的约束是"源码不能出内网"，还是"任何数据都不能碰外部服务"？前者，自托管机器对症，值得接入试用；后者，它是云端产品，帮不了完全气隙的场景。

动手建议：先在一台 devbox 上把 My Machines 跑通，观察任务的执行位置和回传内容，再决定是否推进到团队级部署。过程中遇到的报错，优先跑 agent worker debug，再到官方论坛搜同款——上线第一周，你踩的坑大概率已经有人踩过了。

---

最后更新于 2026 年 9 月 8 日 · 作者：AI345（ai345.info 编辑部，专注 AI 工具实测与中文教程）