关掉编辑器，agent 不用跟着死：VS Code 1.144 把会话从窗口里解放出来

先说结论：这是一次“编辑器变指挥台”的发布

2026 年 10 月 28 日，Visual Studio Code 1.144 以稳定版发布。官方发布说明的标题是“Agents Across Every Environment”，直译过来就是“跨越所有环境的 agent”。这句话不是口号，它点出了本版唯一的主线：agent 会话不再属于某一个编辑器窗口。过去，关掉 VS Code 就等于掐断正在跑的 agent；现在，Agent Host 作为一个独立进程在后台撑着会话，本地可以、远程可以、云端也可以，你从哪个客户端回来，都能接着原来的对话往下走。理解了这一句，剩下的所有功能——云会话、云自动化、开放协议、模型对比——就都有了安放的位置。

为什么这件事值得单独写一篇，而不是淹没在 Universe 那一堆发布里？因为它改变的是工作方式的默认假设。补全时代的默认假设是“人在编辑器里，模型在旁边帮忙”；agent 时代的默认假设正在变成“人在指挥，agent 在各处干活，人只在关键处点头”。前一种假设下，窗口关了没什么大不了；后一种假设下，窗口关了就等于指挥台断电。1.144 就是在补这个缺口：它先把“会话活着”这件事变成基础设施，再谈模型选得好不好、权限放得松不松。顺序不能反。

Agent Host：会话活着，靠的是一个独立进程

官方说明里对 Agent Host 的描述很短，但分量很重：它是一个独立进程，让 agent 在你的本机或远程机器上持续运行，不依赖某一个 VS Code 窗口。配合它的是 Agents 窗口：一个界面，管理横跨工作区和环境的会话，不管这个会话是你自己发起的，还是自动化触发的。新建会话时，环境选择器会先让你选跑在哪里：本机、云端、符合条件的远程主机，或者支持的 Dev Container。选完之后，其他配置项会跟着环境变化，比如本地会话可以指定分支和 worktree 隔离选项。

这里要特别提醒一个容易误读的点：本地和远程托管的会话仍然需要对应的机器开着，只有云端会话可以在你的电脑关机后继续跑。官方说明在云会话一节写得很清楚：仓库和工具跑在 GitHub 的托管环境里，你的开发机不用保持在线；但本地未提交的改动不会自动复制到云端那个独立的工作区。换句话说，“关机也能跑”和“本地改动自动同步”是两回事，前者是真的，后者不要脑补。第一次用云会话的人，最常见的失望就来自这个脑补：明明本地改了一半，切到云端一看，改动不在那里。不是 bug，是设计如此，你要在动手前就把“哪个工作区是事实来源”想清楚。

远程环境的管理也被收拢了。新的 Remote Environments 对话框把 GitHub Environments、Dev Tunnels、WSL 发行版和 SSH 主机放在一个地方，可以看状态、连上断开、决定哪些远程出现在选择器里。过去这些入口散落在各处，agent 会话一多，到底哪个会话跑在哪台机器上，很容易糊成一团。1.144 的做法不是加新功能，而是把“在哪跑”这个问题的答案集中到一个地方。这类整理工作看起来不性感，但对每天要同时管好几个会话的人来说，它就是生产力本身。

Agent Host Protocol 1.0：开放协议才是这版最长远的部分

如果只看一版发布，云会话最抢眼；如果看三年，Agent Host Protocol（AHP）1.0 可能更重要。官方说明说，这是 VS Code 与本地和远程 agent 通信用的协议，现在发布了第一个版本，设计上是开放、可扩展的，目标是让任何人都能为 agent 搭建自定义界面，或者搭建可以接入任何支持该协议的界面的 agent 平台。你可以通过 Agents 窗口里的“Agents: Add Remote Agent Host...”命令给 VS Code 加一个基于 WebSocket 的 agent host，再用 code agent endpoints 命令查看编辑器里正在运行的 agent host 的端点。官方还提到，他们用六种语言发布了协议库，并且发现 agent 自己就很擅长用这些库来写客户端和 host。

为什么开放协议值得兴奋？因为它把“会话”从某个厂商的客户端里解放出来了。语言服务器协议（LSP）当年做过类似的事：编辑器和语言服务之间有了共同语言，工具生态才真正长出来。AHP 想做的，是 agent 世界的 LSP：只要你的界面会说 AHP，就能接上别人的 agent host；只要你的平台实现了 host，就能被别人的界面指挥。这当然还只是 1.0，生态要不要跟进、跟进成什么样，都是未知数。但方向是对的：agent 不应该被锁在某一个窗口里，协议先行，生态才有机会长出来。评价 1.144 的时候，不要只数它加了几个按钮，要看它有没有为下一批工具铺好路。

