WhatsApp客服机器人实战：人工接管与模型降级设计

大多数WhatsApp机器人教程只讲到"收到消息、调用大模型、回复"就结束了。但真正在生产环境中决定成败的，恰恰是这个流程之外的部分——机器人什么时候该闭嘴、模型接口挂了怎么办、如何避免骚扰用户。ApexFlow Digital在迪拜为客户运行的一套WhatsApp线索机器人，展示了这些环节的具体实现方式。

WhatsApp线索机器人架构示意

技术栈与前提说明

这套系统使用Node.js配合@whiskeysockets/baileys库建立WhatsApp连接，通过OpenRouter调用大语言模型，用磁盘上的JSON文件保存会话、线索和跟进状态，另外跑一个轻量HTTP服务做健康检查。

一个必须说清楚的前提：Baileys走的是WhatsApp Web协议，并非官方Business Cloud API。它部署快、不需要模板审批，但属于非官方方案，WhatsApp有权限制行为类似垃圾消息的号码。如果业务需要保证可用性或高并发量，应当改用Cloud API。不过下文讨论的设计模式对两者都适用。

什么是 Baileys？ Baileys（@whiskeysockets/baileys）是一个用 TypeScript/JavaScript 编写的开源库，它通过 WebSocket 直接复现 WhatsApp Web 的通信协议，让开发者无需官方审批即可收发消息、读取联系人、处理群组与媒体文件。相比官方 Business Cloud API，Baileys 的优势是上手快、无需模板审核、支持个人号，但其最大风险在于非官方协议：WhatsApp 的《商业行为准则》禁止自动化或批量发送类垃圾信息，一旦被判定违规，号码可能被临时封禁甚至永久封停，且没有申诉渠道。因此 Baileys 适合验证原型、小规模线索收集等低风险场景；面向客户的正式业务、需保证送达率或并发量较大的系统，应迁移到 Cloud API 并按要求提交消息模板。

OpenRouter 的作用：OpenRouter 是一个统一的多模型网关，通过一个兼容 OpenAI 格式的 API 可以调用 GPT、Claude、Gemini、Llama 等多种模型，支持按模型切换、失败重试和成本对比。这正好契合下文“六模型降级列表”的设计——无需为每个模型单独维护 SDK 和鉴权，一次封装即可横向切换。

回复短，是设计出来的

系统的提示词明确要求回复控制在一到三句话以内，并且只在潜在客户表现出明确意向时才发送预约链接——比如对方询问价格、服务范围、时间安排或要求通话。

这个约束背后有一条产品逻辑：冗长热情的机器人消息是用户流失的主要原因。用户给商家发WhatsApp消息时，期待的是快速得到有用信息，而不是收到一篇推销文案。把回复长度写进系统提示词，而不是指望模型"自觉"，是让风格稳定的关键。

模型降级：不让接口故障变成沉默

单一模型接口迟早会出问题。这套机器人维护了一个包含六个模型的有序列表，逐个尝试，每次调用设置超时限制。如果所有模型都失败，它不会沉默，而是发送一条固定的简短回复。

for (const model of FALLBACK_MODELS) {
  try {
    const res = await callOpenRouter(model, history, { timeoutMs: 12000 });
    if (res.ok) return res.text;
  } catch (_) { /* 尝试下一个模型 */ }
}
return EMERGENCY_REPLY;

这段代码的实用价值在于：客户感知不到后端故障，对话不会因为API超时而中断。相比"静默失败"，一条预设的应急回复至少维持了服务的表面连续性，也为人工介入争取了时间。

超时与降级的工程意义：调用外部大模型时常见的失败模式有三类——网络超时、限流（429）和服务端错误（5xx）。如果不做超时控制，单次请求可能挂起数十秒，导致用户等待体验崩溃；如果只依赖单一模型，一次区域性故障就会让整个机器人“失声”。降级列表加超时的组合把不确定性收敛为可预期的行为：要么某个模型在限定时间内返回结果，要么走应急回复。需要注意两个细节：一是超时阈值应根据业务容忍度设置（本例为 12 秒），过短会误杀正常但较慢的推理；二是每次降级都应记录日志，否则你无法知道主模型实际可用率是多少——这正是作者在“如果重新构建”中提出要记录降级事件的原因。

