當使用者開始在 ChatGPT、Claude 這類 AI host 裡完成原本要在自家網站做的事，純文字回應就變成產品體驗的天花板。使用者問「有哪些獨角獸可以租」，如果只拿到一段條列文字，他還是得回到你的網站才能真的下單。AWS Machine Learning Blog 在 2026 年 9 月 11 日發布的示範，處理的正是這個落差：讓服務在別人的對話框裡也能有介面，而且不用綁死在某一家 host。
問題不在模型，在回應的形狀
MCP Apps 是 Model Context Protocol 的擴充，讓 AI host 直接渲染互動式 HTML widget。AWS 的示範應用 Unicorn Rentals 用同一個 MCP server，在 ChatGPT、Claude 或其他支援 Apps 擴充的 host 上呈現一致的體驗：瀏覽可租的獨角獸、預訂、查看進行中的租借、歸還。
值得注意的是示範裡的一個設計判斷：不是每個請求都值得給卡片。view_bookings 和 return_unicorn 這兩個工具沒有綁定 widget，直接回傳純文字，跳過整個渲染流程。介面是成本，只有需要視覺化選擇或確認的步驟才付這個成本。
一次工具呼叫，其實是兩段流程
根據 AWS 的架構說明，使用者問一句話之後發生的事分成兩階段。
第一階段是工具呼叫：host 把自然語言轉成 MCP 的 tools/call 訊息，送到 AgentCore Gateway 端點，AWS WAF 先做 IP 允許清單與受管規則檢查，Gateway 再用 IAM 執行角色叫起 AgentCore runtime 上的 MCP App。App 把業務邏輯交給 AWS Lambda，Lambda 對 DynamoDB 執行操作後回傳結果，App 再包成 MCP 格式交還 host。
第二階段是 widget 渲染，只有在工具帶有 resource URI（例如 ui://widget/unicorn-list）時才會啟動。host 發出 resources/read，App 回傳自帶樣式與邏輯的 HTML，host 把它放進 sandboxed iframe 渲染，並透過 MCP Apps 的生命週期把工具回應裡的 structuredContent 注入進去。widget 需要的圖片則走 Amazon CloudFront，來源是 Amazon S3。
這裡有兩個對產品團隊實際的影響。第一，工具回應的資料結構和 widget 的呈現是分開的兩件事，_meta.ui.resourceUri 決定用哪個 widget，structuredContent 決定餵什麼資料。第二，host 可能快取工具清單與 widget HTML，所以「改一個字馬上生效」不是預設行為。
AgentCore 幫你省掉的是哪一段
AWS 的說法是 AgentCore 處理「undifferentiated heavy lifting」。拆開來看，AgentCore runtime 提供 serverless、session 隔離、原生支援 MCP 的執行環境；AgentCore Gateway 則用單一安全端點把服務暴露給相容的 host。示範中的 MCP App 是 TypeScript 應用，建在官方 @modelcontextprotocol/sdk 與 @modelcontextprotocol/ext-apps 擴充上，以 Express.js HTTP server 的形式執行，由 runtime 內部管理。
工具用 registerAppTool 註冊，資源用 registerAppResource 註冊，兩者都只需要名稱、設定與處理函式。這代表團隊要自己維護的是業務邏輯與 widget 設計，而不是 host 適配層。如果你的團隊正在把工具呼叫當成產品架構問題來處理，Muse Spark 1.1 與 Meta Model API 的實務訊號那篇談的註冊與治理問題，和這裡是同一條線上的事。
還沒被回答的部分
示範涵蓋的是註冊、呼叫、渲染與部署路徑，但幾個實際會遇到的問題，來源沒有給出答案：widget 在 host 的 sandboxed iframe 裡能用到哪些瀏覽器能力、不同 host 對 MCP Apps 擴充的支援程度是否一致、以及快取造成的版本更新延遲怎麼處理。這些不是示範的缺陷，而是把介面搬進別人的對話框之後，必然要自己驗證的邊界。
如果你的服務目前只有文字型工具回應，這份示範提供了一條可複製的路徑：先挑一個真正需要視覺化選擇的流程做成 widget，其餘維持純文字，再觀察 host 端的快取行為是否符合你的更新節奏。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。