编码助手过去几年很擅长在开发者给的边界里干活：源文件、终端、仓库、拉取请求、API，这些结构化工具它用得很好。但这个边界 10 月 1 日被拓宽了——GitHub 把计算机使用（computer use）放进 GitHub Copilot 的公开预览，覆盖 Copilot CLI 与 macOS、Windows 上的 Copilot 应用。它让 Copilot 能读取应用里可访问的内容与可视画面，点控件、输文字、按键、滚动、拖拽，并在多个桌面应用之间串起工作流。真正有意思的不是「它能点按钮」，而是「这个按钮不必属于为 AI 设计的软件」。
自动化面从 API 边界扩到 GUI 边界
对开发者、IT 与企业自动化团队，这件事的意义在目标软件上。GitHub 明确点名，它面向的是没有 API、没有命令行、也没有 MCP 接口的遗留软件与纯图形界面软件。现实里大量业务系统从没为自动化设计过：有些有不错的 API，有些有命令行，而有些只剩下一扇窗、一堆控件。对最后这类，传统编码 agent 往往束手无策，除非底下恰好有接口可调用。计算机使用提供的是另一条路：按人看到并操作的界面去交互。它未必让每个老程序突然好自动化，但它确实把可自动化的面积变大了——软件不必先变成「agent 就绪」才能被操作。
本地桌面自动化，默认关、企业可一刀切禁
这件事的另一面是信任面。GitHub 把计算机使用默认关闭，用户必须显式开启，Copilot 才会动用计算机使用工具。需要视觉上下文时，macOS 上要无障碍权限与屏幕录制权限，Windows 上则跟随 Copilot 自身的应用与工具权限模型。审批时，用户可以对本次会话允许、选择总是允许，也可以拒绝或取消。对企业，还有一个更硬的开关：features.computerUse 这一项设置可以让组织直接禁止该能力，治理粒度到组织层级。换句话说，能力给到个人，闸门留在管理员手里。
GUI 老程序被打开，但代价是新的信任面
计算机使用把 agent 的触手伸向了 GUI 边界，但代价也明确：它要的不再是一次 API 调用，而是对屏幕与无障碍接口的实际访问。让一个 agent 看屏幕、点控件，和在对话框里要几行代码，是两种量级的风险。GitHub 用「默认关闭加显式授权加企业开关」来兜底，方向是对的，但真正落地时，企业仍要把它当成一个新的权限面来审：哪些应用允许被操作、操作到什么程度、截图与上下文的去向如何。这与本站此前看过的把工具调用可靠性做成 harness 一等公民的思路并不冲突，而是补上了「没有接口的老软件」这一块——过去 harness 管的是 API 世界，现在要把窗口世界也纳入边界。
它处在「agent 从理解软件到操作软件」的转折上
从「能读懂软件」到「能操作人用来跑软件的界面」，这一步比又多一个 Copilot 功能更值得记一笔。它让编码 agent 头一次对那一大层「没接口的老系统」有了路径，对依赖内部工具、遗留桌面应用的企业尤其现实。但同时，它也把权限与审批的复杂度从接口层搬到了界面层。对正在评估的团队，一个务实的起点是：先列出那些「只有 GUI、没有 API」的高频流程，再把计算机使用限定在最小必要范围，用企业开关把风险关进笼子里。
一句话：当编码 agent 开始点开纯图形界面的老程序，自动化的边界就不再是「软件有没有接口」，而是「你愿不愿让它坐到那台电脑前」。