背景

在當前 AI 應用開發浪潮中，越來越多的開發者專注于構建基于大語言模型（LLM）的 chatbot 和 AI Agent。然而，傳統的純文本對話形式存在局限性，無法為用戶提供足夠直觀和豐富的交互體驗。為了增強用戶體驗，開發者們開始探索在對話界面中動態插入 UI 組件的解決方案。

雖然 LLM 具備生成 HTML/CSS 代碼的能力，但這種方式往往缺乏標準化和可靠性，生成的代碼質量參差不齊，難以維護和復用。特別是在企業級應用中，我們需要確保生成的 UI 組件符合既定的設計規范和技術標準。

因此，一個更優的方案是利用 LLM 的 Tool Use（工具調用）能力，通過預定義的函數接口來生成標準化的 Web 前端組件。這種方法不僅能確保組件的質量和一致性，還能夠更好地與現有的前端框架和組件庫進行集成。本文將探討如何基于 Amazon Bedrock 的 Tool Use 功能來實現這一目標，構建可靠、可復用的生成式 UI 解決方案。

傳統方法的局限性

在傳統的 LLM 生成 UI 實踐中，直接讓模型生成 HTML/CSS 代碼存在諸多挑戰：

輸出的不確定性

• 生成代碼的質量不穩定，可能會出現語法錯誤導致的 HTML 無法正確渲染；

• 同樣的自然語言輸入描述可能產生完全不同的輸出樣式；

• 瀏覽器直接渲染 LLM 輸出的代碼存在安全性問題。

工程化問題

• 難以與現代前端工程體系深度整合；

• 組件復用性差，無法建立統一的設計規范；

• 無法高效利用成熟的組件庫（如 Ant Design、MUI 以及 Shadcn 等）。

生態系統割裂

• 無法高效利用成熟的組件庫（如 Ant Design、Material-UI）；

• 樣式系統難以統一，影響產品設計一致性；

• 缺乏與現代構建工具和開發流程的無縫銜接。

Tool Use 方案概述

基于 Tool Use 的 UI 生成方案提供了一個更加結構化和可控的解決方案：

核心架構

• 預定義標準化組件接口，形成可調用的組件集合；

• 通過 JSON Schema 嚴格約束組件結構和屬性，并允許組件嵌套組件的方式；

• 采用遞歸組合模式構建復雜的組件樹。

工作流程

用戶輸入 → LLM 解析需求 → 組件選擇與組合 → 生成 JSON 組件樹 → 前端渲染

技術優勢

• 可靠性：從 LLM 直接生成代碼轉換為 LLM 選擇組件再組合，確保生成可預期的結果。

• 可維護性：標準化的組件定義便于統一管理和更新。

• 擴展性：易于整合新的組件。

• 安全性：LLM 只輸出 JSON 組件樹，瀏覽器端不需要直接渲染 HTML，提高安全性。

生態整合

• 無縫對接現有組件庫；

• 支持主題定制和樣式覆蓋，比如通過 Tailwind 等方式，主題樣式可復用；

• 便于引入狀態管理和數據流方案，比如可以動態生成 Checkout 組件等完成交易類操作行為。

實現方案詳解

本方案的實現主要包含兩個核心部分：組件工具定義和前端渲染實現。讓我們深入了解每個部分的具體實現細節。

組件工具定義

我們將生成 UI 組件抽象成 LLM 可用的 1 個工具，基于 Tool Use JSON Schema 來定義組件生成工具，這種方式具有以下優勢：

• 支持組件的遞歸嵌套

• 確保生成的組件結構符合預期

