人工智能分析阅读约 9 分钟

VS Code 1.144 让编码会话不再受笔记本开合限制

持久智能体主机和云会话改变了编码任务在客户端断开连接后如何继续。什么是稳定的,什么是预览版,以及如何在不丢失更改的情况下测试交接。

K
Ken Jo

您在办公桌上开始一项编码任务,从另一台设备上检查它,然后返回以查看差异。理想体验是同一项工作持续进行,沿用相同指令,并让决策保持可见。每次设备更改后重建对话是开发工作的另一种形式。

VS Code 1.144于2026年10月28日成为稳定版本。 其发行说明将智能体会话连续性和远程管理以及带有自己的预览或实验标签的功能结合在一起。云会话在 GitHub 基础设施上运行,因此当开发笔记本电脑离线时,它们的执行可以继续。 官方发行说明。

本指南解释了客户端和工作运行地点之间的区别、Agent Host Protocol 的贡献以及如何通过真实的代码审查交接来评估持续会话。

Visual Studio Code 1.144 的官方远程环境屏幕截图。 Visual Studio Code 1.144 的官方远程环境屏幕截图。 Used with permission from Microsoft. 图片来源 · 许可与图片说明。

关闭窗口和停止工作进程是不同的事件

编码界面显示消息、文件和审批请求。执行任务的进程可能位于其他地方。一旦这些角色分离,关闭界面并不一定意味着放弃任务,只要主机及其环境仍然可用。

Microsoft 10 月 28 日 Universe 大会概述 将智能体主机描述为管理会话、执行框架、模型、文件和终端的独立进程。它表示 Agent Host Protocol 已达到 1.0 并将客户端连接到持续的会话状态。对于评估“继续工作”的实际含义来说,这是一个有用的架构区别。

本地主机仍然依赖于本地机器。远程主机取决于其远程计算机和连接安排。云会话具有单独托管的环境。根据客户端离开时需要保持可用的位置来选择执行位置。

将客户端视为控制室窗口。另一个窗口可以显示相同的工作,但它不会移动其下方的机械。显示会话的电话不会将休眠的本地计算机变成始终在线的服务器。

我们的看法:当任务身份能够随执行一起保留时,持久性就会变得有用。持续的会话应该明确它使用哪个代码仓库、它产生了哪些更改以及它正在等待什么决定。仅仅保持一个进程的活力是一个较小的成就。

客户端接口、智能体会话和本地、远程或云执行主机之间的概念分离 客户端与主机职责的原创说明图,由 VS Code Universe 大会概述。它是一个简化的规划模型,而不是网络拓扑。

AHP 同步各界面所查看的会话状态

官方 Agent Host Protocol 官方网站,11 月 2 日检查,将 AHP 描述为一种双向、基于状态的界面协议。客户端在共享会话状态下运行;主机广播行动并仲裁冲突。重新连接可以提供错过的操作或当前快照,以便接口可以赶上。

这很重要,因为智能体会话包含的不仅仅是文字记录。它可能包括等待批准的操作、正在运行的终端或更改的文件。如果两个界面显示这些事实的版本不一致,则即使代码生成本身良好,操作会话的人员也可能做出错误的决定。

该协议的重新连接示例显示待处理的客户端操作与主机状态一致。对于读者来说,实际含义很简单:重新连接应该恢复作业的当前状态,包括先前请求的处理结果。它不应该需要猜测在网络失败之前是否已获得批准。

共享协议还为客户端互操作性创建了边界。客户端需要了解会话状态及其显示的操作。协议的存在并不意味着每个工具都可以连接到每个提供商或以相同的方式公开每个功能。

对于比较界面的团队,检查其工作流程中重要的决策。备用客户端可以显示待处理的权限请求吗?它可以识别更改的文件和任务的当前状态吗?返回编辑器是否会保留相同的工作而不是开始第二次对话?

稳定发布和预览能力是单独的标签

