Computer Use 公开预览：先补的不是 API/MCP，是系统权限

10 月 28 日，GitHub 在 Universe 26 上更新了 GitHub Copilot app 的 changelog：Projects 进入 public preview，Computer Use 在 macOS 和 Windows 上公开预览。如果把这次发布只看成“Copilot 会聊更多需求”，会漏掉一个关键转向：Copilot 开始把工作单元从单仓库 session 挪到跨工具项目，并把手伸向没有 API、CLI 或 MCP 的桌面应用。我的判断是，Computer Use 的权限模型和 Projects 的上下文边界，比新功能本身更影响个人使用和企业合规。

Copilot app 从“会话”到“项目”的变化

官方 changelog 明确说，工作并不总是落在单个仓库或单次会话里：一个功能可能跨多个仓库，一份发布计划可能只包含规格、设计稿和资产，根本不碰仓库。Copilot Projects 在公开预览中把这些工作放进一个项目容器，让上下文、agent 和结果待在一起。你可以启动一个项目，描述目标，加入仓库、设计 mock、Slack 线程或设计会议笔记作为上下文，再为任务选择模型和工具。Copilot 会按需跑多个 agent，最后把结果（例如 pull requests）带回给你审查。同一个 changelog 还提到，聊天里可以用自然语言生成和编辑图像；这是同一个 app 里扩展出来的非代码能力。

这里有一个容易被忽略的细节：官方还提到“对于单仓库内的聚焦任务，你仍然可以直接从那个仓库启动 session”。这说明 Projects 不是要取代单仓库会话，而是补上跨仓库和非代码材料的工作形态。这个边界在官方文档里也是分开叙述的；如果只想处理一个仓库里的 bug，先在 Projects 里建项目反而会多一层上下文管理成本。这层取舍后面会单独列一张表。

单仓库 session 与 Projects 的边界

如果只看官方公告，很容易把 Projects 当成“多仓库版 Copilot”。但把 changelog 里的两句话拼起来，边界会清晰一些：单仓库 session 适合围绕一个仓库的修改和问答；Projects 适合启动时就需要多个来源上下文的工作。下面是按官方描述整理的对比：

这张表是我的整理，不是官方对照表；但每一格都能在 changelog 的 Projects 段或单仓库 session 段找到对应句。需要提醒的是，官方没有给出“多仓库才算 Projects”的数量阈值。如果你的任务跨两个仓库但其中一个只是顺带改一行，仍可用单仓库 session 加手动同步，不必过早迁到 Projects。过早使用 Projects 的代价是，每次都要维护一份项目上下文，而这份上下文里的 Slack 线程和设计稿可能很快就过时。反过来，如果发布计划完全不碰仓库，用单仓库 session 根本无法启动，Projects 才有入口。

Computer Use 的审批与组织开关

Computer Use 在 macOS 和 Windows 上公开预览，允许 Copilot 在桌面应用中完成任务，例如报销单流程。官方给出的能力边界很直白：它可以读取应用内容、点击控件、输入或编辑文本、在应用之间导航，包括那些没有 API、命令行接口或 MCP 集成的应用。这句话其实点出了价值来源：以前只能通过接口触达的工具，现在可以靠屏幕理解和模拟点击覆盖长尾应用。官方没有提 Linux，所以别假设 Linux 也能用；这是按官方描述反推的适用边界。

但代价是权限。官方写明，Copilot 在控制某个应用之前会请求批准；组织也可以通过 managed settings 禁用这个功能。个人用户启用路径是 Settings > Computer Use > Enable Computer Use，macOS 还需要授予 Accessibility 和 Screen Recording 两项权限。也就是说，开启 Computer Use 不只是点一个开关，而是把自己的屏幕内容和辅助功能控制权交给一个 agent。我的经验判断是，企业内部如果想启用，应该先把 managed settings 的默认值确认清楚，否则员工可能在不清楚屏幕录制范围的情况下打开。另一个未说清的成本是审批频率：官方只说控制应用前会请求批准，但没说是一次性批准某个应用，还是每个步骤都要点一次。如果每填一个报销字段都要批一次，它比人工处理更慢；如果一次批准覆盖整个工作流，安全边界又变宽了。这是需要从 computer use 文档里继续核实的点。

