從聊天機器人到儀表板：Google 的 A2UI 協定如何重新定義 AI 代理能呈現的內容

快速解答： A2UI（Agent-to-UI）是由 Google 建立的開放原始碼協定，能讓 AI 代理生成豐富、互動式的使用者介面——表單、圖表、地圖、儀表板——而非純文字回應。此協定於 2025 年 12 月發布（v0.8 公開預覽版），允許代理傳送宣告式 JSON 元件描述，用戶端應用程式則將其渲染為原生的互動式小工具。對於數據團隊而言，這代表 AI 可以輸出可探索的儀表板，而不是條列式摘要，從而改變我們與 AI 進行數據分析和視覺化的互動方式。

1. 你的 AI 代理一直說話，但其實它應該展示

聊天機器人模式從未設計用於數據

請一個通用型助手分析季度銷售數據。你會得到什麼？一堵文字牆。條列式要點。也許還有一個你需要複製到筆記本才能看到圖表的程式碼區塊。模型可能理解你的數據——但它常常以最原始的形式回答：段落。

自 2022 年以來，我們一直透過一個線性、純文字的聊天視窗與能力非凡的模型互動——這個視窗的基本形狀與經典的 IRC 相同。系統能夠推理複雜數據集、標記異常並提出建議——然而介面只是一個你從頭到尾閱讀然後遺忘的滾動訊息列表。

2025 年 12 月，Google 開源了 A2UI（Agent-to-UI）——一個允許代理生成豐富、互動式使用者介面而非純文字的協定。表單、日期選擇器、圖表、地圖、儀表板——在你的應用程式中原生渲染，由代理即時生成。

實際的展示說服力十足：Google 展示了一個餐廳搜尋代理生成包含日期選擇器、時間選擇器和提交按鈕的預訂表單——而不是許多聊天機器人為了簡單預約而需要的那種痛苦的多訊息文字往返。對於數據團隊而言，其意義更為鮮明：代理可以生成一個可探索的儀表板，而不是關於數據的描述。

2. 什麼是 A2UI？白話文解說

讓代理建立介面而非撰寫段落的協定

A2UI（Agent-to-UI）是一個開放原始碼協定，允許代理傳送宣告式 UI 描述——描述按鈕、表單、圖表、地圖和佈局的 JSON 訊息——給用戶端，用戶端將其渲染為原生的互動式元件。可以把它想像成「代理專用的 HTML」，具有更強的安全性和可攜帶性預設值。

A2UI 解決的問題：信任邊界

我們身處多代理系統的時代。不同伺服器、不同供應商的代理彼此協調。它們無法直接碰觸你的 UI。

舊模式？在 iframe 內傳送原始 HTML 或 JavaScript——笨重、視覺上不一致，而且安全隱憂重重。A2UI 的做法：傳輸行為像數據但讀起來像設計的 UI。代理傳送 JSON 藍圖；用戶端用自己的原生小工具渲染。

運作方式：三訊息模式

surfaceUpdate

描述 UI 元件樹——要顯示什麼。這裡一個日期選擇器，那裡一個圖表，下面一個提交按鈕。

dataModelUpdate

提供應用程式狀態——要顯示什麼數據。圖表系列、地圖座標、表單預設值。

beginRendering

觸發渲染——何時顯示。用戶端將元件與數據組合並顯示介面。

以餐廳預約為例：代理傳送描述日期選擇器、時間選擇器、人數下拉選單和提交按鈕的 JSON。用戶端使用自己的 UI 框架（React、Angular、Flutter、Lit）渲染每個部分，套用自己的樣式和無障礙標準，呈現出一個一致的表格。沒有 iframe，沒有外來程式碼執行。

三項核心設計原則

安全優先

宣告式數據，而非可執行碼。代理從受信任的目錄請求元件——與傳送不明碼相比，降低了任意程式碼執行的風險。

原生感受

沒有 iframe。用戶端用自己的 UI 框架渲染，因此生成的 UI 可以繼承應用程式的樣式、無障礙和效能特性。

LLM 友善結構

一個帶有 ID 參考的扁平元件列表，比雜亂的標記組合更容易讓模型生成、修正和逐步串流。

生態系統（v0.8 公開預覽版）

A2UI 目前是 v0.8 公開預覽版，以 Apache 2.0 授權發布。現有的穩定渲染器支援 Lit、Angular 和 Flutter（透過 Google 的 GenUI SDK）。React 支援預計在 2026 年第一季推出，SwiftUI 和 Jetpack Compose 則預計在第二季。此協定支援多種傳輸方式，包括 A2A 協定、AG UI、SSE 和 WebSocket。

首批生態系統合作夥伴包括 CopilotKit/AG UI（相容層）、Opal（AI 迷你應用）、Gemini Enterprise 和 Flutter 的 GenUI SDK。這是 Google 押注於代理驅動介面的開放標準——而數據視覺化的影響深遠。

3. 為什麼聊天機器人無法勝任數據分析：五堵牆

聊天視窗是探索數據的錯誤介面

