把 Coding Agent 接進聊天平台，看起來只是轉送 Prompt。

過去，我曾自行開發 Adapter，將 Discord／Telegram 串接到 Coding CLI 的 headless 模式。功能雖然可以運作，但實際使用後才發現：聊天室裡看似連續的協作，底層可能只是一段段獨立的 CLI 呼叫。

真正困難的不是訊息串接，而是如何讓 Coding Agent 持續工作。

Session lifecycle、Context 管理、Streaming、工具呼叫與權限管理、Cancel／Resume，以及不同 Coding CLI 之間的介面差異，最後都必須由 Adapter 自行處理。原本只是聊天平台整合，最後卻逐漸變成一套 Coding Agent Runtime。

Agent Client Protocol（ACP）提供了 Client 與 Agent 之間的共通介面。

它將 Session、串流更新、工具呼叫、權限請求與取消操作等互動標準化，讓整合層不必直接綁定每一套 Coding CLI，也能保留替換不同 Coding Agent 的彈性。

OpenAB 是從這些實際問題中收斂出的工程解法。

它將聊天平台、Session Pool 與 Coding Agent Runtime 串接起來，並透過 ACP 建立共通的 Agent 通訊邊界。

這場演講將從自製 Adapter 遇到的問題開始，拆解 Coding Agent 離開 Terminal 後必須面對的 Runtime 挑戰，進一步介紹 ACP 與 OpenAB 的架構設計，並現場展示：

送出任務 → Agent 持續執行 → 回報進度 → 驗證結果

這不只是把 Terminal 搬進聊天室，而是重新設計團隊與 Coding Agent 的協作方式。

透過 OpenAB，團隊可以在熟悉的聊天平台中交付任務、掌握進度、適時介入，並驗證 Agent 的工作成果，不再需要持續守在 Terminal 前逐步操作

聽眾收穫：

• 理解為什麼「將 Coding Agent 接進聊天平台」不只是 Prompt 轉送，而需要處理 Session、Context、Streaming、Permission 與 Runtime lifecycle 等工程問題。
• 了解 Agent Client Protocol（ACP）如何提供 Client 與 Agent 之間的共通通訊介面，降低不同 Coding Agent 整合與替換的成本。
• 透過 OpenAB 實例，理解如何設計包含 Session Pool、Agent Runtime、隔離執行環境與工作流程管理的協作架構。
• 建立新的 Agent 協作模式：從「人在 Terminal 前逐步指揮 Agent」轉變為「提供任務、環境、權限與驗證條件，讓 Agent 自主完成工程工作」