Cursor 自托管机器：AI Agent 接入私有网络的成本与边界

Cursor Self-Hosted Machines 将工具执行迁入企业自管机器，Agent 循环、推理与规划仍留在云端。本文拆解 Cursor 自托管在私有网络中的数据边界、Team Pools 部署流程、Cloudflare 容器成本、隔离责任与适用场景，并提供可直接运行的配置步骤，帮助团队判断是否值得上线。

Thursday, September 3, 2026

Omid Saffari

Tools

Cursor

Cursor 于 2026 年 9 月 2 日推出的 Cursor 自托管改动，同时重划了安全边界，也转移了基础设施账单：团队可以让 AI 编程代理的工具执行留在自己控制的机器上，但从此也要自行负责这些 Worker。模型、规划和 Agent 循环仍然运行在 Cursor 云端。

Cursor 自托管带来的是拆分式运行时

一个 Cursor Cloud Agent 由两部分组成。Agent 循环负责决定下一步行动并调用模型；工具执行则负责修改文件、运行终端命令、打开浏览器、连接本地 MCP Server，以及访问内部服务。

Cursor Self-Hosted Machines 将这两部分拆开。循环、推理、规划、界面和会话编排仍由 Cursor 负责，工具则交给由你管理的 Worker 执行。

Cursor 的 Run on 菜单与 Self-Hosted Machines 资源池控制面板 — Cursor Self-Hosted Machines

这个 Worker 可以是笔记本电脑、VM、Mac、Kubernetes Pod，也可以是集成合作伙伴提供的沙箱。它通过出站 HTTPS 连接 Cursor，接收工具调用，在本地执行后返回结果。Cursor 不需要在 Worker 上开放入站端口，也不需要公网 IP。

双方的运行职责如下。

层级	Cursor 托管的 Cloud Agent	Self-Hosted Machine
Agent 循环、模型与规划	由 Cursor 运行	仍由 Cursor 运行
文件修改、命令、浏览器操作、本地 MCP	Cursor 托管的隔离 VM	你的 Worker
主机生命周期与隔离	Cursor	你或你的基础设施提供商
执行容量	包含在托管运行环境中	由你规划规格并付费
模型用量	按所选模型计费	仍按同一所选模型计费

Cursor 提供两种 Worker 形态。My Machines 将一台机器绑定到一个人的账户，适合开发机或范围较窄的个人工作流。Team Pools 则是面向 Enterprise 团队的命名队列。请求会在资源池中等待可用 Worker 领取，每个资源池 Worker 同一时间只能处理一个 Cloud Agent 会话。

架构图：Cursor 云端的 Agent 循环向客户网络内的 Worker 发送工具调用并接收结果 — Agent 循环留在 Cursor 云端，工具执行则迁入你的网络。

这不是 Cursor 的本地部署方案，而是由客户拥有执行侧的拆分式运行时。能否满足企业策略，关键就在这个区别。

哪些数据留在内网，哪些仍会传出

代码仓库的完整检出副本、构建缓存以及机器本地凭据都留在你的 Worker 上。命令、仓库操作、构建和内部服务调用也在那里执行，因此不必再把整个代码仓库复制进供应商托管的执行 VM。

不过，Agent 做决策仍然需要上下文。运行期间，Worker 会把 Agent 所需的文件内容、终端输出、Diff、截图、本地 MCP 返回结果和路由元数据发送给 Cursor。截图、视频和日志引用也可能上传到 Cursor 托管的工件存储，以便显示在 Pull Request 和控制面板中。

你可以屏蔽工件存储主机，Agent 仍能继续工作，但这些工件将不会出现在 Pull Request 和控制面板中。Privacy Mode 同样适用：从 Worker 发出的代码不会被 Cursor 或其模型提供商用于训练，但这并不意味着会话可以离线运行。

这也是最先需要面对的业务影响：安全审查现在可以分别审批执行位置和模型处理，但两者依然缺一不可。

Cursor 自托管代理适合谁，会改变什么

需要访问内部服务的企业后端团队

