VS Code 1.134，把 Agent 搬到主视图

微软在 8 月 19 日推送了 Visual Studio Code 1.134 更新。这次版本的重点很明确：继续把 VS Code 从一个代码编辑器，改造成适合管理多个编码 Agent 的工作台。

新版本加入了四项直接面向聊天和 Agent 协作的能力：并排聊天、提示时间线、聊天中查找，以及将集成浏览器设为 HTML 文件默认编辑器。它们看起来都不像是会改变开发方式的大功能，却共同解决了 Agent 编程中最烦琐的一类问题：上下文太长、任务太多、过程难追踪，开发者很难知道 Agent 到底做了什么，以及自己应该从哪里接手。

这也是 VS Code 1.134 的价值所在。它没有重新发明一个更复杂的 Agent 框架，而是开始补齐多会话协作和过程审查所需要的基础设施。

并排聊天：从单线程对话变成工作台

过去，VS Code 里的聊天更像一个单线程窗口：开发者提出问题，等待模型回答，再继续追问。如果只是在代码中解释一个函数，这种方式足够。但一旦进入 Agent 模式，事情会迅速变复杂。

一个 Agent 可能在修改前端页面，另一个 Agent 正在跑测试，还有一个子智能体负责检查依赖升级。所有工作都发生在不同会话中。如果这些会话只能在一个窗口里来回切换，开发者就不得不频繁记忆上下文：刚才哪个窗口在处理登录逻辑？那个子任务有没有完成？测试失败信息究竟来自哪一次运行？

VS Code 1.134 允许开发者将聊天窗口按照水平或垂直方向并排放置。聊天记录和子智能体会话可以直接拖入不同的编辑器分组中，开发者可以在同一个工作区里同时比较结果，或者持续监控多个任务的执行进度。

这和浏览器开几个标签页不是一回事。标签页解决的是访问入口问题，并排聊天解决的是上下文对照问题。比如，左侧可以放主 Agent，让它负责整体重构；右侧放测试 Agent，观察它对修改结果的反馈；下方再放一个代码审查会话，专门检查潜在的边界条件。开发者不需要不断切换窗口，信息之间的对应关系也更清楚。

更重要的是，VS Code 会在返回会话或重新加载窗口后，恢复聊天分组布局和当前焦点。这意味着布局不再只是一次性的视觉安排，而可以变成一种稳定的工作方式。对于每天处理多个项目、多个 Agent 任务的开发者来说，这个细节比新增一个模型选项更实用。

当然，并排窗口也会带来新的管理成本。窗口一多，注意力就容易被切碎。如果没有明确的任务边界，开发者可能只是把混乱从垂直滚动改成了水平滚动。因此，这项功能真正适合的场景不是同时打开更多聊天，而是让不同会话承担清晰的角色：规划、执行、测试、审查分别放置。

提示时间线：Agent 的过程终于可以回看

Agent 编程最难审查的地方，不是最终生成了几百行代码，而是它为什么会走到这一步。

普通聊天记录通常是从上到下的一长串文本。开发者想回到早先的某个关键提示，只能不断滚动，或者依赖浏览器式搜索。对于短对话，这不算问题；但在一次持续数小时的 Agent 会话中，提示、工具调用、文件变更、错误反馈和追加要求会堆叠在一起。真正影响结果的，往往是很早之前的一句话。

新版本在智能体窗口的文本记录侧边栏中加入了提示时间线。时间轴上的每个节点对应一次提示，当前所在位置会被高亮显示。鼠标悬停时可以查看对应提示，点击节点则直接跳转到相关位置。

它的作用可以类比 Git 的提交历史，但两者关注点不同。Git 记录的是代码状态的变化，提示时间线记录的是意图和指令的变化。前者回答代码改成了什么，后者回答 Agent 是在什么要求下做出这个修改的。

