简介这是一套基于PHP开发的微信在线AI客服系统源码面向需要为企业微信搭建智能客服的中小团队与个人开发者可解决7×24小时自动应答、人工转接与对话管理等实际需求。压缩包共38个文件以31个PHP源码文件为主体另含说明文档、配置示例与少量前端页面资源整体约20.57MB结构上按服务层、AI逻辑、对话管理与后台配置等模块拆分便于二次开发与参数调整。系统支持文本对话、图片分析、视频分析等交互方式并内置对话管理、人工转接、咨询提醒等高级功能同时提供配置文件方便设置回复模板与对话策略。目前已有65人学习下载适合希望快速搭建可定制智能客服平台、研究PHP客服系统架构的开发者参考借鉴。1. 微信在线AI客服系统到底在解决什么问题很多团队做微信生态的客服第一反应是接个第三方SaaS结果发现客户消息里夹着订单号、手机号、售后图片数据全落在别人服务器上老板一问「能不能私有化」就卡住了。2026年这波「微信在线AI客服系统源码」的需求本质就是要把大模型对话能力、微信消息通道、企业知识库这三样东西捏在自己手里跑在自己的服务器上。它适合两类人一是手里有微信小程序或公众号、每天咨询量在几百到几千条的中小团队二是做交付的集成商需要一套能改、能贴牌、能对接客户已有CRM的底座。源码方案的核心价值不是「免费」而是你能看到每一条消息从微信服务器进来、经过意图识别、命中知识库、调用大模型、再回到用户手机上的完整链路出问题时有得查。2. 微信消息通道怎么接公众号、小程序与客服消息的选型2.1 三种接入方式的边界与选择依据微信侧能拿到用户消息的入口主要有三个选错了后面全是返工。公众号服务号走的是微信服务器推送模式用户在对话框发消息微信把XML或JSON推到你的回调URL你必须在5秒内响应否则微信重试三次然后放弃。小程序客服消息类似但用户是从小程序内的客服按钮进来消息体结构不同。企业微信则是另一套API适合内部员工和外部客户混合的场景。接入方式消息到达形式响应时限适合场景主要限制公众号服务号服务器推送XML/JSON5秒对外客服、菜单交互需认证服务号模板消息受限小程序客服服务器推送JSON5秒小程序内咨询需用户主动点客服按钮企业微信回调主动调用API5秒内部外部混合需企业认证配置复杂我一般建议如果客户主要在小程序里下单就选小程序客服如果还要做菜单、推模板消息公众号服务号更顺手。两者可以同时接用同一个消息路由层做分发。2.2 回调URL的验证与消息解密微信推送的消息默认是加密的用的是AES-256-CBC密钥在公众号后台配置。验证回调URL时微信会发一个GET请求带signature、timestamp、nonce、echostr四个参数你需要用token做SHA1校验后原样返回echostr。这一步翻车最多的是token填错或者服务器时间不同步导致签名对不上。# wechat_callback.py import hashlib import time from flask import Flask, request, make_response app Flask(__name__) WECHAT_TOKEN your_token_here # 公众号后台配置的Token def check_signature(signature, timestamp, nonce): 微信签名校验token、timestamp、nonce字典序排序后SHA1 arr sorted([WECHAT_TOKEN, timestamp, nonce]) sha1 hashlib.sha1(.join(arr).encode(utf-8)).hexdigest() return sha1 signature app.route(/wechat, methods[GET, POST]) def wechat(): if request.method GET: # 回调URL验证 signature request.args.get(signature, ) timestamp request.args.get(timestamp, ) nonce request.args.get(nonce, ) echostr request.args.get(echostr, ) if check_signature(signature, timestamp, nonce): return make_response(echostr) return make_response(signature error, 403) # POST消息处理见下一节 return make_response(success)这段代码的关键点WECHAT_TOKEN必须和公众号后台「服务器配置」里的Token完全一致大小写敏感。sorted排序是微信规定的字典序不是按参数名长度。返回echostr时不要加任何额外字符否则验证失败。如果一直提示「token验证失败」先检查服务器时间date命令看是否和标准时间差超过几分钟。2.3 消息体解析与5秒响应的工程处理微信推送的消息是XML格式公众号或JSON小程序包含FromUserName用户openid、ToUserName你的公众号原始ID、MsgTypetext/image/event、Content文本内容等字段。5秒响应是硬限制但大模型生成一条回复通常要2到8秒所以必须做异步收到消息后立刻返回「success」空串然后把消息丢进队列由后台worker调用AI生成回复再通过客服消息接口主动推给用户。# 消息入队立即返回success import json import redis r redis.Redis(hostlocalhost, port6379, db0) app.route(/wechat, methods[POST]) def handle_message(): xml_data request.data # 解析XML省略假设已得到user_msg字典 user_msg parse_wechat_xml(xml_data) # 丢进Redis队列worker异步处理 r.lpush(wechat_msg_queue, json.dumps(user_msg)) return make_response(success) # 必须5秒内返回这里有个血泪经验如果你在回调里直接调大模型微信等不到响应会重试用户会收到重复回复。用Redis做队列是最轻量的方案worker用brpop阻塞读取处理完调客服消息接口。注意客服消息接口有48小时窗口限制用户最后一次互动后48小时内才能主动推送超了就只能等用户再发消息。3. AI客服大脑怎么搭意图识别、知识库与模型调用3.1 意图识别用规则还是模型意图识别的目的是判断用户这句话是要查订单、问售后、还是纯闲聊。小团队我建议先用规则关键词匹配比如「订单」「物流」「退款」命中售后意图「你好」「在吗」命中闲聊。规则的好处是可控、可解释、零延迟。当规则覆盖率达到70%以上再考虑上模型用BERT微调或者直接调大模型做few-shot分类。# intent_router.py 规则意图识别 INTENT_RULES { order_query: [订单, 物流, 发货, 快递, 到哪了], after_sale: [退款, 退货, 换货, 坏了, 质量问题], human_service: [人工, 转人工, 真人, 客服], chitchat: [你好, 在吗, 谢谢, 再见] } def detect_intent(text): for intent, keywords in INTENT_RULES.items(): if any(kw in text for kw in keywords): return intent return unknown # 兜底走大模型参数说明INTENT_RULES的key是意图标识value是关键词列表。any做的是子串匹配中文不需要分词也能用。unknown兜底很重要不要硬塞进某个意图交给大模型做开放域回答更稳。如果发现「人工」被误判成「order_query」检查关键词顺序把human_service的优先级提前。3.2 知识库检索向量库选型与分块策略知识库是AI客服能不能答准的核心。常见做法是把产品文档、FAQ、售后政策切成小块用embedding模型转成向量存进向量库用户提问时先检索最相关的3到5块拼进prompt让大模型基于这些内容回答。向量库选型上小规模几千条用Chroma或FAISS本地跑就够上百万条再考虑Milvus或Qdrant。分块策略直接影响召回率。我一般按语义段落切每块300到500字重叠50字。切太碎会丢上下文切太大检索精度下降。下面是一个用LangChain做分块和入库的示例# build_knowledge_base.py from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma # 1. 读取文档 with open(faq.txt, r, encodingutf-8) as f: raw_text f.read() # 2. 分块按段落切块大小400重叠50 splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap50, separators[\n\n, \n, 。, , , ] ) chunks splitter.split_text(raw_text) # 3. 向量化并存入Chroma embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectorstore Chroma.from_texts( textschunks, embeddingembeddings, persist_directory./chroma_db ) vectorstore.persist() print(f入库完成共{len(chunks)}块)参数说明chunk_size400是经验值中文场景下400字大约对应一个完整问答对。chunk_overlap50保证跨块语义不断裂。separators的顺序很重要优先按双换行切再按单换行最后按句号这样能尽量保持段落完整。bge-small-zh-v1.5是中文小模型CPU也能跑适合预算有限的团队。如果检索结果总是不相关先检查分块是不是把问答对切散了把chunk_size调到600试试。3.3 大模型调用与Prompt模板设计大模型调用层要处理三件事拼prompt、调API、解析返回。Prompt模板决定了回答风格和准确性。我一般用这个结构系统角色 检索到的知识 用户问题 输出约束。# llm_client.py import openai SYSTEM_PROMPT 你是一个微信在线客服助手。请根据以下知识库内容回答用户问题。 如果知识库中没有相关信息请如实说「这个问题我需要转人工确认」不要编造。 回答要简洁控制在100字以内。 def build_prompt(user_question, retrieved_docs): context \n---\n.join(retrieved_docs) return f知识库内容 {context} 用户问题{user_question} def call_llm(user_question, retrieved_docs): prompt build_prompt(user_question, retrieved_docs) response openai.ChatCompletion.create( modelgpt-4o-mini, # 或替换为国产模型 messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: prompt} ], temperature0.3, # 低温度保证回答稳定 max_tokens200 ) return response.choices[0].message.content参数说明temperature0.3是客服场景的推荐值太高会胡说太低会死板。max_tokens200防止模型长篇大论微信消息太长体验差。retrieved_docs一般取top 3太多会稀释关键信息还增加token成本。如果模型总是说「转人工」检查检索是不是没召回把相似度阈值调低或者增加召回数量。4. 源码落地时最容易翻车的五个地方4.1 现象用户收到重复回复 → 原因5秒超时重试 → 解决异步队列消息去重微信服务器在5秒内没收到响应会重试最多三次。如果你在回调里同步调大模型必然超时。解决方法是收到消息立刻返回success把处理逻辑丢给后台worker。但光这样还不够微信重试的消息可能重复入队需要在入队前用MsgId做去重Redis的setnx设一个60秒过期的key就能挡住。4.2 现象AI回答和知识库对不上 → 原因分块把问答切散 → 解决按语义边界切重叠FAQ文档里一个问答对通常是「问题xxx\n回答xxx」的结构如果按固定字数切很可能把问题和回答切到两个块里检索到问题块但回答块没召回。解决方法是自定义分隔符把「问题」作为切分点保证每个块包含完整问答。或者用RecursiveCharacterTextSplitter时把\n\n优先级提到最高。4.3 现象客服消息推送失败 → 原因48小时窗口过期 → 解决记录最后互动时间模板消息兜底微信客服消息接口规定用户最后一次发消息后48小时内才能主动推送。如果用户昨天问了问题你今天才处理完想回复接口会返回45015错误。解决方法是数据库记录每个openid的last_interact_time推送前判断是否超窗。超窗了只能用模板消息需用户订阅或者等用户再发消息。4.4 现象向量检索慢 → 原因每次请求都重新加载模型 → 解决模型常驻内存HuggingFaceEmbeddings如果每次检索都实例化加载模型要好几秒。正确做法是在应用启动时初始化一次全局复用。Flask里可以放在before_first_request或者用单例模式。Chroma的persist_directory也要确保只加载一次不要每次请求都from_texts。4.5 现象大模型API费用失控 → 原因无缓存无长度限制 → 解决加语义缓存max_tokens相同问题反复问每次都调API是浪费。可以在Redis里做一层语义缓存把用户问题embedding后算余弦相似度超过0.95就直接返回缓存答案。另外max_tokens必须设不然模型可能生成几百字。还有个小技巧把系统prompt和知识库内容做前缀缓存部分模型厂商支持prompt caching能省不少钱。5. 把AI客服接进现有系统的三个进阶技巧5.1 用函数调用让AI直接查订单纯问答的客服价值有限用户问「我的订单到哪了」AI应该能直接调你的订单接口查物流而不是让用户自己去看。用大模型的function calling能力可以实现定义query_order(order_id)函数模型判断用户意图后返回函数名和参数你的代码执行查询再把结果喂回模型生成自然语言回复。# function_calling.py tools [{ type: function, function: { name: query_order, description: 根据订单号查询物流状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单号} }, required: [order_id] } } }] # 模型返回tool_calls后执行本地函数 def handle_tool_call(tool_call): if tool_call.function.name query_order: args json.loads(tool_call.function.arguments) return query_order_from_db(args[order_id])关键点description要写清楚模型靠它判断什么时候调。required里的参数模型必须提供但用户可能没给订单号这时候模型会追问体验反而更好。执行完函数后要把结果作为role: tool的消息追加到对话里再调一次模型生成最终回复。5.2 多轮对话的上下文管理微信客服天然是多轮的用户可能先问「订单」再问「什么时候到」再问「能改地址吗」。如果每轮都独立处理AI会丢失上下文。做法是用openid做key在Redis里存最近5轮对话历史每次请求把历史拼进prompt。但要注意token长度超过模型上限要截断最早的轮次。存储方案优点缺点适用规模Redis List读写快天然支持过期内存成本高日活1万MySQL持久化可分析读写慢日活1万内存字典零依赖重启丢失测试环境我一般用Redis Listlpush新消息ltrim保留最近10条expire设7天。这样既控制内存又保证上下文够用。5.3 人工接管与AI的平滑切换AI不是万能的用户说「转人工」或者AI连续两次回答「不知道」就应该切到人工。实现上用一个状态字段标记会话是bot还是human人工接管后AI不再自动回复客服在后台看到消息手动回。切回AI可以设一个超时比如人工30分钟没说话自动切回bot。# session_manager.py def should_transfer_to_human(session): if session.get(intent) human_service: return True if session.get(unknown_count, 0) 2: return True return False def update_session(openid, intent, answer): key fsession:{openid} r.hincrby(key, unknown_count, 1 if answer 不知道 else 0) r.hset(key, intent, intent) r.expire(key, 3600)这套逻辑跑下来人工接管率能控制在15%以内大部分标准问题AI自己就消化了。最后说个我自己的习惯每次上线新知识库先拿历史聊天记录跑一遍离线测试看召回率和准确率别直接上生产。这个后悔药我吃过一次半夜被客户电话叫醒的滋味不好受。希望帮到你。本文还有配套的精品资源点击获取