Webnav.ai 與 Chatbase 對比
逐項功能對比，以及 Webnav.ai 在加入 AI Actions 後的定位。
一句話總結
Chatbase 開創了「AI Actions」——讓聊天機器人不只是回答，而能真正做事（下單、查單、退款），方式是呼叫你的 API。Webnav.ai 現已具備同樣能力的 AI Actions，同時保留自身優勢：原生真人客服、原生工單、可自託管／資料不外流的架構。
功能對比
| 能力 | Chatbase | Webnav.ai |
|---|---|---|
| 基於你內容訓練的 RAG 問答 | ✅ | ✅ |
| 自動爬取網站 | ✅ | ✅ |
| 串流回應 | ✅ | ✅ |
| 多語言 | ✅ | ✅（en / zh / ja / ko / zht） |
| 一行代碼嵌入 widget | ✅ | ✅ |
| AI Actions（工具呼叫） | ✅ | ✅ 新增 |
| 電商：下單／查單、查物流、退款 | ✅（靠 Shopify/Stripe + actions） | ✅ 新增（呼叫你自己的 API） |
| 寫操作的確認步驟 | ✅ | ✅（伺服器端，exactly-once） |
| 原生真人客服 | ❌（需 Zendesk/Intercom） | ✅ 原生 WebSocket |
| 原生工單系統 | ❌（需整合） | ✅ 原生 |
| 自託管／資料留在自有設施 | ❌ | ✅ |
| 線索（Lead）收集 | ✅ | ✅（對話留資 + 自動捕獲 + 後台） |
| 開放 REST API + 對外 Webhook（Zapier / Make / CRM） | ✅ | ✅（API Key + 簽名 webhook） |
| MCP（Model Context Protocol）工具伺服器 | 部分 | ✅（JSON-RPC over HTTP） |
| 多渠道（WhatsApp / Slack / Messenger / Email） | ✅ | ✅ 已交付¹ |
| 語音 AI（語音輸入/朗讀） | ✅ | ✅ 已交付² |
¹ 渠道框架 + Slack/WhatsApp/Messenger 適配器 + 免憑據的 generic 通道均已內建；接入真實 Slack/WhatsApp 需在「Admin → 多渠道接入」填入該平台 token。
² widget 內語音輸入（STT）與回覆朗讀（TTS），基於瀏覽器 Web Speech API，data-voice="true" 開啟。
兩者「做事」的原理
兩者都不擁有你的訂單或資金，都是編排層：
- LLM 理解意圖（「我的訂單到哪了？」）。
- 決定呼叫某個已註冊的 action（工具） 並抽取參數。
- 平台帶著參數呼叫你的後端 API。
- 你的 API 回傳資料，LLM 轉成自然語言回覆。
在 Webnav.ai 中這就是 AI Actions 功能，你的平台需實作的契約見 電商接入規範。
Webnav.ai 刻意不同之處
- 資料留在你手裡。 Webnav.ai 從不儲存你的訂單、客戶或支付資料，只轉發已簽名的請求並轉述結果；身份令牌僅原樣透傳。
- 原生真人交接。 內建真人客服與工單，無需第三方客服訂閱。
- 開放／可自託管。 整套可部署在你自己的設施上。
已上線（原路線圖項目）
原本規劃中的五項能力均已交付：
- 線索收集 — 對話內留資表單、自動郵箱捕獲、後台線索列表。
- 開放 API + Webhook — Bearer API Key 調用
/api/v1/*，加上 HMAC 簽名的對外 webhook；Zapier / Make / 你的 CRM 即由此對接。見 Zapier / Make 接入。 - MCP 工具伺服器 — 以 JSON-RPC over HTTP 連接你的 MCP 伺服器作為工具後端（Admin → AI Actions，mode = MCP）。
- 多渠道 — Slack / WhatsApp / Messenger 適配器 + 免憑據的
generic通道；平台 token 在 Admin → 多渠道接入 配置。 - 語音 AI — 瀏覽器 Web Speech 語音輸入 + 回覆朗讀（
data-voice="true"）。