摘要： AWS 於 2026 年 9 月 4 日發布用 Amazon Bedrock AgentCore 與 Amazon Nova 2 打造 WhatsApp 點餐助理的完整架構。文字、語音訊息與通話分別使用專屬 runtime，但共用同一批 MCP 後端工具，並能讓顧客在同一段對話中傳文字、留語音訊息或直接通話，且三種管道共享同一個後端與記憶。方案包含 SQS、IAM 與 KMS 加密等設計，並以 AWS CDK 提供可重現的部署流程。
餐飲業的點餐管道經常分散在 App、網站、電話和櫃檯四處，每一條都是獨立運作的系統；顧客在不同管道之間切換時，歷史紀錄往往連不起來。AWS 官方部落格在 2026 年 9 月 4 日發布一篇文章，說明如何用 Amazon Bedrock AgentCore 與 Amazon Nova 2 打造多模態的 WhatsApp 點餐助理，讓顧客在同一段對話中傳文字、留語音訊息或直接通話，且三種管道共享同一個後端與記憶。
這篇文章並非概念展示，而是一套完整的部署方案，架構圖、AWS CDK 程式碼與逐步設定一應俱全。對產品開發者來說，真正值得留意的不是「AI 接電話」這個亮點，而是背後的架構取捨：不同輸入媒介怎麼共用同一套業務邏輯，同時讓各層保持獨立、可以替換。
WhatsApp 為什麼適合當前端
文中點出一個現實：顧客早就生活在通訊軟體裡，WhatsApp 的全球用戶超過二十億。餐廳與其要求顧客下載另一個 App、註冊會員，不如讓顧客在原來的對話裡把餐點點好——既不用安裝任何東西，也不需要登入。
顧客入口採用 Meta WhatsApp Business Platform，並用單一 WhatsApp Business 號碼同時處理文字、語音訊息與語音通話。AWS 部落格強調，三種管道共用同一個後端與跨管道記憶，因此顧客今天傳文字、明天打電話，系統照樣認得出是同一個人。
架構核心：把管道與業務邏輯分開
整套設計刻意拆開三件事：對話交給 WhatsApp 層，三種管道各由一個 Agent 執行環境處理，菜單、購物車、訂單與店家位置則放在後端。AWS 部落格指出，管道與點餐邏輯分離之後，要新增或移除某個管道，後端都不需要跟著改。
實際使用的 AWS 元件包括：Amazon API Gateway 對外提供 webhook、對內提供以 IAM 授權的後端 API；AWS Lambda 負責訊息收發與點餐邏輯；Amazon SQS 佇列處理非同步作業，讓 webhook 能迅速回應 Meta 的驗證要求；Amazon DynamoDB 存放顧客資料與訂單；Amazon Location Service 負責地址定位與最近店家查詢。
AgentCore 的角色尤其值得一看。Amazon Bedrock AgentCore 提供三種能力：runtime 負責執行 Agent，每段對話各自在專屬 microVM 中隔離；Gateway 是受管的 MCP server，將後端 REST API 包裝成 Agent 能直接呼叫的工具；memory 提供跨管道共用的記憶，並以雜湊後的 customer_id 作為索引。
三種管道，工具只有一套
文章逐一說明三種管道的流程，差別僅在媒體型態與執行環境，後端工具與記憶則完全共用。
文字訊息：文字訊息進入 webhook 後，worker 推導出 customer_id，再呼叫 chat runtime。這個 runtime 以 Amazon Nova 2 Lite 搭配 Amazon Bedrock Converse API 處理文字，需要時經由 MCP gateway 呼叫後端工具，最後由 Sender Lambda 送出回覆。
語音訊息：語音訊息以 OGG Opus 格式送達，worker 下載音訊後交給 voice-note runtime。音訊先解碼成 16 kHz PCM，再送入 Amazon Nova 2 Sonic 的 speech-to-speech 工作階段。AWS 部落格特別強調，這條路徑中沒有轉錄服務，是真正的「語音進、語音出」。
語音通話：語音通話走 WebRTC，媒體由 Amazon KVS 提供的 TURN relay 傳輸；voice-call runtime 是唯一必須執行於 VPC 內的環境，並經由 NAT gateway 對外連線。
三種管道都透過 AgentCore Gateway 這個受管 MCP server 呼叫同一批工具，例如 GetMenu、AddToCart、PlaceOrder。換句話說，你只要維護一套後端 API，就能讓不同媒介的 Agent 一起使用。
部署流程與安全設計
整個系統以 AWS CDK 部署，CDK 會建立一組相依的 stack，並產生一組需要註冊給 Meta 的 webhook URL。文章也提到，建置流程（AWS CodeBuild、Amazon ECR、Amazon S3）只在部署時執行一次，用來建立 ARM64 的 Agent 容器映像，不屬於任何請求路徑。
安全方面，Meta Access Token、App Secret 等敏感資料存放在 AWS Secrets Manager，customer_id 的 pepper 則放在 Systems Manager Parameter Store。所有靜態資料以 AWS KMS 加密，日誌與指標由 CloudWatch 負責。
對想實際動手的人來說，這篇文章提供的不只是一張架構圖，而是一條可重現的部署流程。你可以先從文字管道開始，再逐步加入語音功能，因為管道與邏輯分離的設計讓擴充相對容易。
如果你正在評估「AI 助理是否該支援語音」，這套架構提供了一個務實的切入點：不需要為了語音而重寫後端，只要新增一個 runtime 並接上同一套 MCP 工具即可。