后端团队可能依赖私有软件包仓库、预发布数据库，以及托管 VM 无法访问的服务端点。Team Pool 可以部署在同一个受控网络内完成构建，无需向 Cursor 开放入站链路。

真正的收益是访问控制，而不是自动获得隐私。平台团队可以继续使用现有的网络策略和密钥存储，安全团队则能明确审查哪些结果会通过出站连接传出。

依赖 Mac 的 iOS 团队

Cursor 托管的 Cloud Agent 运行在 Ubuntu VM 上。需要 Mac 硬件进行 iOS 开发的团队，可以把 Mac 注册为 Worker，授予必要的计算机操作权限，让 Agent 在这台机器上点击、输入、截图或操作浏览器。

好处是远程 Agent 可以使用与构建任务相同类型的硬件。代价对运营 Mac 构建集群的人并不陌生：镜像漂移、权限、在线率、清理和替换仍由你负责。

Agent 需求波动明显的平台团队

平台团队可以把 Cloudflare Containers 接入 Team Pool。参考模板会为每个已领取的会话启动一个隔离容器，用 Durable Object 管理该容器，还可以把代码仓库快照缓存在 R2 中。

即使没有 Worker 在线，资源池也会保留，因此容量可以缩容到零。新任务到来后，控制器领取请求并启动容器。这样，计算费用会随实际用量变化，而不必长期维持一组热实例。

使用有状态 Devbox 的个人开发者

如果项目依赖本地工具或难以重建的状态，My Machines 会更合适。同一台机器可以供多个 Agent 共用；这对个人开发机很方便，对敏感任务却值得警惕。

它的优势是可以快速完成环境准备，风险则是不同运行之间会留下残余状态，因为 Cursor 不会在每次会话间擦除并重建你的笔记本电脑。工作目录、凭据、进程清理和机器健康都由你负责。

一套可直接运行的 Cloudflare 部署方案

Cloudflare 方案的价值，在于它能清晰呈现新的责任边界。你需要 Cursor Enterprise、一个具备 Agent 权限范围的团队服务账号密钥，以及启用了 Containers 和 R2 的 Cloudflare Workers Paid 账户，同时还要准备 Node.js 20 或更高版本与 Docker。

注册 Team Pool
安装 Cursor CLI，确认它可以运行，再临时连接一个本地 Worker，让资源池出现在 Cursor 中。
Bash
curl https://cursor.com/install -fsS | bash agent --version export CURSOR_API_KEY="<team service-account API key>" CURSOR_API_KEY="$CURSOR_API_KEY" agent worker --pool cloudflare-test start
资源池出现后，用 Ctrl+C 停止该 Worker，再运行 unset CURSOR_API_KEY。测试 Cloudflare 时应保持本地 Worker 停止，避免它抢先领取请求。

部署 Cursor 参考模板

克隆模板、安装依赖、登录 Cloudflare，并创建可选的快照存储桶。

Bash

git clone https://github.com/anysphere/cloudflare-workers.git
cd cloudflare-workers
npm install
npx wrangler login
npx wrangler r2 bucket create cursor-pool-worker-snapshots

保存凭据
把 Cursor 服务账号密钥存入 Worker Secret。只有容器需要访问私有代码仓库时，才添加 Git 凭据。
Bash
npx wrangler secret put CURSOR_API_KEY npx wrangler secret put GIT_USERNAME npx wrangler secret put GIT_TOKEN
个人 Cursor API Key 无法用于 Team Pool。这类配置错误最容易被误判为基础设施故障，因为控制器会返回 401。
设置资源池与容量
在 wrangler.jsonc 中，把 CURSOR_POOL 改为 cloudflare-test。containers[].max_instances 应设置为你愿意同时运行的最大会话数，而不是团队的开发者人数。
参考文件默认将 max_instances 设为 10，并使用 standard-1 容器，规格为 0.5 vCPU、4 GiB 内存和 8 GB 磁盘。实际构建可能需要更大的规格。
部署并观察首次运行
完成部署后，在启动 Cloud Agent 并选择自托管资源池时，持续查看控制器和容器视图。
Bash
npx wrangler deploy npx wrangler tail npx wrangler containers list
首次由计划任务触发的控制器运行最多需要 5 分钟才会开始。会话已被领取却没有启动，通常意味着容器容量、代码仓库克隆或 Git 凭据存在问题。