这对调试 Agent 尤其重要。假设模型在重构后引入了一个看似无关的行为变化，开发者可以沿着时间线检查：是不是某一次追问扩大了修改范围？是不是开发者在中途要求模型采用了新的实现策略？是不是一次工具调用失败后，模型在没有充分上下文的情况下自行补偿？

过去，这些信息存在于聊天记录里，但不容易定位。提示时间线把长对话从一篇连续文本变成了可导航的事件序列。它不会自动提高模型的推理能力，却会降低人类审查模型行为的成本。

在企业开发环境中，这种能力还有更现实的价值。Agent 生成代码后，团队需要复盘任务是如何执行的，尤其是涉及权限、数据处理和生产配置时。提示时间线可以帮助开发者更快定位关键指令，判断问题来自需求表述、上下文选择，还是模型执行过程。

聊天中查找：Ctrl+F 终于覆盖 Agent 对话

VS Code 1.134 还把一个看似基础的能力补到了聊天工作流中：使用 Ctrl+F 搜索完整对话。

搜索范围覆盖聊天视图、聊天编辑器和客服窗口。开发者可以直接查找此前出现过的函数名、错误信息、文件路径、依赖版本或某个具体决定，不再需要在长对话里手动滚动。

这项功能并不新鲜，几乎所有编辑器和浏览器都有全文查找。但它在 Agent 场景里的意义更大，因为聊天内容已经不只是问答，而是逐渐变成项目上下文的一部分。

例如，开发者在半小时前让 Agent 解释过一个缓存失效问题，之后又连续执行了几轮重构。现在只要搜索错误码或模块名称，就能回到当时的分析位置。对于经常把 Agent 当作项目工作日志使用的人来说，聊天搜索比单纯提升回答速度更能节省时间。

不过，搜索解决的是找到内容，不是理解内容。面对长达数百轮的对话，开发者仍然需要判断哪些提示真正改变了任务方向。提示时间线和聊天搜索结合起来，才构成了相对完整的回溯路径：时间线负责定位关键节点，全文搜索负责查找具体文本。

HTML 预览：让 VS Code 更像前端调试台

这次更新还改进了本地 HTML 文件的预览流程。如果开发者经常打开 HTML 文件进行查看，而不是直接编辑源码，可以通过 workbench.editor.associations 设置，把 HTML 文件关联到 VS Code 的集成浏览器。

配置完成后，HTML 文件会直接以浏览器方式打开，而不是默认进入文本编辑器。对于静态页面、邮件模板、组件输出和 Agent 生成的前端原型，这可以减少在源码和预览之间来回切换的动作。

相关配置可以写成：

{
  "workbench.editor.associations": {
    "*.html": "workbench.browser"
  }
}

这并不等于完整替代 Chrome、Edge 或专业浏览器调试工具。复杂的网络请求、性能分析、扩展兼容性和跨浏览器问题，仍然需要真正的浏览器开发者工具。但对于快速检查 Agent 生成的 HTML、验证页面结构和观察简单交互，集成预览已经足够顺手。

它和前面三项聊天功能放在一起看，也有明显的逻辑：Agent 负责生成和修改，开发者需要在同一个工作区里快速检查结果。代码、对话和页面预览之间的距离越短，反馈循环就越快。

这次更新真正改变了什么

如果只看功能列表，VS Code 1.134 更像一次体验优化。但从产品方向看，微软正在把 VS Code 的 Agent 能力从单次对话推进到多任务调度和过程管理。

此前的 Agent 编程，重点是模型能否完成一个任务。现在问题变成了：开发者能否同时管理多个任务，能否知道每个任务执行到哪一步，能否在模型修改代码后快速审查，并能在出现偏差时回到关键上下文。

这也是 Agent 编程与传统代码补全的分水岭。

代码补全通常发生在光标附近，开发者的注意力集中在一小段代码上。Agent 则可能跨越多个文件，调用终端、搜索代码、运行测试，甚至创建新的工作区任务。它带来的效率提升不是把一行代码写快几秒，而是把一部分连续工作委托出去。但委托之后，监督、复核和重新分配任务就成为新的瓶颈。

