每日突破性工具推薦｜Agent Host Protocol（AHP）

工具定位

Agent Host Protocol（AHP） 是 Microsoft 在 2026 年公開並持續推進的開放式 AI Agent Session 協定，目標不是定義模型怎麼推理、怎麼呼叫工具，而是解決更上層的問題：長時間執行的 Agent Session，要如何被多個客戶端共同觀察、控制、斷線重連、遠端執行，並且在不同 Agent Harness 之間維持一致的 Session 體驗。

它目前已實際用在 VS Code 的 Agent Host 架構中。VS Code 將 Copilot、Claude 等 Agent Harness 從傳統 extension host 抽離到獨立 Agent Host process，讓 Agent 工作不再綁死單一編輯器視窗。

AHP 適合的不是一般聊天機器人，而是正在建立 IDE Agent、Coding Agent、Agent Desktop、Remote Agent、長時間 Agent Workflow 或多客戶端 Agent 平台 的團隊。

為什麼近期值得推薦

AHP 的價值在 2026 年 8～9 月開始明顯浮現：

• Microsoft 正式公開 Agent Host 架構與 AHP，並將其放進 VS Code Stable。
• AHP 0.9.0 已加入 Automation catalogue、automation-run channels、可恢復的 turn error 等長時間工作流能力。
• 官方已提供 TypeScript、Rust、Go、Kotlin、Swift、.NET 等多語言 Client SDK。
• VS Code 1.136 持續擴大 Agent Host 的多視窗與遠端工作能力。
• 協定開始明確區分 AHP 與 ACP：ACP 處理 client-to-agent 的一對一通訊；AHP 則負責多 Client 共享同一個 Agent Session 的協調與同步。

這使 AHP 不只是「VS Code 內部協定」，而開始具有成為 Agent Session Coordination Layer 的潛力。

突破性重點

1. 將 Agent Session 從 IDE 視窗生命週期中解耦

傳統 Coding Agent 常見架構是：

IDE Window
    │
    ↓
Extension Host
    │
    ↓
Agent Runtime

一旦視窗關閉、Extension Host 重啟或 IDE 發生問題，Agent Session 也容易跟著中斷。

AHP / Agent Host 改成：

IDE Window A ─┐
IDE Window B ─┼──→ Agent Host ───→ Agent Harness
Browser UI   ─┘        │
                        └── Owns Session State

Agent Host 本身成為 Session 的真正 Owner；Client 只是 Viewer / Controller。

這個邊界改變非常重要，因為它讓 Agent 從「IDE 功能」進一步變成「可持續執行的工作負載」。

2. State-first，而不是 Message-first

很多 Agent Protocol 主要描述：

Request → Response
Prompt → Stream
Tool Call → Result

AHP 則把核心放在 共享狀態同步。

Host 維護 authoritative state，Client 訂閱 URI-addressed channels，例如：

• sessions
• chats
• terminals
• changesets

Client 首先取得 snapshot，之後再接收有順序的 actions。

概念上是：

Snapshot
   │
   ↓
Action 1
   ↓
Action 2
   ↓
Action 3
   ↓
Reducer
   ↓
Consistent State

這使多個 Client 可以收斂到相同狀態，不必各自理解特定 Agent SDK 的內部事件。

3. 使用 immutable state + pure reducers

AHP 的狀態模型大量採用前端熟悉的 Redux-like 思路：

Current State
+
Action
↓
Pure Reducer
↓
New State

這種設計帶來幾個明顯優勢：

• 狀態變化可重播。
• 多 Client 容易一致化。
• 斷線後可以補送 missed actions。
• Client 不必直接操作 Agent Runtime internals。
• Debug 與 deterministic synchronization 更容易。

對長時間 Agent 來說，這比單純 websocket event stream 更可靠。

4. Multi-client 是一級能力

AHP 最具差異化的一點，是它從一開始就假設：

1 Agent Session
≠
1 Client

而是：

               ┌── Desktop IDE
               ├── Agents Window
Agent Session ─┼── Browser
               ├── Mobile / Remote UI
               └── Automation Controller

多個 Client 可以同時觀察與控制 Session。

這種模型非常適合未來的 Agent 工作方式：Agent 可能在工作站執行，人類在筆電、瀏覽器或手機查看狀態；另一個自動化系統則只關注批准、狀態或變更集。

5. Remote Agent 不再只是 SSH Terminal

Agent Host 可以直接部署到遠端 Workspace 旁邊，Client 再透過 WebSocket / SSH / dev tunnel 連線。

Local UI
   │
   ↓
AHP
   │
   ↓
Remote Agent Host
   │
   ├── Source Code
   ├── Shell
   ├── Git
   └── Agent Harness

