Dialogflow：Google 對話平台

误区「Dialogflow ES 和 CX 就是同一個產品的新舊版本吧？我在 ES 裡做的機器人，應該能直接遷移到 CX 繼續用。」

正解ES 與 CX 是兩個獨立平台，不是版本升級關係。ES 以意圖線性匹配為核心，CX 以 Flow/Page 狀態機為核心，官方不提供一鍵遷移工具。ES 的意圖、實體、Webhook、Session 邏輯都需要按 CX 模型重構，訓練短語可以複用，但流程編排必須重建。項目初期就應確定平台，中途切換成本接近重做。

为何常见：兩者都叫 Dialogflow，文檔放在同一站點，Google 長期強調 CX 是下一代平台，容易讓人誤以為是升級關係。

误区「Dialogflow 底層有 Google 的大模型，我隨便寫幾個意圖就能跑得很好。」

正解Dialogflow 的意圖匹配本質上是基於訓練短語的監督學習，短語太少、太相似或意圖之間短語重疊，識別準確率會明顯下降。即使 CX 集成了 Gemini 生成式能力，傳統 NLU 仍是可控性的基礎。官方建議每個意圖至少 10-15 條多樣化短語，並用 Entity 標註關鍵詞變體。上線後還需要根據 Fallback 率持續補充短語。

为何常见：生成式 AI 的宣傳讓用戶低估了傳統 NLU 的數據工程要求。

误区「我可以把後端邏輯都塞進 fulfillment webhook 里，機器人就無所不能了。」

正解Webhook 是同步 HTTP 調用，有超時、重試與並發限制，不適合長時間任務。正確做法是 Webhook 只做查詢與決策，異步任務放入 Cloud Tasks 或隊列，長時間處理完成後通過消息通道回傳結果。此外，ES 與 CX 的 Webhook 請求/響應結構不同，網上大量 ES 示例不能直接套用到 CX。

为何常见：把「return JSON」理解為「執行任意任務」，忽略了同步接口的執行時長限制。

误区「部署 Dialogflow 之後，客服團隊就可以裁掉了。」

正解Dialogflow 適合高頻、結構化、意圖明確的查詢，例如訂單狀態、營業時間、退換貨政策。複雜投訴、多輪模糊需求、情緒化對話仍需要人工處理。Google 官方提供的 Agent Assist 正是把 AI 定位為「座席助手」而非替代品。合理的目標是自動化常見問題 + 將複雜會話順滑轉接人工，而不是追求 100% 自動化。

为何常见：廠商演示只展示最順暢的對話路徑，長尾與異常場景的處理能力容易被高估。

误区「Google 的產品在國內可以用，接入微信和釘釘沒問題吧？」

正解Dialogflow 是 Google Cloud 服務，中國大陸網絡無法直接訪問其控制台與 API，需要海外服務器與合規評估；官方也不提供微信集成，第三方社區方案依賴於 Webhook 轉發，穩定性和安全性需自行保障。大陸業務應優先評估本地化替代方案，或通過海外節點 + 合規咨詢的方式接入。

为何常见：ChatGPT 等生成式產品在國內的流行讓部分用戶忽視了 Google Cloud 服務的區域可用性限制。