于2026年5月6日, Code团队推出了1.119版本更新, 这期更新并非大张旗鼓地堆砌新功能, 而更像是对现有工作流进行精细化调整, 特别是AI Agent协作体验、Token成本控制以及日常文档操作这几个方面, 对于使用VS Code进行编写的人而言, 有些变化在日常使用中会悄无声息地发挥作用。

先简要交代一番背景: 在4月底的时候, 刚刚宣告会自6月1日起转向依据使用量来计费的模式, 这表明你每一回跟AI对话所耗费的Token会直接对账单产生作用。1.119版本恰好处于这个时间节点上, 针对Token使用施行了一些优化举措, 使得这件事情变得没那么“耗费金钱”。下面把这些更新逐一拆开进行查看, 顺便谈论一下在开发场景里面具体能够怎样去运用。

一、Agent能“看”你的浏览器了——但不经过你同意不行

在此次更新当中, 最为直观的那种变化, 便是Agent以及集成浏览器的交互方式得到了改进。

以前, AI Agent基本上仅仅能够读取你本地的代码文件, 对于外面的事物完全一无所知。1.119版本准许你将浏览器标签页附加到聊天上下文当中, 如此一来, Agent便可以读取页面内容并且与之进行交互。举个例子来说: 当你在调试所编写的后端接口时, 浏览器开启着文档页面, 把那个标签页共享给Agent, 它就能够直接看到接口的返回结构与状态码, 而无需你手动去复制粘贴一大段JSON过去。

那开发者什么情况下会用到这个功能？比较典型的有几个：

一种是运用Flask或者用于做Web应用的情景, 前端页面出现了渲染方面的问题, 将页面分享给Agent, 能够直接读取DOM结构以及控制台报错, 进而确定后端哪一段视图函数出现了问题, 修改代码、刷新页面、验证修复可以在一个对话回合之内达成。

首先, 在进行数据可视化项目之时。比如说, 选取用或Dash去生成图表。接着, 于浏览器里对效果予以预览。然后便会察觉到, 颜色搭配亦或者布局并不对劲。随后, 将页面分享给Agent。最后, 它能够针对渲染效果与设计意图展开对比。进而给出建议, 用以调整代码之中的样式参数。

然而存在一个细节是值得予以留意的: Agent不会自行去访问你所打开的浏览器页面, 而是需要你进行明确的授权方可；这属于一种设计层面的克制, 即是宁愿多增添一步确认的操作, 也不会让AI于你未留意之际读取到敏感内容；要是你正在调试一个关联用户数据的后台页面, 且没有进行授权, 那么Agent就无法看到那些信息；在共享完成之后能够随时点击浏览器之中的分享按钮来终止授权, 并且控制权始终是掌握在你手中的。

另外存在着一项相对省心一些的小改进, 它是这样的: 当Agent打算去打开一个全新的标签页时, 并且这个标签页所归属的域名, 与你已然打开然而却尚未进行共享的某一个页面相一致的时候, 那时它将会弹出窗口来询问你是不是要直接去使用已经存在的标签页, 而并非是毫无头绪地去开启一个新的。对于那些习惯了去打开几十个标签页的人而言, 这样的一个细节是颇为实用的。

二、Token优化的背后逻辑——省下来的都是成本

1.119这个版本引入了一项具备实验性质的功能, 该功能是运用轻量级模型去完成管控Agent相关的待办事项列表的动作。

弄明白Agent的Token被花费在何处, 才能够理解这个改动所具备的价值。每当Agent进行对话之时, 把系统所带有的提示词、工具的定义、对话所历经的过程、相关文件所含内容, 全都打包发送给模型。对于一个复杂度处于中等程度的开发任务而言, 单次Agent交互消耗几万Token属于正常的情况。然而待办事项列表（todo list）的更新是一项高频操作, 在于每完成一个子任务、每一次对计划作出调整, 都需要对列表进行刷新。要是每一回全都借助主力模型比如说GPT - 4级别这种来对这件事情予以处理, 那么Token消耗将会迅速地进行累积。

处理todo list管理, 倘若采用轻量级模型, 这就好比是将“记笔记”以及“写paper”进行了区分——对于前者而言, 并不需要深度推理, 轻量模型已然能够完全满足需求, 然而节余下来的Token会日积月累, 历经一个月之后, 或许会出现较为明显的差距。

从即将于6月1日启用的按量计费模式予以结合看去, 对于日常高频运用AI辅助编程的开发者而言, 这个优化具备经济方面的意义。依据VS Code团队所公布的数据, 在活动Agent会话里, 借助上下文缓存（）已经达成了超出93%的缓存复用率, 再加之轻量级模型的调度策略, 实际的Token效率提升将会更为显著。

