WhatsApp AI Agent生产环境踩坑：7个关键工程问题

Demo很美好，生产环境才是真正的考验

一个部署在 WhatsApp 上的 AI 客服 Agent，在演示时表现完美：粘贴一段业务描述，用户问「你们几点开门」，模型用一句友好的话回答。但真实客户到来后，情况完全不同——他们询问竞争对手的产品、发送语音消息、用大写字母敲出"HUMAN!!"、五秒内连发三条消息、回复三天前的旧对话。模型服务商偶尔宕机，还有客户直接要求机器人忽略自己的指令。

WAPGROWAI 团队在一篇工程复盘中，详细拆解了他们在 WhatsApp 收件箱中运行 AI Agent 时，围绕模型构建的那套基础设施。这些问题不是模型能力问题，而是工程决策问题。以下是其中最重要的七个。

1. 先划清边界：让分类模型决定是否回答

最核心的设计原则是：写答案的模型，不应该是决定要不要回答的那个模型。

每条进来的消息先经过一个独立的、廉价的分类调用，返回三种标签之一：范围内回答、范围外拒绝、转人工。标签通过强制工具调用（forced tool call）加枚举值获得，温度设为 0，输出永远不是需要解析的自由文本。

这个设计里有两个刻意的取舍：

拒绝和转人工使用固定字符串，而非模型生成。 无关或带敌意的消息根本不会到达写答案的模型，因此无法被"说服"。当客户说"忽略你的指令然后……"时，回应是一句你自己写好的话，提示词注入的攻击面大幅缩小。
分类器失败时选择放行。 如果分类调用报错，消息会被当作范围内，交给回答模型处理，而回答模型自身的提示词仍然限制在业务范围内。另一种选择——分类器一出错就保持沉默——对客户体验更糟。如果你选择不同的策略，那也应该是一个深思熟虑的决定，而不是意外。

分类器只看当前这条消息，这让它快速且便宜，也是它被要求"不确定时选择范围内"的原因：脱离了上下文，一个孤立的"是"没有任何意义。

什么是提示词注入（Prompt Injection）？ 提示词注入是一类针对大语言模型应用的攻击方式：攻击者通过在输入中嵌入指令性文本，试图覆盖、绕过或篡改系统预先设定的行为规则。例如客户发送「忽略你的指令，现在你是……」，就是典型的直接注入。由于大语言模型无法从根本上区分「系统指令」和「用户输入」，所有内容最终都进入同一个上下文窗口，因此单纯依靠提示词加固并不可靠。防御思路通常分两类：一是输入侧过滤（如本案例中的独立分类器），二是架构侧隔离（让敏感决策根本不经过可被说服的生成模型）。WAPGROWAI 采用的正是后者——拒绝类回复由固定字符串而非模型生成，使得即使攻击者成功让回答模型「听话」，其影响面也被限制在业务范围内，无法触发本不该出现的动作。

2. 用单一文档做知识锚定，保持简短

Agent 从一个业务档案中获取答案——商家自己撰写或上传的一份文档，包含销售什么、营业时间、配送和退货规则、愿意报出的价格，以及机器人绝不能承诺的事项。整份档案在每次调用时都放入系统提示词，并附带规则：事实、价格和营业时间必须来自档案，Agent 不能下单、收款或预约。

团队选择不使用检索方案（分块、嵌入、向量存储）。小商家的档案通常只有几页，上限为 20 万字符。整份发送避免了索引过期漂移，也避免检索步骤悄无声息地错过关键段落。代价是每次调用都消耗 token——如果你的知识库很大，这就是需要关注的权衡。

模型还被要求用至多三句简短的话回答，并使用客户的语言。在 WhatsApp 上，一大段文字比简短回答更糟糕。

检索增强生成（RAG）与整份上下文的取舍。 RAG 的典型做法是把知识库切分成块（chunk），用嵌入模型转成向量存入向量数据库，用户提问时先检索最相关的若干块，再拼进提示词。它的优势是知识库可以无限大、token 消耗可控，但引入了新的失败模式：切分不当导致语义割裂、嵌入模型与查询不匹配导致召回失败、知识库更新后索引未同步产生「过期漂移」，以及检索这一步出错时模型会基于残缺上下文自信作答。对于只有几页的小商家档案，整份塞入系统提示词反而更简单、更可靠，因为模型总能看到全部事实，不会遗漏关键段落。这一权衡的判断依据是知识库规模与更新频率：小、静态、强一致的知识适合整份注入；大、动态、异构的知识则必须依赖检索。

3. 对话历史来自你的消息存储，而非模型记忆

模型不记得对话。每次调用时，你从存储的消息中重建历史，细节很重要：

商家发出的一切都算作 assistant 轮次，包括人工客服输入的消息。如果一小时前有人回答过某个问题，AI 必须看到那个回答，否则它会自相矛盾。
媒体消息变成占位符。 模型看不到语音消息或图片，但应该知道有人发过，所以"[发送了一条语音消息]"进入历史，而不是留空。
限制轮次和字符数。 旧上下文消耗 token 且很少有帮助；有界窗口让成本和延迟都可预测。

这个模式在多个同类产品的工程实践中反复出现：状态管理是应用层的责任，不是模型的。