const generateUI = {name: 'generateUI',description: 'Generate UI components dynamically to display data only when user ask you to render a UI component based on the data user provided. If other tool already used, you dont have to use this tool to generate component.',input_schema: {type: 'object',properties: {component: {anyOf: [{ $ref: '#/$defs/CardList' },{ $ref: '#/$defs/Email' },{ $ref: '#/$defs/ProductCard' },{ $ref: '#/$defs/Table' }]}},required: ['component'],$defs: {component: {anyOf: [{ $ref: '#/$defs/CardList' },{ $ref: '#/$defs/Email' },{ $ref: '#/$defs/ProductCard' },{ $ref: '#/$defs/Table' }]},CardList: {type: 'object',description: 'Vertical Card List component.',properties: {name: { type: 'string', enum: ['CardList'] },children: { type: 'array', items: { $ref: '#/$defs/component'}}},required: ['name', 'children']},Email: {type: 'object',properties: {name: { type: 'string', enum: ['Email'] },to: { type: 'string', description: 'Email sent to address' },from: { type: 'string', description: 'Email sent from address' },subject: { type: 'string', description: 'Email subject' },html: { type: 'string', description: 'Email content in html format' },},required: ['name', 'to', 'from', 'subject', 'html']},ProductCard: {type: 'object',properties: {name: { type: 'string', enum: ['ProductCard'] },image: { type: 'string', description: 'Product image url' },title: { type: 'string', description: 'Product title' },price: { type: 'string', description: 'Product price, including currency symbol (e.g., $
20 €15 ￥100' },description: { type: 'string', description: 'Product description' },},required: ['name', 'image', 'title', 'price', 'description']},Table: {type: 'object',properties: {name: { type: 'string', enum: ['Table'] },headers: {type: 'array',items: { type: 'string', description: 'Table headers'}},rows: {type: 'array',items: { type: 'array', items: { type: 'string', description: 'Each column value based on headers'}},description: 'Each row'}},required: ['name', 'headers', 'rows']}}}
}

組件定義中包含了幾種常用的 UI 組件類型：

• CardList：用于垂直展示卡片列表

• Email：郵件展示組件

• ProductCard：商品卡片組件

• Table：表格組件

每個組件都定義了必要的屬性和類型約束，確保生成的 JSON 數據結構的完整性。

前端渲染實現

前端渲染層采用了組件映射和遞歸渲染的方案，實現了靈活的組件樹構建：

const componentMap = {Email: Email,CardList: CardList,ProductCard: ProductCard,HorizontalScrollArea: HorizontalScrollArea,Table: TableComponent
}const renderComponent = (component) => {const { name, children = [], ...props } = componentif (name) {return React.createElement(componentMap[name],props,...children.map(item => renderComponent(item)))}
}

• 組件映射：通過 componentMap 建立組件名稱到實際組件的映射關系。

• 屬性傳遞：確保組件屬性被正確傳遞到對應的 React 組件。

• 遞歸渲染：支持任意深度的組件嵌套結構。

• 動態創建：使用 createElement 動態構建組件樹。

LLM 輸出示例

比如輸入包含了商品信息，并且 Agent 應用決策需要渲染組件，那么輸出如下，這個組件樹可在前端動態渲染。

const uiTree = {name: 'CardList',children: [{name: 'ProductCard',image: 'product1.jpg',title: 'Product 1',price: '$99.99',description: 'Amazing product'}, {name: 'ProductCard',image: 'product2.jpg',title: 'Product 2',price: '$149.99',description: 'Another great product'}]
}

示例應用場景

動態生成 Table

電商商品推薦，生成商品列表

生成 DSL

通過 Tool Use 的 JSON Schema 實現組件生成，實際上揭示了一種可能更普遍的模式：利用結構化模式定義來約束和引導 LLM 的輸出。這種方法本質上是在設計一套領域特定語言（DSL），它不僅僅局限于工具調用，更是在 LLM 和下游系統之間構建了一層可靠的抽象橋梁。

這種抽象模式具有以下優勢：

1. 輸出可控性

• 通過 Schema 約束確保輸出格式符合預期；

• 降低解析和驗證的復雜度；

• 提供類型安全和結構化保證。

2. 系統解耦

• LLM 不需要了解下游系統的具體實現細節；

• 下游系統可以獨立演進而不影響 LLM 調用層；

• 便于在 LLM 和系統之間添加中間件層（如驗證、轉換、日志等）。

3. 應用場景擴展除了 UI 組件生成，這種模式可以擴展到多個領域：

• 數據查詢：將自然語言轉換為結構化查詢語言（比如 GraphQL 或自定義查詢 DSL），尤其是 text2sql 場景，LLM 生成的 SQL 直接運行查詢并不可靠，而且還需要做額外的提示詞工程來規避不同計算引擎 SQL 語法兼容性的問題；

• 工作流編排：通過 JSON 描述任務流程和依賴關系；

• 配置生成：為復雜系統生成規范化的配置文件。

4. 安全性增強

• 避免直接執行 LLM 生成的代碼；

• 提供驗證和凈化的中間層；

• 實現細粒度的權限控制和行為約束。

實踐建議：

1. 抽象層設計

• 保持簡單，避免過度抽象，當 1 個 Tool 的 schema 定義過于復雜的時候，適當考慮拆分 Tool；

• 預留擴展空間。

2. 驗證機制

• 實現嚴格的 Schema 驗證；

• 添加運行時類型檢查。

這種基于 Schema 的抽象模式正在成為 AI 原生應用開發中的一種最佳實踐。它不僅提供了一種規范化的方式來處理 LLM 輸出，更為構建可靠、可維護的 AI 系統提供了重要的架構基礎。隨著 AI 應用的不斷發展，這種模式將在更廣泛的場景中發揮作用，幫助開發者構建更加健壯和可擴展的 AI Agent 系統。

*前述特定亞馬遜云科技生成式人工智能相關的服務僅在亞馬遜云科技海外區域可用，亞馬遜云科技中國僅為幫助您了解行業前沿技術和發展海外業務選擇推介該服務。

本篇作者

本期最新實驗為《大模型選型實戰 —— 基于Amazon Bedrock測評對比和挑選最合適業務的大模型》

? 立即解鎖當下最火爆的AI大模型，帶你零基礎玩轉 DeepSeek、Nova 等頂尖大預言模型。

📱 即刻在云上探索實驗室，開啟構建開發者探索之旅吧！

?[點擊進入實驗] 構建無限, 探索啟程！🚀