前阵子老板拍板要做微信智能客服让我把大模型接进去。我寻思这不就是调个大模型API嘛半天就能搞定。结果真动手才发现微信消息进来到AI回复发出去中间隔着6个环节每个环节都有坑。消息怎么解析、上下文怎么管、AI回复怎么格式化、发送失败怎么重试……网上的教程要么只讲微信对接要么只讲大模型调用中间这段全是空白。熬了一周把整条链路跑通今天把6个环节挨个拆出来讲每个环节讲做什么、用什么技术、踩了什么坑。想先把微信侧接口跑通的可以去 Eyun开发文档 看看Webhook和发消息接口怎么配那块搞明白了再看这条链路会顺很多。环节一消息输入——用户发微信消息Eyun通过Webhook推送做什么用户在微信里发消息Eyun收到后通过Webhook把消息推到你的服务接口。这是整条链路的入口消息进不来后面全是空谈。Eyun API支撑回调数据是JSON格式关键字段有wId登录实例标识标识是哪个微信号收到的fromUser发送方微信IDmsgType消息类型文本/图片/语音处理逻辑不一样content消息内容接口必须5秒内返回200不然Eyun会认为你没收到触发重试造成重复处理。踩坑点最大的坑是msgType不判断就处理。我一开始默认所有消息都是文本结果客户发了张图片content字段是个URL直接丢给大模型模型回了一堆乱码。后来老老实实按msgType分流文本直接用、图片转OCR、语音转文字。还有个坑是回调重复推送。网络抖动导致我没及时返回200Eyun重发了三次客户收到三条一样的AI回复直接骂你们机器人卡壳了。加Redis幂等后才解决。环节二消息预处理——解析消息体格式转换做什么把不同类型的消息统一转成文本方便喂给大模型。文本直接用图片做OCR识别语音做ASR转文字。技术支撑文本清洗一下去掉机器人、表情符号这些干扰图片调OCR服务把图片里的文字提取出来语音调语音转文字服务踩坑点语音转文字是重灾区。客户带方言的语音转出来一堆乱码AI基于乱码回复答非所问。后来加了置信度判断转文字置信度低于0.7就回一句没太听清麻烦打字说一下比硬答强多了。图片OCR也有坑客户发商品截图问这个多少钱OCR只识别出文字没识别出商品得结合图像识别才行。这种复杂场景建议直接转人工别让AI硬撑硬撑出来的回答只会让客户更火大。环节三上下文检索——从Redis拉历史对话做什么根据用户ID从Redis拉最近几轮对话作为本次AI回复的上下文。这一步决定了机器人是在对话还是在一问一答。技术支撑用Redis的List结构存对话历史按用户分桶。每次拉最近10条消息左推新消息、裁剪旧消息简单粗暴但管用。关于上下文管理和多轮对话的设计思路Eyun平台 上有一些现成的实践案例可以参考比我在这儿干讲细。踩坑点上下文存太多token会爆。我一开始存了20轮大模型prompt直接超长报错还白白烧了一堆token费用。后来砍到10轮够用还省钱。还有个隐蔽的坑Redis宕机导致上下文全丢。客户连问两轮第二轮AI完全接不上客户以为机器人坏了。后来加了本地内存缓存兜底Redis挂了至少能撑一会儿不至于当场露馅。环节四AI处理——调大模型API生成回复做什么拿用户消息上下文知识库材料调大模型API生成回复。这是整条链路的核心回复质量全看这一步。技术支撑System Prompt设计定义AI的角色、语气、回答边界RAG知识库检索从向量库捞相关文档塞进prompt增强回答大模型API调用把组装好的prompt发给大模型拿回回复踩坑点最坑的是大模型胡说八道。有次客户问退货政策AI编了个7天无理由出来实际我们政策是15天。客户拿着AI的回复来扯皮客服差点背锅。后来上了RAG让AI基于知识库回答明确不准编。System Prompt也踩过坑。一开始没限定边界客户问你们老板是谁AI瞎编了个名字。后来prompt里明确写了不知道的就说不知道别编这种边界比调参数重要得多。环节五回复后处理——AI回复格式化加表情/卡片做什么大模型返回的往往是纯文本或半结构化内容直接发给用户体验很差。这一步把AI回复转成人话。技术支撑去掉AI回复里的JSON结构、调试信息加合适的表情符号和换行让消息有人情味超长回复分段微信单条消息有字数限制踩坑点千万别直接把大模型的JSON丢给用户。我早期图省事直接发客户收到一坨带引号和括号的东西直接骂你们机器人坏了吧。还有个细节AI回复太AI了全是根据您的需求我建议您……这种腔调。后来加了个后处理把书面语改口语我建议您改成要不试试自然多了。客户反馈说感觉不像跟机器人聊天。环节六回复发送——调Eyun sendText回复用户记录到数据库做什么把处理好的回复通过Eyun的sendText发回用户同时落库存档更新Redis上下文为下一轮对话做准备。Eyun API支撑sendText发文本回复wId标识实例、wcId标识接收方Token鉴权请求头带Authorization落库更新上下文异步执行别卡住发送流程发送相关的接口细节和错误码处理Eyun开发文档 里有完整说明永久错误1001参数错误/1002鉴权失败/1004资源不存在别重试临时错误才重试。踩坑点发送失败要重试但别无限重试。我见过有人写死循环重试接口挂了直接把服务拖崩。现在最多重试3次指数退避3次还失败就记日志告警。落库也别同步做。有次数据库慢查询发送接口卡了8秒客户以为机器人没反应。后来落库改成异步队列发送不再被数据库拖累稳了。链路耗时分析压测过整套链路耗时大致分布环节平均耗时优化空间消息输入Webhook接收5ms异步框架消息预处理20ms文本/800ms语音语音转文字异步化上下文检索10msRedis本地缓存AI处理1.5s大模型/200ms接口流式输出回复后处理30ms预编译模板回复发送100ms异步落库整条链路平均2秒内出回复。想更快的话AI处理那步用流式输出首字延迟能压到500毫秒内客户体感会好不少。代码AI协作链路的核心pipeline这是6个环节串起来的pipeline骨架我项目里在用的精简版import redis import requests class AIPipeline: def __init__(self, base_url, token, llm_api_key): self.base_url base_url self.headers {Authorization: fBearer {token}, Content-Type: application/json} self.llm_key llm_api_key self.redis redis.Redis(hostlocalhost, port6379, db0) def run(self, webhook_payload): # 环节1消息输入 msg self._extract_msg(webhook_payload) # 环节2消息预处理按类型转文本 text self._preprocess(msg) # 环节3上下文检索 context self.redis.lrange(fchat:{msg[from_user]}, 0, 9) # 环节4AI处理 reply self._call_llm(text, context) # 环节5回复后处理 reply self._postprocess(reply) # 环节6回复发送落库 self._send(msg[wId], msg[from_user], reply) self._save_and_update_context(msg[from_user], text, reply) return reply def _extract_msg(self, payload): return {wId: payload[wId], from_user: payload[fromUser], msg_type: payload[msgType], content: payload[content]} def _preprocess(self, msg): if msg[msg_type] text: return msg[content] elif msg[msg_type] image: return self._ocr(msg[content]) # 图片转文字 elif msg[msg_type] voice: return self._asr(msg[content]) # 语音转文字 return [不支持的消息类型] def _call_llm(self, text, context): history |.join(c.decode() for c in context) prompt f历史对话{history}\n用户{text}\nAI resp requests.post(https://your-llm-api/chat, headers{Authorization: fBearer {self.llm_key}}, json{prompt: prompt, max_tokens: 200}, timeout10) return resp.json()[reply] def _postprocess(self, reply): return reply.strip().replace(根据您的需求, ).replace(我建议您, 要不试试) def _send(self, wId, wcId, content): for i in range(3): resp requests.post(f{self.base_url}/sendText, json{wId: wId, wcId: wcId, content: content}, headersself.headers, timeout15) if resp.json().get(code) 1000: return True return False def _save_and_update_context(self, user, text, reply): key fchat:{user} self.redis.lpush(key, f{text}|{reply}) self.redis.ltrim(key, 0, 9)这段代码是骨架生产环境每一步都要加日志、监控、异常处理。尤其是_call_llm那步超时和降级必须有大模型挂了不能让整条链路跟着死。最后这条链路跑通后我最大的感受是核心不在大模型多强在上下文管理。没上下文AI就是个一问一答的搜索引擎有上下文AI才是在对话。同样的大模型加上下文管理后客户满意度涨了四成。新手别一上来就纠结用哪个大模型、调什么参数。先把这6个环节跑通把上下文管好、把Webhook幂等做好、把错误分类重试做好比换10个大模型都管用。每个环节涉及的接口参数和回调配置细节可以去 Eyun开发文档 翻一翻文档写得比较全照着配基本不会卡。链路理顺了剩下的就是慢慢打磨每个环节的细节共勉。