简介一套面向企业级客服场景的PHP在线客服系统源码基于ThinkPHP框架实现核心亮点是接入AI知识库适合需要为网站或App快速增加智能应答能力的开发者无论是售前咨询还是售后支持场景均能适用。压缩包共收录2010个文件整体约68.72MB文件类型涵盖PHP业务逻辑、JavaScript前端交互、HTML页面模板、CSS样式、JSON配置与SQL数据库脚本另配有Shell/Python辅助脚本和大量文档目录结构清晰便于按模块阅读和二次开发。当前已有136人学习浏览。资源附带从零开始的安装教程重点讲解fileinfo与redis扩展的启用、php.ini中pcntl_signal等函数禁用等环境配置细节并说明AI知识库与客服对话流程的整合方法同时给出运营级客服系统的完整源码结构涵盖人工接待、自动应答、知识库匹配等场景帮助读者避开常见安装陷阱快速跑通整套系统并据此扩展自身业务。1. 在线客服接AI知识库别再做人工复制粘贴先搞清这套组合到底在解决什么做PHP在线客服系统的团队早晚会遇到同一个问题客户在对话框里反复问“发票怎么开”“退货流程是什么”“这个月账单为什么这么多”客服只能翻文档、查工单然后复制粘贴一段过去。把PHP在线客服接入AI知识库不是让AI替你聊天而是让客服机器人或人工助手的每一次回答都建立在你们自己的文档、工单和话术库上答完还能给出处。这套组合解决的是“企业私有知识检索自动化”和“回答质量一致性”适合手里已有PHP客服系统、想让AI回答不再信口开河的创业者、外包开发者和运维团队。方向确实没错但接入过程中的坑相当多从架构选型到分段参数每一步都藏玄学下面按落地顺序完整讲一遍。2. 先想清楚架构再动手PHP客服系统接入AI知识库的三种落地路径与选型表2.1 知识库问答的本质检索增强生成RAG在客服场景的简化模型很多人把“接入AI知识库”理解成“把文档丢给大模型让它学”这是最大的误解。大模型的训练数据里根本没有你公司的售后政策你也不可能为几百篇文档去微调一个大模型。实际用的是检索增强生成RAG一共三步第一步是索引阶段把你的客服文档、帮助中心页面、工单沉淀切分成小块每块做向量化Embedding存进向量库。第二步是检索阶段用户提问时把问题也做向量化去向量库召回最相关的几块内容。第三步是生成阶段把召回的内容和原始问题一起拼成提示词Prompt交给大模型让它“只根据以下资料回答不要编造”。客服场景的特殊性在于知识总量通常不大几十篇到几百篇文档、几万条历史工单但问题高度集中而且回答必须可追溯。客户问你“什么时候到账”你至少要能说出“根据《退款说明》第2.3条预计3个工作日”。这决定了你不能只做一个聊天机器人而是要做一个“带出处的问答工具”。这个定位会影响后面所有的技术选型——凡是回答完无法提供来源、无法人工复核的方案在客服场景里都走不远。2.2 三种落地路径托管平台API、开源流水线、自建向量库基于上面的模型PHP端要真正“接入AI知识库”常见做法有三种按工作量从低到高排第一种直接使用开源或托管的知识库问答平台比如Dify、FastGPT这类带完整界面的项目。它们把文档上传、分段、向量化、检索、对话、API暴露都封装好了PHP只需要调用一个对话接口。Dify尤其适合国内团队因为它支持Ollama本地模型接入也支持国内大模型API数据不出内网。你的主要工作变成“上传文档 调API”知识库流水线上传、分段、索引、召回、生成由平台承担。这几乎是中小团队最快的路径。第二种自建RAG流水线用LangChain或LlamaIndex写一套检索脚本文档切块、调Embedding接口、存Chroma或Milvus再用PHP直接调大模型API。这条路灵活但你要同时维护文档处理脚本、向量库、检索服务三个组件而且客服系统是PHP写的检索服务通常还得用Python单独跑一个HTTP服务多一套系统就多一堆问题。第三种偏极端的做法不引入知识库平台PHP里直接做全流程——自己写文档切分器调大模型厂商的Embedding接口把向量存进MySQL的JSON字段或单独的表里检索时用余弦相似度在PHP里算。数据量小几百条以内时确实能跑但一旦文档数量上千、需要更新和去重这种“野路子”会让你不断填坑我见过太多团队最后推倒重来选第一种。2.3 选型对照表与我的推荐中小团队选托管还是自建维度开源平台Dify/FastGPT自建LangChain流水线PHP纯自研检索上线速度12天12周24周知识库管理界面有可让运营自助维护无要自己写无召回调试难度低平台自带测试中要写测试脚本高数据隐私控制可本地部署最灵活最灵活维护成本中跟着社区版本走高极高适合团队有客服后台、没AI团队有Python研发只做原型演示我的建议很直接没有专职AI工程师的团队优先选第一种部署一个Dify社区版或者直接用托管版先把链路跑通。理由不是它最先进而是它自带“知识库流水线”的可视化调试界面。你上传一份文档、切好段、测几个查询、看召回分数整个流程一目了然。这个可见性在项目初期太重要了它能让你快速判断“是知识库没建好还是大模型没理解”。等在线客服真正跑起来、量上来了再考虑是否把检索层迁到自建流水线。别一上来就搞LangChain10个接AI客服的项目里有7个死在知识库处理上而不是死在AI模型上。3. 用PHP把客服会话接进知识库最小可跑通方案与核心代码3.1 封装一个PHP客户端连接对话API先跑通阻塞模式架构确定之后PHP侧的工作就不复杂了。无论你用的是Dify还是FastGPT它们的对话接口都长得很像传一个问题query、传用户标识user、传会话IDconversation_id返回一个回答。我们先按Dify的对话应用API来写一个最小客户端这套写法换成任何平台都只需要改接口地址和参数名。?php // 知识库对话API的最小PHP客户端阻塞模式 $endpoint https://your-dify-domain/v1/chat-messages; $apiKey app-xxxxxxxxxxxxx; // 应用API密钥在Dify应用设置里生成 $data [ query $question, // 当前用户提问原文 response_mode blocking, // 阻塞模式一次请求返回完整回答 user customer_ . $customerId, // 区分不同客服会话 inputs [ customer_name $customerName, // 可选的对话变量用于prompt拼接 ], conversation_id $conversationId, // 空字符串表示开启新会话 ]; $ch curl_init($endpoint); curl_setopt_array($ch, [ CURLOPT_POST true, CURLOPT_POSTFIELDS json_encode($data, JSON_UNESCAPED_UNICODE), CURLOPT_HTTPHEADER [ Authorization: Bearer . $apiKey, Content-Type: application/json, ], CURLOPT_RETURNTRANSFER true, CURLOPT_TIMEOUT 30, // 阻塞模式下建议30秒以上 ]); $resp curl_exec($ch); $status curl_getinfo($ch, CURLINFO_HTTP_CODE); $err curl_error($ch); curl_close($ch); if ($status 200) { $body json_decode($resp, true); $answer $body[answer] ?? ; // 平台返回的回答文本 $conversationId $body[conversation_id] ?? ; // 保存这个ID用于继续对话 // 这里把 $answer 写进客服后台人工确认后发给客户 } else { // 统一走兜底话术别让客户看到AI报错 $answer 抱歉我暂时无法回答正在转接人工客服。; error_log(Dify API error: . $status . - . $resp . - . $err); }逻辑说明这段代码做了一件事——把客服后台收到的客户问题透传给知识库对话API并拿到AI回答。关键在query字段必须传“客户的原话”不要你自己先改写user字段建议用客服系统的客户ID而不是客服工号因为AI要根据客户身份调整语气conversation_id是上下文延续的关键每次都传同一个IDAI才能记住前面聊过什么。参数说明CURLOPT_TIMEOUT设30秒是因为阻塞模式下大模型生成可能需要几秒到十几秒设太短会频繁超时。response_mode先不要改用阻塞模式跑通。JSON_UNESCAPED_UNICODE是为了防止中文被转成\uXXXX虽然接口能解但出了问题你排错时根本看不清原始报文。3.2 流式输出与普通JSON输出怎么选参数怎么定在线客服场景里客户最反感的是“等待”。阻塞模式如果3秒没反应就有客户开始刷屏。所以正式上线时我建议切到流式模式streaming也就是SSE方式AI一个字一个字往外蹦客户侧看到的是正在输入体感完全不同。?php // 流式(SSE)接收知识库回答适合客服后台逐字展示 $data[response_mode] streaming; // 关键开关从blocking改成streaming $ch curl_init($endpoint); curl_setopt_array($ch, [ CURLOPT_POST true, CURLOPT_POSTFIELDS json_encode($data, JSON_UNESCAPED_UNICODE), CURLOPT_HTTPHEADER [ Authorization: Bearer . $apiKey, Content-Type: application/json, ], CURLOPT_RETURNTRANSFER true, CURLOPT_TIMEOUT 60, CURLOPT_WRITEFUNCTION function ($ch, $chunk) use ($answer) { // $chunk 是SSE数据块形如: data: {event:message,answer:你} $answer . $chunk; // 在实际客服系统里这里用WebSocket把增量推给前端 return strlen($chunk); }, ]); curl_exec($ch); curl_close($ch);参数说明CURLOPT_WRITEFUNCTION是PHP curl的流式回调每当服务端推来一段数据就会触发一次。你在回调里把增量内容追加到缓冲区同时可以立刻通过WebSocket或轮询推给浏览器。这里有个重要的坑SSE的每个data:行都是JSON片段不要尝试把它们拼接起来再json_decode整个字符串因为这不是一个完整的JSON数组。正确做法是逐行解析遇到event:message就把answer字段拼出来。哪些场景用阻塞、哪些用流式我一般这么定客服后台的“自动回复候选”功能用阻塞——人工点一下按钮等2秒拿到完整回答再决定发不发简洁可靠客户面前的自助机器人必须用流式——客户等不起哪怕是假打字也要让它动起来。3.3 在客服后台里跑通“AI辅助回复”让AI当助手而不是当客服接AI知识库最容易翻车的姿势是全自动回复。客户问一句AI直接答一句没有人工审核结果AI某天在敏感问题上来了一句“可以的哦”整个客服团队就得帮你收拾烂摊子。所以我的建议是分两步走第一步先做“AI辅助回复”第二步再做“AI自动回复”。?php // 客服后台的AI辅助回复人工点击触发AI给出建议草稿 // 伪代码按你的MVC结构调整 class AiAssistant { public function suggestReply(int $customerId, string $question): string { $history $this-loadRecentMessages($customerId); // 最近10条会话 $conversationId $this-getConversationId($customerId); // 将历史消息拼进prompt让AI理解上下文 $data [ query $question, response_mode blocking, user customer_ . $customerId, conversation_id $conversationId, ]; $answer $this-callKnowledgeApi($data); // 追加来源提示让回答里带上引用的文档来源 $dataWithSource $data; $answerWithSource $answer; return $answerWithSource; } }逻辑说明这段伪代码强调的是“由人触发”和“带上下文”。loadRecentMessages从客服系统自己的数据库里取出最近对话你可以选择把它们拼进inputs也可以依靠conversation_id让AI平台自己记上下文。我建议两者都做conversation_id保证AI记得对话inputs里的变量用来注入客户姓名、会员等级等平台未必知道的业务信息。参数说明这里的inputs是Dify对话应用里的“预定义变量”需要在Dify应用编排里先声明。你不在应用里声明就传这个字段接口会报参数错误。这也是很多PHP开发者第一次接入时的翻车点——以为inputs可以随意传实际上每个字段必须在平台编排里先定义好否则直接400。4. 知识库建不好AI回答全是幻觉文档清洗、分段与检索参数设置4.1 客服文档要清洗成什么样才能进知识库分段分错全白搭前面第2章说的RAG三步里索引是基础。基础没打好后面调多少prompt都是白费力。客服文档有一类典型问题原始文件是Word排版、有页眉页脚、有大表格、有“请见下图”这类正文里根本带不出信息的句子。如果你直接用现成的文档解析工具把PDF/Word导进去切出来的片段会是“××公司售后政策 第1页共12页”“如上图所示……”这些片段进向量库就是垃圾进垃圾出。我的清洗流程比较固定分享给你参考先统一转成Markdown我用pandoc一条命令的事然后手动删掉页眉页脚、目录、签章页接着把表格精简成关键字段对比如“退款时限3个工作日”最后把长文档拆成主题块每块一个核心问题。这步别嫌烦客服知识库的文档数量通常不超过500篇清洗一次半天到一天换来的是召回准确率的巨大提升。清洗完成后第二步是分段。这里要给一个明确的参数起点Dify默认的分段设置一般是按分隔符切最大块长度建议先从500字符中文场景按字符算不是token开始重叠长度overlap设80。为什么要有overlap因为一个知识点很可能跨段——上段末尾讲“退款的三个条件”下段开头才列举具体条件没有重叠检索时只召回上段AI就只会说一半。4.2 三个必调参数chunk_size、overlap、top_k与score阈值参数调整是AI知识库接入里最“黑匣子”的部分但也不是完全没规律。我总结了四个参数你按这个顺序调参数建议起点调整方向表现特征chunk_size分段大小500字符内容被切得支离破碎就调大到800回答总是缺细节overlap重叠长度80字符出现两个片段重复讲同一件事就调小到40回答冗长重复top_k召回片段数3答不出关键信息就调到56回答要自己脑补了score阈值相似度门槛0.3左右召回一堆无关内容就调到0.5回答张冠李戴逻辑说明这四个参数共同决定AI能看到哪些“参考资料”。top_k决定AI最多能看几段调大了AI能看到更多上下文但也更容易被无关片段干扰score阈值决定“相似度多低的内容就直接丢弃”。客服场景里我宁愿少召回一点、回答得保守一点也不要召回一堆低分内容让AI自由发挥。在Dify里怎么测每个文档上传后平台会做索引你在“召回测试”里输入问题它会把召回片段和相似度分数列出来。这里有一个很容易被忽略的点不要只测“答得对不对”要看“召回的第1名是不是对的”。如果第1名都不对AI回答就全靠大模型瞎蒙说明你的文档清洗和切分有问题而不是大模型不行。先调分段再调检索最后才去碰prompt。4.3 用Dify知识库流水线做召回测试别凭感觉上线Dify这类平台最大的价值是把知识库流水线的每一步都暴露给你看。我见过太多团队上线AI客服的方式是“上传几篇文档配个系统提示词就敢往生产上放”这是对自己不负责。正确做法是每个知识库建好后先跑一遍专门的召回测试集。我的做法是从历史客服工单里抽出50个高频问题每个问题标注“标准答案出处在哪篇文档”。然后把它们喂进Dify的召回测试接口一个个看召回结果。你不要手动在测试框里输入问题那样太慢而且容易挑着舒服的问。直接调用知识库检索API批量测把结果导出来看命中率。# 用Python批量测试召回效果也可以改成PHP这里是流程示意 import requests results [] for question in test_questions: resp requests.post( https://your-dify-domain/v1/datasets/{dataset_id}/retrieve, headers{Authorization: Bearer app-xxx}, json{ query: question, retrieval_model: {search_method: hybrid_search, top_k: 5} } ) records resp.json().get(records, []) top_score records[0][score] if records else 0 results.append({question: question, top_score: top_score, hit: records[0][segment][content][:50] if records else }) # 统计top_score 0.3 的问题占多少这些就是知识库缺口逻辑说明这段批量测试脚本执行的是“检索”这个动作不调用生成。因为你要先确认“检索到的内容是相关的”再谈AI能不能组织成好回答。search_method我用hybrid_search也就是混合检索向量检索 全文关键词检索客服术语经常有缩写和特定名称纯向量检索容易丢精确匹配混合检索更稳。参数说明top_k在检索测试里设5是为了看“AI最多能拿到哪5段”重点观察前两段是否相关。如果前两段不相关你再怎么调prompt都没用。这一步做完你对知识库“到底行不行”就有了量化结论而不是靠感觉。5. 接入AI知识库常见问题排查5个让项目翻车的坑5.1 现象问什么都答非所问回答里出现原文档没有的内容AI一本正经地告诉客户“支持7天无理由退货”但你们公司的政策明明是“仅质量问题可退”。客服后台一查AI回答的内容原文档里根本没有。原因两层。第一层是检索没召回正确片段AI只能凭训练数据里的通用知识回答第二层是系统提示词里没有强约束“只根据参考资料回答禁止推测”。解决先跑第4章的批量召回测试确认检索是否命中然后在系统提示词里加入硬约束比如“你只能使用参考资料中的信息如果参考资料中没有请明确回答‘该问题需要人工确认’”。注意这一步在Dify中改提示词后要同时重新测试召回和生成不要只改提示词不验证。5.2 现象PHP请求超时客服界面卡死客户点发送页面转圈最后客服后台报“504 Gateway Timeout”或PHP报curl: (28) Operation timed out。原因阻塞模式下大模型生成慢加上网络链路有延迟30秒完全不够用是常态。另外PHP-FPM的默认max_execution_time只有30秒一个是故障一个是配置两个撞一起必然翻车。解决第一把PHP端CURLOPT_TIMEOUT提到60秒把PHP-FPM的max_execution_time同步调大第二正式环境换流式模式让用户在等待时看到“正在输入”知觉上不卡第三不要在主进程里同步等待把请求丢进Redis队列后立即返回“排队中”由Worker异步调用AI接口再回调客服系统。5.3 现象知识库更新后线上回答还是旧内容运营更新了《退款政策》把退货时限从7天改成5天第二天客户问退款AI还在回答“7天内可退货”。原因多数知识库平台在你编辑文档并保存后只会重新索引被编辑的那一两段而不是全量重建。如果分段变化导致原文位置移动或者向量索引没有刷新旧段还在线上生效。这是平台索引机制的黑匣子你永远不知道它什么时候生效。解决我在Dify里养成了“改完必重建”的习惯。文档内容有较大改动时删掉旧文件重新上传或者触发全量重建索引。上线后每天做个简单巡检——问几个刚更新的政策问题确认回答内容已经是新版本。这条没办法完全自动化只能靠流程兜底。5.4 现象客户问私人问题或敏感问题AI直接回答了“你能帮我骂人吗”“你们公司法人是谁”“给我你们的内部运维密码”……AI要么一本正经胡说要么泄露了不该说的。原因大量客服AI的失败不是死在知识库而是死在安全边界。大模型默认是“有问必答”的你只告诉它来源它还是会顺着客户话头聊。解决三层防线。第一层在PHP入口做关键词前置拦截命中“骂人、投诉、电话、法人”等词直接转人工第二层在Dify的提示词里写敏感问题兜底话术第三层在知识库里不要把敏感文档传进去客服知识库只放能对外说的内容。这个坑我希望你别踩踩过的都知道后果严重。5.5 现象多客服同时使用接口报429限流或延迟飙升刚开始只有3个客服用一切正常上线一周后公司要求全部客服使用AI辅助回复突然接口报错频繁返回429 Too Many Requests。原因AI知识库API并发能力有限每个应用都有速率限制。客服场景最大的特点是“集中突发”早上一开门10个客服同时处理30个会话请求全部堆一起。解决第一在PHP侧做信号量控制用Redis实现一个简单的并发令牌桶每客服同时最多2个AI请求超出就排队等待而不是直接发出去第二打开Dify的“上下文保存”后尽量复用conversation_id减少重复检索次数第三把AI回答结果做本地缓存同一个客户在10分钟内的重复问题直接命中缓存不重复调AI。缓存键用customer_id question的哈希有效期10分钟就够问同一句话的客户真的很多。6. 让AI客服真正能用的三个进阶动作会话记忆、人工接管与效果评估6.1 会话记忆别让AI“失忆”把customer_id和session_id串起来阻塞模式下AI很容易“失忆”——客户问完A问题再问“那退款呢”AI不知道“那”指的是什么。所以客服系统里务必为每个会话持续保存conversation_id并且在AI平台的上下文中保留最近58轮对话。客户重新进来时判断这是新会话创建新的conversation_id避免跨会话串味。6.2 人工接管AI把话说到一半怎么转人工不突兀我的习惯是AI每一次回答卡片底部都带一个“转人工”按钮同时设置两个自动兜底条件第一是客户连续输入“人工、转人工、投诉”等词时强制转人工第二是AI回答内容包含“需要人工确认”时自动拉起人工客服。转人工时要带上完整会话记录别让客户把问题重述一遍这是客服体验的底线。6.3 效果评估用历史工单做回归测试别只看“答对了没”上线两周后你会面临一个避不开的问题AI回答到底好不好我的做法是把最近一个月的真实工单导出抽出100条带标准答案的问题每周做一次批量测试。看三个指标召回命中率检索到相关文档的比例、回答完整率AI回答是否覆盖标准答案要点、转人工率客户最后是否放弃AI去人工。指标不好先别骂大模型回去查知识库分段、查搜索方式、查提示词按第4章的流程重新调一轮。这套链路我做过三次第一次翻车在没做召回测试直接上生产第二次死在超时配置第三次才跑通。现在的习惯是先建知识库再跑批量检索测试确认召回没问题才写PHP代码。希望帮到你。本文还有配套的精品资源点击获取