VS Code让Agent看懂页面

VS Code 把网页元素变成 Agent 的精确上下文

微软昨日（8 月 5 日）发布 Visual Studio Code 1.132，最值得关注的变化是内置浏览器新增元素级反馈，开发者现在可以直接选中网页中的具体元素、逐个添加评论，再把这些信息交给编程 Agent。今天是 8 月 6 日，这次更新已经成为 VS Code 最新一轮面向 Agent 工作流的产品调整。

VS Code 1.132 是微软在 2026 年 8 月推出的编辑器更新版本，重点增强了开发者与编程 Agent 之间的上下文传递能力。 除了元素级反馈，新版本还加入侧边聊天、聊天引用、多语言语音输入，以及混合 Markdown 编辑器中的差异比较功能。

这轮更新看上去分散，实际上都在解决同一个问题：人类知道自己在说什么，但 Agent 不一定知道。过去开发者让 Agent 修改网页，往往要输入“首页右上角那个按钮”“第二张卡片的间距不对”“把标题下面的灰色说明文字缩小一点”。这些描述对人类足够直观，对模型却可能对应多个 DOM 节点。

元素级反馈改变了这种模糊协作方式。开发者不再只用自然语言描述对象，而是把页面元素本身连同评论一起提交给 Agent，相当于在网页上贴了一张带定位信息的批注。

元素级反馈解决的是“指给 Agent 看”

元素级反馈（element-level feedback）是一种将具体网页元素及其批注意见作为上下文发送给 Agent 的交互方式。 在 VS Code 1.132 的内置浏览器中，用户可以进入元素选择模式，选中一个或多个页面元素，并在发送聊天消息之前为每个元素分别添加评论。

开发者可以通过命令 workbench.action.browser.addElementCommentToChat 触发这一模式。这个命令名称虽然不短，但它可以被绑定到快捷键或通过命令面板调用，真正有价值的地方是支持“一次选择多个元素、分别填写意见”。

多元素批注比单纯截一张图更适合前端迭代。截图能够表达视觉结果，却通常没有稳定的结构化定位；元素批注则把“对象是谁”和“要改什么”放到同一份上下文里，Agent 更容易将意见对应到页面结构和相关代码。

一个典型场景是落地页走查。开发者可以选中首屏标题，备注“移动端字号降低一级”；选中主按钮，备注“改成品牌主色，并保留 hover 状态”；再选中导航栏，备注“滚动后保持吸顶”。三项需求可以一次发出，而不必复制 class 名称、描述页面位置或来回补充截图。

这项功能最直接的收益不是让模型变聪明，而是减少指代歧义。Agent 的能力上限依然取决于模型、项目上下文和代码质量，但输入对象更明确后，它猜错文件、改错组件或误解目标的概率理论上会降低。

VS Code 并未在此次信息中给出任务成功率、Token 消耗或修改耗时等量化测试，因此不能把元素级反馈直接解释为性能提升。更准确的判断是：它优化了上下文采集界面，把过去需要开发者手动组织的一部分信息交给编辑器完成。

它比截图反馈多了一层结构信息

结构化页面反馈是将视觉对象、页面位置和修改意见绑定在一起的反馈形式。 它和截图标注很像，但两者并不完全相同：截图的核心是像素，元素级反馈的核心是可被定位的网页对象。

| 反馈方式 | 对象定位 | 是否支持多项意见 | Agent 理解成本 | 更适合的场景 | |---|---|---:|---|---| | 纯文字描述 | 依赖自然语言 | 支持 | 高，容易出现“哪个按钮”的歧义 | 简单逻辑调整、对象唯一的页面 | | 截图加文字 | 依赖视觉位置 | 支持 | 中等，仍需识别图像和映射代码 | 视觉还原、跨应用反馈 | | 复制 DOM 或选择器 | 定位较精确 | 支持 | 中等，但开发者操作繁琐 | 调试具体节点、排查样式 | | VS Code 元素级反馈 | 直接选择页面元素 | 支持，可逐个评论 | 较低，对象与意见绑定 | 在编辑器内完成页面走查和修改 |

元素级反馈并不会取代浏览器开发者工具。DevTools 仍然更适合查看盒模型、事件监听器、网络请求、计算后样式和性能时间线，而 VS Code 的新能力偏向“发现问题后把任务交给 Agent”。前者是诊断工具，后者是协作入口。

这也意味着该功能对前端、全栈和设计工程团队的价值明显高于纯后端项目。一个主要处理数据库迁移或消息队列的 Agent，几乎用不到网页元素批注；一个持续调整 React、Vue 或静态页面的团队，则可能频繁受益。

