WhatsApp Meta Business Agent 按 token 計費：只做入站的團隊在 8 月 1 日前該怎麼選
7 月 2 日之後，WhatsApp Business 的價格變化不再只是財務問題，而是一個 AI 架構問題。
Meta 的價格更新顯示，從 2026 年 8 月 1 日起，WhatsApp Business Platform 上由 Meta Business Agent 產生的訊息會按 token 計費。另一個日期同樣重要：從 2026 年 10 月 1 日起，Meta 會恢復對 customer service window 內送出的 service messages 和 utility templates 按訊息計費。換句話說，許多客服團隊一直視為低成本的自由回覆，也會重新變成明確的計費面。
這不只是價格變化。它會改變每個接收客戶訊息、並希望用 AI 協助分流、資格判斷、查詢和第一輪回覆的團隊的選擇路徑。
如果你做的是 outbound campaign，你原本就會追蹤 template category 和送達費率。但如果你的工作流程主要是 inbound，問題就不同：應該讓 Meta 的託管 agent 留在 WhatsApp 裡，還是把入站層掌握在自己手上，再把訊息送進自己的 AI agent？
新的決策點
Meta Business Agent 對個人經營者和想要 no-code 自動化的小團隊很有吸引力。Meta 將它描述成一個可以回答問題、推薦商品、收集客戶資訊、預約，並在需要時轉人工的 agent。對完全在 WhatsApp Business App 裡工作的商家，這是一套有價值的能力。
但客服量較高的技術團隊，需要把它和另一種模式比較：
| 決策項 | Meta Business Agent | 基於入站 webhook 的自建 AI agent |
|---|---|---|
| 訊息先到哪裡 | WhatsApp / Meta 的 agent 層 | 你的 webhook、佇列、CRM 或工單系統 |
| 計費單位 | 8 月 1 日起按 Meta Business Agent token 用量計費 | 你的模型/provider 成本加基礎設施成本 |
| service 回覆 | 10 月 1 日起，非 Meta Business Agent 驅動的回覆恢復計費 | 取決於你選擇的送出路徑 |
| AI 控制權 | 在 Meta 的 agent 產品內設定 | 完全控制 prompt、模型、檢索、工具和人工接管 |
| 多渠道支援 | WhatsApp 優先，主要面向 Meta 體系 | 同一個 handler 可接 WhatsApp、Telegram、LINE、TikTok、Zalo 和 X |
| 資料存放 | 在 Meta 產品邊界內 | 訊息到達時存入你自己的系統 |
託管 agent 適合「我不想寫軟體，但想自動回覆 WhatsApp 客戶」的場景。webhook 模式更適合「WhatsApp 只是整個客服系統中的一個渠道」的場景。
為什麼這不是普通的 rate card 更新
6 月那篇 rate card 文章講的是 template 價格和市場變化。今天這篇講的是控制權。
service-message 計費影響的是在 24 小時 customer service window 內回覆客戶的團隊。token 計費影響的是選擇 Meta 原生 AI agent 的團隊。這兩個變化會把團隊推向一個選擇：付費使用 Meta 整合在 WhatsApp 內的 AI 路徑，還是把 WhatsApp 當成一個輸入渠道，繼續運行自己的推理層。
對 2 到 10 人的技術團隊，第二條路徑通常更容易評估，因為架構是明確的：
- 客戶送出一則 WhatsApp 訊息。
- 訊息以標準事件進入你的 webhook。
- 後端驗證簽章。
- 路由器決定訊息進入人工、CRM 查詢，還是 AI agent。
- 你的系統記錄事件、模型輸出和人工接管決策。
關鍵差異不在於有沒有 AI，而在於訊息第一次變成可控資料的位置。
UnifyPort 的路徑
透過 UnifyPort，一個 WhatsApp 帳號可以把入站訊息送到你用於其他訊息渠道的同一個 webhook endpoint。事件會以 message.received 到達，且不同 provider 使用穩定的統一 envelope：
{
"id": "evt_7c41f0b2a9",
"type": "message.received",
"provider": "whatsapp",
"account_id": "acc_8c21d0",
"occurred_at": "2026-07-03T09:24:18Z",
"data": {
"conversation": {
"id": "84901234567",
"type": "user"
},
"sender": {
"id": "84901234567",
"type": "user",
"name": "Minh Tran"
},
"message": {
"id": "wamid.HBgM",
"type": "text",
"text": "Can your team check my shipment before closing today?",
"direction": "inbound",
"sent_at": "2026-07-03T09:24:16Z"
},
"event": {
"kind": "message_received"
}
}
}如果 webhook endpoint 設定了 signing_secret，每次簽名投遞都會包含 X-Device-Timestamp 和 X-Device-Signature。簽章是 timestamp、一個點和原始 request body 的 HMAC-SHA256 十六進位摘要。這讓你的後端在任何 AI agent 或人工佇列處理訊息前，都只有一套驗證路徑。
接下來 AI 架構由你決定。簡單客服流水線可以是：
WhatsApp message
-> UnifyPort message.received webhook
-> Signature verification
-> Intent classifier
-> CRM / order lookup
-> AI draft response
-> Human review or auto-reply rule同一條流水線可以接 Telegram、LINE、TikTok、Zalo 和 X。變化的是 provider 值，而不是 handler 程式碼。這很重要，因為 AI 客服系統只有看到完整客戶旅程時才真正有用。如果 WhatsApp agent 只回答一個渠道，而 LINE 和 Zalo 訊息還停在別的地方，自動化仍然是割裂的。
8 月 1 日前要檢查的三件事
在 Meta Business Agent token 計費開始前，先檢查目前 WhatsApp 客服流程裡的三件事。
第一，把入站路由和 AI 回覆分開看。 你可能希望 AI 起草回覆，但這不代表 WhatsApp 應該成為系統記錄的源頭。如果 CRM、工單系統或內部後台才擁有客戶上下文，入站訊息應該先到那裡。
第二，列出哪些決策需要可審計。 線索判斷、退款處理、預約變更和升級規則，通常是業務決策，不只是聊天回覆。如果你需要檢查客戶為什麼被分流、AI 使用了什麼來源、什麼時候轉人工，就需要聊天 app 之外的事件日誌。
第三，數清楚渠道。 如果 WhatsApp 是唯一客戶渠道，Meta 的託管 agent 可能足夠。如果團隊同時處理 Telegram、LINE、TikTok、Zalo 或 X，一個 WhatsApp-only agent 反而會新增第二套營運模式。
什麼時候 Meta Business Agent 是正確答案
確實有一些場景，Meta Business Agent 是合理的預設選項。
如果你是個人經營者，絕大多數訊息都在 WhatsApp 內，不使用自訂 CRM，只想要一個不用寫程式、能從業務內容裡回答常見問題的助手，那麼 Meta 的產品就是為這個場景設計的。它在 WhatsApp 內設定，學習業務內容，人工接管控制也在同一個 app 裡完成。
這和「把多個渠道整合到後端」的技術團隊不是同一個買家。對後者來說，託管 agent 的成本不只是 token 帳單，還包括把資料、路由和升級流程拆到不同介面的成本。
架構決策裡應該寫什麼
實際決策可以很簡單：
- 如果 WhatsApp 本身就是工作台，用 WhatsApp 原生 agent。
- 如果 WhatsApp 只是客服系統的一個輸入，保持入站層中立。
- 如果 AI 決策需要記錄、路由、測試，或跨渠道複用，把 agent 放在自己的 webhook 流水線後面。
UnifyPort 在這套架構裡的角色很窄，也很明確：把 WhatsApp 和其他主流訊息平台的訊息，作為一條簽名事件流送進你的系統。它不決定你的 AI 模型、prompt、CRM 或升級規則。它只是讓你的系統足夠早拿到原始材料，自己做這些決策。
8 月 1 日會讓 AI 成本變得可見。10 月 1 日會讓 service 回覆重新變得可見。對只做入站的團隊，接下來一個月正好用來決定：是讓 WhatsApp 擁有 agent，還是讓 WhatsApp 只負責把訊息送進你已經信任的系統。