VS Code 1.139 为什么把远程容器扩展到更多主机

VS Code 1.139 把远程容器扩展到更多主机，重点不是“编辑器又多支持了几种远程连接”，而是让代理的实际执行环境更贴近项目。现在，通过桌面端 Agents Window 发起的会话，可以把 Agent Host 放进位于 SSH、Tunnel 或 WSL 主机上的项目 Dev Container 中；界面仍在本地，文件编辑、命令和工具链则在容器内运行。

官方发布说明：https://code.visualstudio.com/updates/v1_139

这次扩展改变的是执行位置

传统远程开发已经能让 VS Code 连接另一台机器，但代理场景多了一层要求：代理不仅要看见代码，还要可靠地调用项目指定的编译器、包管理器、命令行工具和依赖。如果代理运行在本地电脑，而项目依赖只存在于远程容器中，环境差异就会不断转化为命令失败和重复配置。

VS Code 1.139 的做法是把职责拆开：本地 Agents Window 负责交互和会话入口；SSH、Tunnel 或 WSL 主机承载工作区；项目 Dev Container 提供隔离后的工具链；Agent Host 则在容器内拥有会话，并执行文件编辑和命令。这样，代理面对的环境与开发者为项目声明的环境一致。

图1：本地界面负责控制，远程主机承载工作区，Agent Host 在 Dev Container 内使用项目工具链。

为什么要覆盖 SSH、Tunnel 和 WSL

这三类主机代表了常见但差异很大的工作位置。SSH 适合团队服务器和云端开发机，Tunnel 适合通过 VS Code 隧道访问受控环境，WSL 则把 Linux 工具链带到 Windows 本机。共同点是：代码所在的位置不一定等于桌面界面所在的位置，而项目真正需要的依赖又可能只存在于容器中。

扩大主机范围后，团队不必在笔记本、本机远程扩展环境和容器之间重复安装同一套工具。对大型仓库、需要 Linux 原生依赖的项目、依赖专用算力或靠近内部数据的工作负载，容器内 Agent Host 还能减少“本地能聊、远端不能跑”的割裂。

Agent Host 是这次变化的关键

Agent Host 是独立于具体编辑器窗口的进程，它拥有代理会话，并通过 Agent Host Protocol 与客户端通信。会话不再必须绑定某一个窗口，也就更容易放到工作区附近运行。对远程容器而言，这种客户端与宿主分离的架构尤其重要：桌面端可以关闭或切换视图，而会话的执行上下文仍由远端容器中的 Agent Host 维护。

这也说明该功能不是新的代理模型或新的代理框架。它改变的是代理所在的运行环境，不会自动替换项目的 Dev Container 配置，也不会绕过远程主机的权限、安全策略和资源限制。

最小启用路径

启用前先核对四个条件：VS Code 已更新到 1.139 系列；目标文件夹可以通过受支持的 SSH、Tunnel 或 WSL 连接访问；仓库中存在受支持的 Dev Container 配置；远程主机能够使用 Docker。缺少任一项，都无法把 Agent Host 放进项目容器。

然后在设置中启用实验开关：

{
  "chat.agentHost.devContainer.enabled": true
}

这个 JSON 只启用 Dev Container Agent Host 能力，不会替你安装 Docker，也不会生成 devcontainer.json。启用后，在 Agents Window 的文件夹菜单中选择 Use Dev Container，再为目标项目创建会话。首次运行后，应检查代理执行命令时使用的编译器、依赖版本和工作目录是否确实来自容器，并像普通代码变更一样审阅差异。

上线前要保留的门禁

首先，这是实验性能力，并采用渐进发布方式。部分用户不会默认看到开关，功能名称和行为也可能调整。其次，远程主机上的 Docker、镜像拉取、网络代理、挂载权限和磁盘空间仍是常见故障点；VS Code 只负责连接和编排，不能消除这些基础设施约束。

再次，部分由编辑器扩展提供的工具仍可能依赖已连接的客户端。Agent Host 位于容器中，并不意味着所有扩展能力都自动搬进容器。团队应把“容器内可执行的命令”和“客户端扩展提供的工具”分别列入验收清单。

图2：版本与开关、远程前置条件和能力边界需要分别核对。

哪些团队最值得采用

如果项目已经把依赖、运行时和开发工具稳定地写进 Dev Container 配置，这项能力的收益最直接：代理与开发者共享同一套环境，复现问题和审查命令都更容易。远程算力昂贵、仓库体积大、内部依赖不能下沉到个人电脑的团队，也能让执行更靠近代码和数据。

如果团队的容器配置尚不稳定，或者 Docker 权限和镜像供应链仍频繁变化，则应先治理环境，再扩大代理使用范围。否则，Agent Host 只会更快地暴露既有配置问题，而不会自动修复它们。

常见问题

它等同于 Remote-SSH 吗？

不等同。Remote-SSH 解决如何连接远程主机；这里解决的是代理是否进一步进入该主机上的项目 Dev Container 执行。两者可以组合，但职责不同。

本地 VS Code 界面也会进入容器吗？

不会。桌面 Agents Window 仍然在本地，Agent Host 和工作区相关命令在远程容器内运行。

远程主机没有 Docker 怎么办？

无法使用这一 Dev Container 路径。可以继续使用普通远程 Agent Host，或先按组织安全规范部署受支持的容器运行环境。

为什么设置打开后仍看不到选项？

先确认版本、Agents Window、远程连接类型、项目容器配置和 Docker 状态。由于功能仍在渐进发布，界面入口也可能尚未对当前环境完全开放。

结论

VS Code 1.139 扩展远程容器支持，本质上是在统一代理、代码和工具链的执行边界。SSH、Tunnel 与 WSL 只是承载位置，真正的价值来自 Agent Host 可以进入项目声明的 Dev Container。对已经容器化开发环境的团队，这是减少环境漂移的一步；对尚未稳定管理容器配置的团队，则应把它视为需要门禁的实验能力，而不是一键式远程自动化。