侧边聊天让长任务不再被临时问题打断

侧边聊天（side chats）是在不打断当前 Agent 任务的情况下发起的独立辅助对话。 VS Code 1.132 中，用户可以输入 /btw 开启侧边聊天，询问临时问题，同时保留正在运行的主要任务。

侧边聊天针对的是 Agent 工作流中的另一个真实矛盾：任务越来越长，但开发者的注意力仍然是碎片化的。Agent 可能正在跨文件重构认证模块，开发者突然想确认某个配置项的含义；如果直接把问题塞进主对话，模型上下文会混入无关内容，任务边界也可能变得模糊。

/btw 的产品含义类似开会时暂时插入一句“顺便问一下”，但不改会议议程。开发者可以让主 Agent 继续执行原任务，再通过侧边聊天确认类型定义、解释报错或讨论另一种实现，不必等待主任务结束。

聊天引用则进一步补上了多会话之间的信息流转。用户可以通过 #chat: 引用其他聊天，也可以直接把聊天标签页拖入输入框，让当前对话获得另一个会话的背景信息。

这套机制让聊天记录从一次性消息变成可组合的上下文对象。过去开发者往往需要复制上一段结论，或者重新向 Agent 解释“我们刚才为什么没有选择方案 A”；现在可以直接引用相关会话，减少重复输入，同时保留决策过程。

不过，引用更多聊天并不等于结果一定更好。上下文越多，模型需要区分的目标、约束和历史决策也越多；如果被引用的会话已经过时，Agent 仍可能基于旧结论继续工作。开发者仍需明确指出哪些约束有效、哪些讨论仅供参考。

语音输入终于开始理解 shell 语法

面向终端的语音输入是一种将自然语音转换为可执行命令文本，同时保留 shell 符号和参数结构的输入方式。 VS Code 1.132 改进了语音命令处理，重点不是普通听写，而是识别开发者口中的命令语义。

例如，用户说出“git commit dash m hello world”，系统会生成 git commit -m "Hello World"。这里真正困难的不是识别 git、commit 或 hello world，而是把“dash m”转换为 -m，并为提交信息补上适当的引号。

传统语音听写对代码和命令行一直不够友好。自然语言允许省略标点，shell 却高度依赖连字符、引号、管道符和参数顺序；少一个字符，可能就从合法命令变成报错，甚至改变命令行为。VS Code 这次开始保留 shell 语法，说明语音输入正在从无障碍辅助功能转向更实用的开发输入方式。

新版听写默认在设备端处理，并使用多语言 Nemotron 3.5。系统或浏览器区域设置对应的语言受到支持时，听写会采用该语言；如果区域语言不在支持范围内，则由模型自动检测语言。

设备端处理是这项功能的重要前提。终端中经常出现内部项目名称、服务器路径、分支名称和环境信息，本地听写可以减少原始语音离开设备的需要，也通常更有利于控制交互延迟。不过，具体数据处理边界仍应以用户所安装版本的设置、相关扩展状态和微软说明为准。

多语言支持对中文开发者尤其有用，但它也有一个难以彻底消除的问题：中英文混说。真实工作中常见的表达是“帮我 git checkout 到 feature login 分支”，模型必须在中文语境、英文命令、项目专有名词之间切换。自动语言检测提供了基础，最终可用性仍取决于混合语言和专业词汇的识别准确率。

Markdown 差异终于不必在源码与预览间二选一

混合 Markdown 编辑器是一种同时提供 Markdown 结构编辑与渲染后阅读体验的编辑界面。 从 VS Code 1.132 开始，其试验性 Markdown 差异功能能够直接在渲染后的文档中高亮新增、变更和删除内容，并保留对已修改文件的直接编辑能力。

这项更新解决了文档审阅中的视角冲突。源码差异适合检查标记和逐行变化，但阅读体验差；渲染预览适合确认标题、列表、表格和引用块的最终效果，却容易掩盖具体改动。新版将两种视角叠加，开发者可以一边看最终文档，一边识别哪些内容发生了变化。

Markdown 差异对 README、技术方案、变更日志和模型生成文档尤其有价值。Agent 一次重写几段说明后，审阅者无需在原始源码、Git diff 和渲染预览之间反复切换，就能判断它是否删除了关键限制、改变了术语，或者破坏了表格结构。

“仍可直接编辑”比单纯高亮更关键。差异视图如果只能看，开发者发现错误后还得切回源码；混合编辑器则试图把发现、确认和修正放在同一界面中。它仍是试验性能力，复杂嵌套结构、HTML 混排和大型文档中的实际表现值得继续观察。