当然, 当前这项功能仍旧印着那“实验性”的标签。 设置的路径是如此这般, 即要先去打开设置（Ctrl+）, 接着得搜索“todo list”, 随后找到相关选项最终启用它。要是你使用的乃是付费版本而且每日对话量比较大的时候, 那就能够考虑进行尝试一番哒 ；要是仅仅是偶尔使用罢了, 那影响倒也不算特别大的。

三、追踪——让你看清Agent到底干了什么

编程中存在一个关于Agent的常见困惑现象, 有个情况是, 它协助你达成了一项任务, 而你却并不十分明晰在达成这个任务的整个过程中间经历涵盖了哪些具体的步骤, 这里要强调下, 还包括调用了哪些工具, 另外一个方面且会消耗花费了多少Token。存在这样的状况, 有时候存在明明是一个非常简单的问题, 然而Agent却迂回曲折地绕了一大圈才最终给出答案结果, 而且甚至在这个过程当中还做了一些有些“多余动作”。

1.119版本增添了（OTel）追踪方面的支持, 简要来讲, OTel是一种开源的观测标准, 1.119使得Chat里Agent的每一次交互, 涵盖LLM调用、工具执行、Token使用量, 都能够被导出成为OTel格式的trace, 并且所有信号的命名以及属性都依照OTel的GenAI语义规范, 数据能够接入诸如这类的可视化工具进行查看。

对开发者来讲, 这东西究竟用处何在呢? 来列举一个更为具体些的场景: 当你着手开展一个数据处理方面的项目时, 去让 agent 协助你撰写一段用于清洗数据的代码。agent 先是调用了文件读取工具, 接着执行了代码, 随后又再度阅读了一遍文档, 最终才给出了结果。借助 otel 追踪, 你能够看到一条完整无缺的时间线, 即哪一个步骤耗费了多少毫秒, llm 返回的究竟是什么, token 消耗了多少。一旦察觉到Agent于特定环节长时间处于”纠结“状态（像是对同一文件进行多次读取的情况）, 这意味着你的提示词大概不够精准精确, 或者Agent对应的上下文策略需要进行相关处理作出调整。

设置的方式为: 于VS Code的设置之中进行搜索“”, 依照文档去配置端点以及导出参数。当下Chat导出的信号涵盖trace（追踪链路）、（指标数据）以及（事件记录）, 其涵盖范围涉及Agent对话的整个生命周期。对于那些需要向团队汇报AI工具使用成效的技术管理者而言, 这些数据同样能够给出比较客观的参考。

请注意, 你得将数据导出至外部分析工具方可查看, 仅依靠VS Code自身界面无法直接使用这些追踪数据。倘若你仅是个人开发者, 平常对Agent执行过程并无深入探究的需求, 此项功能属于“锦上添花”类别；但是若你于团队中推进AI辅助编程的落地实践, 这种观测能力将会颇具价值。

四、安全弹窗少了——信任控制更聪明了

在运用VS Code开展项目开发之际, 你必定遭遇过这般的弹窗, 即“是否准许这个工作区对网络进行访问? ”“是否准许写入临时文件夹呀? ” 特别是在借助虚拟环境来安装依赖之时, 在执行网络请求繁多的爬虫脚本之际, 又或者是在运行自动化测试之际, 这些弹窗会时不时地现身高出打断你的节奏。

1.119版本针对信任以及安全控制策略作出了调整, 其核心目的在于降低不必要的打断, 并且与此同时维持安全性不降低。具体来讲, 实现方式为对权限请求的触发时机以及范围判断逻辑, 实施了优化举措, 从而促使系统针对“已然信任的操作”与“需要再次进行确认的操作”, 做出的判断更为精准。

于实际开发之际, 这所意味着的是: 当你于一个早已构建起信任的工作区内频繁去执行pip , 去运行测试套件, 或者是利用其发送HTTP请求之时, 系统会将上下文予以记住, 不会每一回都弹出窗口问你一回。此一改动归属于“用上之后才知晓其好处”的类别——交互中断的减少大概能够节省一些无实效的心理切换成本, 虽说难以进行量化, 然而对于那些需要长时间维持专注的编程任务来讲, 每一分未被打断的时间皆具备价值。

五、预览切换终于变快了——文档工作流的小优化

项目里头文件的运用频次实际上是颇为高的, 有文档, 有项目说明, 有API接口文档, 甚至还要借助导出撰写分析报告。每回写完一部分想要预览成效, 就得手动去开启预览面板, 或者借助快捷键, 反复地进行切换。

