VS Code Copilot 扩展模型与智能体选择

GitHub Copilot 这次 Universe 更新，把重点放在了编码任务的连续性上：同一个会话可以跨客户端接着用，代理可以在云端、本机或远程机器执行，用户也能随时接手。模型选择只是其中一环。

对前端和全栈开发者，更有用的问题是：关掉编辑器后任务还跑不跑，手机能控制哪台机器，多模型结果怎么比较，以及团队配置到底能不能强制执行。这份更新给出了操作入口，但没有提供效率提升的实测数据。

关掉 VS Code 后，代理到底在哪里继续工作

先分清客户端和执行机器。手机、VS Code、网页是查看和控制任务的入口；代码在哪执行，取决于会话连接的环境。

云端会话运行在 GitHub 基础设施上。用户可以从 VS Code 的 Agents 窗口启动任务，关掉笔记本后继续执行，再从 GitHub Copilot app、GitHub Mobile、github.com 或 Copilot CLI 找回同一个会话。从 Slack 或 Microsoft Teams 私信启动的会话，也能在这些客户端继续。

本机采用新的 Agent Host，把 Copilot 会话与单个 VS Code 窗口分开。关闭项目文件夹或窗口，后台任务仍可继续。不过，这不等于电脑关机后还能运行。

远程执行则通过 Remote SSH 或 dev tunnels 接入另一台机器。代理使用远端的代码、工具和依赖，本地断开连接或退出 VS Code 后，远端仍能工作，前提是远程机器及其 Agent Host 保持运行。

手机也能控制开发机上的代理。在项目目录执行 code agent host --github-environment，随后通过 GitHub Mobile 查看进度、补充指令或发起任务。手机负责控制，开发机负责执行，同样需要保持机器和 Agent Host 运行。

跨端继续的是同一个会话，任务能否持续执行仍取决于它所在的机器。

编辑器和 Agents 窗口也会同步同一个实时会话，切换视图无需重新开始。

多模型对比和桌面操作，分别解决什么问题

这次更新还统一了部分执行基础。基于 Microsoft Copilot SDK 的 Copilot harness，已成为编辑器和 Agents 窗口中新会话的默认选项。

Harness 可以理解为组织模型调用、工具执行和会话流程的运行框架。统一这层框架，是为了让 VS Code、Copilot CLI 和 GitHub Copilot app 的代理行为更一致；原文没有给出一致性测试结果，也不能据此认定不同模型会产生相同答案。

对于同一道编码题，Agents 窗口支持并行运行不同模型和 harness，再把结果放在一起审阅。用户可以请 Judge model 推荐方案，也可以选择 Synthesize，组合其他尝试中的思路。这项能力处于预览阶段。

它提供了比较方案的工作台，但 Judge 的推荐仍然需要验证。原文没有交代评判标准、额外调用成本，也没有证明综合后的实现优于单个方案。

另一个扩展是 computer use：代理可以读取和操作桌面应用，包括点击控件和编辑文字。在 macOS 或 Windows 上，先在 VS Code Settings 启用 chat.agentHost.computerUse.enabled，重启 VS Code，再在本机运行的 Copilot 会话中执行 /computer on。

每个应用都需要用户批准。它与 Copilot CLI、GitHub Copilot app 共用设置，macOS 所需系统权限只需授予一次，组织也能通过策略禁用。这仍是实验功能，不能仅凭公告推断其操作可靠性。

终端入口也在简化：Windows 可通过 VS Code 安装器安装 GitHub Copilot CLI，macOS 可在将 VS Code 加入 PATH 时安装，Linux 则按原文所述运行 copilot。公告没有展开 Linux 的具体安装交互。

自定义入口集中后，配置和管控仍是两回事

Agents 窗口侧栏新增 Customizations 入口，也可以运行 Chat: Open Customizations。其中 Browse 页面集中展示 skills、MCP servers、plugins 等定制项。

Customization Marketplace 处于预览阶段，默认开启；Business 和 Enterprise 管理员需要允许 Editor preview features。

连接外部服务则有另一条路径：Copilot connectors。它可以把 Slack、Notion、Microsoft Learn 等服务的上下文带入会话，无需用户安装或管理 MCP server。从 Browse 连接一次后，同一账号可在受支持的 Copilot 客户端复用。

Connectors 同样处于预览阶段，适用于所有 Copilot 套餐，并与 Copilot harness 配合工作。Business 和 Enterprise 仍需管理员允许 Editor preview features。原文没有说明各服务能读取哪些内容，不能把「连接成功」理解为拥有全部数据访问权。

团队管理方面，管理员可以通过策略要求或禁止指定插件、添加 marketplace，以及限制安装来源。企业严格 marketplace 设置还能关闭内置市场，策略管理的开关会锁定在 Customize > Plugins。

仓库中的 .github/copilot/settings.json 可以登记插件市场、启用默认插件，但贡献者仍能关闭它们，除非企业策略另有要求。

仓库配置提供默认值，强制约束要靠管理策略。

开发者还可以自建客户端：运行 code agent host，通过开放的 Agent Host Protocol（AHP）连接同一个 Agent Host。客户端库支持 TypeScript、Rust、Go、Kotlin 和 Swift，并支持实时同步与重连后补齐更新。对 Node 或 TypeScript 开发者，这是接入已有会话的接口，但公告没有展开鉴权、部署和协议兼容细节。

我的判断

这批更新最有价值的地方，是把会话、客户端和执行环境的关系讲得更明确。相较于一直守着编辑器，云端或远程执行更适合需要等待的编码任务；代价是必须确认代码、依赖和工具实际位于哪个环境。

但这是一份功能公告，没有作者实验，也没有团队前后对照数据。跨端连续、框架统一、多模型评审都有合理用途，是否更快、更省钱或更准确，原文都没有证明。

我会优先采用会话连续性和执行环境选择，把多模型对比用于少数存在明显取舍的任务。Computer use 的适用面更宽，但仍是实验功能；能用稳定命令或脚本完成的步骤，暂时没有必要仅因新入口出现就改成桌面点击。

能拿来做什么

• 给前端或 Node 项目发起长任务前，先确认执行位置。需要关机离开就选择云端；需要远端工具链就连接远程机器，并保持其 Agent Host 运行。
• 比较两种实现方案时，可以在 Agents 窗口并行尝试，再结合项目测试和代码审阅选择结果；把 Judge 和 Synthesize 的输出作为参考。
• 团队可以用 .github/copilot/settings.json 提供插件默认配置。涉及必装插件或安装来源限制时，应交给管理员策略执行。
• 自建 TypeScript 工作台时，可以评估 AHP 及其客户端库，重点验证会话同步、断线恢复和鉴权是否满足项目需求。