人工接管：持久化才是关键

机器人会检测每条收到的消息中是否包含转人工的请求语句，支持英语和阿拉伯语（如"speak to a person""call me"等）。匹配成功后执行三步操作：

将该发送者加入暂停集合，机器人不再回复该会话
将暂停标记写入磁盘，确保重启后不会在人工对话中途被唤醒
通过WhatsApp向负责人发送提醒，附带聊天链接

第三步的持久化是多数教程会跳过的环节。没有它，一次时机不巧的部署就会把机器人重新塞回一场已经由真人接管的对话中——这是生产环境里非常尴尬的故障。

为什么内存标记不够：很多教程用内存中的一个 Set 或 Map 记录“该用户已被人工接管”，这在单进程、不重启的环境下能跑通，但生产部署常见滚动更新、崩溃重启、水平扩容等操作。一旦进程重建，内存状态清零，机器人就会重新开始自动回复，而此刻客服可能正与用户沟通报价或投诉——机器人突然插入一句自动回复会造成严重混乱。把暂停标记写入磁盘（或数据库）本质上是把“会话状态”从进程生命周期中解耦，使重启、扩容都不会改变业务语义。当实例数超过一个时，本地 JSON 又会面临多进程并发写入与状态不一致问题，因此需要升级到 Redis 或 Postgres 这类共享存储。

忽略列表：把控制权交给运营者

有些联系人本身就是朋友、供应商或老客户，不需要机器人打扰。负责人可以向机器人号码发送/ignore或ignore <号码>来排除某个联系人，用/unignore恢复。这个列表存在JSON文件中，在所有逻辑之前被检查，包括语音消息转写。

让运营者能随时调整机器人行为边界，比在代码里硬编码例外规则灵活得多。

只跟进一次，且有严格条件

调度器定期检查线索状态，最多只发一次跟进消息，且必须同时满足三个条件：

线索沉默时长在24到72小时之间
线索未被暂停
处于迪拜工作时间（10:00至19:00）

发送一次后，系统不再主动联系该线索，每次发送都会通知负责人。作者在复盘时提到两处改进空间：跟进文案应存放在配置中而非代码里，以及应当增加明确的退订语句。

数据存储与合规提醒

聊天历史和线索档案以JSON格式存储在本地。如果用户位于阿联酋，需要关注Federal Decree-Law No. 45 of 2021个人数据保护法，明确数据存储位置以及哪些处理方（包括大模型提供商）能接触到这些数据。原文特别注明这不构成法律建议，应咨询专业律师。

阿联酋 PDPL 的基本要求：Federal Decree-Law No. 45 of 2021（俗称阿联酋个人数据保护法）于 2021 年颁布、2022 年生效，参照欧盟 GDPR 思路，要求处理个人数据时具备合法依据、遵循目的限制与最小必要原则，保障数据主体对其数据的访问、更正和删除权。对本项目而言，关键点在于：一是明确聊天记录和线索档案存储在何处（本地磁盘 / 云区域）；二是厘清处理方链条，包括 WhatsApp、OpenRouter 以及调用到的具体大模型提供商——用户消息可能会被这些第三方接触甚至用于训练，需要在隐私政策中披露。若涉及跨境传输，还需评估接收方的合规水平。这里仅作背景说明，不构成法律意见。

如果重新构建，会做哪些改变

作者给出了三条反思：面向客户的关键业务应使用Cloud API和经过审批的模板；当实例超过一个时，状态管理应从JSON文件迁移到数据库；记录每一次人工接管和模型降级事件，以便了解模型故障的实际频率。

这些经验指向一个共同主题：生产级WhatsApp机器人的难点不在AI能力本身，而在于围绕AI构建的边界控制、故障恢复和数据治理。把机器人当作一个需要运维的系统来设计，而不是一个接上API就完事的脚本，才能真正在业务场景中跑起来。