Cloud Agent Capabilities
基于 Cursor 官方 Capabilities 文档解释 computer use、artifacts、remote desktop、MCP HTTP/stdio、安全差异和 CI failure autofix。
Cloud Agent 的能力不只是“云端写代码”。它能在独立 VM 里运行软件、控制 browser / desktop、生成 artifacts，并在某些条件下跟进自己 PR 的 CI failures。
阅读目标：读完本章，你应该能判断 Cloud Agent 的验证证据是否足够，并能解释 MCP HTTP 与 stdio 在云端的安全差异。
1. Computer use
Computer use（计算机使用，让 AI 像人一样用鼠标键盘操作桌面 / 浏览器的能力）是 Cloud Agents 区别于本地 Agent 的重要扩展。每个 Cloud Agent 运行在自己的 isolated VM，带完整 desktop environment。Agent 可以用 mouse 和 keyboard 控制 desktop 和 browser。
这意味着它可以：
- 启动 dev server。
- 打开应用。
- 点击 UI flow。
- 验证修改是否真的可用。
- 再 push PR。
商业级验收要看它是否真的用 artifacts 或日志证明了关键路径，而不是只写“已完成”。
2. Demos 和 Artifacts
Cloud Agents 会生成 screenshots、videos、log references 等 artifacts，附到 PR 上，帮助你不用 checkout branch 就快速判断变化。
如果在 Cloud Agents dashboard 里开启 Allow posting artifacts to GitHub，Cloud Agents 可以把 artifacts 嵌入 GitHub pull request description。
注意公开 URL 边界：
- GitHub image proxy 要求 public URLs。
- PR 描述里的 artifacts 使用 long, unguessable URLs。
- 这些 URL 无需 authentication 也可查看。
所以 artifact 不要包含 secrets、后台私密数据、客户资料或不可公开截图。
3. Remote desktop control
你可以接管 agent 的 remote desktop，在 agent 的 VM 中直接测试软件。测试完后再把控制权交还给 agent，让它继续工作。
适合：
- 复杂 UI flow。
- 本地不方便 checkout 的 PR。
- 需要看浏览器真实状态的改动。
- 需要确认 demo artifact 是否可信。
不适合：
- 输入敏感凭据。
- 绕过正式 staging / review。
- 把 remote desktop 当生产环境。
4. MCP tools
Cloud Agents 可使用 team 配置的 MCP servers，通过 cursor.com/agents 的 MCP dropdown 添加和启用。
它们可以访问外部 tools 和 data sources，例如 databases、APIs、third-party services。
Cloud Agents 支持 OAuth。对 team-level shared MCP server 来说，OAuth 仍是 per-user。
5. HTTP vs stdio MCP
官方推荐尽量用 HTTP MCP。
| Transport | 行为 | 安全含义 |
|---|---|---|
| HTTP | tool calls 通过 backend proxy，server config 不出现在 VM 环境 | Agent 拿不到 refresh token、headers 等配置 |
| stdio | server 在 cloud agent VM 内运行 | Agent 能访问 server config 和 env vars |
Custom MCP 支持 HTTP 或 stdio。SSE 和 mcp-remote 当前不支持。
敏感字段会 encrypted at rest，并在保存后无法被用户读回：
envheadersCLIENT_SECRET
如果使用 stdio MCP，必须确保 VM 环境能运行该 server。Cursor 无法在 agent 启动前验证 stdio server 一定可运行。
6. CI failure autofix
Cloud Agents 会自动尝试修复它们自己 PR 中的 CI failures。目前官方说明支持 GitHub Actions。
会跳过自动跟进的情况：
- 你向该 branch push 了新 commit。
- 你给 agent 发了 follow-up message。
- 同一个 check 在 base commit 上已经失败。
- PR 已经有 10 次 CI-failure follow-ups。
关闭方式：
- 个人 Cloud Agents：到 Dashboard 的 My Settings 关闭 Automatically fix CI Failures。
- 单个 PR：评论
@cursor autofix off。 - 重新开启：评论
@cursor autofix on。
如果希望 Cloud Agent 修复你自己的 PR CI，也可以正常评论，例如 @cursor please fix the CI failures。
7. 验收策略
| 能力 | 验收证据 |
|---|---|
| Computer use | browser flow screenshot / video / logs |
| Artifacts | PR 中的截图、视频和日志引用 |
| Remote desktop | 人工接管后复现关键路径 |
| MCP tools | 工具调用目标、权限、结果和是否泄露敏感字段 |
| CI autofix | CI runs、commit history、agent follow-up 次数 |
不要把 artifacts 当作最终合并依据。最终合并仍要看 diff、tests、security review 和产品验收。
深读：为什么 HTTP MCP 更适合 Cloud Agent
Cloud Agent 是一台云端 VM。stdio MCP 运行在 VM 内，Agent 能接触到 server 的 env 和配置，这和本地 IDE 的 stdio MCP 类似。
HTTP MCP 通过 backend proxy 调用，server configuration 不进入 VM 环境。对数据库、内部 API、第三方服务这种高敏感工具，HTTP MCP 的权限边界更容易审计。
本章自检
完成本章后，用这 3 个问题检查自己是否真正理解：
- 为什么 artifact URL 的公开可访问性会影响截图内容选择？
- HTTP MCP 相比 stdio MCP 的安全边界差异是什么？
- Cloud Agent 什么时候不会自动修复自己 PR 的 CI failure？
通过标准：你能为一个 Cloud Agent PR 写验收清单，包含 artifacts、remote desktop、MCP 权限和 CI follow-up 检查。
官方来源
- Cursor Cloud Agent Capabilities —— 官方 computer use、artifacts、remote desktop、MCP 和 CI autofix。
- Cursor MCP —— 官方 MCP 背景。
- GitHub image proxy —— GitHub 图片代理公开 URL 背景。
- Cursor Cloud Agent Setup —— 官方环境和 stdio MCP 运行背景。