VS Code 1.139：把编码 Agent 关进远程 Dev Container 里跑

2026 年 9 月，VS Code 1.139 做了一件看起来很小、实际很关键的事：它把 Dev Container 会话从「本地文件夹」扩展到了远程项目。在此之前，Agents 窗口里的 Agent 会话只能跑在本机的 Dev Container 里；从 1.139 开始，SSH、Tunnel 和 WSL 主机上的项目也能让 Agent 在容器的 Dev Container 中运行。这意味着你终于可以让 Agent 使用和项目完全一致的工具链、依赖版本与系统库，而不是把它扔在你这台笔记本上、指望它能猜对 Node 版本。

一、这次到底发布了什么

官方发布说明写得很克制：这个版本让庞大的 Agent 会话列表加载更快、把 Dev Container 支持扩展到远程项目、并改进日常编辑体验。真正的重点是第一条功能说明——Remote Dev Container sessions：在 SSH、Tunnel 和 WSL 主机上，让 Agent 跑在项目的 Dev Container 里。配套的还有会话列表改进（大型列表加载更快、一屏塞下更多会话、原地重命名）以及编辑体验优化（软换行位置的标记、避免重复输入右括号）。换句话说，这不是一个新玩具，而是把一年以来 Agent 基础设施的演进补齐了最后一个缺口。

// .devcontainer/devcontainer.json — the agent runs here, not on your laptop.
// Pin the toolchain once and every agent session inherits it, whether the
// host is your machine, an SSH box, a dev tunnel, or WSL.
{
  "name": "agent-workspace",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu-24.04",
  "features": {
    "ghcr.io/devcontainers/features/node:1": { "version": "22" },
    "ghcr.io/devcontainers/features/python:1": { "version": "3.12" },
    "ghcr.io/devcontainers/features/docker-in-docker:2": {}
  },
  "postCreateCommand": "npm ci && pip install -r requirements.txt",
  "remoteUser": "vscode",
  "containerEnv": { "AGENT_ID": "vscode-agent", "CI": "false" }
}

1.139 把 Dev Container 会话从本地扩展到远程主机

二、为什么要用 Dev Container 而不是裸远程机

为什么是 Dev Container 而不是「远程机器」？因为容器才是可复现的最小单元。远程主机只是位置，容器才是契约：镜像、特性、初始化命令、环境变量，全都能写进 devcontainer.json 并纳入版本控制。当 Agent 在一个声明式的容器里执行任务时，它看到的工具链版本、它装的依赖、它跑的命令，都和你 CI 里跑的是同一套。示例 1 就是这份契约：把 Node 22、Python 3.12 和 Docker 一块钉死，再用 postCreateCommand 做一次性初始化。容器化的最大收益不是省事，而是让「Agent 到底在什么环境里改了我的代码」这个问题有了确定答案。

// settings.json — the one setting 1.139 introduces for this workflow.
// Dev Container sessions are rolling out gradually, so you may need to
// enable it by hand before it appears in your build.
{
  "chat.agentHost.devContainer.enabled": true
}

// Then, in the Agents window, open the folder menu and choose
// "Use Dev Container". Requirements, per the release notes:
//   - the remote folder has a supported Dev Container configuration
//   - Docker is available on the remote host

三、撑起这一切的 Agent Host 架构

要让会话跨越窗口存活，靠的是 Agent Host 这套架构。官方在 2026 年 8 月的博客里解释得很清楚：Agent Host 是一个独立的进程，拥有 Agent 会话的生命周期，Agent Host Protocol（AHP）则负责连接主机与客户端。以前，本地 Agent harness 跑在每个编辑器窗口的扩展宿主里，关掉窗口就等于关掉运行时；现在会话的归属搬到了独立进程，多个窗口、Agents 窗口乃至浏览器客户端都能连到同一个主机。示例 3 展示的就是这个能力的手动版本：在远程机器上跑 code agent host，然后从任意客户端接入同一个会话。协议本身是「状态优先」的，主机负责把 harness 事件翻译成可持久化、可展示的状态，客户端断开再连上也能追平进度。

#!/usr/bin/env bash
# The Agent Host is a real process you can start yourself. Running it as a
# standalone server is what makes a session outlive the window it began in.
set -euo pipefail

