很多餐廳的點餐管道分散在 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 工具即可。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。