Cursor Self-Hosted Machines 企业部署：执行在内网，推理和 Agent Loop 仍在 Cursor 云端

官方入口与模板：

• Cursor Self-Hosted Machines 文档
• Cursor 官方博客：Self-Hosted Machines
• anysphere/k8s-workers

结论：执行留内网，不等于数据完全不出内网

Cursor 在 2026 年 9 月 2 日推出 Self-Hosted Machines。官方表述是：代码工作副本、Build 产物和 Secrets 保留在企业管理的机器上，Agent 的工具调用在本地执行；Worker 通过一条长期的出站 HTTPS 连接接入 Cursor，Cursor 不主动进入企业网络。

但“全部留在内网”需要准确理解。Self-Hosted Machines 迁移的是执行环境，而不是整个 Agent 平台。模型推理、规划和 Agent Loop 仍运行在 Cursor 云端；工具输出会回传给 Cursor 以完成下一轮推理，这些输出可能包含代码；对话 Transcript 也可能被 Cursor 处理和保存。Artifact 默认上传到 Cursor 管理的存储，除非企业在出口层阻断对应域名。

因此，它适合“源码工作目录、依赖缓存、编译环境、内部服务访问、长期凭据不能落到第三方 VM”的企业，但不能被宣传成完全离线推理、Air-gapped 部署或“任何代码片段绝不离开内网”。若组织政策禁止任何代码或工具输出进入外部推理服务，Self-Hosted Machines 本身仍不满足该要求。

架构：Worker 主动出站，云端负责推理

一台 Self-Hosted Machine 上运行 Cursor CLI Worker。它持有仓库工作目录，负责编辑文件、启动进程、执行测试、访问内网 API，并把工具结果通过已建立的出站连接返回给 Cursor Harness。一次请求进入后，Cursor 云端负责推理和计划，把 Tool Call 发给专属 Worker；Worker 执行后返回结果，直到任务结束。

数据流：

开发者/Slack/API
  -> Cursor Cloud (Planning + Inference)
  <--> 出站 HTTPS 会话
  <--> 企业 Worker
  -> 内部 Git/Build、Secrets/Internal APIs

三个重要结论：

1. 企业防火墙不需要允许 Cursor 主动入站；Worker 主动建立出站 HTTPS。
2. Repo、Build 与 Secret 可以不进入 Cursor 托管 VM，但 Agent 看见的 Tool Output 仍会进入推理上下文。
3. Worker 不是完整的本地模型服务器，断开 Cursor 云端连接后不能继续完成 Agent Loop。

官方要求放行 api2.cursor.sh 与 api2direct.cursor.sh 以维持 Agent Session。downloads.cursor.com 用于 CLI 更新和 macOS 首次安装 Computer Use；cloud-agent-artifacts.s3.us-east-1.amazonaws.com 用于上传截图、视频和日志 Artifact。阻断 Artifact 域名只会让 PR/Dashboard 缺少预览，不会停止其他 Tool Call；阻断前两个 Agent Session 域名则无法启动或继续。

My Machines 与 Team Pools 怎么选

Self-Hosted Worker 有两种主配置。

My Machines

把一台个人 Laptop、Devbox、Mac 或远程 VM 绑定到个人账户，适合开发者试点和有状态的一次性任务。一台 My Machine 可以承载多个 Agent，但它的文件、缓存和进程也可能互相影响，企业生产场景必须额外做目录、用户、容器或 VM 隔离。它使用浏览器登录、个人 User API Key 或短期 User-scoped Token，不接受 Service Account Key。典型启动：

curl https://cursor.com/install -fsS | bash
agent login
agent worker start --name "patrol-devbox" --worker-dir /srv/repos/patrol-web

自动化环境中避免把 Key 写进命令历史，可通过 POST /v1/sub-tokens 获取短期 User-scoped Token，再从轮换文件读取：

agent worker start --auth-token-file /var/run/cursor/token --name "patrol-devbox" --worker-dir /srv/repos/patrol-web

