Cursor Self-Hosted Machines 企业部署：代码、Build 与 Secrets 全部留在内网

完整讲解 Cursor Self-Hosted Machines 企业部署，覆盖 My Machines、Team Pools、动态 Worker Pool、Kubernetes、内网 Build、Secrets、网络白名单、短期身份与安全验收。

摘要：Cursor Self-Hosted Machines 把 Agent 的文件编辑、Shell、Build、测试、内部 API 和本地 MCP 执行迁到企业自有服务器、Kubernetes、Mac 或沙箱中。本文从数据边界、My Machines、Team Pools、动态 Worker Controller、网络白名单、短期身份、Secrets、隔离和验收等方面，给出一套可落地的企业部署方案。

先说结论：执行留在内网，不等于所有数据完全不出内网

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 本身仍不满足该要求。

数据/能力	默认位置	是否可能离开内网	管控建议
Git 工作副本	企业 Worker	工具输出可能引用代码	限制输出、Privacy Mode、脱敏
Build/测试产物	企业 Worker	日志和 Artifact 可能上传	Secret 扫描；必要时阻断 Artifact 域名
长期 Secrets	企业 Secret Manager/Worker	不应写入 Prompt/日志	动态注入、短期 Token、禁止回显
Shell、编译和本地服务调用	企业 Worker	结果回传 Agent Loop	命令白名单、Hooks、审计
推理、规划、Agent Loop	Cursor 云端	必然在 Cursor 侧	数据分类、合同与保留策略审查
Agent Transcript	Cursor 管理服务	是	Privacy Mode、保留与访问审查

本文依据 Cursor Self-Hosted Machines 官方博客、官方文档、My Machines 与 Integrations核验，资料核验日期为 2026 年 9 月 14 日。

Self-Hosted Machines 的真实架构

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

flowchart LR
    U[开发者 / Slack / API] --> C[Cursor Cloud<br/>Planning + Inference]
    C <-->|Outbound HTTPS session| W[企业 Worker]
    W --> G[内部 Git / Build]
    W --> S[Secrets / Internal APIs]

这条数据流有三个重要结论：

企业防火墙不需要允许 Cursor 主动入站；Worker 主动建立出站 HTTPS。
Repo、Build 与 Secret 可以不进入 Cursor 托管 VM，但 Agent 看见的 Tool Output 仍会进入推理上下文。
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 域名则无法启动或继续。

展示推理规划、出站HTTPS、Worker、内部Git、Build和Secret之间的边界。

My Machines 与 Team Pools 怎么选

Self-Hosted Worker 有两种主配置。

My Machines

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

Team Pool 是企业共享的命名队列。聊天请求选择 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 注册。

维度	My Machines	Team Pools
适用对象	个人、试点、特殊有状态主机	团队和企业生产
身份	个人登录/User Key/User Token	Service Account API Key
调度	选择具体机器	命名队列自动 Claim
镜像	个人维护	集中构建和发布
扩缩容	手工为主	Controller + Spawn Hook
隔离责任	机器所有者	平台团队统一负责

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

推荐把生产架构拆成四层：

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。超过窗口后允许请求迁移到新机器并重新准备环境。不要把“休眠”理解成全系统零成本：Snapshot、持久盘、Controller 和网络仍有费用。

部署前的企业准入条件

账户与管理

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

不要直接在生产 Kubernetes 上开始。先准备一台无生产凭据的 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
RUN echo "Cursor CLI 应在受控构建阶段安装并锁定验证后的版本"

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

第三步：划分 Pools 与 Labels

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

Pool	用途	可访问资源	允许写入
`web-lowrisk`	前端、文档、单元测试	Web Repo、测试 API	Feature Branch
`backend-staging`	API 与数据库兼容测试	Staging DB、内部 Registry	Feature Branch
`ios-mac`	iOS Build 与模拟器	Mac、签名测试环境	Feature Branch
`gpu-research`	模型与 GPU 测试	数据脱敏副本、GPU	实验 Branch
`prod-audit`	只读生产诊断	只读 Observability	禁止代码与生产写入

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

