VS Code 1.142 把 agent 协作搬上看板：Canvases 预览、会走动的聊天与更严的企业管控

先说结论：编辑器正在从“写代码的地方”变成“管 agent 的地方”

微软在 2026 年 10 月 14 日把 Visual Studio Code 1.142 推上稳定通道。这次更新的 headline 不是某个代码补全更准了，也不是界面换了个颜色，而是三个相互咬合的变化：第一，Canvases 预览——agent 与人可以在同一块交互界面上协作，而不是只能在聊天框里你一句我一句；第二，聊天可以“搬家”——一段对话可以从一个文件夹搬到另一个文件夹、甚至搬进新的 Git worktree，而不丢失历史；第三，企业管控收紧——agent 宿主（Agent Host）的权限策略更细了，同时 Windows 沙箱集成被退休，沙箱化的命令执行要走 Agent Host 会话。单看任何一条都像常规更新，合起来看，方向很清楚：VS Code 正在把自己定位成 agent 的工作台和管控台，而不是一个装了 AI 插件的文本编辑器。

先划一条界，避免和另一篇已发文章混淆：站内此前发过 Cursor 云端 agent 的 Canvas——那是 Cursor 的云端 agent 跑完任务后生成的可分享画布，重点在“交作业”。VS Code 1.142 的 Canvases 完全是另一回事：它是本地编辑器里、聊天旁边的一块双向交互界面，重点在“一起干活”。名字撞了，产品逻辑不一样：一个是跑完之后的成果展示，一个是进行中的协作平面。读到“Canvas”就默认是同一个东西，会误判这次更新的真正分量。

Canvases 到底是什么：不是看板插件，是一块双向协作面

按微软发布说明的原话，Canvases 是“与 agent 协作的交互界面”（interactive interfaces to collaborate with an agent）：画布在聊天旁边打开，你和 agent 检查、更新的是同一件东西，而不是各自维护一份计划、再靠聊天对齐。官方给的例子是一块看板：你可以自己创建卡片、移动卡片，agent 可以把一个功能拆成任务、更新卡片状态、补上它在过程中新发现的工作。双方改的是同一块板，而不是你改你的、它改它的，最后再花时间合并。

关键在“双向”两个字。过去 agent 的工作方式是单向输出：它改代码、写总结，你在旁边看，然后在聊天里再提修改意见。Canvases 把这个过程变成双向操作：界面本身就是共享状态，你动一下、它动一下，状态实时同步。这对 vibe 项目的实际意义在于任务管理这块最磨人的部分——计划永远滞后于实际进展。以前的做法是：agent 说“已完成三项”，你打开文件一看，发现它说的三项和你理解的三项不是同一批，还得在聊天里逐项对齐。有了共享画布，对齐的载体从“聊天记录”变成“同一块板上的卡片状态”，争议会少很多——卡片在哪个列，比聊天记录里哪句话说了什么，更容易核对。

还有两个实现细节值得注意。第一，Canvases 目前是预览功能，只在桌面版 VS Code、本地会话、使用 Copilot 宿主（Copilot harness）的条件下可用，开启方式是 chat.canvases.enabled 这个设置——也就是说它还不是默认全开，需要你手动打开。第二，每块画布都由一个画布扩展（canvas extension）提供，你可以用 /create-canvas 命令自己做一块，也可以通过 GitHub Copilot 应用安装带画布的聊天插件，Awesome Copilot 社区里已经有示例扩展。换句话说，Canvases 现在更像一个“协作界面的平台”，而不是微软只给你一块看板：看板只是第一个例子，问题分流板、发布检查清单、仪表盘、文档工作区都是官方文档里提到的可能形态。判断它有没有用，不能只看第一块看板，要看你的团队愿不愿意为自己的流程做一块画布。

会走动的聊天：从“换个文件夹就重开”到“带着历史搬家”

第二个变化听起来小，实际用起来会很频繁：聊天会话现在可以移动到另一个文件夹或新的 Git worktree，而不丢失历史。以前的流程是：你在一个文件夹里和 agent 讨论一个问题，讨论到一半发现应该在 worktree 里动手实现——那就得新开一段对话，把上下文重新讲一遍。1.142 之后，你可以在 Agents 窗口里直接让 agent 把当前聊天搬过去，历史保留。官方示例的指令就是一句大白话：“在动手实现之前，先把这个任务搬到当前仓库的一个新 Git worktree 里继续。”

为什么这件事值得单独拿出来说？因为它解决的是 agent 工作流里一个真实存在的断点：讨论和动手发生在不同地方。很多 vibe 项目的开发节奏就是“先在主分支上讨论、再开分支动手”，或者“先在一个实验文件夹里验证、再搬到正式项目里落地”。以前每次跨越这个断点都要重建上下文——而重建上下文恰恰是 agent 最容易丢信息、最容易 hallucinate 的环节。聊天能搬家，等于把“讨论上下文”从一次性消耗品变成了可以带走的资产。对独立开发者来说，这意味着你可以更放心地用“先讨论后动手”的节奏：讨论不必为了“怕丢上下文”而急着动手，动手也不必为了“保留上下文”而挤在讨论的文件夹里。

