GitHub Copilot开始操作桌面软件，公测阶段要用户逐次批准

10月1日，GitHub把computer use放进了公开预览，覆盖Copilot CLI与GitHub Copilot桌面应用，平台是macOS与Windows。能力描述得很直白：Copilot可以读取应用里可访问的内容与视觉上下文，点击控件、输入和编辑文本、按键、滚动、拖拽，跨应用走完一整套工作流。这条更新把Copilot能碰的范围从代码编辑器推到了整块屏幕。

官方给出的适用场景是那些没有接口可用的软件。按GitHub的说法，computer use最适合自动化老旧软件和只有图形界面的程序——这类软件不提供API、没有命令行，也没有MCP集成，过去只能靠人来点。举例来说，可以让它汇总浏览器里的通知、更新演示文稿的内容，或者在桌面应用之间搬运数据，走完一段原来是人工的流程。

控制权按官方说明做了几层收口。Copilot在接管某个应用前需要用户逐次批准；用户选择过的“始终允许”应用，之后可以回看或重置这份名单。在macOS上，启用过程会引导用户开启辅助功能与屏幕录制两项系统权限。企业侧还有一道闸门，组织管理的设置可以直接关掉这个功能。启用方式是在CLI里执行开启指令，或在桌面应用设置里打开对应开关。

官方建议的提问方式是把想要的结果、涉及的应用和约束条件一起说清楚。这个提示本身透露了这套能力当前的成熟度：它依赖描述准确性，而不是自己猜。对使用方来说，任务拆得越具体，越接近可复现的自动化；反过来，一句笼统的“帮我处理一下这个表格”，得到的往往是不可预测的一串点击。

需要留意的是边界，而不是宣传口径。公开预览意味着功能可用，但不等于安全评估已经完成；点错窗口、权限给得过宽、屏幕上恰好显示着敏感数据，这些都属于仍待验证的情形。GitHub给出的产品控制是批准机制与组织开关，两者解决的是入口问题，不解决执行过程中的误判。所以更稳妥的用法是先在非生产文件与低权限账号上跑通流程，把密码管理器和客户资料排除在可操作范围之外，同时保留保存、发送、删除、发布这几个动作前的人工确认。

把这条更新放到近一年的变化里看，它和“让智能体操作整台电脑”是同一件事的不同侧面。区别在于GitHub选择从开发者触点多、同时又有明确审批机制的场景切入，先解决可管可控的问题，再谈能力上限。对日常用Copilot写代码的人来说，短期可以关注的是这套权限模型在企业里怎么配，因为它决定了这类功能能不能真正落地。