在 GCP 上建構多智能體蜂群以實現對話式商務：實作原型

從藍圖到實作：HappyDelivery 原型系統

Google Developers 於 2026 年 10 月 27 日發布技術指南，示範如何在 Google Cloud Platform (GCP) 上建構以多智能體蜂群（Multi-Agent Swarms）為架構的對話式商務系統。軟體工程師 Prateek Khushalani 指出，先前文章只提出包含接入層、記憶層與認知層的三層解耦架構藍圖，這次發布的「HappyDelivery」原型則把該設計做成可運行的軟體，整合 LangGraph、Gemini、FastAPI 與 Google Cloud 技術，用來驗證多智能體蜂群在實際商業場景中的運作方式。

三層解耦架構與技術堆疊

原型系統把客戶訊息處理流程分成三個獨立層級，確保訊息從終端設備到 AI 推理都能穩定傳輸。

第一層：接入層（Ingress Layer） 這一層負責處理來自 WhatsApp、RCS、Apple Messages 及 SMS 等多個通道的非同步 HTTPS POST Webhook 請求。系統透過各平台專屬的驗證器（如 MetaHmacValidator、RcsJwtValidator 等）確認請求合法，再把各廠商的 Payload 轉成統一的 `CommonMessageEvent` 標準格式。各平台都要求快速回應 HTTP 200 OK，因此系統在 150 毫秒內把標準化訊息推送到 Google Cloud Pub/Sub，隨即回傳狀態碼，讓訊息接收與後續 AI 推理彼此解耦。

第二層：會話與購物車層（Session & Cart Layer） 這一層用 Cloud Memorystore (Redis) 儲存客戶狀態，鍵值格式為 `session:{phone_number}`。訊息平台本身沒有狀態，這一層補上了這個缺口，客戶中斷對話後重新連線，系統能立刻還原購物車內容與個人偏好（如飲食限制）。原文指出，單個基礎版 Redis 實例的原始吞吐量可達每秒 10,000 至 50,000+，讀寫延遲低於 1 毫秒，足以支撐每秒 3,000 至 15,000 個活躍對話輪次，不會成為系統瓶頸。

第三層：智能體蜂群層（Agent Swarm Layer） 這一層用 LangGraph 建構多智能體圖，把推理任務分給不同的專門智能體。Supervisor（使用 Gemini Flash）負責低延遲的路由分類；Profile Specialist 處理個人偏好；Inventory Specialist（使用 Gemini Pro）負責庫存查詢與購物車變更；Transaction Specialist（使用 Gemini Pro）則綁定支付工具，進行確定性計算。這種分工避開了單一龐大提示詞的缺陷，提升系統可靠性。

程式碼實作與效能驗證

原型程式碼展示了各層級的具體實作與部署細節。接入層用 FastAPI 實作，透過 `verify_whatsapp_signature` 等函數進行 HMAC 驗證，並用 `normalize_payload` 把資料轉成 Pydantic 模型。部署在 Cloud Run 的實測中，連續 5 次 HTTPS Webhook 請求的回應時間介於 266.84 毫秒至 301.73 毫秒之間，且能正確拒絕簽名無效的請求。

會話層由 `RedisSessionStore` 類別管理，用 `SETEX` 命令設定 24 小時過期時間。實測中，會話檢索的平均延遲為 0.318 毫秒，顯示還原狀態幾乎不增加額外延遲。智能體層則定義了 `AgentState` 類型，包含電話號碼、購物車項目及下一步驟指示。系統透過 `build_happydelivery_swarm` 函數建立狀態圖，並用 `calculate_cart_totals` 等確定性 Python 工具處理稅金與運費計算，確保財務數據精確，避免大語言模型算錯。

端到端流程與成本分析

系統透過 Pub/Sub 訂閱者協調三層運作。在模擬的三輪對話中，客戶先要求補充牛奶和雞蛋，並加上電影夜零食，Supervisor 把請求路由到 Inventory Agent，由它查詢庫存並建議商品。第二輪，客戶把 Sprite 換成 Coke Zero，系統立即更新購物車並重新計算總價。第三輪，客戶確認購買，Transaction Agent 執行 Stripe 支付並清空購物車。自動化測試套件驗證了 Webhook 驗證、目錄搜尋、確定性定價及多輪狀態轉換等核心行為，5 項測試全部通過。

成本方面，該原型把狀態外置到 Redis、用確定性工具處理數學運算，並採用模型分級策略，由 Gemini Flash 處理路由、Gemini Pro 處理複雜推理，有效降低 Token 消耗。3 輪對話的實測中，總 Token 消耗約為 4,240 個，成本僅約 0.0061 美元。以一筆 20.32 美元的訂單來看，這筆成本佔總金額的 0.030%，遠低於標準支付處理費用。若啟用 Gemini Context Caching，輸入 Token 成本可再降低 75%，每筆訂單成本降至約 0.0033 美元。

實作經驗與結論

開發過程的經驗顯示，為避免多智能體推理帶來的延遲（Swarm Tax），系統需在最終結果傳回前先發送即時進度通知。此外，把數學計算放進確定性工具，並為各智能體設定專注的系統指令，比使用單一龐大提示詞更能確保行為可靠。這個原型證明，在 GCP 上結合 LangGraph、Gemini 與雲端基礎設施，能建構出兼具對話式體驗與企業級嚴謹性的對話式商務系統。