做了快两个月，跑了 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 把当时的上下文、知识库命中片段、模型输出原始日志翻出来。这个习惯帮我定位了几十个看似玄学的问题，强烈建议你也这么做。
最后一点小经验：别让数字员工全天候无人值守硬扛。最理想的状态是白天人工在线时，把它当成“实时草稿助手”，业务员确认后一键发送；夜间和节假日再让它全自动响应。这样既保住了体验，又给灰度上线留足了安全垫。这个项目迭代空间还很大，比如接入知识库自动更新、增加多语言询盘支持、以及在跟单链路中结合订单系统。做这种数字员工，核心不是把模型调得多聪明，而是把“边界”和“留痕”做到位。边界管住错误，留痕管住迭代，这两件事做扎实，项目就成功了一大半。
