在 VS Code 里自由切换 Copilot、Claude、Codex、OpenCode、Pi、Kimi、Qwen：任何 Agent 都能接

现在的 AI Coding Agent，已经多到让人开始犯选择困难症了。

写代码可能想用 GitHub Copilot，复杂重构想试 Claude Code，某些任务更适合 Codex，喜欢开放生态的会用 OpenCode，还有 Gemini CLI、Qwen Code、Pi、Kimi、Auggie……

问题是，每个 Agent 都有自己的 CLI、配置、Session 和交互方式。你不是在选择 Agent，而是在反复切换一整套工作环境。

我一直在想一件事：为什么不能把 VS Code Agent Window 变成一个通用入口？

Folder 还是那个 Folder，Files、Terminal、权限确认、Session 历史也都留在同一个界面里。需要哪个 Agent，就像切换 Model 一样直接选择。

于是，我做了 AHP-ACP Gateway。

项目地址：

https://github.com/formulahendry/ahp-acp-gateway

它已经发布到 npm，也已经进入 Microsoft Agent Host Protocol 官方的 implementations 列表。

这不是“再做一个 Agent 插件”

AHP-ACP Gateway 的目标，不是给 VS Code 增加某一个 Agent。

如果只接 GitHub Copilot，可以写一个 Copilot 专用适配器；只接 Claude Code，也可以再写一个 Claude 专用插件。这样做短期很快，但 Agent 每增加一个，Client、Session、权限和 UI 都要重新适配一次。

我更想解决的是协议两端的解耦：

上面可以是 VS Code，也可以是其他 AHP Client；
下面可以是 Copilot、Claude、Codex，也可以是任何兼容 ACP 的 Agent；
中间的 Gateway 负责 Session、状态、进程和协议转换。

换句话说，Client 不需要理解每个 Agent 的私有实现，Agent 也不需要专门适配每一种 UI。

这才是“Universal Agent Host”真正有价值的地方。

AHP 管 Session，ACP 接 Agent

这套架构里有两个关键协议：AHP 和 ACP。

AHP（Agent Host Protocol）解决的是 Client 和 Agent Host 之间怎么协作。

它关心的不是某个模型如何生成 Token，而是更上层的问题：Session 在哪里、当前状态是什么、多个 Client 如何看到同一段对话、断线后怎么恢复、工具和权限状态如何同步。

这意味着 AHP 天然适合做 Remote Agent Host。

Agent 可以运行在另一台机器、开发服务器，甚至一个长期运行的 Gateway 上。VS Code 只是连接它的一个 Client。另一个 AHP Client 也可以观察同一个 Session，实时收到相同的状态变化。

ACP（Agent Client Protocol）解决的是 Client 或 Host 如何用统一方式控制 Agent。

启动 Session、发送 Prompt、流式接收回复、展示 Tool Call、请求权限、取消任务、切换 Model、Mode 和 Reasoning，这些能力都可以通过统一协议完成。

所以，两者组合起来的数据流非常清楚：

AHP Client
    ↓
AHP-ACP Gateway
    ↓
ACP Agent

AHP 让上层 Client 可替换，ACP 让下层 Agent 可替换。

Gateway 把这两个方向连接起来。

这两个协议放在一起，还有一个很容易被忽略的好处：能力可以独立演进。

VS Code 想改 Session UI，不需要等待每一个 Agent 跟着升级；某个 Agent 新增 Model 或 Reasoning 选项，也不需要为每个 AHP Client 单独写插件。Host 负责把两边的协议状态对齐，Client 和 Agent 都只需要做好自己的一半。

过去增加一个 Agent，往往意味着重新做一套集成。现在增加一个 Agent，可以退化成一件简单得多的事：告诉 Gateway 应该执行什么 command，以及它会通过 ACP 暴露什么能力。

VS Code 终于可以“选 Agent”了

连接 Gateway 后，VS Code Agent Window 里会出现一个 Agent picker。

你可以选择 GitHub Copilot、Claude Code、Gemini CLI、Qwen Code、Auggie、Qoder CLI、Codex CLI、OpenCode、OpenClaw、Kiro CLI、Hermes Agent、Kimi CLI、Pi ACP。

