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 只負責將訊息送入你已經信任嘅系統。