VS Code 新版聚焦云端代理与模型选择

VS Code 1.144 把 AI 编程的重心，从对话框延伸到了任务如何持续运行、模型如何分工，以及修改如何被检查。原文称，这个版本于 2026 年 10 月 28 日发布，重点是把 Agent 的工作流程接起来。

对前端和全栈开发者，最值得看的是三件事：合上电脑后任务能否继续，复杂任务值不值得调用多个模型，以及少点几次批准之后，自己还看不看得住代码。下面按原文梳理能力与限制；其中的效率收益，作者没有提供实测对照。

任务搬到云端，先解决代码从哪里来

Cloud sessions 让 Copilot 在 GitHub 基础设施提供的托管环境里运行仓库和工具，开发机不必一直在线。任务启动后，可以去 GitHub.com 或 GitHub Mobile 查看进度，再回到 VS Code 继续处理。

云端会话使用独立工作区，本地未提交的修改不会自动跟过去。

假设你刚改完一个组件，又让云端 Agent 根据新接口补测试，它未必拿得到这些修改。原文建议先提交或推送；实际交接时，更关键的是确认目标代码已在云端可访问的仓库版本中。Cloud sessions 还要求付费 Copilot 计划，并受组织策略约束。

Cloud automations 则把一次性任务变成持续触发的流程。这项 Preview 功能同样跑在 GitHub 基础设施上，支持定时执行和仓库事件触发。例如，带指定标签的 issue 分配给你时，自动做初步分诊。它支持限制工具和增加过滤条件，但原文没有展开失败重试、执行时长或资源配额。

远程环境入口也做了整合。新的 Remote Environments 对话框统一展示 GitHub Environments、Dev Tunnels、WSL distributions 和 SSH hosts，可以查看状态、连接或断开，并控制哪些环境出现在选择器中。入口位于 Environment picker 底部的 Manage Remote Environments。它解决的是管理分散的问题，各种环境自身的运行条件仍然存在。

让 Fusion 选模型，还是自己比较结果？

Copilot Fusion 接管了更多调度决策：每次请求使用什么模型、投入多少推理，以及怎样组织执行。简单任务可能只用一个模型；复杂任务则可能由一个模型起草，其他模型审查。

用户可以选择 Standard、High、Max 三档 effort。这里的 effort 更接近愿意投入的处理力度，原文没有给出它与响应时间、正确率之间的定量关系。

计费需要单独看：Fusion 使用的每个模型，都按各自标准费率收费。原文称，付费 Copilot 计划在 2026 年 11 月 30 日之前使用 Fusion 可享 30% 折扣；High 和 Max 面向 Copilot Pro+、Max、Business、Enterprise 计划开放。

多个模型参与，不能直接推导出结果更好，也不能忽略总成本。

Model comparisons 提供了另一条路径：把同一提示交给不同模型及 harness，并排检查结果。harness 可以理解为模型执行任务时使用的工具和运行框架，因此比较结果可能同时受到模型和执行环境的影响。

原文举例，可以让四个模型完成同一项测试编写任务，再比较产出。符合条件的 Agents window 新会话默认启用比较，本次还扩展到无文件夹聊天，以及本地仓库、没有提交记录的空仓库；Dev Containers 暂不支持。

对程序员而言，比较标准最好落在可验收的结果上：测试能否运行，是否覆盖关键分支，有没有改动无关文件。只看回答是否流畅，很难选出适合项目的模型。

少点批准按钮之后，怎样检查它改了什么？

Assisted permissions 已对 Copilot 会话正式可用。它对每次工具调用做基于 LLM 的风险检查，低风险操作自动批准，高风险或无法判断的操作继续询问用户。

这套机制依赖 Folder isolation，也可能受组织限制。管理员禁用后，入口仍可见，但会变灰并展示原因。原文没有提供风险识别准确率，因此不能据此断言它能识别所有危险操作。

Working set 处理的是修改审查。这个 Experimental 功能在 Copilot harness 中汇集 Agent 通过工具产生的编辑，支持对单项修改 Keep、Undo，也可以在聊天输入框上方集中管理。修复涉及多个文件时，开发者可以撤回其中一个文件的修改，保留其余部分。

但它有一个很实际的边界：终端命令产生的编辑不会进入 working set。Agent 如果通过脚本批量改文件，仍要检查 Git diff。相关设置是 chat.editor.workingSet.enabled。

Computer Use 则把操作范围扩大到桌面应用。它目前是 Experimental，只适用于用户自己 macOS 或 Windows 机器上的 Copilot harness 会话。Agent 会请求开启权限，也可以通过 /computer on 开启、/computer off 停止，相关设置为 chat.agentHost.computerUse.enabled。

此外，聊天中的图像生成处于 Preview，使用 GPT Image 2.5 Flare，可生成图标、背景、网站线框图，也能修改附件图片。chat.copilot.imageGeneration.model 设为 off 可关闭，chat.copilot.imageGeneration.watermark 设为 true 可添加可见的「Made with AI」水印。图像生成还会额外消耗 AI credits。

扩展任务上下文的 Copilot connectors 同样处于 Preview：它通过 GitHub 管理的 MCP servers 连接 Slack、Notion、Microsoft Learn 等服务，省去本地服务器配置。Customizations 的新首页 Browse 则展示已配置市场中的插件和技能；Business、Enterprise 用户还需要管理员启用 Editor preview features。

我的判断

这次更新的方向有道理。Agent 开始连续读代码、调用工具、修改文件后，运行位置、模型调度和审查入口都会影响交付。把这些环节接起来，比单纯增加模型选项更接近日常开发需求。

但原文是一篇功能导览，没有展示真实任务记录，也没有给出完成率、耗时、费用或错误率对照。「更少打断、更少猜测」属于作者判断，暂时只能当作经验建议。

Fusion 与手动固定模型相比，省去了调度选择，也增加了费用预估难度；Model comparisons 让结果更容易比较，但开发者仍要承担验收工作。云端自动化适合尝试 issue 分诊这类任务，已有确定规则的检查则可以继续放在 CI 中。原文没有证据说明 Agent 能替代这些稳定流程。

Working set 的价值也很明确：它让部分修改更容易取舍。但终端编辑不在覆盖范围内，因此它还承担不了完整的变更审查。

文章还有两处信息缺口。标题为权限模式比较的段落没有给出完整比较表；chat.canvases.enabled 虽被列为功能入口示例，却没有解释对应能力。都不宜自行补全。

能拿来做什么

• 选一个有明确验收条件的真实任务做 Model comparisons，例如给已有组件补测试，并比较可运行性、边界覆盖和无关修改，再决定日常使用的模型。
• 启动 Cloud sessions 前，确认目标提交已能从远端取得，并写清任务范围与验收命令，避免 Agent 基于旧代码完成工作。
• 如果频繁批准工具调用拖慢了流程，可以在组织允许时试用 Assisted permissions，同时保留 Git diff 审查；使用 working set 时，单独检查终端命令造成的修改。
• 如果维护 VS Code 扩展，可以检查发布链路。原文提到，@vscode/vsce 4.0.2 及以上支持 vsce publish --oidc，可从 GitHub Actions 发布而不在仓库密钥中保存 PAT；Azure DevOps global PATs 将于 2026 年 12 月 1 日退役，Azure Pipelines 用户应关注迁移到 Microsoft Entra ID 与 service connection。