聊天適用於問答、寫作和程式碼生成。但對於應該是空間化、互動式且視覺化的分析，它表現極差。以下是五堵牆——以及生成式 UI 方法如何應對。

牆 1：文字牆

請聊天機器人分析一萬行銷售數據。你可能會得到很多段落的條列。人類的視覺處理在模式識別任務上遠比閱讀密集文字快速。一個設計良好的圖表可以在不到一秒內傳達資訊，而用散文閱讀則需要數分鐘。

你實際需要的是： 一個帶有懸浮詳細資訊、向下鑽研和日期篩選器的互動式圖表。

牆 2：線性牆

聊天是序列式的——每則訊息都爭奪注意力。你無法同時看到銷售趨勢、客戶區隔和利潤分析。分析是空間性的，而不僅是時間性的。

你實際需要的是： 一個多面板儀表板，視圖並排顯示並可反應式更新。

牆 3：互動牆

只想看第三季？你輸入「篩選到第三季」。代理可能重新生成整個分析。想看六月的放大？另一則訊息。與去年比較？又一則訊息。本來應該是一次點擊的互動，變成一句話、一次呼叫、一次完整重寫。

你實際需要的是： 立即回應的原生下拉選單、範圍選擇器和切換開關。

牆 4：探索牆

分析是非線性的：追隨一個異常、轉向、退一步、嘗試另一個角度。聊天紀錄是永久且序列式的——你無法像在儀表板的狀態控制中那樣「取消」探索。

你實際需要的是： 具有復原、重做和分支探索的互動式狀態。

牆 5：呈現牆

你找到了洞見——但產出物是一長串聊天紀錄。這很難匯出為儀表板或適合簡報的故事。

你實際需要的是： 可匯出的儀表板、可下載的圖表，以及產品支援時的一鍵生成投影片。

結論：聊天優化了對話，而非探索。A2UI 是邁向符合分析師實際工作方式的介面的一條路徑。

4. A2UI 用於數據視覺化：RizzCharts 範例

Google 已經展示了一個代理建構的分析介面

代理發出宣告式元件描述。用戶端將其渲染為原生的互動式小工具。

RizzCharts 是什麼

RizzCharts 是 Google 的官方 A2UI 範例——一個 AI 驅動的電子商務儀表板，展示了視覺化的生成式 UI 模式。其互動模型不同於聊天優先的工具：

• 使用者：「按類別顯示銷售細分」→ 代理生成一個具有向下鑽研功能的互動式環圈圖，以原生方式渲染。
• 使用者：「有沒有任何異常的商店？」→ 代理生成一個帶有突出標記和工具提示的地圖。
• 使用者點擊一個區段 → 儀表板鑽研到子類別，無需新的聊天回合。

用戶端不需要從代理的套件執行任何程式碼，沒有 iframe——宣告式 JSON 渲染為原生元件。代理（範例中的 Gemini 加上 Google ADK）透過工具（如 get_sales_data 和 get_store_sales）取得數據，然後使用 surfaceUpdate → dataModelUpdate → beginRendering 流程建構 A2UI 承載。

為什麼這很重要

代理不僅以文字分析數據——它正在建立一個使用者可以探索的介面。將結構與狀態分離意味著當新數據到達時，圖表可以反應式更新。同一個 JSON 可以針對 Web、行動和桌面介面。自訂目錄可以將 A2UI 擴展到領域元件：財務圖表、醫療時間軸、工程圖、地理空間圖層。

限制

A2UI 是一個協定，不是一個產品。它定義了代理如何溝通 UI——而不是在 UI 存在之前必須發生的清理、統計、圖表類別選擇和設計推理。一個完整的視覺化工作流程仍然需要一個智慧層來決定要顯示什麼以及為什麼。

5. 從協定到產品：生成式 UI 數據平台的面貌

A2UI 定義傳輸；智慧是價值所在

A2UI 針對最後一哩路：將互動式 UI 從代理送到螢幕。完整的管線仍然需要超越傳輸的深度：

1. 數據理解——解析 CSV、Excel、JSON、PDF；推斷綱要；偵測欄位類型；處理編碼邊界情況。
2. 數據清理——標準化日期；處理空值；處理極端值；解決不一致。
3. 統計分析——分佈、相關性、趨勢、異常、成長——決定哪些是有趣的。
4. 圖表選擇與設計——將圖表類型與意圖配對；調色盤；視覺層級；響應式佈局。
5. 互動式生成——篩選器、向下鑽研、工具提示、有助於理解的動畫。
6. 匯出與呈現——PPT、PDF、PNG、SVG，或針對不同受眾的嵌入。

A2UI 幫助步驟 5 到達用戶端。步驟 1–4 和 6 仍然需要沒有協定能夠取代的領域智慧。這個差距就是標準與產品之間的差異。

ChartGen AI 如何實踐這個理念

在 ChartGen AI，我們一直基於相同的生成式 UI 理念進行建構——不是因為我們具體傳送 A2UI 線路格式，而是因為我們共享這個信念：代理應該輸出互動式的視覺工作空間，而不是關於圖表的段落。