Kubernetes Secret Volume 能在 Pod 运行期间更新文件，比启动时固定的环境变量更适合 Token 轮换。需要任务承担云角色时可加 --identity-socket，Worker 会设置 CURSOR_AGENT_SOCKET，Agent 通过本地 Socket 获取识别本次 Run Owner 的短期 OIDC Token。

Team Pools

企业共享的命名队列。聊天请求选择 Pool 后等待可用 Worker；Worker Claim 后，该聊天后续活动都会转发给它。官方描述为“一台机器处理一个 Agent”，不要把单 Worker 当作无限并发容器。Team Pool 需要 Cursor Enterprise，管理员在 Cloud Agents Dashboard 启用 Self-Hosted Machines。Worker 使用 CURSOR_API_KEY 中的 Service Account API Key，并以 Pool 名或 Labels 注册。

企业推荐拓扑：控制面、调度面、执行面分离

四层：

• Cursor 控制面：会话入口、Agent Loop、推理与任务状态；
• 企业调度面：Controller、请求队列观察、容量与策略；
• 隔离执行面：一次 Claim 对应一个 Pod、VM 或 Sandbox；
• 内网资源面：Git、Artifact Registry、CI、测试数据库、Secret Manager 和业务 API。

Worker Controller 观察 Pool 的 Pending Request，通过企业提供的 --spawn Hook 创建机器。已有空闲 Worker 会 Claim；没有容量时请求留在队列，直到 Controller 拉起新实例。任务结束后，Worker 可 Reset 并重新进入 Pool，也可在 Idle Timeout 后销毁。

Follow-up 有两种取舍：保留热 Worker，响应快但成本高；或 Snapshot/Hibernate 工作区，在 Reconnect Window 内恢复相同 Worker ID。超过窗口后允许请求迁移到新机器并重新准备环境。不要把“休眠”理解成全系统零成本。

部署前的企业准入条件

账户与管理

• Cursor Enterprise 计划；
• Cursor Team Admin 开启 Self-Hosted Machines；
• 专用 Service Account，不用员工个人账户跑共享池；
• 不同安全域建不同 Pool；
• 记录 Worker、Run Owner、Repo、Branch、Pool 和 PR 的关联。

网络

• 只允许 Worker 主动出站 HTTPS；
• 放行 Agent Session 必需域名；
• 是否放行 Artifact 域名由数据策略决定；
• 包仓库、Git、CI 和业务 API 使用精确域名白名单；
• 禁止任意公网出站和公共文件分享站；
• 对 DNS、TLS、代理和流量日志做留存。

计算与镜像

• 不可变基础镜像，固定 OS、Cursor CLI 和工具链版本；
• 每个任务独立 VM/Pod/Sandbox，禁止共享可写 Workspace；
• Rootless 容器或非 Root 用户；
• CPU、内存、磁盘、PID 和执行时间限制；
• 只读基础层 + 任务临时盘；
• 任务结束后销毁临时盘或执行可验证的安全擦除。

Secrets

• Service Account Key 只用于 Worker 注册，不交给 Agent Prompt；
• 业务 Secret 由 Vault、AWS STS、GCP WIF 或 Azure Federated Identity 按 Run 动态签发；
• 测试和生产身份分离；
• 默认只读，写操作需要环境与资源范围；
• Token TTL 短于任务最大运行时长，并支持续租与撤销；
• Shell set -x、Crash Dump、Build Log 和 Artifact 做脱敏。

从单机试点到 Team Pool：部署步骤

第一步：在隔离 VM 验证 CLI Worker

先准备一台无生产凭据的 Linux VM，安装 CLI，运行：

agent login
agent worker start --name "cursor-pilot" --worker-dir /opt/workspaces/pilot

从 cursor.com/agents 的 Environment Picker 选择该机器，执行只读任务，再执行创建分支、运行测试和生成 Draft PR 的任务。用 agent worker debug 检查认证、Privacy Routing、Repo Labels 和 Cursor 是否识别 Worker；也可在启动时加 --debug。

第二步：建立镜像供应链