并排聊天解决的是任务可见性，提示时间线解决的是过程可追溯性，聊天搜索解决的是上下文检索，HTML 预览解决的是结果验证。四项功能分别对应 Agent 工作流中的一个环节，组合起来比单独看更有价值。

从竞品角度看，VS Code 的优势依然不是某一个聊天界面，而是它拥有成熟的编辑器、终端、版本控制、调试器和插件生态。Agent 被放在这些工具旁边，能够直接使用项目文件和开发环境。微软这次更新的方向，是让 Agent 更自然地嵌入开发者已有的工作台，而不是再做一个与编辑器割裂的聊天产品。

但它也没有解决 Agent 编程的核心风险：模型可能误解需求，修改超出范围，忽略测试失败，或者在多个并行会话之间产生冲突。窗口布局和搜索能力只能让问题更容易被发现，不能替代权限控制、变更审查和自动化测试。

因此，开发者不应该把并排聊天理解成可以放任多个 Agent 同时运行。更可靠的做法是给每个会话划定边界，例如：

• 一个会话负责需求拆解和实施计划；
• 一个会话负责独立实现，并限制可修改的目录；
• 一个会话负责运行测试和定位失败原因；
• 一个会话负责审查差异，不直接提交修改。

这种分工能够减少上下文污染，也让提示时间线更有审计价值。否则，当多个 Agent 在同一批文件上并行修改时，开发者看到的只是更多窗口，而不是更高的生产力。

Codex 支持透露出的信号

本次更新的补充信息还显示，VS Code 的 Agent Host 已支持在不登录 GitHub Copilot 的情况下运行 Codex 会话，并可使用 OpenAI、ChatGPT 或其他已配置的模型提供商。

这说明 VS Code 正在逐步把 Agent 执行环境从单一账号体系中抽离出来。模型提供商、会话管理和编辑器工作区之间的边界正在变得更清晰。对开发者而言，未来更重要的可能不是某个聊天窗口长什么样，而是同一个项目能否按任务选择合适的模型，能否保留完整上下文，并能否统一查看不同 Agent 的状态和变更。

对于需要在国内直连多个模型的团队，类似工作流也意味着模型接入层的重要性会提高。无论是 GPT、Claude、Gemini 还是 DeepSeek，真正影响使用体验的，不只是模型本身，还包括会话是否可迁移、工具调用是否兼容、长上下文是否稳定，以及生成结果能否回到代码审查流程中。OpenAI Hub 这类兼容 OpenAI 格式的聚合入口，适合在模型切换频繁、又希望保留统一调用方式的开发环境里使用，但它无法替代 VS Code 对本地文件、终端和版本控制的管理能力。

结语：Agent 编程进入管理阶段

VS Code 1.134 没有发布一个新的旗舰模型，也没有用一个惊人的基准成绩重新定义编程 Agent。它做的是另一件更务实的事：把开发者在实际使用 Agent 时遇到的摩擦逐个抹平。

这次更新最值得关注的，不是某一项功能是否足够新，而是微软开始认真处理 Agent 工作流中的管理问题。模型能不能写代码，已经不再是唯一问题；开发者能不能同时理解多个会话、快速找到关键指令、检查最终产物，并在必要时介入，才决定 Agent 是否真的能进入日常开发。

从这个角度看，VS Code 1.134 是一次方向清晰的更新。它不会让所有编码任务自动化，却让人类与 Agent 的协作更接近一套可持续的工程流程。对于已经把 Agent 当作开发团队一部分的开发者，这些看似琐碎的界面和导航能力，往往比又一个聊天按钮更有用。

参考来源

• IT之家：微软发布 1.134 版 VS Code：新增并排聊天、提示时间线等功能：介绍本次更新的主要功能及发布时间。
• IT之家：VS Code 1.134 更新报道：国内可访问的相关产品资讯来源，用于补充版本背景。