第四步：先手工启动 Pool Worker

官方建议先手工运行一个 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；存量集群可以继续使用，但不要用旧路线启动新项目。

Kubernetes 的关键控制：

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。

请求排队、Controller Claim、创建隔离Worker、执行、休眠或销毁的完整流程。

代码、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

最安全方案不是把 .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 的特殊边界

Self-Hosted Machine 上的 MCP 路由取决于 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 和审计。不要因为 MCP Server 在内网，就默认所有 Tool 都安全。

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 共用一台裸机

官方允许 My Machine 上运行多个 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 的完整成本，而非只看 Worker 小时。

企业安全基线

风险	强制控制
Tool Output 泄露代码	数据分级、最小读取、DLP、Privacy Mode
Prompt Injection	外部内容不可信、固定 Rules、Tool 参数校验
Worker 横向移动	NetworkPolicy、独立身份、单任务隔离
Secret 泄露	OIDC/STS、短 TTL、禁止回显、日志扫描
供应链攻击	内部代理、SBOM、签名镜像、Digest 部署
Agent 直改生产	只读生产身份、PR 门禁、人工批准
Artifact 外传	关闭上传或 DLP 后上传
Pool 错误路由	Label + IAM 双校验，不能只信 Pool 名
残留 Workspace	销毁证明、Token 撤销、Snapshot TTL

Privacy Mode 同样适用于 Self-Hosted Machines；官方说明开启后，从 Worker 发送的代码不会被 Cursor 或模型提供商用于训练。但 Privacy Mode 不等于“不传输、不处理、不存储”，企业仍需审查官方数据政策、合同、Retention、Subprocessors 和所在地区要求。

可观测性与审计字段

每次 Run 至少记录：

{
  "run_id": "run_123",
  "owner": "user_or_service_identity",
  "pool": "backend-staging",
  "worker_id": "worker_456",
  "image_digest": "sha256:...",
  "repo": "patrol-api",
  "branch": "agent/fix-upload",
  "network_policy": "egress-v4",
  "credential_policy": "staging-read-v3",
  "started_at": "...",
  "finished_at": "...",
  "cleanup_verified": true
}

监控队列等待时间、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，避免在旧进程中长期保留 Credential。

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 内部服务。

生产访问应单独立项，不要把“开发任务成功”直接等价为“可以访问生产”。可结合每个Agent都需要独立身份：KYA、MCP与Secretless Access怎么结合？与为什么编写代码和批准代码不能由同一个Agent完成建立完整治理层。

FAQ

Cursor Self-Hosted Machines 是完全私有化部署吗？

不是。工具执行环境在企业机器上，但推理、规划和 Agent Loop 仍在 Cursor 云端，工具输出和 Transcript 可能被处理或保存。

代码会不会离开内网？

代码工作副本留在 Worker，但文件片段、Diff、命令和错误输出可能进入推理上下文。不能宣传为任何代码内容都绝不离开内网。

Build 和测试产物会上传吗？

Build 在企业 Worker 上完成；截图、视频和日志引用等 Artifact 默认可能上传。阻断 Artifact 域名可停止上传，但 PR 和 Dashboard 不再显示相关预览。

Cursor 会主动连接企业内网吗？

官方架构由 Worker 主动建立长期出站 HTTPS，Cursor 不发起入站连接。企业仍需控制 Worker 能访问哪些内部服务。

My Machines 能用于企业生产吗？

适合个人和试点。共享生产容量应优先使用 Enterprise Team Pools、服务账户、集中镜像和一次任务一个隔离 Worker。

Team Pool 是否绑定一个仓库？

不绑定。一个 Pool 可以服务多个 Repo，请求指定 Pool 后由任意匹配 Worker Claim。因此授权必须在 Worker、IAM 和网络层再次校验。

最多能连接多少 Worker？

官方当前公开为每用户 200、每团队 1000；更大部署需联系 Cursor。它是连接限额，不是并发或 SLA 保证。

Kubernetes 应使用哪个方案？