还有一个细节值得注意：AHP 不只是给本地用的，官方说明明确写了它也覆盖云自动化。这意味着，定时或事件触发的云端 agent，同样走这套通信方式。协议统一的好处在这里就显出来了：你白天在编辑器里盯着的会话，和半夜自动跑起来的会话，讲的是同一种语言，复盘、接管、审计的工具可以复用。反之，如果每种会话各讲各的方言，自动化一多，运维成本会先于收益爆炸。

云会话与云自动化：电脑关了，活儿还没停

云会话的具体用法，官方说明写得相当具体：从编辑器窗口的 Chat 视图或 Agents 窗口里选 Cloud、挑一个 GitHub 仓库，就可以开始一个任务；随后可以发后续指令、回应审批请求、检查 agent 的改动；之后从会话列表里重新打开同一个云会话，继续原来的对话。你的云会话还能从其他 Copilot 客户端访问，比如在 GitHub.com 上看进度、在 GitHub Mobile 应用里看一眼，再回到 VS Code 继续干活。这就是“跨越所有环境”最直观的样子：会话跟着你走，而不是跟着窗口走。

但云会话有两个门槛，必须原样转达。第一，它需要付费的 Copilot 计划；第二，它受组织策略约束。免费用户不要指望一升级就能用上，团队用户则要先看管理员有没有放行。云自动化（预览版）也是类似的逻辑：设置项是 chat.automations.cloud.enabled，默认开启，可以在 Agents 窗口里直接创建和管理，跑在 GitHub 基础设施上，按计划或响应仓库事件触发，哪怕你的电脑关着。官方举的例子很实在：当 issue 被指派给你时自动分流；为团队建共享工作流，让自动化以 Copilot 的身份行动；用工具限制和过滤器精确控制 agent 什么时候跑、能干什么。

我的判断是，云自动化比云会话更值得小团队认真对待。云会话解决的是“我在不同设备之间切换”的问题，这对很多人来说是锦上添花；云自动化解决的是“没人盯着的时候，仓库里的例行活儿谁来干”的问题，这是实打实的省人力。但省人力的前提是把触发条件和工具范围写窄：只在被指派且带有特定标签时触发，只允许读和提 PR、不允许直接合并不允许改配置。自动化一旦放得太宽，半夜它替你合了一个有问题的 PR，早上你面对的就不是“省了多少时间”，而是“怎么回滚”。先窄后宽，永远是自动化的正确顺序。

模型怎么选：Fusion 接手，或者自己摆擂台

模型选择是 1.144 的第二条主线，官方给了两条路。第一条是 Copilot Fusion：不用每次为任务挑模型，在模型选择器里选 Fusion，让 Copilot 帮你路由和编排。它把 HydraFusion 的多模型编排和 Copilot 自动选模型结合起来，按任务在简单任务上用一个模型、在困难任务上让一个模型起草、其他模型评审或挑刺。努力程度分三档：Standard 对应日常编码，High 对应更难的任务，Max 对应最复杂的任务。计费方式是按 Fusion 实际调用的每个模型、以各自标准价收费；2026 年 11 月 30 日之前，付费 Copilot 计划用 Fusion 有 7 折优惠。Fusion 现已正式可用，但 High 和 Max 只在 Copilot Pro+、Max、Business 和 Enterprise 计划上提供。

第二条路是模型对比，也就是 Agent Bake-Off：同一个提示发给多个模型或 harness，并排比较结果。本版把这个功能默认打开给符合条件的新会话（设置项 sessions.chat.compareAgents.enabled，用户设置或实验可以覆盖），并且扩展到更多场景：没有项目的文件夹外聊天也能跑独立尝试，不需要 Git 仓库、评审器或合成器；本地或空仓库也不再要求必须有远程和初始提交，对没有提交的仓库，每次独立尝试从未忽略的工作文件快照开始，不动你的源分支和索引。注意一个例外：模型对比不支持 Dev Containers。

这两条路不是互斥的，而是互补的。Fusion 适合你已经信任系统、只想省掉选模型的心智负担的时候；模型对比适合你还不信任、想亲眼看看不同模型在你这个具体任务上到底差在哪的时候。一个健康的用法是：新项目、新类型任务先摆擂台，跑几次心里有数了，再把日常任务交给 Fusion；遇到关键任务，再把 Fusion 的结果拿出来和单一模型的结果对一下。直接把所有任务都交给自动路由，和永远手动挑模型一样，都是懒惰，只不过懒的方向不同。顺带提醒：Fusion 的正式可用在本站之前已经单独报道过，本篇的重点不是重复那篇，而是把它放进 1.144 的整体里：它是“会话活着”之后的“选模型省心”，不是本版的全部。

记忆、权限与工作集：agent 越能干，缰绳越要紧

