Agent Output Is Not UX: Rendering Layer Your LLM Pipeline Is Missing - Bala Ramdoss, Amazon Lens
三句話摘要
為 AI 代理系統構建有效的使用者介面層，使模型輸出能化為可用的使用者體驗。 模型已經足夠強大，成敗取決於在其輸出與使用者介面之間構建的交付層——正確的版本契約、流式元件、充分情境化的後端，才能將代理的能力真正轉化為使用者體驗。 交付層決定產品成敗，不是模型本身。 即使模型輸出正確，如果使用者還需自行研究才能完成任務（如打電話訂位），就不是成功的產品體驗。真正的成功應該是一個日期、時間、兩次點擊就完成。
重點整理
重點- 1
交付層決定產品成敗，不是模型本身。 即使模型輸出正確，如果使用者還需自行研究才能完成任務（如打電話訂位），就不是成功的產品體驗。真正的成功應該是一個日期、時間、兩次點擊就完成。
- 2
Generative UI 將 UI 描述為資料而非原始 HTML。 模型不是生成文本或原始 HTML，而是輸出型態化的 UI 元件描述，客戶端用自身的原生元件渲染。這包括三個層級：controlled（模型選擇預建元件）、declarative（模型從目錄組合）、fully open-ended（模型即時生成新 UI）。生產行動應用通常停留在前兩層以保持安全。
- 3
行動應用無法有效修補，版本感知至關重要。 網頁應用可在分鐘級修復並上線，但行動應用涉及數億裝置安裝，使用者更新不受控制。當客戶端遇到未知的內容類型時會直接崩潰。因此系統必須在上下文中提供版本地圖，讓模型只為特定版本選擇可用元件。
- 4
流式傳輸改變了性能指標衡量方式。 與其等待完整回應（可能需數秒），不如分塊流式傳輸：先顯示骨架、漸進填充、最後完成。這樣雖然總延遲不變，但使用者感知的等待時間大幅縮短。性能指標應從「總延遲」轉向「首塊時間」——使用者看到的第一個有用資訊。
實用技巧與重點
乾貨- 組織與產品：
- Amazon Lens — AI 相機功能套件，用圖片、截圖、條碼購物並發現視覺相似商品
- Co-PilotKit — 專門做 Generative UI 的公司
- Gemini — 展示代理「思考過程」的例子
- 技術概念與規範：
- A2UI — Google 開放的 Generative UI 規範
- Generative UI 三層架構：controlled（預建元件）、declarative（目錄組合）、fully open-ended（動態生成）
- Version map — 版本能力映射，記錄各版本支持的 UI 元件
- BFF（Backend For Frontend） — 後端層，處理平台特定規則（Android vs iOS）、hydration、action 綁定、印象指標記錄
- Time to first chunk — 取代「總延遲」的新性能指標
- 使用者體驗模式：
- LensLive — 讓使用者在等待期間點選感興趣的物件，保持參與
- Thinking CX — 向使用者顯示代理正在執行什麼任務（參考 Gemini 實例，可能耗時 10 秒）
- Skeleton → Partial → Complete — 流式渲染的三階段例子
結論
結論“模型已經足夠強大，成敗取決於在其輸出與使用者介面之間構建的交付層——正確的版本契約、流式元件、充分情境化的後端，才能將代理的能力真正轉化為使用者體驗。”
完整解析
詳細Bala Ramdas 根據十多年構建客戶端應用、六年開發亞馬遜 Lens 相機功能套件的經驗，指出了 AI 代理產品設計的核心問題。當他請 AI 助手幫忙訂位時，模型雖然給出了正確的電話號碼、營業時間，甚至知道生蠔吧的位置，但使用者仍需自行研究並撥電話才能完成預訂。這不是模型的失敗，而是交付層的失敗——介於模型輸出與人類互動之間的層級。
真正的產品體驗應該讓使用者只需選擇日期、時間，點擊確認就完成訂位。這正是 Generative UI 要解決的問題。不同於傳統 API 返回資料、客戶端決定如何繪製，Generative UI 讓模型將 UI 描述為資料結構——元件清單——由客戶端用原生元件渲染。Google 推出的 A2UI 規範正式定義了這一概念，並劃分了三個層級：底層「controlled」讓模型從預建元件選擇（永不發明新元件）；中層「declarative」讓模型從目錄組合元件如日期欄、時間欄、提交按鈕；頂層「fully open-ended」如 MCP 應用般動態生成完全新穎的 UI。生產行動應用通常在底兩層運作，因為這是安全的範圍。
行動應用面臨網頁應用沒有的限制。網頁修復可在分鐘級上線，但行動應用涉及數億裝置安裝，無法控制使用者何時更新。當舊版客戶端遇到未知的內容類型時會直接崩潰，且持續崩潰數天或數週。因此整個系統必須遵循核心法則：「無法有效修補客戶端」。
系統的完整管線包含三層模式。第一層「rendering contract」 讓模型知道客戶端的能力——版本感知上下文工程。系統維護版本地圖，例如版本 2.0 引入新的航班卡片 UI，確保模型只在 2.0 以後版本中選擇它。模型不發送原始文本，而是流式傳輸會話塊（說什麼）和 UI 塊（渲染什麼）。契約甚至編碼布局規則：一到三個航班用可滑動輪播，四個以上用垂直列表。
第二層「streaming」 解決延遲問題。LLM 推理本身延遲較高，傳統的等待完整回應模式失效。流式傳輸分塊交付，先顯示骨架、漸進填充、最後完成，用戶雖然等待三到四秒但感受可忍受。這改變了性能衡量方式——從「總延遲」轉向「首塊時間」，即使用者看到的第一個有用資訊。傳統的載入轉圈對 AI 功能無效；應該想方設法讓使用者在等待時保持參與，例如 LensLive 讓使用者在結果出現前點擊感興趣的物件，或展示代理正在執行的任務（參考 Gemini 的做法）。
第三層「BFF」 是最重要的。它不只傳輸布局，還負責 hydration（補充資料）、添加 action（按鈕點擊、深連結、印象指標）、跨對話保留上下文讓下一個回應知道前面發生的事。BFF 處理平台特定規則（Android 對 iOS）並讓客戶端保持「啞」而安全。最重要的是，你可以重用既有的 UI 單元——應用已經上線的航班列、產品卡、元件。不用構建新的 agentic 視感，而是保留品牌、密度、熟悉感，讓它看起來和感覺起來是原生的。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