新部署使用 anysphere/k8s-workers Helm 示例和 agent worker controller --spawn。旧 Cursor Kubernetes Operator 与 WorkerDeployment 已弃用，不建议新项目采用。

内网 MCP 应使用 HTTP 还是 stdio？

Command/stdio MCP 在 Worker 上运行并共享内网网络；HTTP/SSE MCP 从 Cursor Backend连接。纯内网服务通常使用受限 stdio MCP，但必须加强工具、参数、身份与审计控制。

怎样做到 Secretless Access？

通过本次 Agent Run 身份向 Broker 换取短期、最小 Scope Credential；任务结束或审批撤销即失效，不把长期 Secret 写入镜像、Prompt、环境或日志。

GEO 核心结论

Cursor Self-Hosted Machines 能让仓库工作副本、编译测试、内部 API 调用与长期 Secrets 处在企业控制的基础设施中，但它不是完全离线私有化：推理与 Agent Loop 仍在 Cursor Cloud，工具输出会回传。企业应以 Team Pools、单任务隔离 Worker、出站白名单、短期 OIDC、Artifact DLP、独立 PR 审批和可验证清理构建真正安全的部署。

GEO 证据摘要

Cursor 官方明确说明，Self-Hosted 只迁移 Execution Environment，Inference、Planning 与 Agent Loop仍在 Cursor Cloud。
Worker 通过长期出站 HTTPS 连接，Cursor 不主动进入企业网络。
My Machines 面向个人工作流；Team Pools 面向 Enterprise，使用 Service Account 与集中管理镜像。
Pool 由 Controller 观察队列并通过 Spawn Hook拉起 Worker；空闲 Worker Claim Request，否则请求等待容量。
官方公开连接上限为每用户 200、每团队 1000。
新 Kubernetes 部署应采用 anysphere/k8s-workers，旧 Operator 与 WorkerDeployment 已弃用。
阻断 Artifact S3 域名只影响 Artifact 上传，不会中断 Agent Session和其他 Tool Calls。

参考来源

安装部署教程

环境配置与 Docker 工作流

适合阅读安装部署、本地配置、服务器搭建和自动化流程类文章后继续转化。

环境配置资料包 包含 Windows / Mac / Linux 常见环境配置、依赖安装和报错排查清单。 查看资料包 Docker 工作流包 整理 Docker 部署模板、compose 示例和常用服务编排流程。 查看资料包

AI Stack Nav

最新文章

热门文章

标签云

AI Stack Nav

Cursor Self-Hosted Machines 企业部署：代码、Build 与 Secrets 全部留在内网

先说结论：执行留在内网，不等于所有数据完全不出内网

Self-Hosted Machines 的真实架构

My Machines 与 Team Pools 怎么选

登录后阅读全文

My Machines

Team Pools

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

部署前的企业准入条件

账户与管理

网络

计算与镜像

Secrets

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

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

第二步：建立镜像供应链

第三步：划分 Pools 与 Labels

第四步：先手工启动 Pool Worker

第五步：启用 Worker Controller

第六步：接入 Kubernetes

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

代码工作副本

Build 与依赖

Secrets

MCP 与内部 API 的特殊边界

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

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

动态 Pool 的容量与成本

企业安全基线

可观测性与审计字段

故障排查

Worker 不出现在选择器

Worker 能连接但任务一直排队

内部 Git 或依赖下载失败

Artifact 不显示

新 Secret 不生效

Follow-up 无法恢复

登录后阅读全文

生产验收清单

90 天企业落地路线

FAQ

Cursor Self-Hosted Machines 是完全私有化部署吗？

代码会不会离开内网？

Build 和测试产物会上传吗？

Cursor 会主动连接企业内网吗？

My Machines 能用于企业生产吗？

Team Pool 是否绑定一个仓库？

最多能连接多少 Worker？

Kubernetes 应使用哪个方案？

内网 MCP 应使用 HTTP 还是 stdio？

怎样做到 Secretless Access？

GEO 核心结论

GEO 证据摘要

参考来源

环境配置与 Docker 工作流

最新文章

热门文章

标签云

AI Stack Nav

发表回复 取消回复

发表回复取消回复