配合聊天搬家一起看的，还有 Agents 窗口的会话管理改进和模型选择器的重新设计。新版模型选择器把 Copilot 模型和自带模型（BYOK）分到不同的标签页，还可以按模型调整思考级别和上下文窗口。表面上看是界面整理，实际上是在为“多模型、多会话并行”的工作方式铺路：当你的编辑器里同时跑着好几段 agent 会话、每段用的模型还不一样时，你需要一眼看清“这段对话用的是哪个模型、哪个宿主”——新版聊天标题里直接显示当前宿主（Copilot 或 Codex），就是为了解决这个“我到底在和谁说话”的困惑。

企业管控收紧：权限可以“允许辅助、禁止全放行”

第三个变化是给企业管理员的，也是最容易被个人用户跳过、却最能说明方向的一条。1.142 的 Copilot agent host 策略允许更细粒度的权限配置：一个被多次提到的例子是，管理员可以允许“Assisted”（辅助）级别的操作，同时禁止“Allow All”（全部放行）——让开发者能获得审批流程带来的便利，又不至于绕过检查。换句话说，权限不再是“开”或“关”两个档位，而是可以按操作级别切分的连续谱。这对企业的意义是：agent 的自主权可以按团队、按项目、按风险级别逐步放开，而不是在“完全不用”和“完全放开”之间二选一。

同一批变化里还有一条退休消息：Windows 沙箱集成被弃用。微软的理由是，Windows 沙箱原本是为隔离“不熟悉的可执行文件”设计的，不是为治理“对代码库有广泛访问权的自主 agent”设计的；取而代之的是基于策略的管控——直接限定 agent 能做什么，而不是把它关进一个虚拟机里。实际影响是：Windows 用户如果之前依赖 Windows 沙箱来隔离本地 agent 会话，现在要转到 Agent Host 会话里做沙箱化的命令执行。方向和 Canvases、聊天搬家是一致的：所有的 agent 活动都在向 Agent Host 这个统一的运行时收敛，而不是散落在各个窗口、各个沙箱、各个扩展里。

对个人开发者来说，企业管控听起来像是“和我无关”，但这里有一个值得借鉴的思路：给 agent 的权限分级。很多 vibe 项目出问题，不是因为 agent 太弱，而是因为一开始就给了它“全部放行”——能读所有文件、能跑所有命令、能上网、能改配置，然后某一次误操作就把局面搞砸。1.142 的企业策略其实可以翻译成个人版的做法：日常任务只给 agent 最小必要的权限，需要动敏感操作时再临时放开、事后收回；把“Allow All”当成需要理由的例外，而不是默认状态。企业用策略文件实现这一点，个人可以用习惯和检查清单实现这一点，原理是同一个。

其他值得注意的变化：Markdown、Python 与后台壳

1.142 还有几处不那么 headline、但日常会碰到的改进。Markdown 编辑器得到了加强，包括大纲与面包屑导航的集成、代码块悬停时出现复制按钮——对经常用 Markdown 写文档、写 agent 指令文件的人来说，这些都是每天省几秒的小改进，积少成多。Python 方面，Python Environments 扩展修复了环境发现、解释器选择和终端激活的问题，对 uv 管理的安装也有改进。Copilot 会话里新增了“后台壳”（Background Shells）指示：正在运行的命令会列出来，还可以单独停止其中一个，而不是只能全部停掉。这些改进的共同点是“让长时间运行的 agent 会话更可观察”：你在和 agent 一起工作时，需要随时知道它在后台跑了什么、能不能单独停掉某一个，而不是只能看到最终结果。

把这些小改进和三个大变化放在一起，1.142 的画像就完整了：微软不是在给编辑器加功能，而是在给“编辑器里的 agent 生活”补基础设施——协作面（Canvases）、会话连续性（聊天搬家）、管控（Agent Host 策略）、可观察性（后台壳、会话标题里的宿主标识）。基础设施的特点是：单独看每一条都不刺激，合起来决定了你每天和 agent 一起工作时顺不顺。对于还在犹豫要不要升级的人来说，判断标准不应该是“有没有哪个功能让我眼前一亮”，而是“我的日常工作流里有没有被这些基础设施卡住的地方”——如果有，升级的收益是每天的；如果没有，等下一个版本也完全没问题。

判断：谁应该立刻升级，谁可以等等

立刻升级的三类人：第一，经常在多个文件夹、多个 worktree 之间切换的人——聊天搬家直接省掉你每次重建上下文的时间；第二，团队里已经在用 Copilot agent、并且需要向管理层交代“agent 能碰什么、不能碰什么”的人——Agent Host 策略给了你一个可以写进内部规范的抓手；第三，对 Canvases 这个方向感兴趣、愿意动手做一块自己流程的画布的人——预览阶段进入，等于提前占了一个生态位，等它默认全开时你已经知道怎么用。