镜像中仅放稳定依赖，不写入任何 Secret。推荐阶段：源码扫描 -> SBOM -> 签名 -> 漏洞门禁 -> 推送内部 Registry -> 部署引用 Digest。镜像至少包含 Git、Shell、企业 CA、项目 Runtime、编译工具、Cursor CLI 和日志代理。

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates curl git jq build-essential && rm -rf /var/lib/apt/lists/*
RUN useradd --create-home --uid 10001 cursorworker
USER cursorworker
WORKDIR /workspace

生产镜像应通过企业内部镜像代理安装 Cursor CLI，并校验来源和 Hash，而不是每次 Pod 启动都从公网执行安装脚本。

第三步：划分 Pools 与 Labels

不要建一个 default Pool 访问所有资源。按信任边界拆分：

Label 只做调度提示，真正授权必须由网络、IAM、Kubernetes Service Account 和 Secret Policy 执行，不能因为 Agent 选择了某个 Pool 就自动获得高权限。

第四步：先手工启动 Pool Worker

服务账户 Key 注入 CURSOR_API_KEY，但不要写入镜像、Helm Values 或 Git。

export CURSOR_API_KEY="${RUNTIME_INJECTED_CURSOR_KEY}"
agent worker start --pool "web-lowrisk" --worker-dir /workspace

实际 CLI 参数应以部署时 agent worker start --help 和官方 Team Pools 页面为准；Beta 产品的参数可能调整。

第五步：启用 Worker Controller

Controller 只负责 Claim 和 Spawn，不应持有业务生产 Secret。逻辑：

Pending Request -> 校验 Pool/Labels/Team -> 检查并发、配额和预算 -> 创建一次性 Sandbox -> 注入短期 Worker Token -> Worker 建立出站连接并 Claim -> 执行任务 -> 上传允许的结果 -> Snapshot 或销毁。

设置 max_workers、max_pending_age、spawn_timeout、idle_timeout、reconnect_window 和失败重试上限。Spawn 失败不能无限重试；达到阈值后应标记请求失败并告警。

第六步：接入 Kubernetes

新部署应使用官方 anysphere/k8s-workers 模板：Helm 示例运行 agent worker controller --spawn，每个 Claim 创建一个 Worker Pod，或用 --warm-idle 保留少量热 Pod。官方已把旧 Cursor Kubernetes Operator 与 WorkerDeployment Helm Chart 标为 Deprecated；存量集群可继续使用，但不要用旧路线启动新项目。

apiVersion: v1
kind: Pod
metadata:
  labels: { app: cursor-worker }
spec:
  serviceAccountName: cursor-worker-lowrisk
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    seccompProfile: { type: RuntimeDefault }
  containers:
    - name: worker
      image: registry.internal/cursor-worker@sha256:REPLACE_WITH_DIGEST
      resources: { limits: { cpu: "4", memory: 8Gi } }
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities: { drop: ["ALL"] }

项目写入使用单独 EmptyDir 或加密临时卷。若要恢复 Follow-up，使用加密 Snapshot，并将 Snapshot Key、Run ID、Owner 与过期时间绑定；不要让新用户 Claim 上一用户的 Workspace。

代码、Build 与 Secrets 如何真正留在内网

代码工作副本

Worker 从企业 Git 或已批准代码源获取仓库。优先使用短期 Git Credential，并限制到目标 Repo。每个 Run 使用新 Branch 和独立 Workspace，任务结束后清理 .git-credentials、SSH Agent、Package Token 与临时 Patch。

“工作副本留内网”并不等于模型没见过代码。Agent 为完成任务会把文件片段、Diff、错误和命令输出纳入推理。对 Restricted Repo 应建立单独政策：禁止 Self-Hosted Agent、只允许特定文件，或先完成脱敏和法律审查。

Build 与依赖

依赖下载经过内部 npm/pypi/Maven/Container Proxy；构建缓存按 Project 和 Trust Level 分区，禁止不同租户共享可写缓存。Build Log 默认过滤环境变量、Token、客户数据和 Signed URL。编译产物留在内部 Artifact Registry，只把测试结果摘要和必要日志返回 Agent。

Secrets 与 Secretless Access

最安全方案不是把 .env 放到 Worker，而是 Secretless Access：Agent 通过本次 Run 的身份向 Broker 请求一个 Scope 很小、TTL 很短的 Credential。Broker 校验 Owner、Pool、Repo、Branch、Action 和 Approval 后签发。

request: { agent_run: run_123, pool: backend-staging, repo: patrol-api, branch: agent/fix-upload, resource: staging-postgres, actions: [select, explain] }
policy: { ttl: 15m, deny: [drop, alter_role, grant], require_human_for: [migration, production_write] }

即使 Secret 不离开内网，只要 Agent 可以用它调用系统，仍可能产生越权效果。因此控制重点应是“Agent 能完成什么”，而不仅是“Agent 能否读取明文 Secret”。

MCP 与内部 API 的特殊边界：取决于 Transport

Command/stdio MCP 在企业机器上运行，可以访问私网、内部 API 和本地服务；HTTP/SSE MCP 由 Cursor Backend 处理 OAuth、Session Cache 和认证，从 Cursor 云端发起连接。

因此需要访问纯内网端点的 MCP 应采用 Command/stdio，或通过经过批准的 Gateway 暴露；但 stdio MCP 的进程和环境位于 Worker，Agent 可能影响其输入和行为，必须使用工具白名单、参数 Schema、Scope Token 和审计。

Artifact、截图和日志：最容易被忽略的出口

Worker 会把 Screenshot、Video 和 Log Reference 上传到 Cursor 管理存储，以便显示在 PR 和 Dashboard 中。若企业不允许，可在 Egress Firewall 阻断 cloud-agent-artifacts.s3.us-east-1.amazonaws.com。阻断后 Agent 仍可执行 Tool Call，但 Artifact 预览会缺失。

推荐在上传前实施 DLP：OCR 检查截图、正则/熵扫描日志、识别 Token、邮箱、手机号、内部域名和客户数据。浏览器 Computer Use 尤其容易截到登录态、通知和其他窗口，默认应关闭，只为专用 Desktop Pool 开启。

隔离模型：不要让多个 Agent 共用一台裸机

若多个 Agent 共享 OS 用户、Workspace、Docker Socket、浏览器 Profile 或 SSH Agent，它们可能互相读取文件、进程和凭据。

推荐优先级：一次任务一个 MicroVM > 一次任务一个强隔离 Sandbox > 一次任务一个 Pod 且 RuntimeClass 强隔离 > 共享 VM 内普通容器。严禁挂载宿主机 Docker Socket；若任务需要构建镜像，使用 Rootless BuildKit、Kaniko 或远端受控 Builder。

Worker 回收前必须：终止所有子进程、卸载临时卷、撤销 Token、清除 Workspace、删除浏览器 Profile、验证无残留网络连接，并把销毁结果写入审计事件。

动态 Pool 的容量与成本

Cursor 官方公开限额为每用户最多连接 200 个 Worker、每团队最多 1000 个 Worker；更大的公司级部署需要联系 Cursor。这是连接上限，不是保证并发、吞吐或性能 SLA。

月度成本至少包含：模型 API 费用 + Worker 计算 + 存储/快照 + 构建缓存 + 网络出口 + 安全与运维成本。

优化方式：

• 按任务类型选 CPU/Memory/GPU/Mac Pool；
• 保留少量 Warm Idle，突发容量动态拉起；
• 大仓库制作已验证 Snapshot；
• Idle Timeout 后休眠或销毁；
• Reconnect Window 只覆盖常见 Review 间隔；
• 限制单任务最大运行时间、磁盘和并行数；
• 统计每个合并 PR 的完整成本。

企业安全基线

Privacy Mode 同样适用于 Self-Hosted Machines；官方说明开启后从 Worker 发送的代码不会被 Cursor 或模型提供商用于训练。但 Privacy Mode 不等于“不传输、不处理、不存储”。

可观测性与审计字段

每次 Run 至少记录：

run_id、owner、pool、worker_id、image_digest、repo、branch、network_policy、credential_policy、started_at、finished_at、cleanup_verified。

监控队列等待时间、Spawn 成功率、冷启动时间、Worker Claim 冲突、任务成功率、Build 失败、Artifact 拦截、Secret Policy 拒绝、单 PR 成本和清理失败。清理失败的机器应立即 Quarantine，不得回到 Pool。

故障排查

Worker 不出现在选择器

确认 Worker Process 仍在运行，Cursor App 与 CLI 使用同一账户，--worker-dir 目录存在且 Git Remote 正确，并检查三个必要出口。运行 agent worker debug；若启动前检查，使用 agent worker start --debug。

Worker 能连接但任务一直排队

检查 Pool 名、Labels、Service Account 所属 Team、Worker 是否已经 Claim 其他 Chat，以及 Controller 并发/配额。Team Pool 请求只能由匹配且 Idle 的 Worker Claim。

内部 Git 或依赖下载失败

验证企业 CA、DNS、Proxy、SSH Known Hosts 和 Package Registry Credential。不要为了排障临时开放全公网；按失败域名逐项审批。

Artifact 不显示

若 Tool Call 正常但 Screenshot/Video 缺失，检查是否阻断 Artifact S3 域名。这可能是预期的安全策略，不应误判为 Agent 整体失败。

新 Secret 不生效

检查 Secret 是注入 Worker、MCP 进程还是业务 Command。环境变量通常在进程启动时固定；推荐挂载可轮换 Token 文件或重新创建 Worker。

Follow-up 无法恢复

检查 Worker ID、Snapshot、Reconnect Window 和 Workspace 是否仍存在。超过恢复窗口后允许新 Worker 重建环境，同时从 Git Branch 与 Agent Context 恢复。

生产验收清单

• 已确认 Self-Hosted 只迁移执行环境，推理仍在 Cursor Cloud；
• 法务和安全团队批准 Tool Output 与 Transcript 数据流；
• Enterprise 已启用 Self-Hosted Machines；
• 使用专用 Service Account 和分域 Team Pools；
• Worker 只有出站连接，无公网入站端口；
• 必需域名和可选 Artifact 域名分别管理；
• 基础镜像有 SBOM、签名、漏洞门禁和 Digest；
• 每个 Run 独立 VM/Pod/Sandbox 与 Workspace；
• Repo、Build Cache 和 Registry 按信任域隔离；
• 使用 OIDC/STS/短期 Token，不注入生产长期 Key；
• Agent 不能直接推送默认分支或发布生产；
• Required Checks、CODEOWNERS 和人工审批启用；
• stdout、stderr、Screenshot 和 Artifact 通过 DLP；
• Idle Timeout、Reconnect Window 和销毁流程验证；
• 清理失败自动隔离 Worker；
• 完成断网、Controller 故障、Pool 饱和与凭据撤销演练。

90 天落地路线

• 第 1-2 周：完成数据流和风险评估，用 My Machines 在脱敏仓库做只读试点。
• 第 3-4 周：建立不可变镜像、出站白名单、日志脱敏和短期身份。
• 第 5-8 周：上线低风险 Team Pool，限制只创建 Draft PR，并压测队列、冷启动和清理。
• 第 9-12 周：接入 Kubernetes Controller、动态扩缩容、Snapshot/恢复、FinOps 和审计平台，再逐步开放 Staging 内部服务。生产访问应单独立项。

结论

Cursor Self-Hosted Machines 能让仓库工作副本、编译测试、内部 API 调用与长期凭据留在企业侧，但推理与 Agent Loop 仍在 Cursor 云端，Tool Output 和 Transcript 仍可能进入云端处理链路。

部署的关键不是“把 Agent 搬回内网”，而是把执行面隔离、把出口收窄、把授权从 Label 移到 IAM/网络/Secret Policy，并为 Artifact、MCP、Snapshot 和清理失败单独设计控制。

几个容易抄错的取舍：

• 阻断 cloud-agent-artifacts.s3.us-east-1.amazonaws.com 只影响预览，不是离线私有化；
• Label 只做调度提示，不能当授权；
• Secret 不离开内网，不等于 Agent 不能越权，控制重点是它能做什么；
• My Machines 适合试点，不是生产隔离方案；
• Hibernate/Snapshot 不等于全系统零成本。