對跨境電商、外貿和小型服務團隊來說，客戶諮詢、報價、訂單號、物流催促、產品圖片和售後問題常常都集中在 WhatsApp 對話裡。客服每天需要逐一開啟聊天、回看上下文，再到知識庫、訂單後台和物流系統查詢資訊。訊息量一上來，就容易出現漏回、重複處理、回覆慢和口徑不一致。團隊雖然希望使用 AI 降低工作量，但如果 AI 看不到真實聊天、拿不到準確業務資訊，或者未經確認就直接發送訊息，新的風險反而會比原來的效率問題更大。
¶ 解決思路：讓 AI 先整理、查詢和起草，再由規則與人工把關
AceDataCloud WhatsApp Account Proxy 可以把使用者自己授權帳號中的已同步聊天、聯絡人、本地訊息和即時事件提供給 AI Agent。Agent 先識別客戶意圖、整理上下文、查詢知識庫或業務系統，再產生回覆草稿；低風險情境按明確規則處理，中高風險情境交給客服確認。發送時使用冪等鍵避免重複訊息，發送後繼續追蹤狀態。這樣建構的不是一個只會自動回覆的機器人，而是一套涵蓋訊息接入、知識檢索、人工確認和結果追蹤的客服閉環。
¶ 為什麼把個人 WhatsApp 變成 AI 客服並不簡單？
客戶會在 WhatsApp 中諮詢產品、詢問價格、發送訂單號、催促出貨、上傳故障圖片以及回饋售後問題。所有資訊堆在聊天視窗裡，客服需要逐一開啟對話、重新閱讀上下文，再去文件或後台查資料。
因此，真正落地 AI 客服時，不能只接一個大模型，還要解決訊息從哪裡來、上下文是否完整、知識是否準確、發送是否安全以及結果是否可追蹤等問題。
¶ 問題一：AI 如何讀到真實聊天？
第一步不是產生回答，而是獲得經過授權的訊息上下文。
WhatsApp Account Proxy 連接使用者自己的帳號，並向 Agent 提供已經同步到關聯裝置的聊天、聯絡人和訊息。但這裡存在明確邊界：
- 只能讀取實際同步到關聯裝置的訊息
- 可以讀取代理在線期間收到的訊息
- 不保證取得全部歷史聊天
- 本地最多保留最近 5,000 則訊息
- 本地最多保留 2,000 個事件
- 即使存在媒體中繼資料，原始媒體也可能已經無法下載
因此，AI 客服不能假設自己掌握了客戶的全部歷史。上下文不足時，應主動確認訂單號、產品型號或具體需求，而不是依靠猜測補全資訊。
¶ 問題二：如何即時發現新訊息？
客服工具如果每隔十分鐘才檢查一次訊息，很難提供即時體驗。
WhatsApp Account Proxy 支援最長 25 秒的長輪詢和 SSE 即時事件流，可以提供訊息事件、發送狀態事件和連線狀態事件。
Agent 應儲存 next_cursor。如果服務中斷後出現 gap=true，說明部分舊事件已經被清理，此時應重新拉取目前聊天狀態。
¶ 問題三：怎樣讓 AI 理解，而不是只做關鍵字回覆？
傳統自動回覆通常依賴「價格」「物流」「退款」「人工客服」等固定關鍵字。客戶稍微換一種說法，系統就可能失效。
AI 客服可以進一步分析：
- 客戶真實意圖
- 目前情緒
- 對話所處階段
- 是否缺少關鍵資訊
- 是否需要查詢知識庫
- 是否應該升級給人工客服
例如客戶說「已經三天了，還是沒有任何消息」，可能是在催物流，也可能是售後工單沒有更新。AI 需要結合最近對話判斷，而不是看到「三天」就直接發送物流範本。
¶ 問題四：知識庫說得對，業務資料也要對
客服回覆通常包含兩類資訊。
¶ 相對固定的資訊
售後政策、產品使用方法、工作時間、退貨條件和常見問題，適合放進知識庫，讓 AI 檢索後產生回答。
¶ 即時變化的資訊
目前訂單狀態、庫存、物流軌跡、客戶等級和退款進度，不能讓 AI 憑歷史知識產生，而應該查詢真實業務系統。
因此，完整的 AI 客服通常需要連接 WhatsApp、企業知識庫、CRM、訂單系統、物流系統和工單系統。WhatsApp Account Proxy 解決的是通訊入口問題，不會自動取代這些業務系統。
¶ 問題五：怎樣避免 AI 發錯訊息？
AI 客服最重要的設計原則，不是自動化越多越好，而是風險越高，控制越嚴格。
¶ 低風險
確認已收到訊息、提醒客戶補充訂單號、提供公開營業時間和發送幫助文件，可以在規則明確後逐步自動化。
¶ 中風險
產品推薦、售後步驟、預計處理時間和多語言翻譯回覆，建議先產生草稿，由客服確認。
¶ 高風險
報價、折扣承諾、退款金額、合約表述、修改群組以及刪除或收回訊息，應強制人工確認，並記錄操作目標和內容。
在向第三方發送訊息、修改訊息或變更群組之前，Agent 應請求使用者確認具體目標和內容。
¶ 問題六：怎樣避免網路波動造成重複回覆？
發送訊息時可能出現請求逾時、連線中斷、502/503 或發送狀態變為 unknown。最危險的處理方式是看到逾時就直接再發一次。
正確方式是為每次業務發送產生固定的 Idempotency-Key。如果結果不確定，應保留原來的冪等鍵，查詢對應發送記錄並檢查訊息事件，不要換新鍵重複提交同一則訊息。
¶ 問題七：如何安全管理帳號和 Token？
Bearer Token 相當於目前執行個體的存取憑證。除健康檢查介面外，REST、MCP、掃碼和配對相關介面都需要授權。Token 只能放在請求標頭中，不應該出現在 URL 或日誌裡。
正式使用時建議：
- 每個帳號使用獨立執行個體
- Token 只保存在伺服器端
- 不把 Token 寫進前端程式碼
- 不提交到 Git 儲存庫
- 限制能夠存取憑證的人員
- 對敏感操作記錄稽核日誌
- 帳號離職或交接時及時撤銷關聯裝置
¶ 問題八：如何處理圖片、檔案和其他媒體？
實際客服不只有文字，客戶可能傳送商品照片、付款截圖、PDF、包裝標籤、語音和影片。
目前代理支援在能力範圍內收發文字和媒體，單個媒體上限為 10 MiB。但帳號代理本身不等於圖片辨識、語音轉寫或檔案解析模型。
常見處理鏈路是：取得媒體、辨識類型、交給相應模型、擷取關鍵資訊、結合上下文產生回覆，最後在必要時由人工確認傳送。
¶ 一套更穩妥的 AI 客服流程
- 接收訊息： 監聽文字、媒體和連線狀態事件；
- 取得上下文： 讀取最近的本機訊息，不假設擁有全部歷史；
- 辨識意圖和風險： 判斷諮詢、投訴、催單、詢價或售後；
- 查詢知識和業務資料： 固定政策查知識庫，訂單和物流查真實系統；
- 產生回覆草稿： 控制語氣、語言、長度和服務口徑；
- 判斷是否需要人工確認： 中高風險情境交給客服；
- 使用冪等鍵傳送： 避免不確定狀態下重複傳送；
- 追蹤傳送結果： 區分
accepted、delivered和read； - 記錄處理結果： 同步到 CRM 或工單系統。
¶ 這套方案不適合做什麼？
WhatsApp Account Proxy 不應被用於：
- 向陌生號碼大量傳送訊息
- 未經同意的行銷群發
- 垃圾訊息
- 繞過平台規則
- 冒用他人帳號
- 承諾永久在線或絕對穩定
- 宣傳能夠讀取全部歷史紀錄
傳送目標應來自目前帳號的現有聊天或聯絡人，而不是任意輸入一個電話號碼進行冷觸達。
同時，這套服務並不自帶 AI，也不會因為設定 MCP 就自動回覆、主動聯絡客戶或自動群發。AI 能做什麼、什麼時候傳送，以及由誰承擔最終決策，都需要在業務系統中明確設計。
¶ 總結
把個人 WhatsApp 變成 AI 客服，真正要解決的是一整套業務問題：訊息從哪裡來、上下文是否完整、AI 如何取得準確知識、哪些回覆可以自動傳送、哪些回覆必須人工確認、如何避免重複傳送，以及連線中斷後如何恢復。
更實用的目標不是一夜之間取代所有客服，而是先讓 AI 做好三件事：
- 整理訊息
- 查詢資訊
- 產生可靠的回覆草稿
在這之後，再根據風險和實際效果逐步增加自動化程度。這樣搭建出來的 WhatsApp AI 客服，才不僅僅是一個會聊天的模型，而是一套可控、可追蹤、能夠真正幫助團隊降低工作量的服務流程。