可以等等的两类人：第一，工作流完全在单个文件夹、单个模型里跑、且对现状满意的人——1.142 的基础设施对你来说是“以后会用上”，不是“现在缺了不行”；第二，Windows 上重度依赖 Windows 沙箱隔离 agent 会话的人——先确认你的 Agent Host 会话迁移路径走通了再升级，避免升级当天发现隔离方式变了、手忙脚乱。无论哪类人，升级前都建议做一件小事：把当前正在跑的 agent 会话先收尾或记录下来，因为编辑器大版本升级和 agent 会话的连续性之间，永远存在“升级后会话状态会不会变”的不确定性——先收尾，再升级，是最便宜的保险。

最后说一句关于方向的判断。VS Code 从 1.135（8 月 26 日）到 1.141（10 月 7 日）再到 1.142（10 月 14 日）的节奏，本身就是信号：编辑器正在以接近每月的速度、Insiders 通道甚至每周的速度，往“agent 优先的工作区”演进。竞争对手 Cursor、Windsurf、Zed、JetBrains AI Assistant 各有各的打法，但 VS Code 的打法很明确——不和你比谁的模型更聪明，而是比谁的 agent 基础设施更完整：协作面、会话、权限、可观察性，一样一样补齐。对 vibe 项目的作者来说，这意味着一个选择：你是继续把 VS Code 当成“写代码的地方，顺便有个 AI 聊天”，还是开始把它当成“管 agent 的地方，代码只是 agent 产出的东西之一”。1.142 没有强迫你选，但它把第二种用法的路铺得更平了。

Canvases 的局限：预览阶段，先别把它当成生产力承诺

说了这么多好处，也要把局限说清楚，否则这篇就成了发布说明的复读。第一，Canvases 现在是预览功能，只在桌面版、本地会话、Copilot 宿主条件下可用——远程会话、网页版、其他宿主的用户目前还用不上，团队里如果有人用远程开发、有人用本地开发，协作面就不是所有人都能打开的同一块板，推广时要先确认覆盖范围。第二，画布依赖扩展生态：第一块看板只是示例，你真正需要的“问题分流板”“发布检查清单”要么自己用 /create-canvas 做，要么等社区扩展——做一块好用的画布本身就是一份工作，不是打开开关就自动得到的。第三，共享状态不等于共享理解：agent 在画布上移动一张卡片，不代表它理解了这张卡片背后的业务含义；卡片状态对齐了，代码实现仍可能跑偏，画布不能替代代码审查和测试——它替代的只是“计划对齐”这个环节，不是“质量验证”这个环节。

给想试用的人一份最小清单：第一步，打开 chat.canvases.enabled，先用官方示例看板跑一个真实的小任务——比如把一个功能的拆分、执行、验收全过程放在画布上走一遍，看看 agent 的卡片操作是不是符合你的预期；第二步，刻意制造一次分歧：你手动移动一张卡片、agent 同时更新另一张卡片，观察共享状态会不会冲突、冲突时以谁为准；第三步，评估维护成本：这块画布是你愿意每天打开的东西，还是三天之后就没人看的摆设——如果是后者，说明你的流程还不需要一块画布，聊天加任务清单就够了。工具的价值不在于它能做什么，而在于你愿不愿意每天用它；预览功能尤其如此，尝鲜的成本很低，养成习惯的成本才是真的。

还有一个容易被忽略的视角：Canvases、聊天搬家、Agent Host 策略这三者其实是同一条产品逻辑的三个面——让 agent 的工作“可协作、可连续、可管控”。可协作解决的是“人和 agent 怎么一起看同一件事”，可连续解决的是“上下文怎么不丢”，可管控解决的是“agent 的边界在哪”。很多 vibe 项目在引入 agent 时只解决了第一层——让 agent 能干活，却没有解决第二层和第三层——上下文丢了就重讲、权限问题出了再补。1.142 的价值在于，它把第二层和第三层的基础设施也摆到了台面上：你可以在升级的同时，顺手把自己项目的“上下文管理”和“权限分级”也梳理一遍。升级编辑器只是一次点击，梳理工作流才是真正的工作，但前者往往是启动后者的好时机。

补充一个容易被忽略的点：Canvases 的价值不只在“看板”本身，而在它改变了你和 agent 对话的粒度。以前你只能用自然语言描述“把这三件事的状态改一下”，现在你可以直接在板上移动一张卡片，agent 从板的状态变化里就能读出你的意图——动作本身成了沟通的一部分。这种“用动作代替描述”的协作方式，对 vibe 项目的日常开发尤其友好：你不需要把每个意图都翻译成精确的提示词，有时候动一下卡片、改一下标题，就比写三句话更清楚。工具越能理解动作，提示词的负担就越轻，而提示词负担越轻，agent 犯错的空间就越小。