微信机器人接 AI 客服GPT/Claude/DeepSeek 多模型切换实战很多团队的 AI 客服是这样长出来的立项时接了一个大模型业务代码里到处都是这家模型的请求格式。三个月后模型涨价了、或者出了个效果更好的新模型想换——发现要改十几个地方测试回归一圈最后不了了之。模型绑定是 AI 客服最常见的技术债。这篇给一个解法在微信通道和大模型之间加一个统一的 LLM 网关层换模型只改配置主模型挂了自动降级到备用模型。为什么需要网关层三个现实问题每个都值回这一层代码各家格式不统一:GPT 是choices[0].message.content,Claude 是content[0].text请求头、参数结构都不一样。没有网关层换模型就是改业务代码。单点故障任何一家模型都有抖动和宕机。绑死一家它挂你的客服就挂。成本分层简单问题“营业时间”和复杂问题“帮我对比三款产品”用同一个旗舰模型纯属烧钱。网关层设计统一入口配置驱动核心抽象就一句话messages 进文本出内部消化各家差异。# llm_gateway.pyimportrequests PROVIDERS{gpt:{url:https://api.openai.com/v1/chat/completions,key:OPENAI_KEY,model:gpt-4o-mini,format:openai,},claude:{url:https://api.anthropic.com/v1/messages,key:ANTHROPIC_KEY,model:claude-3-5-haiku-latest,format:anthropic,},deepseek:{url:https://api.deepseek.com/v1/chat/completions,key:DEEPSEEK_KEY,model:deepseek-chat,format:openai,# DeepSeek 兼容 OpenAI 格式},}defask(provider,messages,timeout15):统一调用入口:messages 进,文本出pPROVIDERS[provider]ifp[format]openai:rrequests.post(p[url],headers{Authorization:fBearer{p[key]}},json{model:p[model],messages:messages},timeouttimeout).json()returnr[choices][0][message][content]else:# anthropic 格式rrequests.post(p[url],headers{x-api-key:p[key],anthropic-version:2023-06-01,Content-Type:application/json},json{model:p[model],max_tokens:1024,messages:messages},timeouttimeout).json()returnr[content][0][text]新增一家模型往PROVIDERS里加一条配置就行。业务代码永远只调ask(provider, messages)。故障降级链主模型挂了客服不挂CHAIN[deepseek,gpt,claude]# 按你的成本/稳定性偏好排序defask_with_fallback(messages):forproviderinCHAIN:try:replyask(provider,messages)log_usage(provider,successTrue)# 记录谁答的,做观测returnreplyexceptExceptionase:log_usage(provider,successFalse,errstr(e))continuereturnNone# 三家全挂 → 走关键词兜底或转人工log_usage别省每个 provider 的成功率和耗时都要记跑两周你就知道该把谁排在链首——模型选型从拍脑袋变成看数据。成本路由简单问题别用大模型SIMPLE_KEYS[营业时间,地址,电话,价格表]defpick_model(content):按问题复杂度路由:简单走便宜模型,复杂走强模型iflen(content)20orany(kincontentforkinSIMPLE_KEYS):returndeepseek# 便宜够用returngpt# 复杂问题再上好模型实战经验客服场景 60% 以上是简单问题全走便宜模型token 成本能砍掉一大半。更省的一招超高频问题比如营业时间干脆别调模型关键词直回固定答案零成本毫秒级。接到微信上网关层插在中间和微信侧的对接反而简单前面文章讲过的结构原样保留只把调模型那一步换成网关微信消息 → WTAPI Webhook → 队列 → pick_model → ask_with_fallback ↓ WTAPI postText ← 生成回复(或兜底话术)WTAPI 负责收消息Webhook和回写postText网关层负责模型调度——两层各管各的模型侧的任何折腾都碰不到微信代码反过来微信侧换实例、换部署形态也碰不到模型代码。回调侧的两条老规矩不变3 秒内返回所以走队列异步、Appid NewMsgId去重。defhandle_text(session_id,from_wxid,content):providerpick_model(content)messagesbuild_messages(session_id,content)# 带会话上下文replyask_with_fallback(messages)ifreplyisNone:reply当前咨询较多,人工客服马上来~# 全挂时的兜底话术notify_human(session_id,content)send_text(from_wxid,reply)# WTAPI postText 回写微信侧的postText和 Webhook 配置想在线调一遍的WTAPI 开发文档weiti.apifox.cn支持在线调试——目前提供 7 天接口调用权限后台附带 Demo 示例可供本地调试。接口路径与字段以文档实时内容为准。上线前两个提醒回复内容要过审:AI 生成的话术可能蹦出敏感词或夸大承诺发送前过一道内容审核关键词过滤起步客服场景的说错话成本比不回复高。会话上下文要隔离多客户共用一个机器人上下文必须按会话 ID 分开存A 客户的对话历史绝不能串到 B 客户的 prompt 里——这既是体验问题也是数据安全问题。合规声明本文示例仅用于技术学习与合规私域自动化场景请使用注册 3 个月以上、已实名的合规账号遵守平台规范与各大模型服务商的使用条款自动回复内容应经审核不得用于骚扰、欺诈等违规场景。