VS Code Agent Host 为持久智能体会话提供了什么

VS Code Agent Host 的核心价值，是把智能体会话从某一个编辑器窗口的生命周期里拿出来，交给独立进程持有。这样，同一会话可以在编辑器窗口、Agents 窗口和浏览器客户端之间继续查看与控制，也可以把执行位置放到靠近工作区的远程机器上。

官方介绍：https://code.visualstudio.com/blogs/2026/08/26/agent-host-architecture

架构文档：https://code.visualstudio.com/docs/agents/concepts/agent-host

Agent Host 解决的不是“换一个更聪明的模型”，而是长时间智能体任务的会话归属、状态同步和执行位置问题。AHP 统一客户端看到的会话状态，但不会统一不同 agent harness 的推理方式、上下文策略和工具实现。

旧边界的问题：会话跟着编辑器窗口走

一个常见场景是：开发者在项目窗口里启动较长的重构任务，随后关闭该项目、切去另一个工作区，或想在独立的 Agents 窗口继续观察。过去，本地 agent harness 运行在每个编辑器窗口的 extension host 中，窗口关闭会让相应运行时失去依托，而且多个窗口会各自加载一套智能体基础设施。

这对短对话影响不大，但对持续数十分钟、需要多次审批和审查改动的任务很不自然。会话数据、运行循环和界面展示被绑在同一个进程边界里，导致“关掉展示界面”和“停止实际任务”很难分开。

新的所有权：Agent Host 持有会话

Agent Host 是专门运行智能体会话的进程。它可以作为本地 VS Code utility process 运行，也可以作为远程机器上的独立服务器运行。编辑器窗口、Agents 窗口和浏览器不再各自拥有一份会话，而是作为客户端连接同一个 Host。

这个调整带来五个直接变化：

• 会话与窗口解耦：关闭启动会话的文件夹或窗口后，会话不必随之消失；
• 多客户端共享：多个 VS Code 窗口可以观察和控制同一会话，而不是复制一份；
• 执行靠近工作区：Host 可以在本机、远程主机或 Dev Container 中运行，文件修改和命令发生在 Host 所在环境；
• 独立进程资源边界：智能体不会因为 extension host 忙于其他扩展而处在同一条关键路径上；
• 多 harness 基础：Copilot、Claude、Codex 等运行时可保留各自能力，再通过适配器映射到共同会话模型。

这里的“持久”需要准确理解。官方说明中，本地会话关闭文件夹后仍可继续，但本地 Host 由 VS Code 管理，因此本地任务要继续运行，VS Code 本身仍需保持运行。远程 Host 则可以在远程开发机上保持活动，客户端断开后，运行中的会话仍由远端 Host 持有。

AHP 如何让多个客户端看到同一状态

Agent Host Protocol（AHP）是 Host 与客户端之间的开放、agent-agnostic 协议。它把 Host 设为权威状态源，客户端订阅 URI 可寻址的资源通道，例如 sessions、chats、terminals 和 changesets。

客户端连接时先获得当前状态快照，随后接收有顺序的状态动作；断线重连后，可以补收遗漏动作，或重新取得快照。这样，编辑器窗口、Agents 窗口和浏览器客户端可以收敛到同一会话视图，不需要各自理解 Copilot SDK、Claude Agent SDK 或其他 harness 的内部事件格式。

当前文档还给出了通信边界：本地 VS Code 与 Host 使用 message port，远程连接使用基于 WebSocket 的 AHP JSON-RPC。协议强调同步后的会话状态，而不是把某个厂商 SDK 的原始事件直接暴露给所有客户端。

本地、远程和浏览器各自扮演什么角色

独立 Host 还可以通过 code agent host 启动；默认监听本机并使用连接令牌保护，使用 --tunnel 时可通过开发隧道暴露。真正部署前仍应按官方文档确认连接方式、令牌管理和网络边界，不应把“能远程连接”理解成默认对公网开放。

多 harness 统一的是会话体验，不是智能体大脑

Agent Host 内部通过 adapter 连接不同 agent harness。适配器把各自的 sessions、tools、permissions、subagents 等能力映射到 AHP 的共同会话模型，但 harness 仍保留自己的 SDK、agent loop、上下文管理、命令和 provider 特性。

这一区分很重要：AHP 不是用来替代 MCP，也不是新的模型调用协议。MCP 关注模型如何接入外部工具和数据；AHP 关注多个客户端如何围绕同一长时间会话共享状态、发送动作和恢复连接。两者可以同时存在于一套智能体开发环境中。

客户端还能贡献自己的工具，Host 会把工具定义加入活动会话，并把调用路由回提供该工具的客户端。但这也意味着：依赖浏览器能力或某个扩展提供的工具时，相关客户端和扩展仍需要在线；不能因为会话在 Host 中持久存在，就假设所有客户端工具也永久可用。

采用前先看清这些边界

• 仍在持续演进：VS Code 官方明确标注 Agent Host 与 AHP 正在积极开发，能力和设置会继续变化；
• 改动审查方式不同：Agent Host 会话可直接把编辑写入会话文件夹或 worktree，完成后应审查 diff，再决定提交、合并或丢弃；
• 旧会话不会自动迁移：仍在 extension host 中运行的既有会话会继续留在那里，两种运行方式可能同时存在；
• 自定义配置位置有差异：Host 更倾向读取 harness-agnostic 的配置目录，不能假设所有只存于 VS Code profile 的旧配置都会被运行时读取；
• 远程执行改变信任边界：Host 靠近代码和依赖运行，远程主机的权限、凭据、网络和日志都应纳入审查。

哪些团队最能感受到收益

如果任务只是几秒钟的补全或一次性问答，Agent Host 的架构优势不一定明显。真正受益的是长时间重构、多分支并行、远程构建、需要多次人工审批，以及希望在桌面与浏览器之间接力管理会话的团队。

评估时可以观察三个指标：关闭项目窗口后任务是否能按预期延续；多个客户端看到的状态和审批是否一致；远程 Host 的文件、命令与变更审查是否落在正确环境。三个条件都满足，才说明会话所有权、同步链路和执行位置真正分离成功。

从更大的开发工具趋势看，Agent Host 把“智能体聊天”推进成了可被多个界面共同管理的持续会话。它提供的是运行和协作底座，而不是替开发者消除权限、审查与环境治理；越是长时间、跨设备的任务，越需要把这些边界设计清楚。