GitHub 在 2026 年 10 月 1 日的 changelog 中宣布，computer use 已在 GitHub Copilot CLI 和 macOS、Windows 上的 GitHub Copilot 应用中进入公开预览。这意味着 Copilot 不再局限于代码补全或对话，而是可以直接操作桌面应用：读取可访问的应用内容与视觉上下文，点击控件、输入和编辑文本、按键、滚动、拖拽，并在多个应用之间导航工作流。
它到底能做什么
官方给出的能力边界很明确：Copilot 通过 computer-use 工具与桌面应用交互。典型场景包括在 Safari 中走完一个报销流程、在浏览器里汇总通知、更新演示文稿内容，或在桌面应用中把信息从一个环节搬到另一个环节。
真正值得关注的是它覆盖的对象：那些没有 API、没有命令行接口、也没有 MCP 集成的遗留软件和纯 GUI 软件。过去这类软件是自动化的死角，RPA 工具往往需要单独采购和脚本维护，而现在 Copilot 试图用自然语言描述目标来驱动它们。
官方建议的使用方式是：描述你想要的结果、涉及哪些应用、以及重要约束。这实际上把提示词从“写代码”转向了“描述任务意图”，对使用者的表达清晰度提出了新要求。
交互机制与权限模型
从官方描述看，computer use 的交互建立在两条信息通道上：可访问性（Accessibility）接口读取的应用内容，以及屏幕视觉上下文。前者提供结构化控件信息，后者补充界面状态。Copilot 据此决定点击哪里、输入什么。
权限控制是这次发布的核心设计。官方强调“你仍然在控制之中”：Copilot 在控制某个应用前会请求批准；对于你选择“始终允许”的应用，可以复查或重置。在 macOS 上，computer use 还会引导你完成所需的辅助功能与屏幕录制权限。组织管理设置可以禁用该功能。
这套模型意味着三件事：第一，默认不是全自动，而是逐应用授权；第二，授权是可撤销的，不是一次性永久放权；第三，企业可以通过管理策略直接关掉，而不是依赖员工自觉。
如何开启
在 Copilot CLI 中，运行 /computer on 开启，/computer show 查看状态，/computer off 关闭。在 GitHub Copilot 应用中，打开 Settings，选择 Computer Use，开启 Enable Computer Use，也可以使用 /computer on。
安全边界与工程取舍
官方资料没有给出沙箱隔离、操作审计日志、敏感数据过滤等细节，因此这些只能作为工程分析来看待，不能当作已确认事实。
从工程角度，桌面级 Agent 的风险面比代码补全大得多。代码补全的输出停留在编辑器里，而 computer use 的输出会直接作用于真实应用：一封发错的邮件、一次误删的文件、一个被改动的财务记录，都可能无法撤销。因此在实际落地时，建议至少考虑以下边界：
- 授权粒度：优先按应用逐个批准，避免对涉及资金、权限、生产环境的软件使用“始终允许”。
- 任务可逆性：把 computer use 优先用于可回滚、可复核的任务，例如信息汇总、草稿生成、数据搬运，而不是直接提交类操作。
- 人工确认点：在关键步骤前保留人工确认，尤其是跨应用工作流的最后一环。
- 组织策略：企业应明确哪些应用允许被控制，并利用组织管理设置统一禁用高风险场景。
对中国开发者的实际影响
第一，AI 编程工作流正在从“写代码”扩展到“操作环境”。过去开发者用 Copilot 生成函数、补测试；现在它可以帮你走完一个只在 GUI 里存在的内部系统流程。对于需要频繁操作老旧后台、内部管理系统的团队，这可能比代码生成更直接地节省时间。
第二，遗留系统自动化的门槛被拉低。国内不少企业仍有大量无 API 的桌面软件和 Web 后台，传统做法是写 RPA 脚本或人工重复操作。computer use 提供了一种用自然语言描述任务的替代路径，但前提是这些应用能被辅助功能接口识别，且企业允许开启该功能。
第三，权限与合规会成为落地瓶颈。macOS 需要辅助功能与屏幕录制权限，Windows 侧同样涉及系统级控制。在受管设备和企业环境中，IT 策略是否放行、数据是否允许被读取，往往比技术能力本身更决定能否用起来。
第四，提示词能力变成新技能。官方明确说 computer use 在描述结果、应用和约束时效果最好。这意味着开发者需要学会把模糊需求拆成清晰的执行意图，这与传统编程思维不同，更接近给一个远程同事写操作说明。
结论
GitHub Copilot 的 computer use 把 Agent 的战场从编辑器推到了整个桌面。它的价值在于覆盖无 API 的 GUI 软件，它的风险也在于此——操作真实应用意味着真实后果。官方目前提供的是逐应用授权、可复查重置、组织可禁用这套控制框架，但沙箱、审计、数据边界等细节尚未在资料中展开。对开发者而言，合理的起步方式是从可逆、低风险、单应用的任务开始，逐步建立对授权范围和失败模式的直觉，再考虑接入更关键的业务流程。