VS Code 的 1.144 页面将该版本标识为稳定版,而 云自动化、图像生成和 Copilot 连接器 保留预览标签;计算机使用和工作集功能被标记为实验性的。云会话体验需要付费 Copilot 套餐,并受组织政策的约束。 发布和功能状态,10 月 28 日,11 月 2 日检查。

这种组合在可扩展编辑器中很常见:稳定的应用程序可以包含不同成熟度级别的单独功能。正确的采用决策属于功能和工作流程,而不仅仅是版本号。

执行选择必须保持可用的内容开始前的问题
本地智能体主机本地执行环境当这台机器休眠或停止时会发生什么?
远程智能体主机远程主机和所需的服务谁负责可用性、访问权限和工作区状态?
云会话提供商管理的执行环境此代码仓库、套餐与组织政策是否允许执行该任务?

该表是操作比较,而不是跨环境的相同行为的承诺。特定扩展、模型和执行框架的要求仍然很重要。测试您的团队打算使用的组合。

对于实验能力,选择单独的、可逆的练习。对于核心连续性评估,请从演示交接的最小工作流程开始。结合多个新功能使识别哪个部分产生意外结果变得更加困难。

三个说明性任务显示了连续性的帮助

开发人员可以移交边界明确的修复任务并稍后进行审查

想象一下,开发人员要求云会话修复代码仓库中失败的解析器测试。该指令列出了故障、相关行为和预期验证。然后,开发人员检查另一个受支持客户端的进度,然后返回编辑器进行审核。

接受标准应与任何更改相同:修复解决行为、相关检查通过并且差异适当。在笔记本电脑关闭时继续工作的能力非常有用,因为它会改变工作可以发生的时间。它并不表明结果已准备好合并。

对于交接,要求会话保留测试的确切命令和结果。一条“测试已通过”的消息比与特定修订版相关的命名检查更难评估。审阅者需要足够的证据来理解结果,而无需重建整个对话。

如果任务因批准或缺失服务而被阻止,则会话应公开该状态。保持活跃但无法进展的工作与做有用工作的工作不同。可见性可以帮助开发人员决定是否进行干预、更改范围或让任务等待。

维护人员可以调查单独的问题,而无需混合文件

示例维护人员可能会要求一个会话重现错误,而另一个会话则检查文档。如果任务有明确的界限,这可以充分利用等待时间。它还需要将每个结果附加到其自己的工作区和审查上下文。

在开始之前定义所有权。命名文件或子系统、分支或工作区以及每个会话应生成的内容。如果两项任务必须涉及同一接口约定,请在应用两项更改之前决定如何协调它们的发现。

根据已知代码仓库状态查看一项结果。否则,成功的测试可能取决于另一个会话未经审核的编辑。工作区边界很有价值,因为它使通过结果的来源更容易确认。

回报是更清晰的审核队列,而不仅仅是更多的同时智能体。两项范围边界清楚的调查可以减少不确定性;多次重叠编辑可以增加它。智能体界面在帮助维护人员了解各项工作的进展时非常有用。

团队可以先验证周期性云任务,再信任定时执行

对于说明性自动化试点,请考虑定期审查以识别需要注意的文档链接。从只读报告和特定输出开始。在扩展任务以进行更改之前,让一个人检查结果。

Cloud Automations 的预览状态在这里很重要,因为重复性工作增加了另一项运营职责。一次表现可接受的任务在按按计划运行之前可能仍然需要速率控制、所有权和对失败的明确响应。将这些要求与其语言输出的质量分开测试。

团队应该知道每次运行在哪里记录其代码仓库修订、结果和外部请求。如果运行无法完成,记录应说明尚未解决的问题。当重复任务的所有者能够区分确实没有变化与检查失败时,重复任务就会变得有用。

从一个代码仓库和适度的范围开始。仅在团队观察到普通运行、故意阻止的运行以及对结果产物的审查后才进行扩展。这些是拟议的试点步骤,而不是声称要对版本进行实际测试。

您未提交的工作需要明确的交接