1.132 的主线是降低上下文交接成本

上下文交接成本是开发者把目标、对象、约束和历史信息传递给 Agent 所付出的操作与表达成本。 VS Code 1.132 的四项主要变化，分别从不同环节减少这种成本。

| 新能力 | 解决的问题 | 关键操作 | 主要价值 | |---|---|---|---| | 元素级反馈 | 页面对象描述不准确 | 选择元素并逐项评论 | 把视觉反馈绑定到具体对象 | | 侧边聊天 | 临时问题打断长任务 | 输入 /btw | 保持主任务连续性 | | 聊天引用 | 多会话信息难复用 | 使用 #chat: 或拖入聊天标签页 | 复用历史结论和上下文 | | 多语言语音输入 | shell 语法难以通过普通听写表达 | 直接说出命令与参数 | 降低终端语音输入门槛 | | Markdown 差异 | 源码 diff 与渲染效果割裂 | 在混合编辑器中查看差异 | 提升文档审阅效率 |

这次更新没有发布一个新的基础模型，也没有用基准测试证明 Agent 编码能力跃升。它更像是对“人如何把任务交代清楚”的一轮系统修补，而这恰恰是当前编程 Agent 最容易被低估的瓶颈。

模型能力接近时，编辑器能否提供高质量上下文，会直接影响实际体验。一个 Agent 即使会写出正确 CSS，如果不知道用户指的是哪个按钮，也只能猜；一个模型即使能完成大型重构，如果临时问题不断污染主会话，执行稳定性也会下降。

VS Code 的优势正在从代码编辑器本身扩展到 Agent 任务编排界面。它不仅需要展示文件和终端，还要管理网页对象、并行对话、历史会话、语音命令和文档差异。编辑器正在承担过去分散在浏览器、聊天窗口、设计批注和 Git 工具中的工作。

这条路线也存在代价。功能入口变多后，命令、聊天标签页、主任务和侧边会话可能让界面进一步复杂；团队还需要建立新的协作规范，例如哪些意见应该作为元素批注、哪些结论需要引用会话、哪些长任务不应被额外上下文干扰。

谁应该优先升级

VS Code 1.132 最适合频繁使用编程 Agent、内置浏览器和 Markdown 文档工作流的开发者。 如果日常工作包含前端页面迭代、Agent 驱动的跨文件修改或大量技术文档审阅，这次更新带来的效率改善会比普通语法高亮更新更明显。

前端与全栈开发者最值得先测试元素级反馈。它能够把设计走查式意见直接送入代码工作流，尤其适合页面元素多、组件复用复杂、纯文字难以描述的项目。

重度 Agent 用户最值得先测试侧边聊天和聊天引用。长任务与临时问答分离后，会话更容易保持清晰；但在正式项目中，仍应通过 Git diff、测试和人工审查确认 Agent 的实际修改。

文档维护者最值得关注混合 Markdown 差异。它不只是让 diff 更好看，而是让渲染结果也进入审阅流程，有助于发现源码层面不明显、最终展示却很突出的格式问题。

语音输入则更像一项潜力功能。它保留 shell 语法并默认采用设备端处理，方向是对的，但是否能成为高频入口，要看多语言混合识别、专有名词准确率和误操作防护能否经受真实终端环境考验。

我们的判断：这是一次不起眼但方向正确的更新

VS Code 1.132 的核心价值，是让 Agent 获得更精确、更可复用且更少干扰的上下文。 它没有靠更大的模型制造发布声量，而是从元素选择、会话分支、语音语法和文档审阅四个细节切入，补齐 Agent 协作中的产品层短板。

元素级反馈是其中最有辨识度的功能。它把“帮我改这个”从一句含糊指令变成带对象的任务描述，也让内置浏览器不再只是预览页面，而开始承担页面验收和任务派发的角色。

侧边聊天则可能成为重度 Agent 用户更常用的能力。Agent 任务越长，并行提问的需求越强；只要 VS Code 能把主任务、侧边问题和引用上下文管理清楚，它就会比单线程聊天更贴近真实开发节奏。

这次更新也提醒了行业一个事实：编程 Agent 的竞争不只发生在模型榜单上，也发生在上下文如何被采集、组织和交付。模型决定它会不会做，工具界面决定开发者能不能把事情说清楚，而 VS Code 1.132 明显在押注后者。

参考来源

• IT之家：微软 VS Code 1.132 发布，内置浏览器引入元素级反馈、支持多语言语音输入——介绍 VS Code 1.132 的元素级反馈、侧边聊天、语音输入和 Markdown 差异等主要更新。