GitHub Copilot 现已可通过 computer use 操作桌面应用

计算机使用（computer use）现已在 GitHub Copilot CLI 以及 macOS 和 Windows 上的 GitHub Copilot 应用中进入公开预览。Copilot 可以代替你与桌面应用程序交互（例如读取可访问的应用内容和视觉上下文、点击控件、输入和编辑文本、按键、滚动、拖拽，以及跨应用导航工作流程）。这扩展了 Copilot 可以帮助自动化的任务，包括那些不提供 API、命令行界面或 MCP 集成的老旧软件和纯 GUI 软件中的工作流程。Copilot 使用 computer-use 工具在 Safari 中完成一个报销流程。控制权仍在你手中。Copilot 在控制某个应用前会请求批准，你可以查看或重置你选择“始终允许”的应用。在 macOS 上，computer use 还会引导你完成所需的辅助功能与屏幕录制权限。组织管理的设置可以禁用该功能。在 Copilot CLI 中，运行 /computer on。使用 /computer show 查看其状态，使用 /computer off 将其禁用。在 GitHub Copilot 应用中，打开 Settings，选择 Computer Use，然后打开 Enable Computer Use。你也可以使用 /computer on。当你描述你想要的结果、涉及的应用以及任何重要约束时，computer use 的效果最好。例如，你可以让 Copilot 汇总浏览器中的通知、更新演示文稿中的内容，或在桌面应用程序中把信息沿某个工作流程传递。进一步了解 GitHub Copilot CLI 和 GitHub Copilot 应用中的 computer use。

GitHub Copilot 在 CLI 与 macOS/Windows 桌面应用中开放 computer use 公开预览，可代为读取界面内容并执行点击、输入、滚动、拖拽等操作，跨应用完成流程，重点覆盖没有 API、命令行或 MCP 集成的老旧与纯 GUI 软件；控制权仍归用户，操作前需批准，组织可统一禁用。

• GitHub Copilot 在 CLI 与 macOS/Windows 桌面应用中开放 computer use 公开预览，可代为读取界面内容并执行点击、输入、滚动、拖拽等操作，跨应用完成流程，重点覆盖没有 API、命令行或 MCP 集成的老旧与纯 GUI 软件；控制权仍归用户，操作前需批准，组织可统一禁用。
• 原贴提到：Computer use is now available in public preview in GitHub Copilot CLI an
• 来源：github.blog

这是什么信号

GitHub Copilot 把 computer use 推向公开预览，且在 Copilot CLI 与 macOS/Windows 的 Copilot 应用两条入口同时上线。能力上，它不只是“给建议”，而是直接操作桌面界面：读取可访问的应用内容与视觉上下文、点击控件、输入和编辑文本、按键、滚动、拖拽，并跨应用串联工作流程。

更关键的信号是官方对适用场景的表述：明确指向那些“没有 API、没有命令行界面、没有 MCP 集成”的老旧软件与纯 GUI 软件。这等于宣布，AI 自动化的边界不再由接口决定，而由界面是否可见、可控决定。

为什么重要

第一，覆盖面的问题被重新定义。过去 agent 能做什么，取决于系统有没有开放接口；没接口的软件就是自动化盲区。computer use 把这块盲区纳入了可操作范围，官方举的例子就是在 Safari 里走一遍报销流程——这类工作恰恰是接口化程度最低、人力消耗最稳定的部分。

第二，分发成本低。CLI 和桌面应用都是开发者已经在用的入口，能力升级不需要用户换工具、换习惯。

第三，权限设计透露出厂商对风险的判断：控制应用前必须请求批准，用户可以查看或重置“始终允许”的清单，macOS 上还会引导授予辅助功能与屏幕录制权限，组织管理策略可以整体禁用。这四项合在一起，说明它被定位成“需要被管起来的能力”，而不是默认可用的便利功能。

对谁有价值

• 内部工具链老旧、日常操作依赖 GUI-only 系统的研发与 IT 团队；
• 需要跨应用搬运信息的运营、财务、行政流程负责人，这类流程往往卡在浏览器与桌面软件之间；
• 正在评估 AI agent 落地边界、要给团队划授权红线的技术与合规管理者；
• 想验证“描述目标即可完成跨软件操作”这一交互范式是否成立的产品与效率工具从业者。

可以怎么行动

• 先挑一条低风险、高频、必须走 GUI 的流程试点，例如汇总浏览器中的通知、更新演示文稿内容、在桌面应用之间传递信息，把成功率与需要人工接手的环节记下来。
• 打开方式：Copilot CLI 里执行 /computer on，用 /computer show 看状态，用 /computer off 关闭；GitHub Copilot 应用里进入 Settings → Computer Use → 打开 Enable Computer Use，也可以直接用 /computer on。
• 下指令时把三件事说清楚：想要的结果、涉及哪些应用、有什么约束。约束写得越具体，越容易观察它在哪一步会走偏。
• 先个人范围验证，再讨论由组织统一放开哪些应用；如果要扩面，优先建立白名单与复核节奏，而不是一次性全量开放。

风险或限制

• 目前是公开预览，稳定性和复杂流程的成功率需要用真实任务实测，不宜按通用可用的成熟度做长期依赖。
• 它需要较高权限（辅助功能、屏幕录制），意味着界面上的敏感信息可能被“看到”，处理涉密或含个人数据的流程前要先做数据边界评估。
• “始终允许”的授权是便利也是隐患，建议定期复核并重置清单，避免权限随时间无声扩散。
• 组织管理设置可以整体禁用该功能，说明在部分合规环境里它未必默认可开，落地前需确认内部策略。
• 原文未提及定价与正式可用时间，规划时不要按已全面商用的前提安排依赖。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《GitHub Copilot 现已可通过 computer use 操作桌面应用》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