这些只是项目自带的默认配置，不是能力上限。只要一个 Agent 兼容 ACP，就可以通过配置加入。

这里的“切换 Agent”，准确来说是在创建 Session 时选择 Agent，或者在不同 Agent Session 之间切换。每个 Session 仍然拥有自己的上下文和 ACP binding，不会把 Claude 的对话上下文凭空塞给 Codex。

这样的边界反而更合理：UI 和 Workspace 可以统一，但不同 Agent 的上下文、能力和生命周期仍然彼此隔离。

选中 Agent 后，Gateway 会启动对应的 ACP 进程，再把它提供的 Model 和 Session Config Options 映射到 VS Code。

因此，界面里不只是能选 Agent：

原生 Model picker 会显示 Agent 提供的 Model；
Mode、Reasoning、权限策略等配置会出现在 Session controls；
Tool Call 和权限请求会使用 VS Code 的交互界面；
Agent 产生的文本、Reasoning、Plan 和 Tool 状态会实时流回来；
Files 面板可以浏览并打开远程 Workspace 文件。

这里有个很重要的细节：Model 切换不是只改 UI。

Gateway 会把 VS Code 选择的 Model 通过 ACP Session Config Options 真正写回 Agent Session。也就是说，你看到的选择和 Agent 实际使用的 Model 是同一份状态。

一条命令跑起来

AHP-ACP Gateway 要求 Node.js 24 或更新版本。

不需要先下载配置文件，也不需要全局安装，直接运行：

npx --yes ahp-acp-gateway

默认会启动：

ws://127.0.0.1:8765/ahp

然后打开 VS Code 的 User Settings JSON，加入：

{
  "chat.remoteAgentHosts": [
    {
      "name": "AHP-ACP Gateway",
      "address": "127.0.0.1:8765/ahp"
    }
  ]
}

如果已经有 chat.remoteAgentHosts，把这一项合并进去，不要重复创建同名配置。

接着通过 Command Palette 运行：

Chat: Open Agents Window

也可以直接执行：

code --agents

在 Agent Window 中：

点击 New；
选择要工作的 Folder；
选择 AHP-ACP Gateway；
在 Agent picker 里选择 Agent；
选择 Model 和其他 Session 配置；
发送 Prompt。

部分 Agent 需要先完成自己的登录。例如 Qoder CLI 可以运行：

npx --yes @qoder-ai/qodercli login

默认使用 npx 的 Agent 会在第一次真正创建 Session 时按需下载。只启动 Gateway，不会立刻下载或执行所有 Agent。

想接自己的 Agent，也只是加一段配置

项目内置了主流 Agent，但真正有意思的是，你可以把自己的 ACP Agent 加进去。

例如：

{
  "version": 1,
  "providers": [
    {
      "id": "my-agent",
      "displayName": "My ACP Agent",
      "description": "My own coding agent.",
      "command": "my-agent",
      "args": ["acp"]
    }
  ]
}

然后运行：

npx --yes ahp-acp-gateway --config ./gateway.json

VS Code 不需要知道 my-agent 内部用了什么模型、框架或者 Runtime。只要它会说 ACP，Gateway 就能把它暴露成 AHP Agent。

这也是为什么标题里虽然写了 Copilot、Claude、Codex、OpenCode 和 Pi，项目真正想做的却不是维护一份越来越长的 Agent 白名单。

目标是让 Agent 接入变成协议问题，而不是重复开发 UI 集成。

Gateway 不只是转发 JSON

如果只是把 AHP 消息改成 ACP 消息，写一个无状态 Proxy 并不难。

真正麻烦的是：Agent Session 是有状态的。

Client 可能断线，Host 可能重启，Tool 正在执行，权限请求还没回答，两个 Client 可能同时观察同一个 Session。此时只做消息转发，很快就会出现状态分裂。

所以 AHP-ACP Gateway 自己维护权威状态：

所有 Action 都有单调递增的 serverSeq；
Session、Chat、Transcript 和 ACP binding 会写入 SQLite；
Client 重连时可以 replay 丢失的 Action；
replay 窗口不够时会返回完整 Snapshot；
Host 重启后会恢复 Session 和已完成的 Transcript；
尚未完成的 Turn 会被明确标记为 interrupted，而不是假装成功；
多个 AHP Client 可以订阅并观察同一个 Session；
权限请求坚持 first-answer-wins，不会自动批准。

