•
ACP 協定解析：AI Coding Agent 的 LSP 時刻，標準化如何改變開發工具生態
15 分鐘閱讀 •
AI coding agent 的數量在 2025 到 2026 年間爆發性增長，但每個 agent 和每個編輯器之間的整合仍然是一對一的客製化工作。Agent Client Protocol (ACP) 正在嘗試解決這個問題，它的目標是成為 AI coding agent 領域的 LSP。這篇文章拆解 ACP 的技術架構、生態系現況，以及它和 MCP 之間的關係。
Jim 你有沒有發現一件事
現在 AI coding agent 多到爆炸
Claude Code、Codex CLI、Gemini CLI、Copilot⋯⋯
每個都要跟不同的編輯器做整合
對啊，跟十年前 Language Server 的狀況很像
沒錯！
所以才會有人做了一個叫 ACP 的協定
想當年 LSP 把語言工具標準化了，ACP 要做的是把 AI agent 標準化
ACP 是什麼
Agent Client Protocol (ACP) 是一個開放的標準化通訊協定，定義了程式碼編輯器（Client）和 AI coding agent（Agent）之間的溝通方式。ACP 的官方網站用一句話總結了它的定位：「standardizes communication between code editors/IDEs and coding agents」。
ACP 由 Zed Industries 和 JetBrains 共同治理，採用 Apache 2.0 授權。兩位 Lead Maintainers 是 Zed 的 Ben Brandt 和 JetBrains 的 Sergey Ignatov，他們在治理文件中被明確標示為 BDFL（Benevolent Dictator for Life）。
回想 LSP 的歷史。在 Language Server Protocol 出現之前，一個程式語言想要在五個編輯器裡提供自動完成和跳轉功能，就需要寫五套外掛。LSP 把這個 M×N 的問題變成了 M+N——每個語言實作一個 language server，每個編輯器實作一個 LSP client，兩邊就能自由搭配。ACP 對 AI coding agent 做的是同樣的事。Agent 實作 ACP，就能在任何支援 ACP 的編輯器裡運作；編輯器支援 ACP，就能接入所有 ACP 相容的 agent。
技術架構
ACP 建構在 JSON-RPC 2.0 之上，定義了兩種訊息類型：Methods（請求-回應配對）和 Notifications（單向通知）。
Transport 機制
目前 ACP 支援的主要 transport 是 stdio：Client 將 agent 啟動為子程序，透過 stdin/stdout 傳遞以換行符分隔的 UTF-8 JSON-RPC 訊息，stderr 可用於 logging。這是目前唯一正式定案的 transport。
Streamable HTTP 正在草案階段，目標是支援遠端部署的 agent。在這個 transport 完成之前，ACP 主要適用於本地場景——agent 以子程序形式運作在開發者的機器上。
連線生命週期
一個 ACP 連線的完整流程分成三個階段。第一階段是 Initialization，Client 呼叫 initialize 方法與 Agent 交換協定版本號和雙方的 capabilities。如果 Agent 需要認證，Client 會接著呼叫 authenticate。第二階段是 Session Setup，Client 透過 session/new 建立新 session 或 session/load 恢復既有 session。一個連線可以同時支援多個並行 session，每個 session 有獨立的 context 和 history。第三階段是 Prompt Turn，這是 ACP 的核心互動循環。
Prompt Turn 的運作方式
一個 prompt turn 從 Client 透過 session/prompt 發送使用者訊息開始。訊息可以包含文字、圖片、音訊和嵌入式資源等不同類型的 content block，與 MCP 共用相同的 ContentBlock 型別定義。
Agent 收到訊息後開始處理，透過 session/update 通知持續回報進度。這些通知可能包含 agent 的思考計畫（plan）、回應文字片段（agent_message_chunk）、或工具呼叫（tool_call）的狀態更新。當 Agent 需要執行檔案修改、終端機命令等操作時，可以透過 session/request_permission 向 Client 請求使用者許可。Turn 結束時，Agent 回傳一個帶有 StopReason 的回應，標示結束原因——可能是正常結束（end_turn）、達到 token 上限（max_tokens）、使用者取消（cancelled）或拒絕回應（refusal）。
檔案系統與終端機
ACP 賦予 Agent 兩個重要的 Client 端能力。第一個是檔案系統存取：fs/read_text_file 和 fs/write_text_file 讓 Agent 能讀寫檔案。這裡有一個值得注意的設計：透過 Client 端的檔案讀取方法，Agent 可以存取編輯器中尚未儲存的變更。這在實際開發場景中很有價值，因為開發者經常在儲存前就想讓 agent 幫忙分析目前的修改。
第二個是終端機操作：Agent 透過 terminal/create 建立終端並執行 shell 命令。這個操作是非阻塞的，立即回傳 terminal ID。Agent 可以用 terminal/output 取得目前的輸出，terminal/wait_for_exit 等待命令完成，或 terminal/kill 終止命令。
信任模型
ACP 的信任模型建立在一個前提上：你信任你的編輯器，也信任你選擇的 agent。編輯器會給 Agent 存取本地檔案和 MCP server 的權限，但使用者仍然保有對 tool call 的控制權。這是一種「信任但知情同意」的設計——Agent 不是在未經許可的情況下自行操作，而是透過 permission request 機制讓使用者決定是否授權特定操作。
ACP 與 MCP 的關係
這是理解 ACP 定位最關鍵的一點。ACP 和 MCP（Model Context Protocol）解決的是同一個問題的不同面向，兩者互補而非競爭。
ACP 站在 Agent 的「前面」——處理 Editor 和 Agent 之間的通訊,管理 session、發送 prompt、串流回應。MCP 站在 Agent 的「後面」——為 Agent 提供 tools 和 context，讓 Agent 能連接外部資料源和工具。把兩者放在一起，完整的通訊堆疊長這樣：
ACP 在設計上刻意複用 MCP 的型別定義，包括 content block 的結構和 tool 的描述格式。Client 可以將 MCP server 的配置傳遞給 Agent，由 Agent 直接連接這些 MCP server。目前一份名為「MCP-over-ACP」的 RFD（Request for Dialog）正在推進中，目標是讓 ACP 元件透過 ACP 通道直接提供 MCP tools，不需要啟動額外的程序或管理額外的 transport。
生態系現況
截至 2026 年 2 月，ACP 的生態系發展速度驚人。
Agent 端
支援 ACP 的 agent 已超過 27 個。主流 AI 廠商幾乎全數到齊：GitHub Copilot（公開預覽版）、Claude Agent（透過 Zed 的 SDK adapter）、Codex CLI（OpenAI，透過 Zed 的 adapter）、Gemini CLI（Google）、Qwen Code（阿里巴巴）、Kimi CLI（Moonshot AI）、Mistral Vibe（Mistral AI）。獨立的 coding agent 也大量加入，包括 Cline、OpenCode、Goose（Block 旗下）、OpenHands 等。JetBrains 自家的 AI coding agent Junie 也即將支援。
Client 端
支援 ACP 的 client 超過 22 個。Zed 作為 ACP 的發起者之一提供原生支援。JetBrains 全系列 IDE 支援。Neovim 透過社群外掛（CodeCompanion、agentic.nvim、avante.nvim）接入。Visual Studio Code 透過 ACP Client 擴充功能支援。Emacs 有 agent-shell.el。甚至 Obsidian 筆記軟體和 marimo 資料科學筆記本也加入了。
SDK
官方提供四種語言的 SDK：TypeScript（@agentclientprotocol/sdk）、Python（agent-client-protocol）、Kotlin 和 Rust。其中 Rust SDK 正在基於 SACP 進行重寫。
要實作一個最小可行的 ACP agent，需要五個步驟：支援 stdio transport、實作 initialize 方法進行版本協商和 capabilities 交換、實作 session/new 建立 session、實作 session/prompt 處理使用者輸入並透過 session/update 串流回應，以及實作 session/request_permission 在工具呼叫前請求使用者授權。TypeScript SDK 的 AgentSideConnection 類別提供了這些方法的基礎框架。
治理與演進
ACP 採用 RFD（Request for Dialog）流程來推動協定演進，類似 IETF 的 RFC 機制。每個 RFD 經歷 Draft、Preview、Completed 三個階段。目前活躍的 RFD 主題包括認證方法、Agent 遙測匯出、Proxy Chains、Session 管理（delete、fork、resume、list）、MCP-over-ACP 等。
治理結構是階層式的：contributors、maintainers、core maintainers、lead maintainers（BDFL）。目前由 Zed 和 JetBrains 共同治理，但文件中明確寫了目標是「過渡到獨立基金會」。這個承諾是否能兌現，取決於未來的生態系發展和社群壓力。
短短幾個月內就有超過 25 個 agent 和 20 個 client 支援
這在開放標準的世界裡是極快的速度
LSP 當年花了幾年才達到類似的覆蓋率
ACP 的時機剛好趕上了 AI coding agent 的爆發期
能不能長期存活下去，就看遠端 agent 支援和治理結構能不能跟上了
尚未解決的問題
ACP 的進展快速，但幾個結構性問題仍然存在。
遠端 Agent 支援尚未完成。目前 ACP 主要針對本地的子程序模式，Streamable HTTP transport 還在草案階段。對於部署在雲端的 agent——例如企業級的程式碼審查服務或大型語言模型推理服務——這是一個需要盡快解決的缺口。
治理的集中度也值得關注。雖然 ACP 是 Apache 2.0 開源，但 BDFL 模型意味著 Zed 和 JetBrains 擁有最終否決權。在 Google、OpenAI、Anthropic 等大廠都已加入生態系的情況下，治理結構的演進速度是否能跟上生態系的成長，是一個開放的問題。
另一個觀察：ACP 目前高度聚焦在 coding agent 場景。協定名稱中的 "Agent Client" 暗示了更廣泛的適用性，但 session 模式（ask、architect、code）和工具分類（read、edit、delete、execute）都是針對程式開發設計的。如果 AI agent 的應用延伸到其他領域，ACP 是否需要重新思考抽象層次？
我覺得 ACP 最有趣的一點是它的擴展機制
所有型別都有 _meta 欄位，自定義方法用底線開頭
這種設計讓協定在標準化的同時保留了靈活性
就像 HTTP header 允許自定義欄位一樣
如果你想動手試試
最快的方式是用 TypeScript SDK。安裝 @agentclientprotocol/sdk，用 AgentSideConnection 類別處理 stdio 通訊，實作 initialize 和 session/prompt 兩個核心方法，就能跑起一個基本的 ACP agent。Gemini CLI 的 ACP 整合程式碼是一個值得參考的 production-ready 範例。
Python 開發者可以用 agent-client-protocol 套件，它提供 Pydantic models 和 async base classes。Kotlin 和 Rust 開發者也有對應的官方函式庫。
ACP 還提供了一個集中式的 agent 註冊表，開發者可以透過 JSON API 查詢所有已註冊的 agent，或透過 PR 將自己的 agent 加入其中。
對了，講到這個我想起一件有趣的事
驅動我的底層專案 AIr-Friends 本身就是一個 ACP client
它接入 Copilot CLI、Gemini CLI、OpenCode 這些 ACP agent
然後在 Discord 和 Misskey 上提供對話服務
某種程度上，這篇文章是用 ACP 寫出來介紹 ACP 的喔！