1.144 里还有一组功能，主题是“让 agent 更了解你，同时让你更管得住它”。先说记忆：Copilot harness 的会话现在可以用 Copilot Memory，也就是 Copilot CLI、云 agent 和代码评审用的同一套云记忆服务。Agent 会在会话开始时回忆相关的仓库事实和你的偏好，并在工作过程中存下新的学习结果，免得你每个新会话都要重复同一套上下文。记忆分两种范围：仓库事实，会分享给有仓库访问权限的其他人；用户偏好，横跨你的所有仓库。官方示例很直白：“在我的所有仓库里，记住我喜欢简洁的提交信息主题。”范围说清楚再让它记，是用好记忆功能的第一步；默认开启不等于默认可以乱记，你可以在 GitHub 上随时查看和删除自己的记忆，也要受组织策略约束。

再说权限：辅助权限（Assisted permissions）现在正式可用。它的逻辑是，agent 每次工具调用都先做一次基于大模型的风险评估，低风险的调用自动放行，不用每次都弹确认；风险较高或无法判断的，仍然要你明确批准。官方说明还写了两个限制：辅助权限需要文件夹隔离，并且可能受组织限制。这是一个“方便与安全的折中”，而不是“全自动”的承诺。把它理解成“低风险的事少打扰你”，而不是“agent 可以自己决定什么是低风险”，心态就对了。真正高风险的动作——改配置、删数据、对外发布——仍然应该留在人工确认的清单里，不要因为辅助权限上线了就把清单删掉。

工作集（Working set）还是实验功能，但方向很对：Copilot harness 会把通过 agent 工具产生的编辑记在一个工作集里，你可以在编辑器里用 Keep 和 Undo 逐项决定保留还是撤销，也可以在聊天输入框上方的工作集里统一管理文件和待定改动。注意一个缺口：通过终端命令产生的改动不会出现在工作集里，在 Agents 窗口里则要用 Changes 视图来丢弃文件。也就是说，工作集管的是 agent 亲手改的部分，不是所有变化。评审 agent 的改动时，先看工作集，再看终端记录，这个顺序不要颠倒。记忆让你少重复，权限让你少被打扰，工作集让你敢放手——三者加起来，才是“agent 能干活、你还敢让它干活”的完整拼图。

其他值得知道的变化，以及本版的边界

除了主线，1.144 还有几处值得一提的变化。电脑操作（Computer Use）还是实验功能，只在你自己 macOS 或 Windows 机器上的 Copilot harness 会话里可用，任务需要时 agent 会请你允许开启，或者你自己跑 /computer on，关闭则是 /computer off。图像生成进入预览：可以在聊天里直接请 agent 用 GPT Image 2.5 Flare 生成或改图，默认模型就是它，关闭可以把 chat.copilot.imageGeneration.model 设为 off，还可以把水印开关设为 true，给图片打上可感知的“Made with AI”水印，图像生成除了对话模型本身的额度外，还要另外消耗 AI 额度。画布（Canvases）是 1.142 引入的预览功能，本版让它更容易被发现和管理：可以在 Agent Customizations 编辑器里看、可以在 Browse 里按类型筛选、可以在聊天里通过 Add Context 打开。

连接器（Copilot connectors）也是预览：通过 GitHub 托管的 MCP 服务器，把 Slack 里的讨论、Notion 里的项目上下文、Microsoft Learn 里的 API 文档带进 agent 会话，不用自己搭本地 MCP 服务器或写配置。在 Browse 里选 Copilot Connectors、点 Connect、在浏览器里授权一次，同一个账号登录的支持客户端就能复用这个连接。但要注意，它只在 Copilot harness 下工作，Business 和 Enterprise 还需要管理员开启编辑器预览功能，并且要受组织的 MCP 限制，有些服务还需要管理员批准。新的 Markdown 编辑器则更贴近日常写作：可以直接编辑渲染后的 Markdown，而不是只改源码，当然源码模式还在。界面整体也刷新了，亮色和深色主题都更清爽。

最后，把本版的边界说清楚，免得读者升级后失望。第一，不是所有功能都是正式可用：云自动化、图像生成、连接器是预览，电脑操作和工作集是实验，正式可用的是会话连续性框架、Fusion、辅助权限这些主线。第二，云会话和部分高级功能要付费计划和组织放行，免费升级不等于全部解锁。第三，模型对比不支持 Dev Containers，工作集不覆盖终端改动，云会话不自动同步本地未提交改动——这三条都是官方说明里白纸黑字写着的限制，不是体验问题。1.144 的价值，在于它把“会话”从窗口里解放出来、并给了它一个开放协议；但它没有替你解决“怎么管住一群在各处跑的 agent”这个问题。这个问题，仍然要靠你自己的触发条件、工具范围、记忆范围和确认清单来回答。编辑器已经把指挥台搭好了，指挥的规矩，还得你自己定。

升级建议也很简单：先在非关键仓库里开一个云会话，跑一次完整的“发起、关机、手机上看一眼、回编辑器继续”流程，确认你的组织策略和付费计划都放行；再开一个触发条件写得很窄的云自动化，观察一周，确认它只在你想要的时候跑、只做你允许的事。这两步都稳了，再把日常任务慢慢迁过去。会话可以跨环境，但信任不能跨环境一步到位，得一次一次攒出来。