用WhatsApp API搭建专属AI Agent：MCP实战指南

WhatsApp不只是聊天工具，它可以成为一个能自动回复、路由分流、甚至替你完成预订的AI系统。Wassenger AI系列课程的收官一集聚焦一个核心命题：当答案只存在于你自己的系统里时，如何通过API亲手构建一个真正属于你的智能体。

前11集几乎没有涉及代码，证明了「大多数场景你根本不需要碰API」。而这一集探讨的是另一半场景——回复取决于只有你的系统才知道的信息：你的库存、你的预约、你的规则。本文梳理这套方案的三块基石与两种接入方式。

为什么要自己写代码

Wassenger官方开发者页面开门见山：「你完全不必接触API」。整个课程的大部分内容也印证了这一点。那什么时候才需要动手？答案是相反的情况——当回复依赖于你的业务系统独有的数据时。

帮助中心的说法很明确：你可以在任何平台套餐上，用API加webhook构建自己的聊天机器人。官方甚至提供了一个Node.js的公开教程，把整个闭环（包括webhook）都替你串好了。换句话说，这不是从零造轮子，而是在成熟基础上做定制。

三块基石：发送、接收、决策

整套自建Agent的逻辑可以拆解为三个清晰的部分。

发送消息

向 api.wassenger.com/v1/messages 发一个POST请求即可。你的密钥放在名为 token 的请求头里，前面不加任何前缀。请求体最简只需两个字段：phone 和 message。成功后返回 201，消息进入发送队列。如果加上 deliverAt 字段，消息就会按指定时间稍后发出，而非立即发送。

接收消息

接收端靠注册webhook实现，需要提供四样东西：一个名称、你的号码、你的URL，以及你想监听的事件。这里最关键的事件是「新消息接入」（new incoming message）。

收到后返回 200 就算完成。如果失败，系统会重试；连续失败20次，webhook会自动关闭并给你发邮件提醒。这种容错机制让系统在异常时不至于静默失效。

Webhook 是一种「反向API」机制：传统API是你主动去服务器拉取数据，而webhook是服务器在事件发生时主动向你的URL推送数据。对于聊天场景，这意味着你不需要每隔几秒轮询「有没有新消息」，而是在用户发送消息的那一刻立即收到通知。你的服务器需要暴露一个公网可访问的HTTPS端点，并在收到推送后返回HTTP 200状态码告知平台「已成功接收」。如果该端点部署在本地开发环境，通常需要借助ngrok等内网穿透工具才能被外部服务调用。Wassenger的20次重试机制参照了业界常见实践——Stripe、GitHub等平台均采用类似的指数退避重试策略，防止因网络抖动导致事件永久丢失。

决策逻辑

输入进来，你的逻辑运转，输出回去。有意思的是，这部分逻辑的大半其实是关于「什么时候不要回复」。官方教程演示了几条克制原则：跳过群聊、跳过已经由人工接管的对话、跳过你列入黑名单的标签。这种「克制」恰恰是没人能替你写的部分——它取决于你的业务边界。

用MCP省下大量代码

你不必为每一个WhatsApp动作都写一个函数。只要把你的模型指向第10集介绍的MCP服务器，它就能直接获得20多个现成的WhatsApp工具。

密钥还是同一把，但请求头不同——这里用的是 Authorization: Bearer。需要注意的是，MCP目前仍处于beta阶段，建议先用它做原型验证，再决定是否交付关键任务。

两大主流API的接入都很简洁：

• Anthropic API：在 mcp_servers 下声明服务器，填入密钥和authorization token，用MCP toolset开启工具，再加上beta标志。Claude会自动执行工具调用并把结果交还给你。
• OpenAI Responses API：只需在 tools 数组里加一项，type设为 mcp，附上标签、服务器地址和你的密钥。四行搞定。

同一台服务器，同一套工具，两种框架都能即插即用。

MCP（Model Context Protocol）是Anthropic于2024年底提出并开源的标准协议，旨在解决AI模型与外部工具、数据源之间的集成碎片化问题。在MCP出现之前，每接入一个新工具，开发者都需要为每个模型单独编写适配代码；MCP将这一过程标准化为「服务器-客户端」架构：工具提供方（如Wassenger）只需发布一个MCP服务器，任何支持MCP协议的模型客户端即可自动发现并调用其全部工具，无需额外适配。这也解释了为什么Anthropic的Claude和OpenAI的Responses API能够用同一台Wassenger MCP服务器——两者都实现了该协议的客户端标准。Beta阶段意味着协议规范和接口可能仍在迭代，生产环境使用前需关注版本变更公告。

最小可行版本与安全规范

起步要比你想象的更小。一个webhook，一个事件，一条由你的代码决定的回复，而且必须在服务器端运行——文档对此说得很清楚。先从API密钥页面拿到你的key，在动笔写任何东西之前，先从自己的机器上成功发出一条消息。

接下来是安全层面的「家务活」，这几条规则值得严格遵守：

• 密钥放进环境变量，绝不写进代码仓库
• API用 token 请求头，MCP用 Authorization: Bearer
• 密钥绝不出现在URL里

一旦察觉任何异常，立即删除密钥——访问权限会在那一秒终止。

判断你是否完成，有三个硬标准：一条消息从你的代码发出并成功送达；一个webhook返回了200；你的密钥存在变量里，而不是你推送过的文件里。三者皆真，方才算完工。

结语

这是整个课程的终点：从一个号码、一个收件箱，到一个会回答、分流、销售和挽回购物车的副驾驶，再到让Claude读取你的聊天记录，最后是一个真正属于你的Agent。对于在WhatsApp上做销售和客服的小团队来说，这条从「零代码」到「全自建」的路径提供了清晰的进阶框架。