Cursor新增桌面操作能力，可测试模拟器

Cursor 的 Agent 现在可以操作开发者电脑上的桌面应用了：写完注册页，打开 iOS Simulator，点击注册流程，查看界面，再回头修代码。原文关注的重点是，这套操作进入本机之后，权限该交给谁，以及 Agent 会看到什么。

结论很具体：macOS 上需要授权的是独立的 Cursor Computer Use 辅助应用；但授权对象选对，只解决了工具能否工作的问题。你的邮件、浏览器登录态和其他窗口，也可能进入它通过截图获取的上下文。

从生成代码到点击界面，Cursor 补上了哪一步

原文称，Cursor 在 10 月 23 日宣布将 Computer Use 带到桌面 IDE 内的 Agent。开发者可以在 Agent 对话里输入 @，从菜单选择 Computer Use；据原文引用的报道，Agent 也可能在任务需要时自行选择它。

它提供的能力是跨 GUI 应用点击、输入和截图。对编程任务来说，价值在于缩短反馈路径：Agent 不必只根据代码推测页面效果，还能打开应用，观察实际渲染结果，再据此修改。

不过，原文没有展示完整测试记录，也没有给出成功率、耗时或缺陷发现数量。开头的注册流程描述是在解释用途，不能当成作者完成过的实验。原文提到没有伴随此次发布宣布价格调整，也不能据此推断具体套餐和使用额度。

此前，Cursor 的云端 Agent 已经能操作桌面，每个 Agent 运行在独立虚拟机中。自托管 worker 也已有可选的 --computer-use 参数，支持在自己的 Mac 或 Linux 机器上启用这类能力。这次变化，是把入口带进开发者正在使用的 IDE。

需求并不突然：7 月 17 日的论坛请求就提出本地桌面控制，希望有主动授权和操作审计；直到 10 月 6 日，工作人员仍表示在探索，没有可分享的时间表。这里的「操作审计」是用户提出的要求，原文并未证实新功能已经实现。

为什么本机桌面需要重新考虑边界

云端 Agent 操作的是隔离虚拟机，本机 Agent 面对的则可能是你当前登录的桌面会话。测试窗口之外，还可能放着聊天记录、邮箱和密码管理器。

「本地」说明被控制的是哪台电脑，并不代表模型在本机运行。

Computer Use 通过截图观察应用，因此合理的使用前提是：任务期间出现在屏幕上的内容，都可能成为模型输入。把敏感窗口最小化、切换账号或关闭应用，影响的是它能接触到的内容范围。

这里还有一个资料缺口。原文写作时，Cursor 更新日志最新条目停在 10 月 16 日，详细配置文档主要覆盖自托管 worker。新的 IDE 入口是否会在切换应用前确认、能否限制可操作应用、截图是否留存，以及是否支持 Windows，都没有明确答案。

因此，下面能说清的是已有文档记录的权限机制。不能把自托管 worker 的全部行为，直接视为 IDE 新入口已经确认的行为。

macOS 的两个权限，应该交给哪个应用

macOS 上，辅助功能权限（Accessibility）负责让工具与应用交互，屏幕录制权限（Screen Recording）负责捕获界面。两项都应该授予 Cursor Computer Use。

自托管文档给出的安装位置是 ~/.cursor/cursor-computer-use/Cursor Computer Use.app，bundle ID 为 co.anysphere.cursor-computer-use。给 Terminal、iTerm、agent、Cursor 或 Cursor Agent Helper 授权，都不能替这个辅助应用获得权限。

下面是原文提供的自托管 worker 命令，用来更新、启动、检查辅助应用，并读取其代码签名要求：

agent update
agent worker --computer-use start
agent worker debug
codesign -d -r - \
  ~/.cursor/cursor-computer-use/Cursor\ Computer\ Use.app

要留意第三行：agent worker debug 只能确认辅助应用是否安装，不能报告权限状态。文档建议实际执行一次打开浏览器并截图的任务，检查截图能否出现在聊天中。这比「命令运行成功」多验证了一层。

授权还受用户身份和代码签名影响。Screen Recording 权限属于批准它的 macOS 用户；macOS 15 及之后的版本可能要求用户定期重新确认。授权跟随应用的代码签名身份，因此不要随意复制、重新签名或重建辅助应用。

团队通过 MDM 管理 Mac 时，也不能把它当成普通配置直接推送。Cursor 没有提供现成的 .mobileconfig。按原文引用的文档，多数 macOS 版本可以静默授予 Accessibility，但 Apple 从 macOS 26.2 开始弃用这种静默允许方式。Screen Recording 则不能通过配置描述文件直接授予。

文档给出的 AllowStandardUserToSetSystemService，作用是让标准用户无需管理员密码便可自行批准，并不是替用户完成授权。

Linux worker 走另一条路径：它操作 X11 显示环境，需要自行安装 xdotool、ffmpeg 和 X11 utilities。供队友观看或接管桌面的 desktop sharing 仅支持 Linux，使用 worker 创建的隔离桌面，并阻止剪贴板传输。这些条件不应套用到 macOS 的本机会话。

我的判断

让 Agent 看见真实界面，再根据结果修代码，这个方向有用。特别是注册流程这样的多步骤交互，代码能编译并不能说明页面可用；实际点击至少可以补充一部分运行时证据。

但作者明确表示，自己没有运行过 Computer Use。文中的使用习惯来自文档整理，没有与人工检查、浏览器自动化或其他测试方案做对照。关于效率和可靠性，目前只能保留判断。

对前端团队而言，Computer Use 更适合作为探索性检查的补充。它可以协助观察页面、尝试流程；需要稳定重复验证的关键行为，仍应考虑写成可复现的自动化测试。原文没有证明桌面点击能替代这类测试，也没有证明它更省时。

我更认同文中的权限处理思路：先缩小可见内容和任务范围，再验证工具是否按预期工作。独立 macOS 用户可以减少个人会话内容进入截图的机会，但这不等于原文已经证明它具备与隔离虚拟机相同的边界。

能拿来做什么

• 首次试用时，把任务限定为「启动 iOS Simulator，打开应用，走完注册流程，并为每个页面截图」。明确路径和交付物，才方便判断 Agent 到底检查到了哪里。
• 在 macOS 上先核对 Cursor Computer Use 的两项权限，再执行真实截图任务。自托管场景中，不要仅凭 agent worker debug 的结果判断授权完成。
• 为 Agent 工作准备独立 macOS 用户，并关闭不愿放进提示词的窗口。任务结束后，可以在 System Settings → Privacy & Security 中取消对应授权，下次使用时重新开启。
• 把点击过程和截图当成代码审查的辅助证据，继续检查 diff。Agent 走通一次流程，不能证明异常输入、其他状态和后续修改都正确。