1.144 发行说明指出,云会话使用单独的工作区,并且 不自动复制本地未提交的更改。在“聊天”或“智能体”窗口中,用户可以选择“云”,选择 GitHub 代码仓库、跟进、响应批准并审查更改;可以从会话列表中重新打开现有会话。 云会话说明。

对于任何在有大量进行中工作的检出目录工作的人来说,独立的工作区是一个重要的事实。本地文件对于任务来说可能是必不可少的,即使它不存在于云会话看到的代码仓库状态中。在移交之前,确定预期的源版本以及提供任何附加材料的授权方式。

不要将界面转换与文件传输混淆。继续相同的对话并不能证明每个本地文件或正在运行的服务都已移动。会话可以保留其意图,同时仍然需要显式访问执行它所需的材料。

对于说明性错误报告,请以经批准的、可重现的形式包含失败的输入。说明智能体商是否应使用已提交的测试样例或新提供的材料。这为会话提供了一个具体的起点,并避免对从未包含问题的代码仓库状态进行长时间调查。

最终审查应反向检查同一边界。确定提议的更改所在的位置以及它们将如何进入工作分支。在查看和应用结果时保留活动的本地编辑。远程工作区的好处不应以牺牲本地工作的不确定性为代价。

通过任务执行、重新连接、证据审查和接受的差异对已知修订进行拟议的连续性检查 持续编码任务的原创验收流程。它结合了已记录的 云工作区边界 与常规工程审查结合;它没有报告独立测试结果。

十分钟浏览不足以验证任务完成

评估连续性的可见部分很容易:会话出现在列表中、客户端重新连接、消息到达。这些都是有用的检查,但开发人员的目标是完成一项工作,其状态在交接中保留下来。

选择一个可以通过可检查产物完成的小任务。如果代码仓库有明显的检查,测试样例、文档更正或孤立的行为修复就可以发挥作用。该任务应该足够有意义,能够公开工作区状态和权限,而不会使第一次试验变得不必要的广泛。

  1. 更新并验证已安装的版本。 使用 VS Code 的检查更新流程并确认版本。查看官方说明中特定于功能的标签。
  2. 选择授权的执行环境。 确认代码仓库访问、套餐资格和组织政策。确定任务属于本地、远程还是云主机。
  3. 记录起始状态。 请注意代码仓库和修订版本。保留本地更改并确定所选工作区所需的任何输入。
  4. 给出有界指令。 命名所需的行为、范围和验证命令。定义您希望查看的产物。
  5. 练习交接。 离开客户端并通过可用的支持接口重新连接。检查同一会话的状态、待审批事项和新工作。
  6. 回到代码。 检查差异和验证证据。确认检查适用于正在审查的修订。
  7. 记录结果和剩余限制。 将成功的重新连接、已完成的任务和已接受的更改分开。它们是具有不同证据的相关里程碑。

如果测试失败,则诊断失败的边界。缺少代码仓库测试样例需要修复工作区;被阻止的工具调用需要做出权限决定;不可用的主机需要执行环境决策。重复相同的提示很少能解决提示之外的问题。

保持第一个结果具体。 “这项任务在这种环境下继续进行,并产生了这个经过审查的差异”是一个有用的操作结论。它告诉同事哪些内容可以重复以及哪些条件很重要。

持久会话应让职责更容易追踪

VS Code 1.144 将更多的智能体工作流程放入连续的工作区中:指令变成操作,操作变成可审查的更改的地方。 AHP 为客户端提供共享状态方向,而执行位置则决定设备断开连接后哪些内容可以继续运行。

真正有意义的升级,是你可以暂时离开、稍后回来,却依然能理解这项工作的状态。当会话保留其源状态、决策和验证时,笔记本的开合就只是时间安排的细节,而不再是工作的边界。

来源

保留决策背后的材料

Telli.sh 是一个选择,可将获准保存的原始资料与审阅后的笔记放在一起。 创建笔记工作区。


← 返回博客