摘要： Cursor Self-hosted Machines 可以把 Cloud Agent 的文件编辑、终端命令、Computer Use 和本地 stdio MCP 工具调用迁移到企业管理的 Linux、macOS、远程 VM、容器或 Kubernetes Worker，使 Agent 能访问内网 Git、私有依赖、测试环境和定制硬件。但它不是“完整私有化 Cursor”：Agent loop、模型推理与规划仍由 Cursor 云端运行，执行过程中所需的文件内容、终端输出、Diff、截图和 MCP 结果仍可能发往 Cursor。本文给出 My Machines 与 Team Pools 的选择、网络放行、最小权限、systemd 与容器化思路、内网 MCP 路由、排错、成本及企业准入清单。
核心结论
Cursor Self-hosted Machines 最适合“代码和工具必须在内网机器上执行，但企业仍能接受 Cursor 云端编排与模型推理”的团队。它解决的是执行位置、私有网络访问、定制硬件和自管镜像问题，不等于本地模型、空气隔离或源码绝不离网。
- 执行在内网，推理仍在云端： Worker 在自管机器上修改文件、运行命令和调用本地工具，Cursor 云端继续负责 Agent loop、规划和模型推理。
- 不需要开放入站端口： Worker 主动建立到 Cursor 的长连接；官方要求出站 HTTPS，无需公网 IP、VPN 隧道或 Cursor 主动连入内网。
- 个人先用 My Machines，企业用 Team Pools： My Machines 适合单个开发者和固定 Devbox；Team Pools 面向 Enterprise，使用服务账号、共享容量和集中路由。
- 源码留在机器不等于内容不出网： 完整 checkout、构建缓存和机器本地凭据可留在本机，但任务需要的文件片段、命令输出、Diff、截图、MCP 结果和路由元数据会发送到 Cursor。
- 内网 MCP 优先 stdio： 命令型 MCP 在 Worker 本地运行，可访问内网；HTTP/SSE MCP 由 Cursor 后端连接，不能默认获得 Worker 的内网网络视角。
Self-hosted Machines到底改变了什么
Cursor 官方把 Cloud Agents 描述为在独立开发环境中运行的异步 Agent，可以克隆仓库、安装依赖、运行测试、操作浏览器并提交变更。通常这些环境由 Cursor 托管。Self-hosted Machines 则把“工具执行面”移动到客户管理的机器。Cursor Self-hosted Machines 官方文档明确说明：Cursor 运行 Agent loop、推理和规划；Worker 执行文件修改、终端命令、Computer Use 以及本地 MCP Server。
因此，它更接近混合架构，而非完整私有化：
| 组件 | 运行位置 | 企业控制程度 | 关键注意事项 |
|---|---|---|---|
| Agent loop、推理、规划 | Cursor 云端 | 通过账号、团队策略和模型选择控制 | 不是离线推理 |
| Worker、文件系统、终端 | 企业自管机器 | 高 | 必须自行加固、补丁、监控和隔离 |
| 完整仓库与构建缓存 | Worker 本地 | 高 | 仍应限制 Worker 可访问目录 |
| 任务所需文件内容与终端输出 | Worker与Cursor之间传输 | 中 | 需要数据分类、脱敏与Privacy Mode |
| stdio MCP | Worker 本地 | 高 | 可访问内网，但权限必须最小化 |
| HTTP/SSE MCP | Cursor 后端 | 中 | 连接来自云端，不继承Worker内网访问 |
| Artifact | 本地生成后上传Cursor存储 | 可选择阻断上传 | 阻断后仪表盘与PR中不显示相关预览 |
“让 Cloud Agent 在内网执行”准确指的是工具动作在内网完成。例如，Agent 可以在内网 Worker 上读取已授权代码、调用私有包仓库、连接测试数据库、执行编译与回归测试，再生成分支和 PR。但如果企业政策要求任何代码片段、日志和推理输入都不得出网，Self-hosted Machines 本身并不能满足这一条件，需要另选完全本地的模型与 Agent Runtime。
继续了解 Cloud Agent 选型，可查看 AI Stack Nav 的 Cursor Cloud Agent 教程。
什么时候值得部署，什么时候不要部署
官方建议大多数团队优先使用 Cursor 托管的 Cloud Agents，因为无需运维 Worker，并提供按 Agent 隔离的 VM、网络 Allowlist、Privacy Mode，以及通过 AWS PrivateLink、Cloudflare Tunnel、Tailscale 等方式访问部分私有资源。只有托管环境无法满足约束时，才应承担自托管成本。
Self-hosted Machines 的典型理由包括：
- 代码、私有 Registry、构建服务或测试系统只能从内网访问。
- 必须复用已有 Devbox、构建缓存、专用 SDK、许可证服务器或企业镜像。
- 需要 GPU、Mac mini 或 iOS 构建环境等定制硬件。
- 企业已有 Kubernetes、弹性 VM 或沙箱平台，希望自己控制容量、镜像和生命周期。
- 内网 stdio MCP 必须与数据库、工单、监控或发布平台交互。
不建议为了“听起来更安全”直接自托管。如果 Cursor 托管环境通过网络 Allowlist、私有连接和受控 Secrets 已经满足要求，自托管会额外引入镜像漏洞、Worker 凭据泄露、资源争用、僵尸进程、横向移动和容量不足等风险。
| 场景 | 推荐运行方式 | 理由 |
|---|---|---|
| 个人测试、单仓库、已有开发机 | My Machines | 配置最快，适合验证执行模型 |
| 小团队但无需自有算力 | Cursor托管Cloud Agents | 运维负担最低 |
| 企业共享Worker、统一镜像 | Team Pools | 服务账号、池化路由、集中管理 |
| 突发任务、成本敏感 | 动态Worker或Kubernetes | 按请求扩缩容，减少空闲成本 |
| iOS构建与GUI验证 | macOS Worker＋Computer Use | 使用Mac硬件与桌面会话 |
| 数据严禁离开内网 | 不适合直接采用 | 推理和必要上下文仍经过Cursor云端 |
架构与数据流：先看懂再开防火墙
Worker 使用 Cursor CLI 注册后，通过 agent worker start 建立长期出站 HTTPS 连接。Cursor 通过该连接发送工具调用，Worker 返回文件内容、命令结果和其他任务上下文。官方强调 Cursor 不需要主动连接进企业网络，因此不必开放入站端口或为 Worker 配置公网 IP。
最小网络放行应按精确主机名设置：
| 出站地址 | 用途 | 阻断后的影响 |
|---|---|---|
api2.cursor.sh | Agent会话 | Worker无法启动或继续任务 |
api2direct.cursor.sh | Agent会话 | Worker无法启动或继续任务 |
downloads.cursor.com | CLI更新及macOS首次安装Computer Use组件 | 更新或首次安装失败 |
cloud-agent-artifacts.s3.us-east-1.amazonaws.com | 上传截图、视频等Artifact | Agent仍可工作，但PR和仪表盘缺少预览 |
| 工具自身依赖的域名 | Git、Registry、API或其他集成 | 只有对应工具失败 |
官方建议防火墙支持时使用精确 S3 Host，不要为了省事开放整个 *.s3.us-east-1.amazonaws.com。如果企业必须经代理出网，可在 Worker 环境中设置 HTTPS_PROXY 或 https_proxy。代理日志需要做敏感字段过滤，不能记录认证头、API Key、源码正文或MCP返回的客户数据。
可用以下只读检查确认网络，不在命令行显示密钥：
curl -I https://api2.cursor.sh
curl -I https://api2direct.cursor.sh
curl -I https://downloads.cursor.com
curl -I https://cloud-agent-artifacts.s3.us-east-1.amazonaws.comHTTP 状态码不一定是 200，重点是 DNS、TLS 和代理链路是否能建立。真正的 Worker 预检应使用官方命令 agent worker debug。
My Machines部署：先完成一台内网Worker
My Machines 是个人级 Self-hosted 配置，适合把某个开发者的 Linux、macOS、WSL、远程 VM 或 Devbox 连接到自己的 Cursor 账号。Worker 从指定目录读取 Git Remote 作为路由信息，以便 Cloud Agent 把目标仓库任务发送到正确机器。
第一步：准备隔离账号和工作目录
不要直接用 root 或日常办公账号运行 Agent。建议创建专用系统用户，将仓库放入独立目录，只授予构建、测试和创建临时分支所需权限。该账号不应拥有生产 SSH Key、数据库管理员凭据、集群管理员 Kubeconfig 或云账号 Owner 权限。
sudo useradd --create-home --shell /bin/bash cursor-worker
sudo install -d -o cursor-worker -g cursor-worker /srv/cursor-workspaces如果企业环境不允许新增用户，也应至少用容器、VM 或独立 Devbox 隔离，不要把包含所有个人仓库和密钥的 Home 目录注册给 Worker。
第二步：安装并验证Cursor CLI
官方对 macOS、Linux 和 WSL 给出的安装方式为：
curl https://cursor.com/install -fsS | bash
agent --version在企业环境中，curl | bash 应先经过安全审核。更稳妥的做法是由平台团队下载固定版本、校验来源和摘要，再通过内部软件仓库分发。文章保留官方命令用于对照，并不建议绕过企业供应链制度。
第三步：登录并启动Worker
个人机器最方便的是浏览器登录：
agent login
cd /srv/cursor-workspaces/YOUR_REPO
agent worker start --name "intranet-devbox"也可以显式指定目录：
agent worker start \
--name "intranet-devbox" \
--worker-dir /srv/cursor-workspaces/YOUR_REPO需要服务多个已存在的 checkout 时可重复 --worker-dir，但每个目录必须存在，并应有正确的 Git Remote。不要把整个 /srv、用户 Home 或文件系统根目录作为 Worker Root。
第四步：从Cloud Agent选择机器
进入 cursor.com/agents，在环境下拉列表中选择刚注册的 My Machine，再发送一个低风险验证任务，例如“读取 README、运行已有单元测试并总结失败原因，不修改文件”。确认任务确实在 Worker 执行、日志没有敏感信息、网络访问符合预期后，再逐步开放写权限。
第五步：验证路由与排错
agent worker debug如果机器不出现在选择器，检查 Worker 进程是否仍运行、CLI 与网页是否使用同一 Cursor 账号、Worker 目录 Git Remote 是否对应目标仓库，以及三个必要 Host 是否能出站。官方路由会核对用户、Worker 名称和目标 Repo；不匹配时应拒绝任务，而不是降级到错误机器。
把Worker作为长期服务运行
长期 Worker 不能只依赖一个 SSH Terminal。官方支持在持久主机或容器中用 systemd、launchd、Docker 或其他进程管理器运行。下面是实施模板，不是 Cursor 官方原样配置，上线前应结合 CLI 当前参数验证。
[Unit]
Description=Cursor Self-hosted Worker
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=cursor-worker
Group=cursor-worker
WorkingDirectory=/srv/cursor-workspaces/YOUR_REPO
Environment=HTTPS_PROXY=http://YOUR_PROXY_HOST:YOUR_PROXY_PORT
EnvironmentFile=/etc/cursor-worker/worker.env
ExecStart=/home/cursor-worker/.local/bin/agent worker start --name intranet-worker --worker-dir /srv/cursor-workspaces/YOUR_REPO
Restart=on-failure
RestartSec=10
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/srv/cursor-workspaces/YOUR_REPO
[Install]
WantedBy=multi-user.targetworker.env 只能由专用账号读取，示意内容如下：
CURSOR_API_KEY=YOUR_USER_SCOPED_TOKEN不建议长期使用静态个人 Key。官方支持短期 user-scoped token 和 --auth-token-file；在 Kubernetes 中把轮换 Token 以文件挂载，可以在 Pod 运行期间更新。具体 Token API 和权限应以 Cursor 当前企业文档为准。
启用服务前，应确认 ProtectHome=true 不会阻止 CLI 读取必需文件；如果 Worker 二进制或凭据在 Home 中，应把它移动到受管路径，或有针对性地调整沙箱。不要为解决启动问题直接删除所有 systemd 加固项。
Team Pools：企业共享容量与集中路由
My Machines 绑定个人身份，更适合试点。Team Pools 面向企业共享 Worker，要求 Cursor Enterprise 计划，并使用 Service Account API Key。团队管理员可在 Cloud Agents 设置中允许 Self-hosted，或要求所有 Cloud Agent 强制路由到自托管 Worker。
Team Pool 的三个核心对象是：
- Worker： 实际执行文件和命令的一台机器或一个隔离实例。
- Pool： UI 中可选择的路由目标，例如
linux-build、gpu、ios或restricted-java。 - Controller： 根据待处理请求启动和回收 Worker 的企业自管控制器。
池名称不应只按部门划分，更应反映信任边界和能力，例如：
| Pool | 允许访问 | 禁止访问 | 适用任务 |
|---|---|---|---|
web-test | 测试API、只读Registry | 生产数据库、云管理员权限 | 前端与接口回归 |
ios-build | 签名隔离区、测试设备 | 生产发布证书自动使用 | iOS构建与UI验证 |
data-readonly | 脱敏数据、只读查询 | 写入和导出原始客户数据 | 分析与迁移评估 |
infra-plan | Terraform plan、测试账号 | apply、生产Kubeconfig | 基础设施变更预览 |
官方允许同一用户连接最多 200 个 Worker、一个团队最多 1000 个；更大规模需要联系 Cursor。这个数字是连接上限，不是每个企业都应追求的容量。实际规模应从并发任务数、启动时间、平均占用时长、失败率和空闲成本推导。
Kubernetes与动态Worker设计
Cursor 提供 anysphere/k8s-workers 参考模板，控制器可用 agent worker controller --spawn 在集群中为已认领请求创建 Worker Pod，也可以用 --warm-idle 保留预热 Pod，而且无需 CRD。官方同时说明这些部署指南属于参考架构，Worker 镜像、基础设施、Secrets、扩缩策略和生产验证由企业负责。
生产设计建议如下：
- 每个任务一个 Pod 或微型 VM，任务结束销毁，避免跨任务残留工作区和凭据。
- 使用只读基础镜像、非 root 用户、只读 RootFS、Seccomp/AppArmor 和最小 Linux Capability。
- 用 NetworkPolicy 只允许 Cursor必要Host、目标Git、内部Registry及任务明确需要的服务。
- 使用短期 Token、短期 Git 凭据和工作负载身份，不把长期密钥固化在镜像或环境快照中。
- Workspace 使用临时卷；需要缓存时将包缓存与源码、凭据分离。
- Controller 只负责容量，不获得生产业务权限；Worker Pool 按信任等级使用不同 Service Account。
- 设置任务超时、最大并发、队列长度、每仓库预算和异常熔断。
示意性的 Pod 安全片段如下，具体字段应与 Cursor 参考模板合并，而不是直接替换其完整配置：
apiVersion: v1
kind: Pod
metadata:
name: cursor-worker-example
spec:
restartPolicy: Never
serviceAccountName: cursor-worker-restricted
containers:
- name: worker
image: YOUR_REGISTRY/cursor-worker:PINNED_VERSION
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
env:
- name: HTTPS_PROXY
value: "http://YOUR_PROXY_HOST:YOUR_PROXY_PORT"
volumeMounts:
- name: workspace
mountPath: /workspace
- name: cursor-token
mountPath: /var/run/cursor
readOnly: true
volumes:
- name: workspace
emptyDir: {}
- name: cursor-token
secret:
secretName: cursor-worker-token如果构建工具需要 Docker Socket，不要直接挂载宿主机 /var/run/docker.sock。这几乎等于给 Worker 宿主机级控制权。优先使用隔离构建服务、Rootless BuildKit、Kaniko 类构建方案或独立短命 VM。
相关集群治理内容可延伸阅读 AI Stack Nav 的 Kubernetes Agent部署教程。
内网MCP、Git与私有服务怎么接
Self-hosted Worker 最有价值的能力之一，是在本机启动 command/stdio MCP，使其共享 Worker 的网络视角。官方路由规则非常关键：stdio MCP 在自管机器运行，可以访问内网 API 和本地服务；URL 形式的 HTTP/SSE MCP 则由 Cursor 后端处理 OAuth、Session Cache 和连接。
因此，要让 Agent 调用只在 10.x 网络开放的 CMDB、测试数据库或工单接口，应优先提供本地 stdio MCP，并在 Server 内部再次实施身份验证、参数校验和操作白名单。不要因为 MCP 运行在内网就默认可信。
推荐将工具分为四级：
| 级别 | 示例 | 默认权限 | 审批策略 |
|---|---|---|---|
| L0 | 读取源码、查询测试状态 | 只读 | 可自动执行并记录 |
| L1 | 运行测试、创建临时文件 | 受限写入 | 自动执行，限制目录和超时 |
| L2 | 创建分支、更新工单、写测试库 | 可恢复写入 | 任务内确认或规则审批 |
| L3 | 发布、删库、改权限、使用生产凭据 | 高风险 | 禁止自动执行，必须人工审批 |
Worker 的 Git 凭据只应允许特定仓库，优先创建分支和 PR，禁止直接 Push 受保护分支。测试数据库使用独立账号、合成数据和短期凭据。MCP 输出也要脱敏，因为结果可能作为推理上下文发送到 Cursor。
什么数据仍会离开内网
这是部署前最重要的合规问题。根据官方文档，完整 checkout、Build Cache 和机器本地凭据留在自管机器；任务过程中 Worker 会向 Cursor 发送 Agent 所需内容，例如文件内容、终端输出、Diff、截图、本地 MCP 结果和路由元数据。开启桌面分享时还会传输桌面画面。
Artifact 默认开启，截图、视频和日志引用会上传到 Cursor 管理的存储，以便在 PR 和 Dashboard 显示。企业可以阻断 cloud-agent-artifacts.s3.us-east-1.amazonaws.com 来停止 Artifact 上传，Agent会话和其他工具调用仍可继续，但相关预览会缺失。
Privacy Mode 也适用于 Self-hosted Machines。Cursor 表示开启后，Worker 发送的代码不会被 Cursor 或模型提供商用于训练。但“不会用于训练”不等于“数据完全不传输”或“零保留”，企业仍需核验合同、数据处理协议、模型提供商、日志保留、地域、子处理者和删除机制。Cursor Security页面列出了Privacy Mode与安全认证信息，最终合规判断应由企业法务和安全团队完成。
建议建立数据清单：
- 可以发送：公开仓库、脱敏测试日志、合成数据、已批准的代码片段。
- 条件发送：内部源码、架构信息、漏洞报告、客户配置，需要Privacy Mode和合同控制。
- 禁止发送：生产密钥、未脱敏个人信息、密码、私钥、数据库Dump、受出口或保密协议限制的数据。
安全加固与准入机制
Self-hosted Worker 获得了真实终端和文件权限，因此安全基线不能只停留在 Cursor 设置。至少实施以下控制：
- 独立OS账号、容器、VM或每任务Pod，不与开发者日常会话混用。
- 精确Worker Root，禁止注册Home、共享盘根目录或生产配置目录。
- 出站域名Allowlist，并记录连接元数据而非敏感正文。
- Repo、MCP、数据库和云权限全部采用最小权限及短期凭据。
- 使用Cursor Hooks或企业外部策略，在命令执行、文件修改和任务结束时检查风险。
- 禁止Agent修改安全规则、CI工作流、分支保护和审计脚本，除非专项审批。
- 所有变更进入临时分支，必须经过测试、独立代码审查和PR保护。
- 删除、发布、权限修改、生产数据库和基础设施Apply必须人工审批。
- 定期销毁Worker、轮换Token、更新CLI及基础镜像，并扫描依赖与容器漏洞。
可在 .cursor/hooks.json 中接入企业脚本。具体事件和Schema应以当前Hooks文档为准，下面仅表达策略意图：
{
"version": 1,
"hooks": {
"beforeShellExecution": [
{
"command": "python3 security/check_command.py"
}
],
"afterFileEdit": [
{
"command": "python3 security/check_protected_paths.py"
}
],
"stop": [
{
"command": "python3 security/final_audit.py"
}
]
}
}需要注意，Hooks 本身也属于高价值控制面，应由 CODEOWNERS 保护，并在外部 CI 再做一次独立校验，不能让写代码的 Agent 同时修改或绕过自己的审查规则。
成本：自托管不会免除模型费用
官方说明，所有 Runtime 都使用所选模型并按对应模型定价。Cursor 托管 Cloud Agents 已包含执行基础设施；Self-hosted Machines 除模型费用外，企业还需支付和运维自己的机器、容器或集群。
真实月成本可以按下式估算：
月总成本
= Cloud Agent模型用量
+ Worker计算资源与系统盘
+ 缓存、Artifact和日志存储
+ 内网出口、代理与安全设备
+ 镜像构建、漏洞扫描和补丁维护
+ 容量冗余与空闲成本
+ 平台工程、安全审计和故障处理人工成本静态 Worker 适合利用率稳定、启动昂贵或依赖大缓存的环境；动态 Worker 适合任务波动明显、隔离要求高的团队。不要只比较云 VM 单价，还要统计队列等待时间、冷启动、任务失败率、平均占用时间、缓存命中率和人工运维时间。
Team Pools 要求 Enterprise 计划，公开页面没有给出可直接套用的统一企业总价时，应写“联系销售并以合同为准”，不要自行推算套餐权益。Cloud Agent 模型价格也会随选择变化，发布文章时建议再次核验 Cursor定价页面。
故障排查
Worker不出现在环境选择器
先运行 agent worker debug，确认 Worker进程在线、网页登录与CLI账号一致、Git Remote正确、Worker Root与目标仓库匹配，并检查 api2.cursor.sh 和 api2direct.cursor.sh 出站链路。
Agent能读代码但无法访问内网服务
确认工具实际在 Worker 运行。stdio MCP共享本机网络；HTTP/SSE MCP连接来自Cursor后端。再检查DNS、代理、NetworkPolicy、服务端Allowlist和Worker身份，不要临时开放整个网段。
Artifact在PR或Dashboard消失
检查是否阻断了 cloud-agent-artifacts.s3.us-east-1.amazonaws.com。这不会停止Agent会话，但截图、视频和依赖Artifact的预览无法上传。若阻断是合规要求，应接受该功能边界，而不是放开更宽的S3通配域名。
Worker频繁断开
检查代理空闲超时、TLS检查、进程管理器重启记录、机器休眠和CLI版本。长连接需要稳定出站网络；桌面设备应关闭自动休眠或改用远程VM。
任务运行到了错误仓库
核对每个 --worker-dir 的Git Remote、Worker名称和触发面的目标Repo。Cursor官方会在用户、机器名和Repo不匹配时拒绝My Machines任务；不要通过复制同名Worker或共享个人账号绕过这一保护。
Agent执行了不应执行的命令
立即停止Worker，撤销短期凭据，保留审计记录并检查受影响目录。之后收紧OS账号、工具Allowlist、Hooks、NetworkPolicy和人工审批。生产密钥不应存在于Worker可读取范围内。
上线验收清单
正式开放给团队前，至少完成以下验收：
- 已确认Self-hosted只迁移工具执行，推理和Agent loop仍在Cursor云端。
- 已完成数据分类，并明确哪些源码、日志、截图和MCP结果可以出网。
- 已核验Privacy Mode、合同、数据保留、子处理者和适用地区。
- Worker使用独立账号、最小目录、最小Git权限和短期Token。
- 防火墙只放行精确Cursor Host及任务必需服务，无入站开放。
- Artifact上传策略已决定，并验证阻断后的产品影响。
- stdio与HTTP/SSE MCP的运行位置已经逐项确认。
- 删除、发布、生产写入、权限修改和基础设施Apply均有人审。
- CI、Hooks、分支保护和安全策略不能被普通Agent任务修改。
- 每任务设置超时、并发、磁盘、CPU、内存和预算上限。
- Worker镜像、CLI、依赖、OS补丁和漏洞扫描有持续维护责任人。
- 已演练断网、Token失效、Worker中断、任务超时、错误仓库和凭据泄露。
- 已记录任务、Worker、Repo、模型、工具调用、Diff、审批和最终PR。
- 已先从只读任务与非生产Repo试点，再逐步开放写权限。
通过这份清单后，Self-hosted Machines 才是可治理的企业执行平面，而不只是“在服务器上跑起了一个Worker进程”。
事实依据与来源
- 官方已确认： Self-hosted Machines 将Cloud Agent工具执行移动到客户管理的机器；Cursor仍运行Agent loop、推理和规划。
- 官方已确认： Worker通过长期出站HTTPS连接接收工具调用，无需入站端口、公网IP或VPN隧道。
- 官方已确认： 完整checkout、Build Cache和本地凭据留在Worker，但任务所需文件、终端输出、Diff、截图、本地MCP结果和路由元数据会发送给Cursor。
- 官方已确认： My Machines面向个人Worker；Team Pools面向团队和企业，要求Enterprise计划及Service Account API Key。
- 官方已确认： stdio MCP在Worker运行，HTTP/SSE MCP由Cursor后端处理；前者更适合访问内网服务。
- 官方已确认： 可在个人、持久主机、容器、动态基础设施和Kubernetes上运行Worker；官方模板属于参考架构，客户负责生产验证。
- 实施建议： systemd加固、Pool分级、Kubernetes安全上下文、L0—L3工具权限和上线清单属于本文工程建议，不是Cursor默认配置。
- 待项目验证： 吞吐量、冷启动、单位任务成本、代理兼容性、内部工具稳定性及合规适配必须在企业自己的网络和仓库中测试。
FAQ
Cursor Self-hosted Machines是完全私有化部署吗？
不是。Worker上的文件编辑、终端命令、Computer Use和本地工具在自管机器执行，但Agent loop、推理和规划仍由Cursor云端运行。它是混合执行架构，不是离线版Cursor或本地大模型平台。
部署Worker需要开放入站端口吗？
不需要。Worker主动连接Cursor后端，只需必要的出站HTTPS。官方表示无需公网IP、VPN隧道或Cursor主动进入企业网络；仍应使用精确域名Allowlist和企业代理策略。
源代码会不会离开内网？
完整仓库可保留在Worker，但Agent完成任务所需的文件内容、终端输出、Diff、截图、MCP结果等会发送给Cursor。若政策要求任何源码片段都不能出网，这一方案不满足完全隔离要求。
My Machines与Team Pools怎么选？
个人试点、固定Devbox或单用户机器选My Machines；企业共享容量、集中镜像、服务账号和弹性扩缩选Team Pools。Team Pools要求Enterprise计划。
可以在Kubernetes里运行吗？
可以。Cursor提供参考模板，控制器可以按请求创建Worker Pod或保留预热Pod。企业仍需负责镜像、Secrets、NetworkPolicy、资源限制、扩缩策略和生产验证。
内网MCP应该用stdio还是HTTP？
优先stdio。命令型MCP直接在Worker运行，能够访问Worker所在内网；HTTP/SSE MCP由Cursor后端连接，不会自动获得内网访问能力。两种方式都必须进行身份验证、参数校验和权限限制。
可以关闭截图和视频上传吗？
可以通过阻断官方Artifact上传Host来停止上传。Agent仍能继续工作，但PR嵌入、Dashboard预览和通知附件会缺失。不要用过宽的S3通配规则替代精确Host策略。
Self-hosted Machines会降低Cloud Agent费用吗？
不一定。模型仍按所选模型定价，自托管还增加机器、集群、存储、网络、安全和运维成本。只有结合利用率、冷启动、失败率和人工维护核算，才能判断是否更便宜。
参考来源
- Cursor Docs：Self-Hosted Machines
- Cursor Docs：My Machines
- Cursor Docs：Team Pools
- Cursor Docs：Self-hosted Integrations
- Cursor Docs：Cloud Agents
- Cursor Docs：Cloud Agents API
- Cursor Security
- Cursor Pricing
环境配置与 Docker 工作流
适合阅读安装部署、本地配置、服务器搭建和自动化流程类文章后继续转化。
