👁 218 次阅读
一、GitHub 为什么突然把 Copilot 变成了『桌面操作员』
2026 年 10 月 1 日，GitHub 在官方 Changelog 发布了一条看起来很安静的更新：Copilot 现在可以在 GitHub Copilot CLI 和 GitHub Copilot app 里『与桌面应用交互』，状态标注为 Public Preview（公开预览）。官方原文是：Copilot can now interact with desktop apps with computer use（《GitHub Changelog 2026-10-01》）。
这条更新在 AI 编码圈子里被大量转发了，但我看完之后第一反应不是『又出一个能点鼠标的大玩具』，而是一句有点反直觉的判断：这是 Copilot 目前为止补上的最实用的一块短板，也是最容易被误判价值的一块能力。
原因在于 GitHub 官方给的理由本身就说明了问题。GitHub 官方文档明确写道：这项能力『expands the tasks Copilot can help automate, including workflows in legacy and GUI-only software that do not provide an API, command-line interface, or MCP integration』（《docs.github.com About computer use》）——它扩展的是 Copilot 能自动化的任务范围，包括那些『没有 API、没有命令行、也没有 MCP 集成』的遗留软件与纯图形界面软件的流程。
请注意这个措辞的分寸。GitHub 没有说『Copilot 现在能取代你的鼠标』，而是把这项能力明确定位在『没有更直接工具可用』的场景。这一点非常关键，也是全文后面反复出现的判断标准。因为对 AI 编码工具来说，真正的进步从来不是多一个演示视频，而是能不能覆盖那些你每天真实卡住的、别人家的旧系统。
二、到底能做什么：GitHub 官方列出的六项能力
把所有营销语言剥掉，GitHub 官方文档里对能力边界的描述非常具体。在启用后，Computer Use 允许 Copilot 做以下事情（《docs.github.com About computer use》原文列举）：
- 通过操作系统的无障碍树（accessibility tree）或截图，读取可访问的应用内容与视觉上下文；
- 点击控件（Click controls）；
- 输入文本（Enter text）；
- 编辑文本（Edit text）；
- 按键、滚动、拖动项目（Press keys, scroll, and drag items）；
- 跨应用导航工作流（Navigate workflows across applications）。
同时文档给了四个官方示例任务：在遗留桌面应用里审查并总结信息、更新演示文稿里的内容、在纯 GUI 软件里录入或更新信息、作为多步流程的一环在应用之间搬运信息（同一文档）。GitHub Changelog 里还放了一张演示图，标题是『Copilot uses computer-use tools to navigate an expense-report workflow in Safari』（《GitHub Changelog 2026-10-01》）——用 Computer Use 在 Safari 里走一遍报销单流程。
这里有一个很容易忽略但非常『工程化』的细节：GitHub 官方文档在开头就放了一个 Tip，明确写着：如果 API、MCP server、终端命令、文件系统工具或专用浏览器工具能直接完成任务，那些工具『typically provides more structured information and predictable results』——通常提供更结构化的信息和更可预测的结果（同一文档）。
换句话说，GitHub 自己把 Computer Use 定位成兜底层，而不是首选层。这不是产品能力不足的托词，而是一条相当诚实的使用边界。因为点击屏幕本质上是把结构化的数据变成了像素去猜，猜对了很快，猜错了一次就要你人工收拾残局。这一点我在第五节会展开说它实际有多麻烦。
三、权限模型：三个档位，以及一个容易被忽视的风险开关
这项能力的默认状态是关闭的。官方文档第一句就是：Computer use is disabled by default（同一文档）。这在新能力发布里算相当克制的做法——不少产品在预览期直接给默认开启。
权限控制有三个档位，且行为被写得很清楚：
| 档位 | 效果 | 持久性 |
|---|---|---|
| Allow | 授权当前会话控制该应用 | 会话结束即失效 |
| Always allow | 永久允许控制该应用 | 本地存储，同时作用于 Copilot app 与 CLI |
| Deny / 规则拒绝 | 拒绝控制 | 优先级最高，覆盖自动与已保存授权 |
表格数据来自 GitHub 官方文档的权限说明：『If you choose Always allow for a specific application, Copilot stores the decision locally. The decision applies to both GitHub Copilot CLI and GitHub Copilot app on the same computer』（同一文档）。
这里最值得停下来想的，是 Always allow 这个开关。GitHub 在风险提示里写得很直接：『If you choose Always allow for an application, later computer-use actions can control it without asking again. Avoid choosing Always allow for applications that contain sensitive information or support high-impact actions』（同一文档）——如果你给某个应用选了 Always allow，之后的 Computer Use 操作可以在不再询问的情况下控制它；官方明确建议不要对包含敏感信息或支持高影响操作的应用选择 Always allow。
注意 GitHub 特意提到『applies to both surfaces』——同一个授权同时覆盖桌面 app 和 CLI。这对效率是好事，但对风险也是放大器：你为了图省事点了一次 Always allow，等于把两个入口的权限一起打开了。
四、上手门槛：两条入口命令，一次权限授权
实际启用路径非常短，这也是它相比很多同类工具更成熟的地方。
# Copilot CLI 里
/computer on # 启用，保存偏好并加载捆绑的 computer-use 插件
/computer show # 查看插件、MCP server 与关联 skills 状态
/computer off # 关闭
# GitHub Copilot app 里
设置 -> Computer Use -> 打开 Enable Computer Use
# 也可以在会话里直接用 /computer on
# 会话中权限模式
/permissions show # 查看当前权限模式以上命令逐条来自 GitHub 官方 CLI 与 app 的使用文档（《docs.github.com Using GitHub Copilot CLI to interact with desktop applications》《Using the GitHub Copilot app to interact with desktop applications》）。
macOS 上还有一个前置步骤需要手动走：授予 Accessibility（无障碍）权限让 Computer Use 能操作控件，以及 Screen Recording（屏幕录制）权限让它在需要视觉上下文时能检查窗口。官方还提供了一个 Check again 按钮——如果权限变更没有被检测到，点它刷新（app 使用文档）。
还有一个细节很多教程不会写：中断方式有两个入口不一样。在 CLI 里是连按 Esc 两次（Esc twice）；在 app 里是点 Stop 或按 Esc。这个差异很小，但在你发现它正在往错误的窗口里点的时候，这个差异会直接影响你能不能及时刹住。
五、官方自己写的局限性：四条你基本都会踩到的坑
这一节是全文我认为最值得看的一段。GitHub 在 Limitations and risks 一节里列的东西相当坦诚（《docs.github.com About computer use》）：
- 界面会随应用版本、操作系统和窗口状态变化。Computer Use 可能点错控件、把文本输错位置，或在非标准控件、动态控件和复杂流程上遇到困难；
- 时序或窗口状态的改变会产生不同结果，可能导致 Computer Use 重复执行动作，或干脆停止继续；
- 模糊的指令或屏幕上出现意外内容，可能引发影响你的设备、数据或所连接账户的非预期操作，包括访问个人、金融或企业系统；
- 应用窗口可能显示敏感信息，包括关于他人的信息——官方建议在把它当作 Copilot 的上下文之前，先确认你愿意提供这些可见内容。
逐条翻译成人话：
第一条和第二条说的是同一个工程事实：屏幕是易变的，DOM 结构不是。你上周能稳定跑通的流程，今天升级了 macOS 小版本、或者目标应用换了个图标位置，它就可能失效。这不是模型不够强，而是把动作建立在像素和控件位置上，本质上就比调用一个稳定的 API 脆弱。GitHub 官方那句 Tip 里说的『可预测的结果』，指的就是这个。
第三条和第四条说的是更现实的隐患：Computer Use 的输入方式决定了它会把屏幕上『看得见的东西』都当成上下文。如果它扫到一个恰好开着的银行页面、聊天窗口、或者包含同事隐私的文档，这些内容就进入了模型上下文。这条风险在别的厂商文档里经常被淡化，GitHub 写得很直白，这一点我认。
所以我的实际使用建议是这样的：把 Computer Use 当成一个高自主度但不高可靠性的执行器。第一次运行必须全程盯屏；只有在你确认某个流程稳定跑过至少三次之后，才考虑给它 Always allow。而且永远不要把它指向金融、身份认证、以及包含他人隐私的界面。
六、横向对比：三家路线，三种取舍
Computer Use 现在已经是主流编码智能体的标配方向，但三家走的是完全不同的路。这一节的对比基于各家官方文档与公开讨论：
| 维度 | GitHub Copilot | Cursor | Anthropic Claude |
|---|---|---|---|
| 形态 | 本地桌面 app + CLI | Self-Hosted Machines 上的 Agent | API / Claude Code 桌面流 |
| 操作系统 | macOS、Windows | macOS、Linux | 多平台 |
| 状态 | Public Preview（2026-10-01） | 显式 opt-in，服务器默认不启用 | 作为 API 能力推出 |
| 前置依赖 | 内置，无需额外装东西 | 需自行安装 Cursor Computer Use 助手 app 并授权 | 需自行搭建环境或走 MCP |
| 授权模型 | Allow / Always allow / Deny 三档 | 按会话或按应用显式授权 | 工具调用审批 |
| 定位 | 面向所有开发者的通用自动化兜底 | 面向自托管团队的可并行批量执行 | 面向开发者自建代理流程 |
数据来源：GitHub 官方 changelog 与文档；Cursor 官方《Computer use and desktop sharing》文档与 Cursor 官方博客《Cursor agents can now control their own computers》；Anthropic Computer Use 能力的公开资料。价格参考 GitHub 官方计划页与 TechRepublic 2026 年 9 月 24 日核查的对比表（GitHub Copilot 与 Cursor 均为免费起步，Pro 分别为 $10/月与 $20/月）。
差异集中在两个地方，值得单独说清楚。
第一，运行位置不同，决定了体验完全不同。Copilot 的 Computer Use 直接跑在你正在用的这台电脑上——这就是它最舒服的地方：不用配置、不用装额外组件、打开就有。Cursor 的 Computer Use 则跑在 Self-Hosted Machines worker 上，官方文档明确要求在 macOS 上自行给一个叫 Cursor Computer Use 的助手 app（bundle id 为 co.anysphere.cursor-computer-use）授予 Accessibility 与 Screen Recording 权限，并且『the worker does not check or request these for you』——worker 不会替你检查或申请这些权限（《cursor.com/docs/cloud-agent/self-hosted/computer-use》）。
第二，成熟度不同，而且差距比宣传大。Cursor 官方论坛里关于桌面 Computer Use 的长期讨论里，团队成员的回复始终是『we are exploring, but I can not share a timeline yet』（我们还在探索，暂时无法给出时间表）；同期有用户实测报告指出 macOS 的 helper 安装包曾出现路径读取失败、黑屏无报错等问题，官方确认部分修复排入后续版本（《forum.cursor.com》相关讨论帖）。相比之下，GitHub 这次直接把 Computer Use 作为内置插件随 Copilot app 和 CLI 一起交付，用 /computer on 一条命令就能开。
这就是我的核心判断：三家能力上限接近，但 GitHub 这次卖的是『零配置』。Cursor 走的是可并行批量执行的重度路线，代价是你得自己搭环境；GitHub 走的是让每个人开箱即用的轻路线。对大多数开发者来说，后者现在就是更值得先试的那个。
七、值得你亲自跑的三步验证清单
Computer Use 属于公开预览阶段，官方标注『in public preview and subject to change』。因为这类能力的评价高度依赖你自己的软件环境，我没有把它当成『已经验证成熟』来写，而是把官方文档里能确认的行为整理成一份可自行复现的清单，你按顺序跑一遍就能得到自己的结论：
- 先关掉它，跑一遍基线。在 CLI 输入 /computer show，确认插件、MCP server 与 skills 的状态；此时让它去操作一个桌面应用，它应当不会执行。这一步确认默认关闭是真实生效的。
- 开一次最小权限的成功路径。用 /computer on 启用，然后给一个只读任务：官方给的示例是『Open APP_NAME and summarize the status information shown in the main window. Do not change any values or submit any forms』（同一文档）——打开某个应用并总结主窗口显示的状态信息，不要修改任何值或提交任何表单。全程盯屏，看它是否能正确读出信息并停手。
- 测一次失败路径，这才是关键。让它做一件涉及点击提交按钮的事，然后在它弹出授权时选择 Always allow，再观察第二次运行时是否跳过询问。同时确认你确实知道怎么中断：CLI 里连按 Esc 两次，app 里点 Stop。如果这两步任何一个感觉不放心，就直接不要把 Always allow 用在含敏感信息的程序上。
三步都跑完，你就能得到比任何评测都可靠的答案：它在你自己的软件栈里到底稳不稳。这类能力的『可用』不是绝对值，而是一个跟你的软件版本强绑定的相对值。
八、定价与信用额度：这项能力有没有额外的账单？
这是我最想给读者讲清楚、但也必须最谨慎的一段，因为 GitHub 官方文档目前并没有给出 Computer Use 单独的计费条目。
我能从官方计划页确认的是 Copilot 的整体计费结构（《docs.github.com Plans for GitHub Copilot》）：个人档 Copilot Pro $10/月（含 1,000 基础 + 500 弹性，共 1,500 GitHub AI Credits）、Pro+ $39/月（3,900 + 3,100，共 7,000）、Max $100/月（10,000 + 10,000，共 20,000）；组织档 Business $19/席位/月（1,900 credits/人/月）、Enterprise $39/席位/月（3,900 credits/人/月）。超额按每 1 AI credit $0.01 计费。官方同时写明：Code completions 和 next edit suggestions 不消耗 AI credits，所有付费计划不限量。
关于 Computer Use 本身，文档只提到一个约束条件：如果组织通过 managed settings 关闭了它，本地偏好无法覆盖该策略（CLI 文档）。除此之外，官方目前没有公布 Computer Use 的独立额度消耗规则。
所以我不打算编一个数字出来。诚实的结论是：这项能力是否会显著吃掉你的月度 credits，目前需要在自己的环境里实测。一个粗略的方向性判断是——因为它依赖截图与多轮工具调用，token 消耗很可能高于纯文本补全，这也正是 Cursor 社区用户抱怨第三方 Computer Use MCP 时说的『very slow and tokens extremely inefficient』（非常慢，token 消耗极其低效）所指的那一类问题（《forum.cursor.com》相关讨论帖）。但 Copilot 的内置实现是否同样重，我目前没有可引用的官方数据。
如果你已经在用 Copilot Pro+ 或 Max，可以先跑一次上面的三步清单，同时观察后台的 AI Credits 消耗变化，这样得到的结论才对你的钱包有意义。
九、结论：这是 Copilot 最实用的一次补位，不是又一次演示
把整篇文章的判断压成几句话：
一，这项能力的定位极其清晰，也极其诚实。GitHub 自己就写了：能用 API、MCP、终端命令或浏览器工具直接干的事，那些工具通常更结构化、更可控。Computer Use 是给『没有更直接工具可用』的场景兜底的，不是来取代它们的。这个定位比很多竞品宣传里含糊其辞的『全自动办公』要健康得多。
二，它真正解决的问题是遗留系统与纯 GUI 软件的最后一公里。官方举的例子是 Safari 里的报销单流程、更新演示文稿、在纯 GUI 软件里录入信息。这些恰恰是过去所有编码智能体的公共盲区——它们能读代码、能跑终端，但一碰到没有 API 的旧客户端就停了。这块盲区一旦被补上，Copilot 的自动化半径会明显变大。
三，代价是可靠性与隐私成本。屏幕是会变的，控件会点错、会重复动作、会半路停下；同时它会把屏上可见的一切都吃进上下文。官方把这四条都写在文档里，没有藏着。我的建议是：先只读、后写入，先盯屏、后放权，Always allow 只留给不含敏感信息、动作影响可逆的程序。
四，横向来看，GitHub 这次最大的优势是零配置。三家能力上限接近，Cursor 走自托管重路线、环境搭建门槛明显更高且部分组件仍在修复；GitHub 直接内置随 app 与 CLI 交付，/computer on 一条命令开启。对大多数开发者，现在先试 Copilot 的版本是合理选择。
需要说清楚的是：这项能力仍是 Public Preview，官方明确标注 subject to change。以上所有判断基于 GitHub 官方文档、官方 Changelog 与公开社区讨论整理而成，不构成对其预览版稳定性的背书。等它 GA 之后，值得再做一次复评——尤其是那个至今没有公开数字的部分：它的真实 credits 消耗到底有多少。
资料来源
- GitHub Changelog《GitHub Copilot can now interact with desktop apps with computer use》2026-10-01：https://github.blog/changelog/2026-10-01-github-copilot-can-now-interact-with-desktop-apps/
- GitHub Docs《About computer use in GitHub Copilot》：https://docs.github.com/en/copilot/concepts/agents/computer-use
- GitHub Docs《Using the GitHub Copilot app to interact with desktop applications》：https://docs.github.com/en/copilot/how-tos/github-copilot-app/computer-use
- GitHub Docs《Using GitHub Copilot CLI to interact with desktop applications》：https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/computer-use
- GitHub Docs《Plans for GitHub Copilot》：https://docs.github.com/en/copilot/get-started/plans
- Cursor Docs《Computer use and desktop sharing》：https://cursor.com/docs/cloud-agent/self-hosted/computer-use
- Cursor Blog《Cursor agents can now control their own computers》：https://cursor.com/blog/agent-computer-use
- Cursor Forum 桌面 Computer Use 相关讨论与实测报告：https://forum.cursor.com/t/desktop-computer-use-let-the-agent-control-local-gui-apps-adobe-office-browsers/166034
- TechRepublic《5 Best Claude Code Alternatives for 2026》价格核查（2026-09-24）：https://www.techrepublic.com/article/news-best-claude-code-alternatives-2026
说明：本文所有能力描述、权限机制与定价数据均来自上述官方文档与 Changelog。文中关于 Cursor 实现细节与成熟度的部分来自其官方文档与官方论坛公开讨论。Computer Use 目前处于公开预览阶段，官方标注 subject to change；文中对其真实 credits 消耗未给出具体数字，因官方文档未公布该计费条目。