---
title: "My Machines"
description: "基于 Cursor 官方 My Machines 文档解释本机 worker、worker= 路由、repo 匹配、artifacts、网络和 MCP 边界。"
verifiedAt: "2026-05-09"
---

My Machines 让 Cloud Agent 使用你已经有的机器：笔记本、devbox、远程 VM 或团队内网工作站。

> [!NOTE]
> **阅读目标**：读完本章，你应该能把一台已有开发机注册给 Cloud Agent，并解释为什么任务会在这台机器执行、什么时候不会 fallback、哪些数据会离开机器。

## 1. 先判断

My Machines 适合“这台机器已经能跑项目”的场景。Cloud Agent 的推理和任务循环仍在 Cursor 云端，但文件编辑、终端命令、浏览器动作和工具调用会在你的机器上执行。

这解决的是三类问题：

| 问题 | My Machines 的价值 |
| --- | --- |
| 本地依赖复杂 | 直接复用现有 repo、依赖、构建缓存和测试输出 |
| 内网服务不可公开 | worker 从内网主动连 Cursor，不需要开放入站端口 |
| 密钥和产物不想进临时 VM | secrets、cache、build outputs 留在你的机器上 |

不适合把它当成无状态云 runner。它依赖 worker 进程持续运行，也依赖 worker 所在目录的 git remote 正确匹配目标 repo。

## 2. 工作方式

worker 会从你的机器向 Cursor 发起 outbound connection。Cursor 云端 agent 通过这条连接下发 tool calls，你的机器执行实际操作。

```mermaid
flowchart TD
  User["Start agent from Web / Slack / GitHub / Linear"] --> Cloud["Cursor cloud agent loop"]
  Cloud --> Worker["Outbound connection to your worker"]
  Worker --> Repo["Local repo checkout"]
  Worker --> Tools["Terminal / editor / browser / MCP stdio tools"]
  Worker --> Artifacts["Optional artifacts upload"]
  Worker --> Result["Branch / logs / comments / dashboard result"]
```

这条链路没有入站端口、公开 IP 或 VPN tunnel 要求。如果你的公司网络只允许代理出站，worker 环境里设置 `HTTPS_PROXY` 或 `https_proxy`。

## 3. 快速启动

官方路径是先安装 `agent` CLI，再登录，再启动 worker。

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

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

常用命令：

| 动作 | 命令 |
| --- | --- |
| 检查 CLI | `agent --version` |
| 浏览器登录个人机器 | `agent login` |
| 在当前 repo 启动 worker | `agent worker start` |
| 给机器命名 | `agent worker start --name "my-devbox"` |
| 指定 repo 目录 | `agent worker start --worker-dir /path/to/repo` |
| 使用 API key | `agent worker start --api-key "your-api-key"` |
| 使用 user-scoped token | `agent worker start --auth-token "token"` |
| 从文件读取长期 token | `agent worker start --auth-token-file /var/run/cursor/token` |

`--auth-token-file` 对 Kubernetes 或长期 devbox 更实用，因为挂载文件可以被轮换；环境变量通常在进程启动时固定。

## 4. 从聊天入口指定机器

Slack、GitHub、Linear 这些入口默认不一定知道你要用哪台机器。要指定 My Machines，使用 `worker=` 或 `machine=`。

| 入口 | 示例 |
| --- | --- |
| Slack | `@Cursor worker=my-devbox fix the flaky test` |
| GitHub | `@cursoragent machine=my-devbox fix the failing build` |
| Linear | 在 issue body 写 `worker=my-devbox` 或使用 `worker / my-devbox` 这类父子 label |

Cursor 只有在三个条件同时成立时才会把任务路由到这台机器：

1. 机器属于触发请求的 Cursor 用户。
2. 机器的 `--name` 和请求中的 `worker=<name>` 或 `machine=<name>` 匹配。
3. 机器注册的 repo 与触发入口解析出的目标 repo 匹配。

repo 来源不是机器名，而是触发入口：

| 入口 | repo 解析 |
| --- | --- |
| Slack | 优先看消息里的 `repo=`，然后是频道默认 repo、用户默认 repo、团队默认 repo |
| Linear | 从 issue、project、`repo=`、labels 或 dashboard 默认值解析 |
| GitHub | 使用提到 `@cursoragent` 的 issue、PR 或 review comment 所属 repo |

