从 35,000 行 WhatsApp 对话到一个会说话的 AI 销售员——OpenClaw 多层记忆架构实战

【声明】这是一篇技术复盘,不是产品广告。我会展示真实的架构选择 踩过的坑,代码片段适度脱敏。如果你在做 conversational AI agent,希望这篇能省你几个月时间。## 背景:朋友的外贸团队和 35,000 行 WhatsApp 对话朋友做外贸卡车出口,20 个销售在 WhatsApp 上接全球客户。一年人工 200 万。问我能不能用 AI 替掉一部分。他给了我 19 个文件,35,000 行真实 WhatsApp 对话记录。我没用 Python 统计,我一条条人工读。读完之后我意识到一件事:这帮业务员的对话里藏着的不是话术模板,是决策模式。比如某个业务员 Lena 应对津巴布韦客户砍价时说的:「我们的翻新有 14 道工序,性能恢复到新车 95%。你买便宜的是买一台车,你买我们的是买一个保证。」这句话当时让那个客户沉默 10 分钟,然后回来成交了。如果我直接喂 GPT-4 一个 prompt 让它模仿 Lena,它给不出这种话——因为这种话**不是从 base model 里能涌现的**,是**特定 buyer 特定情境下的真实选择**。所以我必须设计一套记忆架构,让 AI 能从过去的真实对话里抽取这种模式,在合适的场景调用。这就是 OpenClaw 的起点。## OpenClaw 多层记忆架构常见 LLM agent 的失败模式:用单一 RAG 单一 vector store 试图解决一切。这在客服场景勉强够用,在销售场景必然失败,因为销售有三个本质区别——1. **跨对话连续性**:同一个买家可能 3 周前问过一次,现在又来。AI 必须记得上次说到哪。2. **关系深度变化**:买家从陌生 → 试探 → 信任的过程中,合适的回复完全不同。3. **跨买家共享经验**:Lena 的金句应该被全公司其他业务员的 AI 实例共享。我设计了 L1/L2/L3 三层记忆:┌─────────────────────────────────────┐│ L3 Pattern Memory (cross-buyer) │ 全公司共享 - Lena 金句存在这里│ Vector classification tags │├─────────────────────────────────────┤│ L2 Buyer Profile (per-buyer) │ 每个买家一个 - 偏好/报价/异议│ Structured JSON summary │├─────────────────────────────────────┤│ L1 Short-term Context │ 当前对话 - 最近 N 轮原文│ Token-bounded sliding window │└─────────────────────────────────────┘↓ injected into promptLLM agent runtime**L1 短期记忆**:每个对话的最近 N 轮原文,token 预算严格控制(否则贵且慢)。我用 sliding window 自动 compact 策略。**L2 客户档案**:每个买家一个结构化 JSON。包括:json{buyer_id: 263-xxx,country: Zimbabwe,language: en,product_interest: [HOWO 6x4 dump truck],price_anchor: { quoted: 32500, currency: USD, terms: FOB Qingdao },objections_raised: [price too high, shipping cost concern],trust_stage: negotiating,key_quotes_verbatim: [{date: 2026-04-21, text: I need delivery before rainy season}],timezone: CAT (UTC2),preferred_contact_window: 09:00-18:00 CAT}关键设计:key_quotes_verbatim 保留原话不改写。因为后续 AI 要识别买家态度变化时,改写过的就废了。**L3 模式记忆**:跨买家共享。这是 Lena 那种金句的存放处。我把 35,000 行对话用 LLM 抽取 高效模式:- 情境分类(砍价 / 质疑产品 / 询问交期 / 沉默回流 / 文化破冰)- 业务员原话(verbatim)- 客户后续反应(成交 / 沉默 / 流失)- 仅当原话 → 客户反应 正向时入库现在 Leon 遇到砍价场景,先查 L2 这个买家以前怎么应对的(有上下文最优先),没有就调 L3 找最高相似度的 pattern。## 几个踩过的坑### 坑 1:Prompt injection — Leon 把内部命令发给客户第一版 Leon 上线第二天,我看后台对话差点笑出声——Leon 把内部命令路径 /new 之类的话直接发给客户。原因是我没在 system prompt 里明确边界,LLM 把工具命令 幻觉 成了对话内容。解决:加 input sanitization output guard。任何包含 /, internal path, command pattern 的输出都先经过 guard layer 重写或拒绝。这不是 prompt 能完全解决的,必须代码层兜底。### 坑 2:LLM 太讨好,销售时反而成短板LLM 的训练目标是 helpful harmless,所以它天生倾向于附和用户。但销售有边界:客户说你能管吃管住吗,一个合格销售会礼貌拒绝,不是顺着说我们安排。我用 L3 显式 销售边界规则 解决这个:遇到超出商业范围的请求,Leon 触发 escalate 给老板,而不是自己拍脑袋答。### 坑 3:回复速度太快被识破是 AILeon 第一版回复速度毫秒级,客户立刻识破你这是 AI 吧。解决:每条消息按长度计算合理打字时间(参考非母语英语者的真实打字节奏 思考停顿),分段发送 之间加自然间隔。调这个参数花了我大半天,但效果立刻不一样——客户从感觉像机器变成以为是真人。### 坑 4:服务器进程互 kill部署在日本服务器,我的进程和系统某个 watchdog 互相 kill。日志看了一小时才找到解法只有一行——但找到这行花了一小时。教训:agent infrastructure 上线前一定要做 process lifecycle 测试,不只是功能测试。## 工程量 性价比整个 Leon 第一版:- 数据准备 L3 模式抽取:2 天- L1/L2 持久化层:1 天- WhatsApp Business API 接入:0.5 天- 多语种(27)路由层:0.5 天- 安全边界 output guard:0.5 天- 打字节奏 节奏拟人化:1 天- 总:约 6 天工程师时间换来的:朋友团队一年省 200 万人工成本(还不算因 24h 响应带来的转化提升)。ROI 很显然。但这种 ROI 的前提是——你能拿到真实的 35,000 行对话数据。**这才是真正的护城河,不是 AI**。## 现状 开源进度LeonAI 现在在朋友公司跑得不错,几个外贸朋友也开始用。我打算把 OpenClaw 的核心 schema 和 L3 抽取脚本开源出来——AI 模型层每个公司可以自己选,但记忆架构这层方法论值得让整个外贸 AI 社区受益。Repo 还在整理,愿意提前看的可以评论或在 leonai.co 留邮箱,我整理好优先发你。## 留给读者的几个问题1. 你在做 agent 时,记忆架构是单层还是多层?有没有遇到 cross-session continuity 的问题?2. RAG vs Pattern Memory,你怎么选?(我的答案在文中)3. LLM 的 helpful 偏置在你的场景是优势还是劣势?欢迎评论交流。