代理應用
AWS 開源跨文字、語音留言與通話的 WhatsApp AgentCore 參考架構
AWS 公開可由 CDK 部署的餐飲代理範例，以三個隔離執行期共用同一套記憶與 MCP 後端工具。語音路徑直接採 Nova 2 Sonic speech-to-speech，但 WebRTC、TURN、身分連結及固定網路成本仍須自行治理。
AWS 發布一套完整的[多模態 WhatsApp 訂餐代理參考實作](https://aws.amazon.com/blogs/machine-learning/deploy-a-multimodal-whatsapp-ordering-assistant-with-amazon-bedrock-agentcore/)，把文字、語音留言與即時通話接到同一個商業帳號。這不是單一模型包辦所有媒介：系統建立三個 AgentCore Runtime，文字交給 Nova 2 Lite，語音留言與通話則使用 Nova 2 Sonic；每段會話在獨立 microVM 中執行，三條路徑再以雜湊後的客戶識別碼共用 AgentCore Memory。
公開的 [GitHub 範例](https://github.com/aws-samples/sample-multimodal-whatsapp-restaurant-agent) 把通道層、代理層與訂單後端分開。WhatsApp webhook 先驗證 Meta 簽章，把事件送入 SQS，立即回覆 HTTP 200；背景 worker 再下載媒體、選擇執行期並呼叫代理。菜單、購物車、下單與位置查詢沒有直接寫進提示，而是由 AgentCore Gateway 將 REST 後端包裝成 `GetMenu`、`AddToCart`、`PlaceOrder` 等 MCP 工具，後方連接 Lambda、DynamoDB 與 Amazon Location Service。
語音留言會把 OGG Opus 解碼為 16 kHz PCM，直接執行 speech-to-speech，再編碼回 OGG，路徑中沒有獨立逐字稿服務。通話更複雜：Meta Calling API 傳入 WebRTC SDP offer，位於 VPC 的 `aiortc` 執行期等待 ICE 收集完成，以單次 SDP answer 回覆；DTLS/SRTP 媒體經 Kinesis Video Streams 的受管 TURN relay 傳輸。這些細節使範例比一般聊天機器人教學更接近實際通訊系統。
不過它仍是參考架構，而非經負載與故障測試的成品。部署需要多項 AWS 與 Meta 權限，模型及 AgentCore 可用區域有限；通話 VPC 的 NAT gateway 還會形成固定成本。跨通道記憶雖以加 pepper 的電話號碼雜湊鍵連結，業者仍須處理同意、保留期限、刪除及錯誤身分合併。接下來值得觀察的是中斷處理、工具冪等性、付款授權、語音延遲與人工接手機制，而不只是示範能否完成一筆訂單。