cursor in-cloud 怎么用 何时派云端子代理
cursor in-cloud 怎么用？讲清 slash 派独立 VM 子代理的机制、适合修 CI 与探索的任务清单，以及与 Automations 的边界。
cursor in-cloud 怎么用：在 Agents Window 里输入 /in-cloud，你接下来提交的那条任务会在独立云端 VM 和分支上跑，本地工作区保持干净、会话仍可继续。这篇按官方 changelog 与 subagents 文档，说明它实际做了什么、哪些任务值得派、哪些别用。
/in-cloud 实际做了什么
Cursor 3.7 changelog（2026-06-17） 对 /in-cloud 的定义很具体：在桌面端 Agents Window 输入该 slash 后，下一条任务以 cloud subagent 形式启动，占用独立 VM 和独立分支，本地目录不被改写，本地 agent 仍可继续对话或派其它活。
官方列举的典型场景有三类：修 CI、调查问题、探索代码库。共同点是耗时长或可能并行，且你仍想在本地做别的事。父 agent 可在本地或云端继续，cloud subagent 在后台跑，不必等它结束才能发下一条本地指令。
同一 changelog 还提到环境快照：云端 setup 可在十分钟内完成依赖安装，进度可在共享终端里观看，结果写入 .cursor/environment.json 供团队复用。后续 cloud agent 启动更快，还能跑软件做验证。环境没配稳时，云端任务容易交出半成品 PR，可对照 Cloud Agent 环境与 PR 合并率 里的收口思路。
changelog 另有一节 Handoff between local and cloud：会话可在本地与云端之间来回迁移，长任务 offload 到云、并行开多个 cloud agent，必要时再拉回本地亲手点 UI。这与 /in-cloud 是同一套 cloud subagent 能力下的不同入口，handoff 偏「整段会话搬家」，slash 偏「派一条新任务上云」。
适合 /in-cloud 的任务与不适合的场景
按官方描述，值得派云端的三类任务有明确共性：运行时间长、可与本地工作并行、结果可通过 PR 或分支验收。
| 任务类型 | 适合 /in-cloud 的信号 | 不适合的信号 |
|---|---|---|
| CI 修复 | 需跑完整测试套件、多轮 push 才绿 | 改一行配置即可、本地一分钟能验 |
| 问题调查 | 要搜全库、读大量日志 | 答案已在当前文件上下文里 |
| 代码探索 | 想并行开多条调查线 | 只问一个函数含义 |
派活前可对照四条：任务预计超过本地可接受的等待时间；需要独立分支以免污染当前 checkout；不依赖只有本机才有的硬件或 VPN；云端环境已有 snapshot 或 .cursor/environment.json，否则每次冷启动成本偏高。
反例也清晰。单文件 typo、改一行就能绿的 lint、需要立刻在本机点 UI 验证的改动，留在本地 subagent 或主会话更省。Jigar Joshi 的二手文（见参考资料）建议别用 /in-cloud 处理五分钟级小修，cloud boot 加环境 setup 往往就要数分钟，除非 snapshot 已就绪。官方没有给「最短任务时长」数字，是否派云端按你自己的 boot 时间和任务包大小判断。
与本地 subagent 的差异
本地 subagent（Explore、Bash、Browser 或 .cursor/agents/ 自定义）与父 agent 共享本机会话里的工具配置。Subagents 文档 Cloud subagents 节 写明：cloud subagent 跑在云端 VM，MCP 来自团队在 cursor.com/agents 的配置，不是当前本地会话里挂的那套。
这意味着：本地刚配好、尚未同步到团队云端配置的 MCP，cloud subagent 用不了；反过来，团队云端已授权的数据库或内部 API，本地没开 MCP 也能在云端任务里用。模型与能力规则与其它 Cloud Agents 一致，遵循仓库云端 environment 设置。
本地 subagent 适合上下文隔离、并行搜代码、把冗长 shell 输出挡在子窗口外。文档里 Explore 默认用更快模型并行搜库，Bash 子 agent 吞掉 verbose 命令输出，Browser 子 agent 过滤 DOM 快照，这些都在本机进程内完成。/in-cloud 多出一层：物理隔离（VM + 分支），本地磁盘和终端不被占用。
若你在本地会话里刚加了实验性 MCP，cloud subagent 不会自动继承，要到 cursor.com/agents 给团队补同一 server。反之，云端已配好的 Sentry、Linear 等集成，本地 IDE 没开也能在 cloud 任务里调用。需要「派出去但还在同一台机器」用本地 background subagent；需要「别动我工作区、别占我 CPU」用 /in-cloud。
与 Automations 的边界
/in-cloud 是 slash 手动派活：你在会话里决定「下一条任务上云」。Automations 是事件触发：PR 打开、定时 cron、Slack 消息等条件满足后，cloud agent 按预设指令自动跑，创建入口含 /automate 或 cursor.com/automations。二者都用 cloud agent 算力，但入口与编排完全不同。
| 维度 | /in-cloud |
Automations |
|---|---|---|
| 触发 | 会话内 slash，即时 | 事件或定时，后台 |
| 适用 | 你正在 coding 时临时 offload | 重复流程、团队级响应 |
| 配置 | 当次任务提示词 | 触发器 + 指令 + 工具勾选 |
修 CI、探索仓库这类「当下决定、当下派」的活，用 /in-cloud。每条 PR 都要跑审查、每周一自动生成周报，才该进 Automations。Automations 的触发器清单与工具项见 Cursor Automations 怎么用，本篇不展开配置步骤。
同一 changelog 还提到 /babysit 可让 cloud subagent 迭代 PR 直至可合并，那是 PR stickiness 场景，与 /in-cloud 的「派下一条通用任务」不同。
国内可用性注意
/in-cloud 依赖 Cursor 桌面端 Agents Window 与云端 VM 服务，国内能否稳定使用需自行验证：控制台 cursor.com/agents 能否打开、云端任务状态是否刷新、Git 托管集成是否连通。官方文档未单独列出中国大陆可用性说明，网络路径与账号区域可能影响体验。
团队 MCP 在 cursor.com/agents 配置，若控制台加载慢或 OAuth 回调失败，cloud subagent 会缺少预期工具。自建 GitLab 等集成的网络放行也要在云端侧生效，不只本地 IDE。桌面端 Agents Window 本身需保持可连 Cursor 后端，否则 slash 发了但 VM 状态不更新。
计费按 cloud agent 用量走，与 Automations 拉起的 cloud agent 同一池子。长 CI 修复可能跑很多轮，派之前把任务边界写清楚，避免 cloud subagent 在无关目录里扩 scope。上述网络与控制台限制无法在此替读者验证，建议在非关键分支先试一条短任务，确认 VM 能拉代码、能 push 再派长活。