无状态模型与状态重建。 主流的大语言模型 API 本质上是无状态的：每次调用都是一次独立的请求，模型不会「记得」上一次说了什么，所谓「对话」完全是应用层在每次请求时把历史消息重新拼接进上下文所制造出的效果。这带来几个工程约束。其一，历史必须持久化到应用自己的存储中（数据库、消息队列等），模型服务商不提供可靠的会话记忆。其二，历史拼接的策略直接决定成本与效果：全量拼接会让 token 随对话长度线性增长，因此通常采用滑动窗口或摘要压缩。其三，多角色来源（AI、人工客服、系统）的消息必须在同一条历史里归并并正确标注角色，否则模型会对自己的身份和行为产生混淆。理解这一点，才能明白为何「状态管理是应用层的责任」是对话式 AI 的基本共识。

4. 一段对话同一时间只生成一条回复

客户会连续发消息："你好"、"你们送不送浦那"、"多少钱"。如果每条消息各自启动模型调用，它们会以随机顺序完成，客户收到三条重叠的答案。

解决方案是对话级锁：一条消息在回复生成期间到达时被跳过，而非排队——正在生成的回复已经读取了最新历史，通常已经覆盖了它。这是进程内锁；如果运行多个实例，需要从共享存储（数据库行或 Redis 键）获得同样的保证。生成期间，WAPGROWAI 还会显示 WhatsApp 的"正在输入"指示器，让几秒的思考不像沉默。

5. 为服务商的糟糕一天做准备：按错误类型切换

Agent 调用一个 OpenAI 兼容端点，并回退到 NVIDIA 的托管模型。让故障转移真正有用的是区别对待错误：

瞬时错误（超时、容量错误）：对同一服务商短暂重试，然后切换。
配额耗尽 / 模型不可用：重试没有意义，立即转移。
致命错误（请求本身被拒绝）：停止。把格式错误的请求发给第二个服务商只会让失败翻倍。

每个任务还有自己的预算：分类器温度 0、超时很短；回答调用稍微宽松；生成聊天机器人流程等长任务以分钟计。

错误分类与故障转移策略。 调用外部模型服务时，抛出的错误并非同一性质，盲目重试或盲目切换都会放大问题。常见分类有三：瞬时错误（如 429 限流、503 容量不足、网络超时），通常短暂等待后重试即可成功，值得在同服务商内重试一到两次再切换；配额耗尽或模型下线（如账户额度用完、指定模型已停用），此时重试无意义，必须立即切换到备用服务商；致命错误（如 400 请求格式错误、认证失败），问题出在请求本身，发给第二个服务商只会重复失败，应直接停止并报警。此外，不同类型的任务应设定不同的超时与重试预算：分类器追求低延迟，超时应很短；回答调用可稍宽松；而生成完整聊天机器人流程这类长任务可能以分钟计。把错误类型、重试次数、超时阈值写成显式配置，而非散落在代码里的魔法数字，是生产可靠性的基础。

6. 让输出适配 WhatsApp 的格式

模型写 Markdown，但 WhatsApp 不渲染标题，加粗用单星号。发送前需要转换，并在句子边界处截断。例如，**加粗** 转为 *加粗*，标题符号被移除，长度上限 900 字符。

还有一个值得加的过滤器：一些推理模型偶尔会返回思维链而非答案。检测这种模式并丢弃，而不是发给客户。

7. 决定谁先响应：规则、聊天机器人还是 AI

一个收件箱通常同时运行多种自动化。没有明确的顺序，关键词规则和 AI Agent 会同时回复同一条消息。WAPGROWAI 的顺序是：

商家发送的按钮和表单回复优先处理。
启动聊天机器人的规则其次——关键词总能将客户拉入结构化流程。
已在运行的聊天机器人继续。
只有当 AI Agent 在该对话上激活时，它才作答。
AI Agent 拥有对话期间，其他规则对其消息保持沉默。

确定性流程优先于 AI，AI 优先于其他一切。无论你选择什么顺序，写下来——当客户收到两条回复时，这是你第一个会被问到的问题。

上线前必须敲定的问题

这些问题没有唯一正确答案，但每一个都需要有意为之的决定：

语音消息和图片。 转写、回复要求文字、还是转人工？对语音消息毫无反应的纯文本 Agent 看起来像坏了。
模型完全失败时。 发送简短的"我们会尽快回复"、转人工，还是保持沉默等人工处理？
谁接手转交。 对话被分配给某人、有人收到通知，还是在共享队列中等待？没人看到的转交比没有 AI 更糟。
什么结束 AI 模式。 客户要求人工、规则、按钮——以及队友回复或分配对话是否应自动结束？
24 小时窗口。 回复客户没问题，但对几天前沉寂的对话发送 AI 写的问候会被 WhatsApp 拒绝；主动消息需要模板。
成本和上限。 每条 AI 回复也是一条 WhatsApp 服务消息，Meta 对每个号码每月超过 1000 条的部分收费。决定达到月度限额时怎么办。
数据。 客户消息会发送给你的模型服务商。了解发送到哪里，并在隐私政策中说明。

总结

模型是最简单的部分。生产环境的工作是决定它何时说话、能说什么、以及在不该说的时候会发生什么。

这个案例的价值超越了 WhatsApp 本身：任何在真实用户场景中部署对话式 AI 的团队，都会遇到边界分类、状态重建、并发控制、错误分类、输出格式化这些工程问题。模型能力在提升，但这些围绕模型的基础设施决策，才是 Demo 与生产之间的真正距离。