每台机器的注册 repo 来自启动 worker 的目录中的 git remote。要服务多个 repo，就在每个 repo checkout 里分别启动 worker。

## 5. 失败时不会乱跑

如果 `worker=<name>` 找到同名机器，但这台机器注册的是另一个 repo，Cursor 会拒绝任务，而不是把 repo A 的任务丢到 repo B 的 checkout。

如果没有机器同时匹配 linked user、machine name 和 target repo，请求也会失败，不会自动 fallback 到其他环境。

常见修复：

- 确认 GitHub / Slack / Linear 账号和 Cursor 用户已正确关联。
- 确认 worker 在目标 repo checkout 下启动。
- 确认 git remote 指向目标 repo。
- 确认机器名拼写一致。
- 用 `agent worker start --debug` 生成 preflight report，看认证、repo label 和可见 worker 状态。

`self_hosted`、`pool=` 和单独的 `repo=` 不会指定 My Machines。它们属于 Self-hosted Pool 路由；如果要用个人机器，必须配 `worker=` 或 `machine=`。

## 6. Artifacts 和网络

artifacts 行为与 Cursor-hosted agents 一致：agent 在 worker 内生成截图、视频或日志引用，再由 worker 通过 HTTPS 上传到 Cursor-managed storage。

worker 至少需要 outbound HTTPS 访问：

| Host | 用途 | 阻断后结果 |
| --- | --- | --- |
| `api2.cursor.sh` | agent session | worker 无法启动或维持 session |
| `api2direct.cursor.sh` | agent session | worker 无法启动或维持 session |
| `cloud-agent-artifacts.s3.us-east-1.amazonaws.com` | artifact 上传 | session 继续，但 PR 嵌入、dashboard preview 或通知附件缺失 |

如果防火墙只支持 wildcard，`*.s3.us-east-1.amazonaws.com` 能覆盖 artifacts host，但会放开该 region 的其他 bucket。能配精确 host 时优先精确 host。

## 7. MCP 路由边界

My Machines 下 MCP 按 transport 分流：

| Transport | 运行位置 | 适合场景 |
| --- | --- | --- |
| Command / stdio | 你的机器 | 访问内网 API、本地服务、数据库代理或私有网络 |
| HTTP / SSE URL | Cursor backend | Cursor 管 OAuth、session cache 和 HTTP 连接 |

如果 MCP server 必须访问私有网络，优先用 command / stdio，因为进程直接跑在 worker 机器上。HTTP MCP 则从 Cursor backend 发起连接，适合公开可达或已经有 OAuth 边界的服务。

## 本章自检

上线前至少回答这 4 个问题：

1. worker 是从哪个 repo checkout 启动的，git remote 是否匹配目标 repo？
2. 触发入口中是否显式写了 `worker=` 或 `machine=`？
3. 防火墙是否允许 `api2.cursor.sh`、`api2direct.cursor.sh` 和 artifact host？
4. artifacts、日志和 PR diff 中是否可能出现 secrets、客户数据或内网截图？

通过标准：你能让 Cloud Agent 在指定机器上跑一个真实任务，并能用 debug report、worker name、repo remote 和 PR 结果解释整条链路。

## 官方来源

- [Cursor My Machines](https://cursor.com/docs/cloud-agent/my-machines.md) —— 官方 My Machines、worker 启动、worker routing、artifacts、networking 和 MCP 行为。
- [Cursor Self-Hosted Pool](https://cursor.com/docs/cloud-agent/self-hosted-pool.md) —— 官方企业 worker pool 路由。
- [Cursor Cloud Agent Security](https://cursor.com/docs/cloud-agent/security-network.md) —— 官方 Cloud Agent 安全和网络边界。

## 接下来去哪

<Cards>
  <Card title="Self-hosted Pool" description="继续学习企业级共享 worker fleet、labels、routing 和监控。" href="/docs/cursor/official/04-cloud-agents/54-self-hosted-pool" />
  <Card title="Cloud Agent Capabilities" description="回看 artifacts、remote desktop 和 MCP 安全差异。" href="/docs/cursor/official/04-cloud-agents/52-capabilities" />
</Cards>