1.119 版本那儿新添了个快捷命令, 此快捷命令能够在源文件跟预览视图之间做到快速切换。这快速切换可不需手动跑到侧边去打开预览面板之后再将其关掉。其操作方式着实简单, 于编辑文件之时, 借助快捷键（在 Linux 系统下是 Ctrl+Shift+V这组合键, 在 Mac 系统下是 Cmd+Shift+V 这组合键）来开启预览, 接着运用新增加的切换功能在编辑状态跟预览情形之间来回地跳转。

此微小功能给撰写项目文档的效率所带来的提升是切实存在的, 特别是在你有频繁检查代码块格式、表格对齐状况以及链接是否有效的时候。以往或许得将两个面板并列排放, 如今仅需凭借一个面板来回切换便可达成, 特别是在小屏幕笔记本电脑上, 着实便利了许多。

聊聊使用上的避坑经验

上文将功能阐述完毕啦, 但依据我实际运用的经历, 存在一些隐患还是极有必要预先讲一讲的。

先要讲一下 Agent 浏览器共享这个功能。共享浏览器标签页的却会是便利。那若是你在调试那个页面包含了关于用户、API 密钥明文, 还有或者是内部系统之间的敏感数据。在共享之前的情况下最好得先去查验查验在这个页面当中到底有没有那些不应该暴露展现出来存在着的内容。Agent 是有着能够读到页面之上的所有一切东西。其中包含了那些你平常的时候不会去留意注意到的隐藏字段以及响应头信息。在此建议要在设置之中去检查查看有关信任域配置安排。以此来确保保证只有工作使用的页面才会被进行共享。数据安全这一方面的事情。向来永远都是自己本身所要承担的责任义务所在。工具仅仅只是提供了相应的控制手段方法而已。

关于Token优化这儿还存在一条经验: 那个轻量模型虽说在费用节省方面具备优点, 然而其推理能力终究受限。要是你的todo list结构呈现出复杂状况——举例来讲就是一个任务存有四五层子任务嵌套形式, 并且任务相互之间的依赖关系并非线性而是网状的——那么轻量模型极有可能把顺序弄乱, 反倒致使Agent执行出现差错。建议起始先从简单任务着手进行试用, 在确认它能够正确领会你的任务结构之后, 接着再逐步拓展使用范畴。

此外, 要是你先前使用的是1.118版本或者更早的版本, 在升级到1.119之后最好去检查一下Chat的Token消耗情况是否有变化。有一部分用户在升级之后反馈称, 轻量模型的todo list管理虽说节省了Token, 然而设置项默认是处于关闭状态的, 这就需要手动去开启。要是不开启的话, Token消耗和之前的版本基本上是一样的, 不存在什么能立刻见到明显效果的变化。

最后讲讲版本号方面的情况, 有个细节蛮有趣味——要是你使用的是VS Code版本, 1.119还附带了一个名为“VS Code ”的独立体验, 能够跨仓库运行并行Agent会话, 这个功能目前仅在此处提供, 稳定版用户当下暂时无法使用, 要是你对多仓库并行的Agent协作有兴趣, 能够下载版本去尝试新鲜体验, 不过生产环境还是建议使用稳定版。

这次更新，真的值得升级吗？

回过头去查看一下 1.119 这一版本的五项主要更新内容, 能够以一句话来加以概括, 即不存在哪一项属于“颠覆性”的, 可是对于那些使用 VS Code 来开展开发工作的人而言, 每一项都在日常工作的某一个具体环节当中施展着相应的作用。

使得前后端联调的反馈循环更短的是Agent浏览器共享；在按量计费的大背景下帮你减少开销的是Token优化；让你拥有分析和优化Agent使用方式工具的是追踪；减少开发中打断的是信任控制；改进文档编写体验的是切换。

若是你在日常当中对Chat的Agent模式进行重度运用, 或者在项目里文档所占的比例非常高, 此次更新所带来的体验提升便会较为显著, 倘若你的使用场景偏向传统, 主要涉及代码编辑, 本地运行以及轻量调试, 那么在升级之后或许不会有莫大的感知差别, 不过也不会存在兼容性方面的问题。

平日里, 你运用Chat的频次高不高? 升级过后, 在Token消耗这块, 有没有察觉到什么变化? 欢迎于评论区, 分享你的实际数据——毕竟, 每个人的项目规模以及AI使用习惯均不同, 实际节省的程度也会存在差异。

需要声明免责, 文中所讲的按量计费政策, 以及那个Token优化功能, 是以微软官方公告作为依据的, 具体的计费标准, 还有功能的可用性, 会因为地区不同, 订阅计划不一样, 而产生一些差异, 建议把官方文档当作标准。本文所叙述的操作步骤, 是基于VS Code 1.119版本来做的测试, 后续版本有可能存在调整。

如有侵权请联系删除！