摘要： AWS 於 2026 年 9 月 11 日的示範說明，MCP Apps 可讓 AI host 在對話中渲染互動式 HTML widget。流程先由 AgentCore Gateway 與 runtime 執行工具呼叫，host 再讀取 widget HTML 並注入 structuredContent。文章指出並非每個工具都需要 widget，簡單查詢維持純文字即可。
當 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 端的快取行為是否跟得上你的更新節奏。