把编码代理从编辑器窗口中拆出来
VS Code 1.144 将代理会话放入独立 Agent Host，并用 AHP 同步多个客户端；进程解耦改善续接，却不自动消除客户端工具依赖。
正文
VS Code 1.144 把 Copilot 代理会话从单个编辑器窗口移到独立 Agent Host，并公开 Agent Host Protocol（AHP），让多个客户端围绕同一份会话状态协作。对开发者而言，关键变化不是多了一个聊天界面，而是代理进程、会话状态和显示界面有了不同的生命周期：窗口可以断开，host 仍可运行；另一个客户端能够重新连接并接续会话。不过，依赖已连接编辑器扩展提供的工具仍会随该客户端断开而不可用，因此“会话不断”并不等于“所有工具一直在线”。
变化不只是把会话放到后台
VS Code 1.144 于 2026 年 10 月 28 日发布。其发布说明把 Agent Host 描述为一个独立进程，可以在本机或远程运行代理；AHP 则是 host 与客户端之间的通信协议，目标是允许不同客户端访问代理会话。VS Code 列出的客户端包括 VS Code、Copilot CLI、GitHub Copilot App 和 github.com。也就是说，界面不再必然是会话的所有者，用户可以从另一个支持的界面继续操作。
这个区分对应用架构很重要。传统的窗口内代理通常把 UI 生命周期和执行生命周期绑在一起：窗口销毁时，执行环境也可能结束。拆出 host 后，UI 负责呈现和发起操作，host 负责持有运行中的代理及会话。新客户端接入的对象不再是旧窗口本身，而是 host 所拥有的会话。这种分层使远程 host、多个客户端和后台执行有了共同的会话边界。
但这并不表示任何 VS Code 会话都会自动获得相同行为。官方架构文档区分 Agent Host 会话与 Local harness 会话：Local harness 仍由当前扩展宿主窗口承载，关闭窗口会停止正在进行的工作，也不能从另一界面继续；Agent Host 会话则由独立进程拥有。迁移或排查时，首先要确认当前会话使用哪种 harness，而不能只凭自己安装了 1.144 就推断会话已经脱离窗口。
对于正在集成代理的开发者，这次变化提供了一个可复用的架构方向：将长任务放在一个明确拥有会话的服务进程中，让轻量客户端连接和断开，而不是把执行状态留在前端组件或 IDE 窗口内。若你正在设计自己的运行入口，可以先查看平台目录中对开发工具与 API 接入能力的整理，再决定要自行实现 host，还是先接入现成客户端。
AHP 如何让多端看到同一份会话
AHP 的核心不是把聊天记录定时复制给每个客户端，而是用 host 作为状态权威。官方协议首页说明，它是一个双向、可扩展、以状态为基础的显示协议；VS Code 的架构文档进一步说明，host 管理会话状态，客户端订阅以 URI 标识的资源通道，例如 session、chat、terminal 和 changeset。连接建立后，客户端取得初始状态快照，之后接收有序 action，并通过纯 reducer 把 action 应用到本地状态。
这种模型解决的是多端协调问题。客户端发出操作后，host 可以接受、拒绝，或协调相互冲突的操作；被 host 广播的 action 再让其他客户端更新。客户端不需要假设自己是唯一的写入方，也不应把本地界面状态误当成会话最终状态。对于多人或多设备开发工具，这一点直接影响乐观更新、冲突提示和状态恢复的设计。
断线恢复也因此有明确协议语义。客户端重连时，host 可以发送客户端缺失的 action；如果缺口不适合补发，则发送当前快照。AHP 首页将其称为 reconnect and replay，并展示客户端如何把尚未确认的本地操作与 host 状态对账。实现者应把“重连成功”与“状态已经一致”区分开：在恢复期间，UI 可能仍有待确认的操作；只有收到并应用补发 action 或新快照、完成 reconcile 后，才应把客户端展示为同步完成。
如果自己实现 AHP 客户端，建议把处理流程拆为几个可测的边界：保存最后确认的序列位置；接收 action 时按协议顺序应用；重连后处理补发或快照；将待确认的本地操作与 host 的权威状态对账；冲突时展示拒绝结果而不是静默覆盖。协议提供多语言客户端和一致性测试资源，优先使用 SDK 与测试夹具，避免自行猜测 reducer 或重连的边界条件。关于模型端点、运行时和工具接入的选择，也可以对照站点目录核对具体服务支持范围，相关的 MCP 生命周期边界还可参考Agent Framework 的 MCP 客户端生命周期，但目录信息不能替代对 AHP 协议实现的验证。
独立进程带来的收益与新边界
拆分进程首先改变了执行可用性的依赖。只要 Agent Host 仍在运行，客户端窗口关闭不必然终止会话；客户端可以稍后回来读取同一份状态。VS Code 文档也明确提醒，具体环境仍须存活：本机桌面会话要求应用进程继续运行；远程自有机器要求机器和服务进程运行；云会话则由云服务管理环境生命周期。重新连接能力不是恢复已停止主机的魔法，保存的对话记录也不保证原有云环境仍存在。
另一个边界是工具的归属。连接到 host 的客户端可以贡献工具，例如浏览器工具或由已安装扩展提供的工具；host 会把工具定义加入会话，并将相应调用路由回贡献工具的客户端。这类工具要求提供它们的客户端保持连接。因此，如果长任务依赖编辑器扩展里的私有工具，关掉编辑器后代理可能仍在运行，却无法继续调用该工具。设计任务时应区分 host 自己管理的工具与客户端临时提供的工具，并决定断连时是暂停、报错，还是等待客户端重新连接。
独立 host 还意味着安全和运维责任变得可见。VS Code 文档说明，单独运行 Agent Host 时默认在 localhost 启动服务并使用连接令牌，--tunnel 可以通过开发隧道暴露服务。把 host 放到远程机器或网络边界之外时，必须检查谁能连接、令牌如何分发和轮换、workspace 权限如何限定，以及断开客户端后哪些动作仍可执行。传输协议能同步状态，不会替应用自动定义授权策略。
因此，进程解耦最适合执行时间长、需要跨界面续接，或需要把工作区执行环境与多个 UI 分开的场景。若任务很短、工具只存在于单个 IDE 窗口，继续使用窗口内 harness 可能更简单；引入 host 后还要维护进程、连接认证、版本协商和工具客户端在线状态。判断标准应是生命周期是否真的需要独立，而不是仅仅为了把“代理”部署成一个服务。
自建客户端时先划清协议责任
VS Code 1.144 的发布说明提供了一个实际入口：在 Agents 窗口使用 “Agents: Add Remote Agent Host…” 添加基于 WebSocket 的 host，并通过 code agent endpoints 查看编辑器当前运行的 host endpoints。对希望验证协议的团队，可以先连接官方 host，观察初始化、会话订阅和重连，再决定是否自建客户端或 host。这样能把协议学习与生产部署风险分开。
协议版本也需要纳入兼容策略。AHP 1.0.0 的变更记录规定，host 独立公布 1.0.0 与 0.9.0 两个兼容基线；协商辅助逻辑会在客户端提出的兼容范围内选择较高版本，并明确报告格式错误的版本提议。实际集成中，客户端不应把某个 VS Code 版本号等同于协议版本，也不应默认所有可选能力都存在。连接握手后应根据 host 声明的能力启用功能；例如 automations 或 terminals 之类的扩展能力，不应因为基础聊天可用就被视为受支持。
可以把最小验证拆成三类测试。第一类验证生命周期：关闭一个客户端后 host 与会话是否仍在、重新连接能否找到原会话。第二类验证状态一致性：两个客户端同时查看会话、发送操作时，action 顺序与冲突结果是否一致。第三类验证依赖边界：拔掉贡献浏览器或扩展工具的客户端后，确认正在进行的调用得到明确结果。测试应覆盖快照恢复和 action 补发两条重连路径，因为二者是协议允许的不同恢复结果。
对于团队工具作者，AHP 带来的直接影响是客户端和执行后端可以分别演进，但团队需要明确会话身份、状态权威、工具在线条件和权限边界。对仅消费 VS Code 的开发者，最实用的检查是确认 harness 类型、host 所在位置及任务依赖的客户端工具；对准备构建新 UI 的开发者，则要把 reducer、重连对账和能力协商当成协议实现的一部分，而不只是把 JSON-RPC 请求接通。能够断开再回来只是体验表面，真正需要验证的是会话状态仍由同一个 host 持有，并且每项工具能力仍有可达的执行方。