讓 AI 幫忙排一個日程，收到一份文字方案後，往往還得繼續補充：「把週三換成週四」「刪掉第二項」「這個時間再晚一點」。如果方案直接帶著日期選擇器和幾個可修改的選項，許多來回確認其實可以省掉。
Google 在 2026 年 11 月 11 日發布的 A2UI 1.0，就在處理這類問題。這是 A2UI 開放式生成界面協議的首個穩定版本：Agent 描述需要展示什麼，應用負責把這些描述呈現為用戶能操作的界面。
它面向的是開發者。普通用戶不會因為協議發布，就立即在所有 AI 應用裡看到同一套新功能；產品團隊還需要把它接進自己的業務。
界面由 AI 組織，組件仍由應用掌握
A2UI 把界面描述和實際繪製分開。Agent 輸出結構化消息，說明要使用哪些組件、顯示哪些數據；應用中的渲染器再用對應的界面框架，把它們畫出來。
開發者會先定義一份組件目錄，列出 Agent 可以使用的控件、屬性和函數。Agent 可使用的界面能力由這份目錄限定，輸出還要經過校驗。應用已有的按鈕、卡片和選擇器，因此可以繼續沿用原來的外觀和行為。
這種做法對已有產品比較友好。團隊不必為了加入 AI，就讓用戶在熟悉的應用和風格完全不同的生成頁面之間來回切換。哪些能力能夠開放給 Agent，也有了具體的配置位置。
不過，組件範圍受到約束，只能解決其中一部分問題。用戶能讀取哪些業務數據、某個按鈕是否有權提交操作，仍需要應用自己的權限判斷。
1.0 讓界面和 Agent 的交互更完整
此次更新的一項重點是雙向函數調用。Agent 和渲染器可以向對方發起函數請求，再接收執行結果或錯誤信息。開發者若實現了查詢函數，日期選擇器就可以據此請求更新可用時間，而不用把每次修改都改寫成一句聊天消息。
1.0 還允許在同一個界面中組合多個組件目錄的內容，但這些目錄需要使用相同的 A2UI 規範版本。無障礙支持也有所擴展，包括動態內容更新提示、隱藏內容屬性，以及渲染器應遵循的要求。
已經使用 0.9 的項目，升級時需要檢查實際消息和交互流程。官方遷移指南列出了消息名稱、目錄定義和保留字段的變化，並提醒不要對某些數據字段做不加區分的全文替換。只更新依賴版本，未必就能完成遷移。
各個平臺並沒有同時到達 1.0
按當前官方 SDK 文檔，React、Angular、Lit、Flutter 和 SwiftUI 已列出 1.0 支持；Agent 端提供 Python、TypeScript 和 Dart SDK。
但幾個常見入口還存在版本差異。發布公告註明，Jetpack Compose 當前支持 0.9.1，1.0 尚待推出；字節跳動的 Lynx 渲染器目前支持 0.9，正在適配新版本。Google 自己的 Gemini 接入也仍標註為 0.9.1，Gemini Enterprise 的 1.0 升級仍在推進。
因此，準備接入時要同時看三件事：使用哪個渲染器、它支持哪個協議版本，以及最終運行它的宿主支持到哪裡。不能僅憑「已經有 Android 或 Gemini 支持」，就認為所有 1.0 能力都能直接使用。
它也可以與 MCP Apps 配合
如果目標宿主支持 MCP Apps，卻沒有直接集成 A2UI 渲染器，可以把 Web 渲染器放進 MCP App。A2UI 消息在宿主的隔離框架內變成界面，用戶操作再通過 MCP Apps 的工具調用通道傳回。
這為接入提供了另一條路徑，但沙箱、內容安全策略和版本兼容仍然需要處理。官方指南也區分了較舊的社區示例與新版實現說明，照著示例接入前，要先看清它實際使用的協議版本。
更適合從一個具體操作開始
對開發團隊來說，可以先挑一段已經讓用戶覺得費勁的流程，例如修改一份計劃、比較幾個候選方案，或者確認提交內容。值得觀察的是：來回修改有沒有減少，數據更新後用戶是否還能看懂當前狀態，工具調用失敗時能否順利恢復。
官方快速入門使用了旅行規劃示例，由 Python 服務端配合 React 和 Flutter 客戶端。文檔明確說明，它是學習示例，並非可以直接上線的旅行服務。真實業務裡的賬號、權限、外部 API 和交易處理，仍要由開發者完成。
項目倉庫採用 Apache 2.0 許可，但部署 Agent 時，模型調用、服務器和外部服務仍可能產生費用，不能把開源理解為整套應用運行免費。
A2UI 1.0 提供了一種值得嘗試的交互方式：用戶可以直接修改 AI 給出的內容，而不必把每個調整都重新描述一遍。它究竟能減少多少操作，需要放進具體產品裡驗證。
本文依據截至 2026 年 11 月 12 日可讀的官方公告和文檔整理，未進行實際接入或性能測試。