每个开发者手机里都存着那条通知：“你的终端会话还在运行……已消耗大量磁盘空间。”AI智能体越能干，留下的烂摊子就越难收拾。2026年10月7日，微软用VS Code 1.141给出了答案——但这一版更新的深意，远不止清理磁盘。
2026年10月7日，微软发布Visual Studio Code 1.141稳定版。乍看之下，这是一次功能性的月度更新：会话工作树智能清理、跨平台终端沙盒、多会话网格化布局、GitHub Enterprise多实例同时登录。四条更新各司其职，但放在一起，它们指向一个更本质的判断——VS Code正在经历一场从“写代码的地方”到“管理AI智能体的控制中心”的底层转型。
这不是猜测。一个多月前，微软在VS Code 1.136中引入了Agent Host架构，将Agent会话从编辑器窗口剥离到独立进程。1.141是这张基础设施蓝图下第一个全面收获实用收益的版本。
工作树清理：智能体留下的数字灰尘
AI智能体每执行一次任务，都会在磁盘上创建一个隔离的Git工作树（worktree），保持其变更与主工作区互不干扰。问题在于没有人定期打扫。一个活跃的开发者，如果每天都让Copilot Agent跑几轮任务，几天之内磁盘上就能堆积数十GB的孤立工作树。
1.141新增的“Chat: Clean Up Agent Worktrees”命令直击这个痛点。它提供一个专门编辑器，列出所有休眠工作树，显示每个会话占用的磁盘空间，支持按闲置时长筛选——用户可以勾选并批量删除。为了防止误伤，活跃、正在运行、等待输入和已固定（pinned）的会话被纳入保护名单，不可操作。
在笔者看来，这个功能看似基础，却触及了智能体编程从尝鲜走向日常的关键障碍：当AI智能体真的变成7乘24小时的生产力工具，它的副产物管理就不是锦上添花，而是刚需。
跨平台沙盒：给智能体装上围栏
比磁盘管理更紧迫的问题是安全。当Copilot Agent获得执行终端命令的权限，它可能触发哪些操作？访问哪些文件？如果遭遇提示注入攻击，后果是什么？
1.141将Copilot Agent Host的沙盒能力从实验状态推向正式可用，覆盖Windows、macOS和Linux三大平台。沙盒限制终端命令和子进程对文件系统和网络的访问权限，在不破坏正常使用的范围内划定禁区。用户可通过chat.agent.sandbox.enabled开关控制，并可细粒度配置网络域名白名单、可读写路径、拒绝路径以及Git和GitHub CLI的凭据使用策略。一条/sandbox策略命令即可查看当前会话实际生效的安全策略。
微软没有粉饰太平。官方文档写得直白：沙盒化进程仍然以用户账户运行，被授予的网络访问、额外开放路径、存储凭据或沙盒逃逸都可能削弱保护——它不替代端点安全。沙盒更像是智能体世界里的一道物理围栏，而不是保险箱。
平台依赖方面，macOS用户零额外配置。Linux和WSL2需要安装bubblewrap和socat，WSL1不支持。Windows需要2026年9月8日安全更新，且桌面沙盒仍标记为实验性。对于企业客户，微软提供了统一Copilot管理策略，管理员可以强制开启沙盒并通过allowBypass: false禁止用户绕过——这意味着安全团队终于可以对智能体行为说“不”。
网格化布局与Harness统一化：从单任务到多任务指挥
开发者调试AI智能体的体验此前一直是个被忽视的痛点。当你同时运行多个Agent会话，或在终端和编辑器之间来回切换，窗口管理会迅速变成一场灾难。
1.141的Agents窗口引入了二维网格布局。用户可以像操作编辑器分屏一样拖拽会话到不同区域，调整面板大小，最大化其中一个聚焦，再一键回到整体网格。布局设置可以持久化——这意味着开发者可以在周一上午配置好四个Agent会话的监控面板，整个星期复用。
更深层的变化发生在底层。Copilot Harness——负责组装上下文、运行Agent循环、应用代码变更的核心组件——被迁移到了GitHub Copilot SDK上运行，与独立Copilot应用和Copilot CLI共享同一运行时。结果是什么？在VS Code中启动的会话和在终端中启动的会话行为一致，Agent Host将session从窗口解耦：你可以关闭文件夹、关闭窗口，之后回来继续，状态不丢。
一个更隐蔽的信号是外部会话延续。Copilot CLI或GitHub Copilot App中开始的新对话，会被自动检测并在VS Code中接着继续，完整保留历史。Codex用户也能做同样的事，在ChatGPT和编辑器之间随意穿梭。当另一个应用持有会话时，VS Code会显示“This chat is open in another app”横幅提示冲突。
本质上，微软在把VS Code从“编辑器”重新定义为“智能体生命周期的管理控制台”。这些功能合在一起，让开发者终于可以在一个统一的界面中启动、观察、干预和回收AI智能体的全部执行流程。
GitHub Enterprise多实例：企业痛点的最后一公里
企业用户长期抱怨一个细节问题：如果Copilot认证走GitHub Enterprise Cloud，而代码仓库在GitHub Enterprise Server上，用户就没法同时登录两个实例。
1.141用新的列表式github-enterprise.uris设置解决了这个矛盾。旧版单值github-enterprise.uri被正式弃用。新的配置支持同时指向多个GitHub Enterprise实例，每个账户以host标签区分身份——monalisa@octocat.ghe.com和monalisa@internal-gheserver各归各的、互不干扰。已有凭据自动迁移。
这个更新占据的篇幅很小，但对于混合使用GHE.com和本地Server的大型企业，它解决了一个持续数年的日常摩擦点。
这意味着什么
VS Code 1.141没有引入新的语言支持，没有重新设计UI，没有颠覆性的AI模型更新。但它在做一件更根本的事：让AI智能体从“写代码时的玩具”变成“真正可管理的生产力组件”。
逐一盘点：会话清理负责卫生，沙盒负责安全，网格布局负责监控，Harness统一化负责连续性，Enterprise多实例负责兼容性。五条线合在一起，即使单条看起来都只是改进，它们的叠加效果是质变。
风险依然存在。沙盒的默认关闭状态说明微软对Agent安全的成熟度还持谨慎态度。外部会话延续依赖跨应用状态同步，如果同步失败或冲突，体验会大打折扣。工作树清理保护了活跃会话，但用户仍有误删风险。这些都不是小事。
但方向是清晰的。当Copilot从补全几个字符进化到自主执行整个任务，管理这些智能体就成了一门新学科。对比竞品：Claude Code和Codex CLI都在拼Agent的执行能力，谁的Agent更强、写代码更快。微软则选了一条更笨但也更厚的路——先搭好基础设施，让Agent的运行环境安全、可控、可管理。
在AI编码工具都在比“谁写代码更厉害”的时候，微软选择先回答一个更朴素的问题——谁能让这些智能体老老实实、有条不紊地干活。这个问题的答案，可能比下一个模型基准测试第一名的数字更有决定意义。
快报