# Start a headless host on the remote machine (agent sessions live here).
code agent host --port 8080 --workspace /workspace

# From any client — desktop Agents window, a browser tab, or your own tool
# built against AHP — connect to the same host and watch the same session.
# The session state is the host's, not the client's, so closing a tab
# no longer cancels an agent that is mid-task.

SSH、Tunnel 与 WSL 主机现在都能承载 Agent 会话

四、动手：那个设置与两个前提

启用方式很简单，但有两个前提。第一，打开 chat.agentHost.devContainer.enabled 这个设置——官方也说明 Dev Container 会话正在逐步放开，所以这个设置可能还没有默认开启，需要你手动打开。第二，使用处必须满足两个条件：远程文件夹要有一份受支持的 Dev Container 配置，且远程主机上要有可用的 Docker。之后在 Agents 窗口里打开文件夹菜单，选择 Use Dev Container 即可。示例 2 把设置和这两个前提都写清楚了。值得注意的是官方的措辞——这是「逐步放开」，意味着把远程 Dev Container 当作预览能力来对待，而不是当作稳定依赖。

// Guardrail 1: an agent that can reach the internet is an agent that can
// exfiltrate. If it needs a package registry, that is a dependency to name.
// Default deny, then list exactly what the workspace needs.

const egressPolicy = {
  default: "deny",
  allow: [
    { host: "registry.npmjs.org", ports: [443], scope: "workspace" },
    { host: "pypi.org", ports: [443], scope: "workspace" },
    { host: "api.github.com", ports: [443], scope: "agent", ttlMinutes: 30 },
  ],
  // Anything not listed is a finding, not a silent success.
  onDenied: (req) => audit.record({ kind: "egress_denied", ...req }),
};

五、顺手登场的 Agent Merge 与远程接入

这次一并登场的还有两个容易被忽略的能力。一个是 Agent Merge：在开启实验特性后，Agent 可以在当前会话里打开这个能力，于是你可以让 Agent 自己创建 pull request，并把它一路推过评审与 CI。另一个是远程接入，官方文档里覆盖了 SSH、dev tunnel 和浏览器三种方式，也就是你可以在手机上用浏览器连回远程主机看 Agent 的进度。这两件事组合起来，Agent 的角色就从「帮你写代码」变成了「替你把一个变更推到合并」。能力变强的同时，责任也变了——你需要能回答「它改了什么、经过了谁的批准」。

# Guardrail 2: what did the remote agent actually do while you were asleep?
# Log the session, the tool, the files it touched, and the diff hash, so
# "the agent edited my project" is a record instead of a rumour.

def record_session(session, turn, tool, files, diff_hash):
    ledger.append({
        "ts": time.time(),
        "host": session.host_kind,          # local | ssh | tunnel | wsl
        "agent": session.agent,             # copilot | claude | ...
        "turn": turn,
        "tool": tool,                       # edit, terminal, fetch, ...
        "files": files,                     # workspace-relative only
        "diffHash": diff_hash,              # reproduce, do not re-read
        "approvedBy": session.approver,     # set only when a human gated it
    })

for row in ledger.tail(20):
    print(row["host"], row["agent"], row["tool"], row["diffHash"][:12])

Agent Host 让会话跨窗口、跨设备持续存在

六、给团队的落地清单

给团队的落地清单：第一，把 Dev Container 配置当作产品资产来维护，镜像、特性、初始化命令全部进版本库。第二，明确哪些主机允许承载 Agent 会话（SSH 跳板机、指定的 tunnel 主机、WSL 发行版），其余一律默认不允许。第三，把网络出口做成默认拒绝的白名单，示例 4 给出了策略骨架，任何未声明的出口都应当产生一条审计记录而不是静默通过。第四，为每一次远程会话记录溯源字段（主机类型、Agent、轮次、工具、文件、diff 哈希、审批人），示例 5 是字段清单。第五，把 Agent Merge 接到分支保护与必需检查上，让「自动开 PR」和「自动合并」之间隔着一条人可审查的线。第六，先在预览渠道小范围试用，把远程 Dev Container 会话当成能力而非依赖。