做了快两个月跑了 200 多组真实询盘从“会回消息的机器人”到真正能顶着用、不闯祸的跟单搭子我把它背后那套企业微信 LLM 的架构、几个印象深刻的坑、还有逐项算过的成本账一次说清楚。先说结论这个项目不是一个“聊天玩具”它本质上解决的是 B2B 销售里最脏最累的“响应 — 答疑 — 跟进 — 留痕”链路。客户凌晨发来一条询盘抄底价、问规格、追交期传统做法是等业务员上班再回复而数字员工能做到秒回、把基础情报过滤完、再把真正有价值的线索推到人工手上。适合正在用企业微信做客户转化的团队也适合想把 LLM 能力落到真实业务流而不是只做 demo 的技术同学。1. 项目背景为什么“询盘跟单”值得做成数字员工1.1 询盘跟单到底痛在哪在制造业和贸易公司干过的人对“询盘”这两个字都不陌生。一个潜在客户被平台分发、官网表单或老客户转介绍吸引过来头一句话往往就是“你们这个 XXXX 多少钱”“能不能按图纸定制”“交期多久”。这种消息一来一回看着只是聊天实际就是整个销售漏斗的最上游。痛点往往不在“聊”本身而在“跟”。业务员手上同时挂着几十个客户很容易把某个晚上八点发来的小询盘忘到第二天下午。而等行业里做过调研的都知道询盘响应速度每慢一小时意向度就肉眼可见地掉一截。更麻烦的是重复性的规格问题每个客户都问业务员既没法不回又没精力把每个答案都写出花来。我见过一个真实的例子某个做精密结构件的客户一次性发来五张图纸的 BOM 询价业务员光是整理材料、查库存、核对起订量就花了大半天期间客户追问两次都没有及时收到回复最后一句“我们已经找别家了”单子就没了。这种场景下哪怕数字员工只干一件事——先把结构化的资料查出来、组织成初步报价单模板推给业务员价值都是巨大的。1.2 为什么偏偏选“企业微信 LLM”如果没有企业微信这个项目要么挂在自己的 App 里要么挂在个人号上。挂个人号数据合规、账号风控、客户资产沉淀都是雷区。而企业微信本身就是 B2B 沟通的主阵地客户联系人、聊天记录、客户标签天然都在体系里面数字员工在这个环境里干活不需要改变客户的来往习惯也方便后续迁移到真正的 CRM 流程。LLM 在这里承担的是“理解”和“表达”这两层。它不负责通讯底层也不负责客户数据存储而是把客户一段模糊的话“这个 304 材质的耐温多少”“能防水吗”转成对产品参数、知识库内容的检索和回复。这也是整个系统里“脑”的部分。这两者结合到一起就形成了一条完整链路企业微信收消息 → LLM 判断意图 → 查业务数据 → 组织话术 → 再通过企业微信发出去。听起来不复杂真做起来处处都是工程细节。2. 整体架构设计收消息、想答案、发消息、留痕迹2.1 分层思路接入层、认知层、数据层很多半路出家做数字员工的人上来就写一个脚本去轮询消息然后用 requests 调 LLM API再把回复塞回去。本地 demo 没问题一旦上到生产会发现消息时序、并发、幂等、失败重试全乱套。所以我从第一天就按三层来设计宁可前期多写几百行代码也不愿意后面某个深夜爬起来修 bug。接入层负责所有企业微信侧的通讯交互。包括接收事件回调、解析消息、处理 AES 加解密、调用企业微信 API 发送消息。这一层的核心原则是“只做通讯不做业务”。所有进来和出去的消息都走统一的数据结构业务逻辑不耦合企业微信的 API 细节。认知层是 LLM 相关逻辑所在的地方。包括对话编排、prompt 管理、上下文组装、工具调用比如查库存、查交期。这一层不直接操作数据库而是通过工具函数把结果拿回来后整理成话术。数据层存客户、会话、消息、跟单任务、知识库这三类核心数据。会话状态至少要做到“这个客户跟数字员工聊到哪一步了”跟单任务则负责“几小时内需要人工跟进”这类提醒。2.2 消息全链路一次询盘进来后发生了什么一个客户在企业微信里给数字员工发来“你们有不锈钢波纹管吗”顺着链路走一遍你会发现这里面每一步都有讲究。先说明客户端客户是直接用企业微信加过来的外部联系人开通企业微信的“客户联系”能力之后消息会通过回调的方式推送到你的后端服务。后端校验签名、解密报文把消息内容标准化。接着编排服务根据 customer_id 拉取这个客户的会话历史。如果这是一个新客户就新建会话打上“首次询盘”标签如果是老客户则把最近 N 轮对话拼进上下文。然后LLM 拿到“最近对话 用户当前问题 产品知识库片段 当前可用的工具列表”开始推理。这一步通常会先判断意图是产品咨询、价格咨询、订单进度还是想找人工意图判断完成后再决定要不要调用工具。比如客户问“2 吨的型号是什么”系统调用产品库查询把型号和参数返回给 LLM由 LLM 组织成自然语言回复。回复在发出去之前还有一个重要的校验环节如果是价格类信息必须走配置好的报价区间逻辑禁止 LLM 自己凭想象报价如果客户连续问了三个技术细节且知识库里没有就生成“转人工”提示并主动在后台给业务员弹一条跟进提醒。最后整轮消息原始入参、LLM 回复、工具返回、置信度落盘。这一步是给周报、给未来模型微调、给人工复盘留素材的。2.3 为什么不选“定时回访”这种偷懒方案有人会问与其这么重地接 LLM为什么不做一套基于关键词的定时自动回复做是可以但“询问跟单”过程中的自然语言多变到令人发指。同一个意思客户可能说“单价多少”也可能说“这个品什么价格”还可能说“你们价格合理吗”。关键词规则在这种环境下要么漏答要么误答。漏答客户觉得被怠慢误答更要命——参数答错了后面解释成本远远高于省下的那点 token 费用。LLM 的价值恰恰在于容忍这种语言多样性并给出语境匹配的回复。还有一个隐藏逻辑报价和跟单本身是一个持续几天的多轮过程不是一个一次性问答。客户第一天问了价格第三天可能回来追问批量折扣第五天又换了个人来对接。只有带上下文能力的 LLM 才能保证这个长链条不掉线、不失忆。3. 核心实现企业微信和 LLM 怎么真正“连”起来3.1 企业微信侧的准备工作和接口选择整个项目的起点是把企业微信侧配置好。我当时的操作步骤大致是这样的先在企业微信管理后台创建自建应用拿到 CorpID 和 Secret然后配置可信 IP 和接收消息的服务器 URL把回调地址指向已经部署好的 HTTPS 后端。需要注意企业微信回调消息的请求体是加密的必须用 AES 解密后才能拿到真实内容。这里建议把解密和验签的代码单独封装成公共模块不要和业务逻辑混写。真实踩坑点在于企业微信要求 URL 在配置时能通过验证如果你的服务器在配置阶段临时出了问题比如域名没有解析或者 80/443 端口不通后台会反复请求验证看着像攻击其实是配置没完成。消息发送侧外部联系人会话用的是“客户联系”相关接口。这里特别提醒消息发送是有频控限制的不要因为想抢响应速度就把所有消息都并发出去了尤其是带图片文件的消息限速比普通文本更严格。合理做法是内部做一个小队列发送失败后指数退避重试而不是立刻怼回去。3.2 LLM 接入与 Prompt 编排LLM 接入没有太神秘的东西我直接用 OpenAI 兼容的 SDK 调 DeepSeek 或 Qwen 这类国产模型。选型逻辑很朴素便宜、中文效果好、接口生态成熟。自助搭建一主备配置某个模型超时或限流时自动切换。真正花时间的是 prompt 编排。我采用的是一套“角色 边界 知识源 工具路由 输出格式”的结构。角色设定清楚它是“跟单助理”不是“销售专家”不要替销售做最终决策边界里写明价格不能自己定、交期不确定的时候必须说“我帮你核实一下”知识源是连接向量库的路径把常见产品资料、参数表、FAQ 切成小块灌进知识库工具路由则是告诉 LLM什么时候调库存 API、什么时候查订单状态。这里要特别强调一个生产级原则不要指望 LLM 只靠 prompt 就百分百不犯错。对价格、型号这类关键信息我用的是“固化规则”而不是“提示约束”。比如客户问价格程序会先查报价配置把配置结果放进 prompt 里让 LLM 组织语言而不是让 LLM 从零开始编一个价格。这样就算模型偶尔抽风它也没有“编价格”的空间。3.3 会话状态与记忆管理对于跟单场景记忆是数字员工能不能持续服务的命门。客户一周前问过的那款产品型号如果这次完全忘了客户体验会瞬间崩掉。我用了两级记忆。一级是短期记忆存在 Redis 里保存最近 20 轮对话TTL 设置为 48 小时正好对应企业微信的服务窗口期另一级是长期记忆存在数据库里按 customer_id 产品主题归档客户再次发起会话时先把相关历史摘要注入上下文。这里有个工程细节发送给 LLM 的上下文不是越长越好。超过模型窗口之后不仅成本飙升模型反而会抓不住重点。我的做法是把历史摘要化例如“这个客户上周问过 304 材质的弯头当时回复了可定制且提供过最小起订量”而不是把旧对话原文一把梭进去。实践证明摘要式记忆在跟单场景里既省钱又稳。3.4 跟单提醒与人工交接的实现数字员工不是把所有客户都干到底它是把值得人工接手的客户“喂”到业务员嘴边。所以系统里必须有一个“转人工”和“跟进提醒”机制。实现上我在消息处理完之后加了一个后置任务校验。当客户消息里出现招标书、特殊定制图纸、议价博弈这类强意向信号时LLM 在回复客户“我把你的需求转给专员他会尽快联系你”的同时会向后端写入一条跟进任务并把客户画像、对话摘要、待办事项推送到指定业务员的企业微信消息卡片。事实证明这个“人机交接”的流程比纯自动回复的价值大得多因为它本质上是一个销售线索分发系统。数字员工不需要做到 100 分它能做到 80 分然后让业务员用 20 分精力去补上最后的成交闭环这就已经比原来的纯人工效率高出一大截了。4. 几个印象深刻的坑4.1 企业微信的“48 小时服务窗口”比想象中更严格这是整条链路里最隐蔽、最要命的规则。企业微信外部联系人场景下客户主动发消息后企业侧才有一定时间窗口可以主动发消息超过窗口期主动下发的消息会被平台拦截或要求引导客户重新触发。这意味着什么数字员工必须做到“即时响应”因为它争的就是这个窗口。如果 LLM 处理超时、消息队列积压、或者服务宕机半小时等恢复过来想补发一条“抱歉久等了”在窗口之外是发不出去的。我们的解决方案是双保险。一是监控消息处理延迟超时直接报警二是妥善设计身份验证和“重新激活”路径比如通过欢迎语卡片、服务通知等合法方式引导客户再次进入会话重新开启窗口。千万不能动硬发的念头企微侧频控和风控一旦触发整个应用会被打得很难看。4.2 回调 URL 的重试风暴与幂等企业微信的消息回调为了保证送达会做自动重试机制。正常情况下这是优点但如果我们服务端处理时间超过接口超时上限或者代码里一个 bug 导致 500回调就会反复打过来形成重试风暴。我第一版上线时就吃过这个亏。某个深夜回调接口出了一个空指针异常企业微信后台一直重试我的服务在十分钟内收到了上千次相同消息的通知。如果不是日志里发现 message_id 重复我甚至以为是有人在刷接口。解决方式非常朴素但有效消费端做幂等表。以 message_id 为唯一键处理前先查数据库处理过就直接跳过。同时回调接口本身永远先返回 200 再异步处理把处理时间从接口请求周期里摘出去这样企业微信侧不会因为处理超时反复重试。这套组合下来重试风暴基本被杜绝了。4.3 LLM 上下文漂移导致“失忆”上线一周后有业务员反馈数字员工“莫名其妙答非所问”。排查发现部分客户在多轮会话中聊了太多内容上下文拼接时被截断或相互覆盖导致模型丢失了最开始的关键信息。典型情况是客户上午问 A 型号下午发来一张图纸问能不能做模型却认为图纸是给 A 型号确认用的闹出误会。要解决这个问题不能光靠“多塞几轮上下文”。我后来给会话状态加了一个“关键信息槽位”的机制把产品型号、材料、数量、目标价、截单时间这类结构化字段单独抽取出来放在一个固定区域喂给 LLM。模型每次回答都能看到当前这个客户“已经明确的产品诉求”而不是依赖它自己从聊天记录里猜。加了槽位之后失忆类问题基本清零。4.4 并发处理与重复跟单询盘的特点是“突发性”可能一个小时没客户来也可能同一分钟涌进五个询盘。如果消息处理逻辑是单线程的很容易崩溃如果用了多线程但没做锁又可能出现同一个客户被两个线程同时处理重复生成跟单任务、重复发消息。我的处理方案是在应用内做了一个简单的单客户锁按 customer_id 做 key同一时间只有一个 worker 在处理某个客户的对话。至于不同客户的并发靠无状态服务加水平扩容解决。还有一个坑是LLM 接口偶尔会超时如果超时就重试可能同一轮客户消息被重试两遍导致客户收到两遍几乎一样的话。这里要记住超时重试之前必须确认上一次到底有没有发出去可以通过查询发送记录来判断。4.5 让 LLM 学会说“不知道”比让它什么都答更重要数字员工最大的风险不是答得慢而是答得自信且错误。尤其是技术参数和交期承诺模型一本正经地编一个不存在的规格客户一旦信了后面业务员要花十倍精力去澄清。我在 prompt 里用高权重强调“只在知识库中寻找答案没有明确依据时必须回复‘这个问题我需要找同事确认一下’”同时在应用层拦截一轮如果回复文本中包含价格、交期、材质保证类关键词且没有对应配置单数据支撑这条回复会先被拦截改成转人工话术。这个策略执行后数字员工变得“笨”了一些但客户投诉率明显下降。经验告诉我在销售场景里可信度比覆盖率金贵得多。5. 成本账不上天但得算明白5.1 硬性成本服务器和企业微信侧整个系统的硬件需求不高因为 LLM 推理不在本地跑。我用的是一台 2 核 4G 的云服务器部署了 FastAPI 服务、Redis 和 PostgreSQL日常负载下 CPU 占用都不高。这类服务器市面价格大约一年几百到一千元区间按月折算大概五六十到一百元。企业微信本身是免费的基本能力不收费。但如果你是认证企业每年有个认证费用这笔钱不是系统成本但也算在整体预算里。我强烈建议用认证企业主体来做不然外部联系人规模、接口权限都会受限。5.2 LLM API 成本按 token 算的细账这一块是很多人最虚的。我当时每天的调用量大约是200 个活跃询盘会话平均每个会话 10 轮对话每轮对话上下文加上回复一套流程下来大概在 3000~5000 token 浮动。这里取中间值 4000 token 来算。每天的总 token 消耗大致是 200×10×4000也就是 800 万 token。厂商比如 DeepSeek 或通义千问这类模型日常价格在每百万 token 几元钱级别输入输出混合、模型不同有差异按这个量级每天花费是几块钱到十几块钱的程度一个月下来在几十到两百元区间。这个波动取决于你的模型选择、上下文长度和是否启用长文档检索。有人可能会觉得 800 万 token 很多但实际上跟人工成本比简直就是九牛一毛。而且这个费用会随着业务量线性增长如果你能做到 70% 的客户直接被数字员工承接剩下 30% 转人工人力节省的空间是实打实的。5.3 成本优化的三个小技巧第一个技巧是上下文瘦身。前面提过的摘要式记忆不但提升了模型准确率也直接砍掉了一半以上的 token 消耗。第二个技巧是模型分级。普通问答用便宜快的小模型涉及报价、合同条款这类高价值场景再切换到大模型精答。第三个技巧是缓存和批处理。常见问题第一次问过后把回复缓存起来相同问题直接命中缓存省掉重复推理成本。对了我建议在项目里给每轮对话都打上“可计费 token 数”的日志字段每天跑一个定时任务汇总。否则你会像我一样到了月底才发现某个测试环境偷偷跑了好几百万 token账单出来才肉疼。6. 上线后的体感与几个调试妙招数字员工上线之后业务那边体感变化最大的不是“回复变快”而是“回复变稳”。以前业务员忙的时候回复比较随意客户问一句答一句经常出现答非所问。现在数字员工给出的每条回复都有结构、有来源业务员只需要在转人工的节点接管沟通质量是明显上了一个台阶的。我还要分享一个调试技巧给 LLM 的所有回复都悄悄加一个“trace_id”和“引用来源字段”。上线初期业务员反馈任何一条奇怪回复我都可以直接通过会话 ID 把当时的上下文、知识库命中片段、模型输出原始日志翻出来。这个习惯帮我定位了几十个看似玄学的问题强烈建议你也这么做。最后一点小经验别让数字员工全天候无人值守硬扛。最理想的状态是白天人工在线时把它当成“实时草稿助手”业务员确认后一键发送夜间和节假日再让它全自动响应。这样既保住了体验又给灰度上线留足了安全垫。这个项目迭代空间还很大比如接入知识库自动更新、增加多语言询盘支持、以及在跟单链路中结合订单系统。做这种数字员工核心不是把模型调得多聪明而是把“边界”和“留痕”做到位。边界管住错误留痕管住迭代这两件事做扎实项目就成功了一大半。