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 只负责把消息送进你已经信任的系统。