這比「Local Agent SSH 到遠端」更合理，因為 Agent Runtime、檔案與開發工具都可以保持在資料所在地附近。

6. Agent Harness 與 Client UI 真正解耦

AHP 不規定 Agent 如何推理。

Copilot 可以有自己的 SDK、Loop、Tool 與 Context；Claude 也可以保留 Anthropic 的 Agent SDK 與特定能力。

中間只需要 Adapter：

Copilot SDK ─┐
Claude SDK  ─┼── Adapter ─→ AHP Session Model
Other Agent ─┘

因此 Client 不需要分別支援：

Copilot Session API
Claude Session API
Custom Agent API

而是只理解 AHP。

這種架構與 LSP 的成功模式非常相似：不是讓每個 Editor 都直接理解每一個 Language Server 的私有協定，而是先建立共同契約。

核心架構與運作方式

AHP 可以簡化成四層：

┌─────────────────────────────┐
│ Clients                     │
│ VS Code / Browser / Custom  │
└──────────────┬──────────────┘
               │ AHP
               ↓
┌─────────────────────────────┐
│ Agent Host                  │
│ Session / State / Channels  │
│ Reconciliation / Auth       │
└──────────────┬──────────────┘
               │ Adapter
               ↓
┌─────────────────────────────┐
│ Agent Harnesses             │
│ Copilot / Claude / Custom   │
└──────────────┬──────────────┘
               │
               ↓
┌─────────────────────────────┐
│ Workspace / Tools / Git     │
└─────────────────────────────┘

Remote transport 採 JSON-RPC over WebSocket；Local 則可使用本機 IPC / message port。

Host 是 Source of Truth。Client 的核心工作變成：

1. 訂閱 Channel。
2. 取得 Snapshot。
3. 接收 Ordered Actions。
4. 透過 Pure Reducer 更新 Local State。
5. 發送新的操作。
6. 斷線後重新同步 missed actions 或取得新 snapshot。

這本質上很接近「Agent Session 專用的 distributed state synchronization protocol」。

AHP 與 ACP、MCP 的差異

這三者很容易混淆，但實際上處理的是不同層級。

MCP

重點是：

Agent ↔ Tools / Resources / External Context

也就是 Agent 怎麼取得工具與外部能力。

ACP

重點是：

Client ↔ Agent

標準化一個 Client 與一個 Coding Agent 的互動，例如 prompt、streaming、tool call 與 permission flow。

AHP

重點是：

Many Clients ↔ Shared Agent Host ↔ Agent(s)

它解決的是：

• 多 Client Session synchronization
• authoritative state
• reconnection
• session lifecycle
• remote host
• ordered actions

所以它們不是互斥標準。

一個合理的完整堆疊甚至可能是：

Client UI
   │
   ↓ AHP
Agent Host
   │
   ↓ ACP / Agent-specific SDK
Agent Runtime
   │
   ↓ MCP
Tools / Services

這種分層如果逐漸成熟，會讓 Agent Infrastructure 比現在清楚很多。

主要優勢

Session 可以真正長時間存在

Agent 不再依賴單一視窗是否開啟，很適合：

• 大型重構
• 長時間測試
• 多步驟 Coding Agent
• 背景 Agent
• Agent Automations

多裝置與多 UI 共享同一 Session

不用複製 Conversation，也不用把 Agent State 序列化後重新啟動。

Harness 無關

Client 不需要綁定 Copilot、Claude 或其他特定 Agent Provider。

Remote-first 架構合理

Host 靠近 Workspace，UI 可以遠端操作，對 Cloud IDE、Remote Dev、企業工作站很實用。

Protocol-level Reconciliation

AHP 不只傳 event，而是處理 snapshot、ordered action、reconnect reconciliation，適合真正長時間執行的 Agent。

多語言 SDK 已開始成形

目前官方 Repository 已列出 TypeScript、Rust、Kotlin、Go、Swift、.NET Client，降低其他產品採用 AHP 的門檻。

相較同類方案的優點

相較 Agent Client Protocol（ACP）

ACP 已經是非常有價值的 Editor ↔ Agent 標準，但它主要解決 1:1 Client-Agent 通訊。

AHP 的強項則是：

• N 個 Client 同時看一個 Session。
• Session 不依賴任何一個 Client。
• Host 擁有 authoritative state。
• 內建 reconnect / replay / reconciliation 思路。

因此 AHP 比較像 Agent Session Coordination Protocol；ACP 比較像 Agent Communication Protocol。

相較 WebSocket + 自製事件格式

自製 websocket 很容易快速完成，但接著就會遇到：