成本只是转移，并没有消失

Cursor 托管的 Cloud Agent 已包含执行基础设施。Self-Hosted Machines 仍按 Cursor 的定价使用所选模型，此外还要加上你的 Worker 账单。Team Pools 还要求签订价格定制的 Enterprise 合同。

Cloudflare 可以直观说明新增成本如何计算。Containers 产品依托每月 $5 的 Workers Paid 套餐，该套餐包含 25 GiB-hours 内存、375 vCPU-minutes 和 200 GB-hours 磁盘用量。超出后，内存价格为每 GiB-second $0.0000025，活跃 CPU 为每 vCPU-second $0.000020，已配置磁盘为每 GB-second $0.00000007。

以参考模板的 standard-1 规格为例：假设有 100 个会话，每个工作一小时，运行时用满可用 CPU，随后经历模板设定的 5 分钟空闲窗口。扣除套餐内用量后，当月容器成本约为 $12：

$5 plan + $3.15 CPU + $3.675 memory + $0.168 disk = $11.993

这只是基础设施估算，并非 Cursor 总账单。它没有计入 Worker 和 Durable Object 用量、日志、出站流量、R2、Enterprise 合同、模型用量，以及维护集群的人力；同时还假定模板中最小的规格已经够用。编译负载高的代码仓库可能迫使你升级容器规格。

真正昂贵的选择往往不是每秒单价，而是热容量策略。Cursor 的通用资源池 Worker 默认重连窗口为 3,600 秒，Cloudflare 模板则缩短到 300 秒。窗口更长，后续 Prompt 响应更快，但已配置的内存和磁盘会继续计费；窗口更短，可以降低空闲支出，却会带来更多冷启动。

容量也归你负责。模板默认最多并发运行 10 个容器。当设定容量、账户限额或底层主机无法提供资源时，下一个请求只能等待，或者启动失败。Cursor 可以把任务路由到资源池，却无法凭空提供你没有配置的容量。

隔离同样遵循这一原则。Cloudflare 模板为每个会话分配独立容器，个人机器则可以在同一主机上运行多个 Agent。如果策略要求每次运行都使用全新 VM、擦除磁盘、隔离租户，或在结束后恢复干净的密钥边界，就必须由你自行实现并验证。

补丁更新也会变成固定的运维日程。团队需要负责基础镜像、Cursor CLI、构建工具、证书、依赖和发布。在 Cloudflare 上，部署新容器镜像会停止正在运行的容器，因此更新要么等到活跃会话结束，要么接受中断。

现在应该怎么选

如果 Cloud Agent 需要定制硬件、定制镜像，或托管网络无法提供的工具访问权限，就应在本周行动。先从一个范围受控的资源池和低风险代码仓库开始。安全审查仍须涵盖模型处理及返回的工具数据，因为迁移执行位置并不会让它们消失。

如果唯一诉求只是访问私有源代码管理系统或内部服务，可以暂缓。Cursor 建议先尝试托管环境、网络控制、Tailscale、AWS PrivateLink 或 Cloudflare Tunnel，再决定是否接手一整套 Worker 集群。这些方案仍由 Cursor 负责主机生命周期和隔离。

如果托管 Cloud Agent 已经符合策略要求，也能复现构建，现有流程不受影响。自托管不会增加任何模型能力，改变的只是执行位置和运维责任。

周一就做这件具体的事：选一个有代表性的代码仓库，明确哪些代码、密钥、工具输出和工件可以跨越边界，再分别用托管 Agent 和严格限制容量的自托管资源池运行同一次构建。记录队列等待时间、容器小时数、被接受的改动、清理失败，以及维护镜像所花的时间。只有当控制要求值得承担第二份账单时，才批准建设这套集群。

订阅 Newsletter，获取下一篇面向实操者的 AI 工作流深度解析。