目錄（5 節）
Google 在 2026 年 11 月 11 日公布 A2UI 1.0 穩定版，並以 Alation 的資料動態消息示範同一組卡片與圖表可在 Claude 和自家應用程式中呈現。對已經維護多個前端的團隊來說，這個例子帶出一個實際問題：共用介面描述之後，哪些工作真的能共用，哪些仍要在每個平台各自處理？
但這裡要先問一個更前面的問題。AI 代理能描述畫面，也能透過函式交換資料，不代表它因此取得 App 的所有操作權。要讓介面安全接入現有服務，仍須先盤點元件目錄、資料流、API、使用者確認與錯誤處理。A2UI 1.0 提供協定和 SDK，整合品質則取決於實作者如何接上既有系統。
Google 發布 A2UI 1.0，雙向函式可支援即時查詢
A2UI 1.0 是生成式介面的開放協定穩定版，新增代理與渲染器之間的雙向函式呼叫。 例如訂位或航班選擇介面可以查詢可用資料，但實際能做哪些事，仍由註冊的函式與應用程式權限決定。
A2UI 是 Agent to User Interface 的縮寫，中文可理解為「代理到使用者介面」。代理依照協定描述要呈現的介面，App 的渲染器則以自己支援的元件畫出畫面。訊息以結構化資料傳遞，不是把任意程式碼送到用戶端執行。Google 表示，1.0 加入無障礙支援與擴充中繼資料，也讓航班或訂位選擇器能即時查詢可用性。
雙向函式有兩條路徑。第一種是介面向代理請求資料或服務，例如使用者選了日期後，渲染器呼叫代理端的查詢功能，再把回傳的空位更新到畫面。第二種是代理呼叫渲染器已登記的函式，例如讀取該裝置允許提供的資訊。協定為呼叫和回應定義訊息格式；查詢哪些資料、是否更改訂位、如何確認交易，仍由服務端和 App 的實作負責。
Google 的航班與訂位選擇器是說明協定用途的例子，不能當作所有航空或訂位服務已正式部署的證據。公布資料也呈現不同進度：Alation 說明其產品已用 A2UI 呈現資料卡與圖表；Atlassian 正將互動卡片帶進 Jira；ByteDance 的 Lynx renderer 已支援 A2UI 0.9，正在配合團隊調整至 1.0。這些案例分別代表產品使用、導入方向與版本適配，不宜視為相同成熟度。
「代理描述要呈現的內容，每個應用程式都以自己的原生元件繪製介面。」（Google A2UI 團隊） 若先前看過 AI 代理如何把智慧介面放進對話，可把 A2UI 理解為另一層協定化嘗試：重點是代理輸出與各產品渲染方式之間如何分工。差異在於，1.0 把函式呼叫也納入雙向訊息模型，因而必須更仔細處理權限。
A2UI 如何把代理訊息變成跨平台介面
代理提供介面結構與資料，目標平台的 renderer 依已支援的元件目錄建立畫面。 共用的是協定訊息，不是整套原生程式碼或每個平台完全相同的視覺細節。
生成式介面（Generative UI）指系統依情境組合卡片、表單、選項或圖表，讓使用者能直接檢視與操作。A2UI 將畫面組成拆為訊息、元件目錄和渲染器：協定說明如何建立介面、更新元件與資料模型、移除畫面；目錄則列出各 App 可以使用的元件和函式。渲染器收到訊息後，將它映射為平台上已註冊的元件。
以 Google 提到的航班選擇器為例，使用者提出日期和目的地後，代理可要求建立選擇畫面。渲染器以當地元件呈現日期、航班和按鈕。使用者更改條件後，畫面把相關操作送回代理查詢可用選項；代理回覆結果，介面再更新列表。這是協定可支援的互動流程，不代表協定本身連上任何航空公司的即時庫存。查詢服務、資料授權、價格來源及訂位 API 都要由應用程式另行接通。
每個畫面也有資料模型，用來保存目前選項與介面狀態。若將狀態送給代理，實作需決定哪些欄位隨互動回傳、只送給哪個代理，以及送出時機。這些選擇會影響隱私、資料最小化和除錯能力，不能只以畫面是否順利顯示來驗收。想理解代理的工具權限如何分層，可參考從介面到權限控制的 AI 代理信任設計。
接進既有 App 前，先盤點元件與資料流程
能否接入要逐平台評估元件目錄、renderer、代理 SDK、傳輸方式與既有 API。 A2UI 可共用訊息格式，但不會自動替舊 App 補上缺少的元件、服務端介面或測試。
Google 公布的 renderer 支援狀況並不完全一致。網頁端包含 React、Angular、Lit，Flutter 涵蓋行動、網頁與桌面；iOS 有 SwiftUI renderer。Android 的 Jetpack Compose renderer 在公告時仍是 0.9.1，1.0 支援「即將推出」。
代理端則有 Python、TypeScript 和 Dart SDK。選型時要以預計部署的平台、實際套件版本和維護狀態逐項核對，不能把「有 renderer」等同「該平台已支援 1.0」。
| 整合面 | 公告所列狀況 | 團隊要再確認 |
|---|---|---|
| 網頁 | React、Angular、Lit renderer | 目錄元件是否涵蓋既有設計系統，版本是否符合部署需求 |
| 跨端與行動 | Flutter renderer；iOS 有 SwiftUI renderer | 各端互動、無障礙、狀態更新是否一致 |
| Android | Jetpack Compose 當時支援 0.9.1，1.0 尚待推出 | 升級時間、版本相容與替代方案 |
| 代理端 | Python、TypeScript、Dart SDK | 現有代理框架、驗證流程和錯誤格式如何串接 |
接著要往下追，既有 App 的資料和操作目前如何流動。元件目錄可能要把內部按鈕、表單欄位和資料卡轉成可描述的元件；API 適配層需要處理登入身分、輸入檢查、逾時與錯誤回復。
傳輸層則要選擇符合產品需求的連線方式。A2UI 規格可透過不同傳輸承載訊息，團隊仍須驗證串流、中斷重連、版本協商與請求關聯是否符合既有架構。
測試也不能只比對畫面截圖。不同平台原生元件的排版、鍵盤操作、螢幕閱讀器支援和載入狀態可能不同；錯誤回覆時，使用者需要知道查詢失敗、資料過期或操作尚未完成。若現有 API 沒有明確的失敗狀態、冪等處理或取消機制，新增一層生成式介面不會自動解決它們。
「A2UI 將模型產生介面的方式，與應用程式繪製介面的方式分開。」（ByteDance Lynx 工程主管 Shouqun Liu）
介面狀態和函式權限要如何治理
函式必須先登記在目錄中，並依呼叫者類型和使用者操作條件設定邊界。 App 還要自行決定資料最小化、敏感操作確認、稽核和撤銷方式；協定提供機制，不代替產品治理。
在 A2UI 1.0 中，目錄函式可標示允許渲染器呼叫、代理呼叫，或雙方都能呼叫；需要使用者直接操作的函式也能要求使用者啟動條件。渲染器收到不符合目錄設定的呼叫時，應拒絕並回傳錯誤。這讓開發團隊能把介面互動和可執行操作列成可檢查清單，避免把代理可描述畫面誤解成代理可任意呼叫 App 功能。
實務上可先將功能拆級：讀取公開資訊、讀取個人資料、變更預約，以及付款或提交不可逆操作。每一級都要定義代理能看到的欄位、允許呼叫的函式、身分驗證條件和失敗後的回復方式。更新訂位或航班選項時，應保留使用者檢視摘要與確認的步驟；授權確認不能只靠模型在對話中表示「可以」。操作紀錄還要連結到呼叫者、時間、函式版本和結果，才能追查異常並撤銷錯誤權限。
資料模型也應按任務需要傳送，不要把完整帳戶或健康資料預設交給代理。若介面用於健康服務，孕婦、兒童、慢性病患者及長期服藥者的需求可能涉及額外敏感資訊和不同照護流程，產品須由合適的專業人員檢視資料用途與操作邊界。A2UI 不提供藥物交互作用或臨床判斷依據；這類功能必須另行驗證，不能由介面協定推論安全或有效。
哪些情境適合先做 A2UI 試點
先選範圍小、資料來源明確且錯誤可復原的互動流程，逐項確認平台支援、權限、維護責任與退出方案。 若函式責任、資料流或確認機制仍未定義，應先補齊設計再估算導入。
- 限定一個使用情境： 寫清楚使用者遇到什麼問題、目前如何完成任務，以及試點要改善哪個步驟。
- 列出資料與函式： 區分代理可讀欄位、可呼叫操作、需使用者確認的動作，以及絕不傳送的資料。
- 盤點每個平台： 核對 renderer 和代理 SDK 的 1.0 版本、元件覆蓋、無障礙需求、傳輸和舊 API 適配。
- 定義失敗與退出： 測試逾時、拒絕授權、資料過期和重複提交；指定稽核負責人、回復流程與停止試點的條件。
用同一份檢查表記錄各平台缺少的元件或 API，也把建置、測試、版本升級和長期維護納入成本。跨平台協定可能減少重複描述介面的工作，卻不會取消各端渲染、整合與驗收。Google 公布的案例可供判斷產品方向，自己的試點結果才是評估成本與效益的依據。
- A2UI 1.0 讓代理和介面透過已登記的雙向函式交換請求與結果，函式範圍由實作和權限目錄管理。
- 共用協定不代表各平台版本、元件、API、資料治理與測試都相同。
- 試點前先列資料、函式、使用者確認、失敗回復、稽核責任和退出條件。
常見問題
Q1：A2UI 1.0 是一種 AI 模型嗎？
不是。它是代理描述互動介面、應用程式渲染介面的協定與相關工具，不會自行提供模型或業務資料。
Q2：採用 A2UI 後，網站和手機 App 會長得完全一樣嗎？
不一定。各端使用自己的 renderer 和原生元件，介面結構可共用，但視覺呈現、互動方式與版本支援仍要分平台測試。
Q3：函式呼叫是否代表代理可以直接下單或更改訂位？
不代表。函式需在目錄中登記並符合呼叫權限。涉及帳戶、訂位或交易時，還要檢查使用者確認、錯誤回復與操作稽核。
Q4：導入前最先要做什麼？
選定單一試點流程，列出代理要讀取的資料、可呼叫函式、需要確認的操作，以及每個目標平台缺少的元件或 API，再估算建置和維護成本。
參考文獻
- Google A2UI Team (2026). A2UI 1.0: Build delightful, fast, reliable, agentic experiences. Google Developers Blog.
- A2UI Project (2026). A2UI Protocol Specification v1.0. A2UI Protocol Documentation.
- A2UI Project (2026). Actions, Events and Functions. A2UI Documentation.