为什么 Computer Use 必须放独立 app，而不是 IDE 插件

这一条不是官方说法，而是我根据发布形态做的推导。IDE 插件通常运行在开发者的项目环境里，沙箱、屏幕录制和辅助功能权限都由 IDE 进程管理；而 Computer Use 需要读取系统级屏幕内容、跨应用点击，这类能力必须由一个独立应用直接向操作系统申请 Accessibility 和 Screen Recording 权限，否则权限范围会被 IDE 隔离。官方把它放在 GitHub Copilot app 的 Settings 路径下，而不是 VS Code 扩展设置里，也从侧面印证了这一点。这意味着，即使你在 IDE 里用 Copilot 写代码，和 Copilot 操作桌面应用也是两套权限模型；企业做安全审计时不能只盯着代码仓库权限，还要把桌面 agent 的屏幕录制范围算进去。这个推导可以解释为什么 Computer Use 的组织开关被放在 managed settings 而不是仓库级配置。

同一发布日的 Copilot Fusion：模型调度不是唯一主线

把这次更新和同一天发布的 GitHub Copilot Fusion 放在一起看，能看出两条线。Fusion 做的是模型层面的选择与编排；而 Copilot app 的 Projects 和 Computer Use 做的是任务层面的容器和操作边界。根据同日 JetBrains Universe releases 的摘要，官方提到 Fusion 在前 30 天有 30% 的折扣。这个折扣是摘要里能逐字核到的；我没有打开全文，所以不写它是否也适用于其他 IDE。仅从 changelog 摘要看，模型编排被当成一个需要推广的新入口。

这条跨源对比给我的信号是：Universe 26 这一天，GitHub 同时想把 agent 从“聊代码”推进到“跑工作”。Copilot app 的 computer use 是应用层最激进的尝试，而 Fusion 则是模型层更务实的成本/质量平衡。读者如果只想追一个最有破坏力的变化，我建议先看 Computer Use。但 Fusion 的 30% 折扣会把一部分价格敏感用户先吸引到模型编排一侧，这是官方公告没有并排展示的交叉影响。

一次发布密度复算：31 条更新背后的信号

打开 GitHub Changelog 首页，若只看 2026 年 10 月 28 日，会看到一串密集的 release 和 improvement 条目。我逐条数了一下，当天以 Oct.28 标出的条目共有 31 条，其中包含 Copilot app、Fusion、VS Code、JetBrains、Agentic Workflows、Actions、代码扫描等。作为对比，前一天 10 月 27 日我只数到 1 条。下面这段代码块展示的是可复算的密度计算，数字来自该列表，不是官方统计：

# 可复算的发布密度统计：数字逐条数自 https://github.blog/changelog/ 列表
oct28_entries = 31  # 我逐条数出的 10 月 28 日条目数
oct27_entries = 1   # 10 月 27 日只看到 1 条
print(f"10 月 28 日条目数是 10 月 27 日的 {oct28_entries / oct27_entries:.0f} 倍")

这个 31 倍不是衡量质量的指标，但它说明一件事：如果你在 10 月 28 日之后才看 Copilot 的公告，很容易被单条 changelog 带走注意力，而忽略了整个 Universe 26 发布潮里“应用层接管”的共同转向。我的建议是至少把 Copilot app、Fusion 和 Agentic Workflows 三条放在一起读，而不是只看其中一条。因为如果只读单条，你会分别看到项目、模型编排、工作流自动化，却看不到它们叠加后对工作台边界的影响。

参考来源

• GitHub Copilot app, Universe releases – GitHub Changelog

• GitHub unveils new Copilot tools to advance agent-driven software development

• GitHub Copilot app, Universe releases — GitHub Changelog（一手，官方 changelog）

• GitHub Changelog 首页（一手，官方 changelog 列表，用于统计条目数）

• Projects 文档 — GitHub Docs（一手，官方文档）

• Computer Use 文档 — GitHub Docs（一手，官方文档）

• GitHub Copilot app 产品页（一手，官方产品页）

• GitHub Copilot in JetBrains Universe releases — GitHub Changelog（一手，官方 changelog；本文只使用其摘要中的 30% 折扣原文）

• GitHub Copilot Fusion — GitHub Changelog（一手，官方 changelog）