上傳常見格式的數據，並以自然語言描述你想要什麼。系統目標是提供一個可探索的儀表板——而不是純聊天的答案。六個專業代理涵蓋整個流程：

規劃代理

將請求分解為子任務，並決定需要哪些視覺化。

數據清理代理

綱要推斷、空值處理、日期標準化、極端值偵測。

數據分析代理

統計、模式偵測、相關性分析、洞見生成。

視覺化代理

圖表類型選擇、佈局、調色盤、響應式儀表板組合。

網路搜尋代理

在相關時透過基準和市場脈絡進行外部補充。

PPT 生成代理

將圖表和洞見轉換為具有敘述流程的簡報投影片。

輸出被設計成一個畫布，你可以點擊、篩選、鑽研和匯出——生成式 UI 應用於數據視覺化工作流程。

共享理念：代理生成的 UI 勝過代理生成的文字，用於數據

無論傳輸是 A2UI 的宣告式 JSON 還是多代理視覺化堆疊，洞見都一樣：

對於分析，正確的產出物往往是一個介面，而不是一個段落。

• 代理提出 UI： 與數據集匹配的圖表類型、佈局和互動——使用者不應該微管理「做一個長條圖」。
• 預設互動： 懸浮、鑽研、篩選——而不是埋在聊天中的靜態截圖。
• 原生品質： 介面看起來應該像一個為決策打造的儀表板，而不是一個帶有附件的訊息。

6. 未來：代理驅動的介面對數據團隊的意義

2026–2027 年的三個預測

聊天優先的工具將加入生成式 UI 層。 許多分析產品仍然預設使用文字加靜態圖片。到 2027 年底，更多產品將以互動式儀表板作為第一級輸出——而像 A2UI 這樣的開放標準減少了這種情況發生的鎖定效應。

分析師的工作從建構轉向策劃。 當代理組成儀表板時，人類主導提問、驗證洞見並塑造敘事——編輯判斷勝過手動圖表組合。

領域特定的目錄成為護城河。 協定是開放的；競爭優勢集中在受信任的元件庫和領域智慧——團隊依賴的風險熱圖、同類群組檢視、地理收入圖和其他專業原語。

你現在可以做的事

• 開發者： 今天就使用 A2UI（v0.8）、ADK 和 Gemini 進行實驗，用宣告式 JSON 建構代理驅動的介面。
• 分析師： 使用諸如 ChartGen AI 等已經將儀表板視為主要輸出的工具。
• 產品領導者： 評估內部工作流程是否應該從聊天優先的提示轉向 UI 優先的探索——投資報酬率體現在探索速度和決策品質上。

7. 常見問題

什麼是 A2UI？

A2UI（Agent-to-UI）是 Google 的開放原始碼協定，允許代理傳送描述 UI 元件的宣告式 JSON——表單、圖表、地圖、儀表板——用戶端以原生小工具渲染。公開預覽版約為 v0.8（2025 年底），採用 Apache 2.0 授權。

什麼是生成式 UI？

生成式 UI 意指模型根據提示動態建立佈局和互動元素，而不僅僅填入固定模板。A2UI 是針對多代理和跨信任邊界環境的一款協定。

為什麼聊天機器人不擅長數據分析？

它們將分析序列化為線性文字。探索受益於空間佈局、直接操作和視覺效果。常見摩擦包括文字牆、線性化、緩慢的互動迴圈、有限的探索狀態和薄弱的呈現產出物。

代理如何產生互動式儀表板？

像 A2UI 這樣的協定攜帶元件和綁定數據的宣告式描述。用戶端渲染原生控制項。生產品質仍然取決於上游的清理、分析和設計智慧——而不僅是傳輸。

A2UI 和生成式 UI 有什麼不同？

生成式 UI 是廣義的概念。A2UI 是一個特定的開放方法，強調宣告式數據勝過可執行碼、跨用戶端的可攜帶性，以及跨組織更安全的協作。

8. 停止閱讀關於你的數據——開始探索它

最好的 AI 數據分析是一種體驗，而不僅僅是一場對話

Google 的 A2UI 將從業者早已感受到的東西正式化：洞見需要介面——篩選器、懸浮、比較——而不僅僅是段落。

聊天時代證明了模型可以理解數據。文字仍然不是深度探索的正確預設表面：你無法篩選一個段落，無法鑽研一個條列，也無法懸浮一句話來查看血緣。

A2UI 提供了傳輸故事。生成式 UI 提供了產品理念。多代理系統承載了決定要視覺化什麼的推理。它們共同描繪了下一個時代：預設情況下是互動式、視覺化且可探索的分析。

無論你是直接採用 A2UI、使用共享這個理念的平台，還是自己建構——方向很明確。AI 輔助分析的未來不僅僅是一條聊天線程。它是一個你可以導航的體驗。

在 ChartGen AI 上試試你的檔案：描述問題，根據你的資料行驗證數字，然後探索畫布，而不是以訊息形式重讀同一份摘要。