【Day 17】終結 LLM 應用混沌：AG-UI 協議如何統一通訊介面

17th鐵人賽 llm agent observability ai

mikehsu0618

2025-10-01 22:15:14

166 瀏覽

分享至

當前，人工智慧的發展已經進入一個新紀元。從 OpenAI、Google 到 Anthropic，各大巨頭皆有能力開發出執行深度研究、編寫程式碼 (IDE) 或自動化命令行操作 (CLI) 的專用 AI Agent。然而，在模型能力日趨強大的同時，我們必須正視一個決定產品成敗的關鍵因素：介面與使用者體驗 (UI/UX)。

一個再強大的 Agent，如果缺乏體驗良好且富有洞察力的使用者介面，其價值將大打折扣。問題在於，當前的 AI Agent 開發就像一座座技術孤島。開發者在打造前端介面時，很快就會陷入一個難題：我的 UI，應該使用於哪個 Agent 框架？會不會 Vendor Lock-in?

當前的困境：被 Agent 框架綁架的前端

想像一下，我們要開發一個 LLM 聊天應用。最直覺的做法是：準備一個後端 Agent，並透過一個前端對話框與之互動。然而，魔鬼就藏在細節裡。

前端的發揮空間本應是無限的。它可以是 ChatGPT 那樣簡潔的對話框，也可以是像 FigJam 一樣揮灑創意的協作畫布，更可以是能動態生成元件的「生成式 UI」。但真正的挑戰在於前端與後端的「握手」階段。我們選擇的 AI 框架（例如 LangGraph、CrewAI）或模型供應商（OpenAI、Anthropic）都有自己獨特的資料格式和 API 規範。

這意味著：

高度耦合：你的前端程式碼將與特定後端框架的資料結構深度綁定。如果你為 OpenAI Assistants API 的串流格式設計了完美的 UI，那麼明天要切換到 Anthropic 或接入本地的 LlamaIndex，幾乎等於要重寫整個資料處理層。
重複造輪：每支援一個新的後端框架，前端團隊就需要編寫一個新的「適配器」，耗費大量時間在處理不同格式的資料流、狀態管理和錯誤處理上，而非創新 UI/UX。
創新受阻：這種混亂的局面極大地限制了 UI 的想像力。開發者會傾向於選擇最簡單、最通用的介面（如純文字流），因為打造能夠反映 Agent 內部狀態（例如任務規劃、工具使用情況）的複雜 UI，成本太高。

我們陷入了一個困境：前端的潛力被後端的混亂所封印。

CopilotKit 的旅程：從 UI 元件到統一協定

在這個 AI 的戰國時代中，CopilotKit 最初的切入點非常明確：專注於解決前端 AI 開發的痛點。他們意識到，開發者需要高品質、開箱即用的 UI 元件，來快速建構出色的 AI 應用，而無需從零開始處理複雜的狀態管理和渲染邏輯。

於是，他們推出了一系列強大的前端 AI 元件，支援從簡單的聊天對話框到能呈現 Agent 思考過程的複雜任務介面。為了讓這些元件能被最廣泛的開發者社群所用，CopilotKit 的策略是盡可能支援所有主流的後端 AI 框架。

他們為 LangChain、OpenAI Assistants API、CrewAI 等多個框架分別開發了專屬的整合套件（例如 @copilotkit/langchain）。這在初期是一個成功的策略，讓開發者無論使用何種後端技術，都能享受到 CopilotKit 帶來的前端便利。

然而，隨著支援的框架越來越多，CopilotKit 團隊自己卻陷入了他們試圖為開發者解決的那個「泥沼」的更深處。他們發現自己變成了「翻譯官」，為每一個框架的資料格式和 API 結構，特地編寫和維護一個獨立的轉接層。每當一個框架更新 API，或是一個新的熱門框架出現，他們就需要投入大量精力進行適配和維護。

這個過程讓他們深刻地意識到：問題的根源不在於缺乏好的前端元件，而在於前端與眾多 Agent 框架之間，缺少一個標準化的溝通協定。

他們面對的，正是整個 AI Agent 生態系統的縮影。不斷地為每個框架實作一次性接口，是一種治標不治本的權宜之計。真正的解決方案，是建立一套所有參與者都能共同遵守的「通用語言」。

生態系的拼圖：MCP、A2A 與 AG-UI

在 AG-UI 誕生之前，富有遠見的 Google 和 Anthropic 已經意識到，要讓 AI 代理從單一的實驗品走向一個可協作、可擴展的龐大生態系，就必須建立標準化的溝通協定，就像為 AI 世界打造一套通用的「網路基礎設施」。其中，兩個重要的協議率先被提出。

MCP (Model Context Protocol)

