挑選一次假期時，用戶可能只需要將六個套餐並排比較，然後點一下日期即可。但聊天式智能體卻常常將航班、飯店、價格等資訊塞成一段長文字，最後再給出一個跳轉鏈接。谷歌與 CopilotKit 在10月29日發布的 A2UI 教程，就是從這段具體的訂票過程入手：將可選的卡片和輸入框放入對話中，讓用戶在原有的界面上繼續操作。

界面隨著請求的生成而產生後，軟體團隊需要交付的內容也發生了變化。以前由設計師整理好的整個頁面，現在可以拆分成一組預先定義的組件，再讓智能體根據任務進行組合。用戶詢問旅行相關信息時，就會出現航班卡片；用戶補充座位要求時，界面會更新相應的選項。這套機制將對話推進到可以提交結構化信息的環節。

模型描述意圖，客戶端決定如何繪製

A2UI 是谷歌推出的一項與應用框架無關的開放標準。智能體使用數據來描述界面，應用則利用現有的組件來完成繪製。教學資料將其解釋為兩種常見的方式：開發者可以事先製作完整的卡片，或者讓模型直接生成在沙箱中運行的界面代碼。而最常使用的A2UI 声明式模式，則讓智能體從應用提供的組件目錄中組合界面。

這裡有一處會改變產品判斷的細節：組件目錄由客戶端掌控。智能體發來的數據必須經過這個目錄，超出可信集合的組件將被阻擋。因此，軟體團隊仍能控制品牌樣式、組件功能以及允許出現的交互方式。讓模型決定此刻需要哪張「卡片」，與讓模型獲得任意執行代碼的入口，是兩種不同的權限安排。

基本目錄提供了18種通用組件，涵蓋了佈局、顯示、輸入和容器等功能。官方同時也說明，多數生產應用程式都會定義自己特有的目錄。例如地圖組件可以由前端負責繪製，智能體則只提供座標資訊。這樣一来，地圖的實現細節和數據的意圖就可以分開處理：前端維護穩定的顯示效果，智能體則處理用戶這次想要去哪裡。

教程中的航班卡片還展示了這種分工是如何落地的。應用程式會聲明航空公司、起飛時間、抵達時間和經停次數等字段，並將它們綁定到自己的渲染組件中。組件說明會被加入模型提示詞中，而字段規則則用來驗證返回的數據。一次界面生成的質量，既取決於模型是否理解任務，也取決於團隊如何定義這些業務字段。

點擊確認後，才將所選擇的內容交回給智能體。

在這套方案中，CopilotKit 負責連接工作。智能體發出 A2UI 操作，AG-UI 將該操作作為事件傳送到客戶端；用戶在界面上所做出的選擇，也通過同一條事件流返回。谷歌的 ADK、LangChain 和 Strands 等兼容框架也能參與這條鏈路。後端框架可以不同，但界面描述仍然使用共同的语言。

更有價值的變化發生在第二次互動中。許多生成式界面只負責畫出一次結果，數據變化後就過時了。教程中的 A2UI 介面將輸入綁定到數據路徑，將按鈕綁定到需要提交的字段。用戶選擇艙位、填寫電子郵箱，再按確認，應用才會將這些值送回智能體，隨後更新同一個介面。

電子郵件驗證在客戶端運行。當格式有誤時，頁面可以直接顯示提示，無需為這個錯誤額外調用模型。這個小安排劃出了一條實用的成本邊界：確定性的檢查交給軟體，任務理解和下一步組織再交給智能體。對用戶而言，錯誤停在輸入框旁邊，比在對話中重新解釋一次更容易處理。

對於軟件交付，這仍是一套開發集成方案。教程提供了接入端點、註冊組件目錄和啟動示例應用的路徑，生產團隊還需要接上自己的業務操作。訂票卡片能收集信息，實際交易如何授權和執行，仍由具體應用決定。官方的演示把界面往前推進了一步，沒有提供所有企業都能直接套用的交易後臺。

這種分工會影響企業軟件入口的爭奪。聊天框吸引用戶提出需求，組件目錄決定哪些需求能夠變成有效操作。掌握目錄的團隊，可以將自己的表單、地圖和業務卡片帶入智能體對話；接入框架則負責將選擇傳回來。用戶少了一次頁面跳轉，應用方則多了一項需要維護的資產：可被智能體調用、又受自己約束的交互能力。