• reconnect 怎麼補資料？
• 多 Client 如何避免 state divergence？
• 哪邊才是 authoritative state？
• optimistic update 如何 reconcile？
• 不同 Agent Provider 的事件怎麼統一？

AHP 直接把這些問題納入協定設計。

相較純 IDE Extension 架構

Extension Host 適合 Extension，但不一定適合數十分鐘甚至數小時的 Agent Workload。

Agent Host 專用 Process 可以避免：

• Extension 負載拖慢 Agent。
• Editor Window 關閉直接中斷 Agent。
• 每個視窗重複載入 Agent Runtime。

缺點與限制

1. 協定仍在快速演進

AHP 目前仍是 0.x 階段，官方也明確表示 Agent Host 與 AHP 正在持續開發。

這代表現在導入時應預期：

• Schema 變更
• Action / Channel 調整
• SDK API Breaking Change

不適合把尚未穩定的 Wire Contract 直接視為永久標準。

2. 生態遠小於 MCP / ACP

AHP 的概念很有潛力，但目前真正使用它的產品仍有限，VS Code 是主要 Reference Implementation。

要成為真正跨 IDE 標準，還需要：

• 更多獨立 Host Implementation
• 更多非 VS Code Client
• 更多 Agent Harness Adapter
• 第三方 SDK 實戰驗證

3. State-first 模型增加實作複雜度

如果你的 Agent 只是：

Prompt → Tool → Answer

根本不需要 AHP。

Snapshot、Reducer、Action Sequence、Channel、Reconciliation 都是額外 Complexity。

只有 Session 真正長時間、跨 Client 或遠端時，這些成本才值得。

4. 並不替你解決 Agent Runtime 本身的可靠性

AHP 能同步 Agent Session State，但它不是 Temporal、Restate 或 Durable Execution Runtime。

如果 Agent Process 本身崩潰：

• Tool 是否 exactly-once？
• Workflow 是否 durable？
• Side Effect 是否能 replay？

仍是另一層問題。

因此不要把「Client 可以斷線重連」誤解成「Agent Runtime 本身具備 transaction-grade durability」。

5. Security Boundary 需要額外設計

遠端 AHP Host 能操作真正 Workspace、Terminal 與 Changeset，因此：

• Authentication
• Authorization
• Tunnel Security
• Tool Permission
• Credential Boundary

都是高風險面向。

AHP 已有 OAuth / Bearer Token 等認證設計，但真正部署仍必須和企業 IAM 與環境安全策略一起考量。

適合的使用者與專案

AHP 特別適合：

• 自製 Coding Agent IDE
• Cloud IDE
• Remote Development Platform
• Agent Desktop App
• 多 Agent Harness Client
• Agent Monitoring Console
• 長時間 Coding Agent
• 需要跨視窗共享 Session 的 IDE
• Agent Automation Platform
• Enterprise Agent Control UI

尤其是以下情境：

同一個 Agent Session
需要從 IDE、Browser、Remote UI
共同查看與控制

AHP 的價值會非常高。

不適合的使用者與專案

目前不需要優先導入：

• 一般 Chatbot
• 普通 RAG
• 單次 API Agent
• 只有一個 Client 的簡單 Agent
• 不需要 Session persistence
• 不需要 Remote Agent
• 不需要 Agent Harness abstraction

這類專案使用一般 WebSocket、OpenAI Agents SDK、LangGraph、Mastra 或 ACP 通常更直接。

簡短結論

AHP 最值得注意的不是它又定義了一種 Agent Protocol，而是它提出了一個非常合理的新邊界：

過去

IDE Window
↓
Agent

改成：

Clients
   │
   ↓
Agent Session Protocol
   │
   ↓
Agent Host
   │
   ↓
Agent Harness

Agent Session 從此可以獨立於任何一個 UI Client 存在。

這個方向很像過去 Language Server Protocol 對 IDE 與 Language Tooling 的解耦：AHP 不要求所有 Agent 使用同一套推理框架，而是試圖讓「Session、狀態同步、遠端連線與 Client 體驗」形成共同層。

目前它仍在 0.x 階段，因此我會把採用建議分成：

Agent / IDE Infrastructure 研究
→ 強烈推薦研究

自製 Coding Agent Client
→ 很值得 PoC

Remote Agent Platform
→ 很值得評估

一般 Agent Application
→ 暫時沒有必要

Mission-critical Protocol Dependency
→ 等規格進一步穩定

如果 AHP 未來能像 LSP 一樣得到多家 IDE、Agent Harness 與 Agent Client 採用，它可能成為 Coding Agent 時代的 Session Coordination Standard。這種潛力，比單純再出現一套新的 Agent Framework 更值得持續追蹤。