一個代理如果沒有外部資訊，就如同一個沒有感官和記憶的大腦，空有智慧卻無從施展。MCP 專注於解決代理如何獲取和理解上下文的核心問題。在沒有 MCP 的世界裡，每個代理都需要用客製化的方式去讀取檔案、存取 API 或搜尋資料庫。這種混亂導致了大量的重複開發，且難以擴展。

MCP 旨在馴服這種混亂。它定義了一套標準化的方式，讓代理可以聲明「我需要什麼資訊」（例如：某個文件的內容、用戶過去一週的行事曆），並透過一個統一的管道將這些資訊安全、結構化地「餵」給代理。簡而言之，MCP 是代理的輸入層協議，它標準化了代理與外部世界（文件、API、資料庫）的連結，成為了代理的「感官與記憶」。

A2A (Agent-to-Agent Protocol)

隨著任務日益複雜，單一代理已難以勝任所有工作。未來的趨勢必然是「Multi-Agent」的天下，由多個各司其職的專家代理協同作戰。一個「研究代理」負責搜集資料，一個「寫作代理」負責撰寫報告，還有一個「程式碼代理」負責生成程式碼。但問題是，它們之間該如何溝通？

A2A 協議正是為了解決這個問題而生。它為代理之間的協作與任務分派奠定了基礎。透過 A2A，一個代理可以發現、呼叫並委託任務給另一個代理，並以標準化的格式接收結果。它就像是代理團隊內部的「工作流程系統」和「通用語言」，確保了複雜任務可以被高效地拆解和執行。A2A 是代理間的協作協議，它讓「代理團隊合作」成為可能。

AG-UI：補上最後一塊拼圖的標準

基於這樣的深刻洞察，CopilotKit 團隊提出了 AG-UI (Agent-User Interaction Protocol)。這不僅是他們產品的自然演進，更是對整個生態系統困境的回應。

AG-UI 是一個事件驅動的協定，旨在同步代理、使用者和應用程式之間的狀態。它不關心你的後端是用 LangGraph 還是 Google ADK 實現的，它只定義了一套標準的「事件」，讓前端能夠：

理解 Agent 的狀態：Agent 是正在思考、執行工具，還是等待使用者輸入？AG-UI 將這些狀態標準化，前端可以輕易地監聽並做出相應的 UI 變化。
接收結構化資料：Agent 處理後的資料（無論是文字、圖表還是 JSON），都可以透過標準化的事件傳遞給前端，UI 不再需要解析五花八門的自訂格式。
實現豐富的互動：由於前後端徹底解耦，開發者可以放心地打造更複雜的 UI。例如，即時顯示 Agent 的任務執行樹、允許使用者中途介入修改流程、或將 Agent 生成的資料動態渲染成互動式圖表。

AG-UI 的出現，帶來了革命性的改變：

徹底解耦：前端團隊和後端團隊終於可以獨立工作。前端只需要懂 AG-UI 協定，而後端可以自由地切換、組合任何 AI 框架。
前所未有的靈活性：今天你的產品使用 OpenAI，明天可以無縫切換到 Google Gemini，而前端 UI 不需一行程式碼的改動。這為企業提供了巨大的技術選型自由度，避免被單一供應商鎖定。
催生 UI 創新：它為「生成式 UI」和更複雜的 Agent 互動模式鋪平了道路，讓開發者的精力真正回歸到「如何為使用者創造最佳體驗」上。

完整的 Agent 技術棧：從大腦到感官

AG-UI 的出現，恰好補齊了這圖中面向使用者的那一塊，讓我們能更清晰地看到一個完整的 AI 代理技術棧：

大腦 (LLMs)：提供語言與推理能力的核心（如 OpenAI、Anthropic、Gemini）。
框架 (Frameworks)：賦予大腦記憶、規劃、使用工具的骨架（如 LangGraph, CrewAI, LlamaIndex）。
工具 (Tools)：透過 API 和服務，賦予 Agent 感知和改變世界的能力。
神經系統 (Protocols)：
- MCP 負責感官輸入（獲取上下文）。
- A2A 負責內部溝通（代理間協作）。
- AG-UI 負責表達輸出（與使用者和 UI 同步）。
介面 (Apps/UX)：最終呈現給使用者，連接人類與 AI 的橋樑。

AG-UI 作為「神經系統」的關鍵一環，確保了 Agent 的「所思所想」能夠精準、高效地傳遞到它的「介面」上。

總結

AI Agent 的未來，絕不僅僅是底層模型的算力競賽。當強大的 Agent 逐漸普及，決勝的關鍵將轉向那些能提供無縫、直觀且可靠協作體驗的應用。AG-UI 協議的出現，正是為了解決這一挑戰，它為混亂的 Agent 前後端通訊建立了一套標準，讓開發者能專注於創造真正有價值的用戶體驗。這不僅是一次技術上的突破，更是推動 AI Agent 從「後台工具」走向「前台夥伴」的關鍵一步。

References：