它管理的也是 Agent 进程生命周期。

默认每个 AHP Chat 对应一个 ACP subprocess。Agent 异常退出、启动超时、Prompt 超时或者忽略 Cancel 时，Gateway 会终止并淘汰失效进程，避免上一轮的迟到消息污染下一轮对话。

这部分不太适合出现在漂亮的 Demo 截图里，却决定了 Gateway 能不能长期运行。

从本地入口到 Remote Gateway

默认配置只监听 127.0.0.1，适合直接在本机使用。

但 AHP 的价值并不局限于 localhost。

当 Gateway 部署到开发机、服务器或远程 Workspace 后，VS Code 仍然可以通过 WebSocket 连接。Agent 进程、Session 状态和项目目录都留在远端，本地只承担 Client UI。

例如，你可以把 Gateway 放在一台配置好依赖、凭据和开发工具的 Dev Box 上。办公室电脑使用 VS Code 创建 Session，回家后再从另一个 AHP Client 查看进度，两个 Client 看到的仍然是 Host 上那份权威状态。

也可以做一个专门的观察端：它不负责写代码，只订阅 Session，展示 Agent 正在执行的 Tool、等待中的权限请求和最终结果。这正是把 Session 从某个编辑器窗口中独立出来之后，才会自然出现的能力。

这会带来几个很实际的变化：

不同设备可以连接同一个 Agent Host；
多个 Client 可以实时共享和观察 Session；
Agent 不需要随着编辑器窗口关闭而消失；
计算环境、代码和工具可以留在远程机器；
Client 重启后可以重新连接并恢复状态。

非本地部署时，Gateway 会要求配置 Token 和 TLS termination，不允许把一个无认证的 Agent Host 直接暴露到网络上。

AHP 在这里不是多套了一层协议，而是把 Agent 从“编辑器中的一次性功能”变成了可以独立运行的服务。

目前还有哪些边界

这是 0.1.0 的 MVP，不是一个已经包办所有 Agent 场景的平台。

当前重点是最核心的闭环：Session、默认 Chat、流式回复、Reasoning、Tool、权限、Cancel、Model、配置、重连、持久化、文件读取和基础 Terminal。

一些能力仍然留在后续版本：

多 Chat 和 Fork；
writable resource；
真正的 PTY 和 Terminal command detection；
Changeset；
MCP forwarding；
Attachment 和图片输入；
多用户策略和内置 Sandbox。

Gateway 本身也不是 Sandbox。ACP Agent 继承运行 Gateway 的系统账号权限，运行不可信 Agent 时仍然应该放进容器或其他隔离环境。

把边界说清楚，比在 README 里堆满“支持一切”更重要。

已经进入 AHP 官方实现列表

AHP-ACP Gateway 已经合入 Microsoft Agent Host Protocol 官方 implementations 列表，分类是 AHP Server。

AHP 官方仓库：

https://github.com/microsoft/agent-host-protocol

官方实现列表：

Agent Host Protocol

这件事对我来说挺重要。

因为它说明这个项目不只是“能在我的电脑上跑起来”，而是开始成为 AHP 生态中的一个公开实现：任何 AHP Client 都可以连接，任何兼容 ACP 的 Agent 都可以被接入。

项目也已经发布到 npm：

https://www.npmjs.com/package/ahp-acp-gateway

当前稳定版可以直接运行：

npx --yes ahp-acp-gateway@latest

现在就试一下

如果你想体验，最短路径只有三步：

# 1. 启动 Gateway
npx --yes ahp-acp-gateway

# 2. 在 VS Code 中配置 chat.remoteAgentHosts

# 3. 打开 Agents Window，选择 Folder、Agent 和 Model

如果你已经在写 ACP Agent，也欢迎直接把它接进来试试。遇到兼容问题，可以提 Issue；如果你希望新增默认 Provider，也可以提交 PR。

最重要的是，如果你也认同“编辑器不应该绑定某一个 Agent，Agent 也不应该绑定某一种 Client”，欢迎来 GitHub 给项目点个 Star。

项目地址：

https://github.com/formulahendry/ahp-acp-gateway