尧图网站建设 
1. 从Demo到生产为什么客服场景是Agent的试金石先抛一个很多人问过我的问题AI Agent在2025年还有哪些场景是真正能算清ROI、敢上生产的我的答案里客服一定排前三。原因不复杂。客服场景有几个天然优势第一对话边界相对收敛不像通用助手那样天马行空第二业务价值直接可见人力成本、响应时长、转人工率都是硬指标第三数据闭环容易建立每通对话都是天然的标注样本。说白了客服是少数“投入产出能算明白账”的Agent落地场景。但我得先泼一盆冷水你看到的那些客服Agent Demo和真正能上生产的客服Agent完全是两个物种。Demo只需要用大模型套一层Prompt能聊就行生产环境则要考虑并发链路、状态管理、工单系统对接、敏感词拦截、抽检审计、降级兜底……这一堆东西加起来才是完整的架构设计。这篇文章我打算从实际落地角度把客服Agent从架构设计到多轮对话优化的完整链路拆一遍。内容会包括我自己的选型思路、踩过的坑、以及一些可以直接抄作业的配置方案。适合正在做客服智能化、或者准备在企业内部推Agent落地的人参考也适合那些刚从Prompt工程转向Agent工程、想找个真实场景练手的人。先说清楚这里讨论的范围基于大型语言模型LLM的在线文本客服Agent。不涉及语音机器人那套VAD、ASR、TTS的链路是另一套复杂度但对话管理、意图识别、知识库召回这些核心模块是通用的语音场景同样能复用。2. 大模型不是Agent客服Agent的边界在哪里很多团队第一次做客服Agent犯的最大错误是把大模型当成Agent写一段Prompt就直接上。结果呢上线第一天就被用户绕晕答非所问第二天被安全团队约谈因为模型输出了不该输出的内容第三天业务方要求加十几个对话流程你发现光改Prompt已经改不动了。问题出在哪在于没有理解“大模型”和“Agent”的分工。大模型的本质是一个概率语言模型它的强项是“生成”。你给它上下文它给你接话。但客服场景需要的不是“接话”而是“解决问题”。解决问题需要的是流程控制、状态管理、工具调用、知识检索、风险判断——这些都是LLM不擅长、甚至根本做不到的。所以我的经验里客服Agent的架构设计有一个核心原则让大模型做决策让代码做执行让规则做兜底。三者缺一不可。以大模型做决策指的是意图识别、槽位抽取、情感判断、回复生成这些“需要理解力”的环节交给LLM来做让代码做执行指的是查订单、建工单、退换货流程、知识库检索这些“确定性操作”必须由程序代码来控制不能让大模型自由发挥让规则做兜底指的是敏感词过滤、黑名单、风险拦截、限流降级这些“不能出错”的环节必须用硬规则来保证100%执行。这个三角色分离的架构能回答一个关键问题AI客服到底能做什么、不能做什么。能做的是理解用户意图、检索知识、生成拟人化回复、引导用户提供必要信息不能做的是直接操作系统完成高风险操作或者说能设计但需要多层审批和审计不能跨出知识边界胡说八道不能在极端情绪下继续激化矛盾。所以我们内部定了一条架构红线Agent只负责“对话”和“决策”不直接负责“执行”——所有涉及订单、支付、退款的系统操作必须走API网关由后端触发并且每一步都要留审计日志。3. 整体架构设计四个核心模块和一条控制链聊完了边界来看具体的架构设计。我们的客服Agent架构经历了三轮迭代从最早的单体Prompt到后来的多Agent协作最终定型为现在的**“中心控制器专家Agent工具层”**三层结构。这套架构的核心思路是把对话理解和业务处理解耦让专业模块做专业事。3.1 整体分层结构最上层是接入层负责对接不同渠道的消息——网页聊天窗、微信公众号、小程序、企业微信、API开放接口。各渠道的消息格式、会话保持、异步回调差异很大接入层的职责是把这些差异抹平统一转换成内部的标准消息结构。中间是核心控制层这是整个Agent的中枢也是多轮对话优化的主战场。它包含会话管理器、意图识别器、状态跟踪器、回复生成器四个关键组件。消息进来后先进入会话管理器读取或创建会话上下文然后交给意图识别器判定用户这次想干什么接着状态跟踪器结合历史状态和当前槽位判断还缺什么信息、该走什么流程最后回复生成器根据当前状态和检索到的知识生成回复内容。最下层是能力支撑层包括知识库FAQ文档、订单系统API、CRM用户信息、工单系统、敏感词库、抽检日志库等。这一层是Agent的“手脚”让Agent不止能说话还能办事。3.2 流程编排为什么不用纯ReAct这里必须聊一个很多人在架构选型时纠结的问题流程编排到底用ReAct自由推理还是用预定义的流程模板ReActReasoningActing模式确实是当前Agent的主流模式优点是灵活、能应对开放性任务。但如果你真的在客服生产环境用过ReAct一定会遇到三个头疼的问题一是不可控模型自己决定下一步做什么很容易跑偏比如用户本来在问退换货模型聊着聊着开始推荐商品二是状态丢失ReAct的每一步都依赖模型对上下文的记忆一旦上下文超出窗口或者被截断整个流程就乱了三是审计困难自由推理的过程没法预定义审核节点安全团队很不放心。所以我们最终选择了混合模式流程骨架用预定义模板流程中的动态决策用LLM。举个例子退换货流程是固定的——确认订单号、确认商品、确认原因、安排退货——这个骨架用代码写死但每一步的“理解用户回答”和“生成引导话术”是动态的交给LLM。这样既保证了流程不走偏又让对话体验足够自然。这套架构里还有一个容易被忽视但极其关键的组件状态跟踪器。它维护一个结构化的对话状态槽位列表比如订单号、商品编号、退货原因、用户情绪等级。每轮对话更新一次状态LLM只负责从用户的话里抽取槽位值状态是否完整、下一步该问什么由代码逻辑判断。这等于把“记忆”从模型上下文里抽离出来放到更可靠的结构化存储中。4. 工具选型解析模型、框架和向量库的取舍说完了架构来聊工具选型。这块我直接给结论再说理由。4.1 模型选型大模型做精度、小模型做拦截模型选型上现在市面上可选的大模型很多海外有GPT-4o、Claude国内有各类开源和商用模型。我的建议是不要迷信某一个模型而是反过来从场景需求倒推核心对话模型负责意图识别、回复生成需要强语义理解能力推荐选择指令遵循能力强、中文效果好的模型。有条件的话可以同时接两个模型做冗余一个主用一个备用一个挂了另一个顶上避免客服通道全断。意图拦截模型不要用大模型做敏感词和风险拦截太贵也太慢。用轻量级规则引擎或者小型分类模型跑第一道拦截大模型只处理正常对话这是成本优化的关键一步。Embedding模型提供给向量检索使用需要把用户问题和知识库文本映射到同一个向量空间推荐使用专门的Embedding模型而不是直接拿对话模型来生成向量。我踩过的一个坑是早期为了省事直接用对话模型来生成Embedding结果知识召回准确率惨不忍睹。后来换成了专门的Embedding模型并做好文本预处理召回效果立竿见影。4.2 Agent框架LangGraph还是自研状态机Agent开发框架现在也很多LangChain、LangGraph、AutoGen、字节的Coze等。我们的实践是调研用了LangGraph生产用了自研状态机。原因不是LangGraph不好而是客服场景的状态流转太有行业特性了——我们需要状态持久化到Redis、需要跟工单系统深度绑定、需要精细控制每个节点的超时和重试策略通用框架在这些方面反而成了约束。自研状态机看似重复造轮子但实际上状态机代码也就几百行换来的是完全可控的流程编排。但如果你是从零起步、团队又不大用LangGraph起步是完全可以的它能帮你快速搭建骨架边跑边改。只是上线前一定要想清楚框架的升级怎么办框架作者不维护了怎么办这些问题在做技术选型时就该有答案。4.3 向量库先想清楚检索什么再选工具知识库召回我们用到了向量检索选型时对比了Milvus、Qdrant、Elasticsearch等。最终选了Qdrant理由是部署轻量、API简洁、支持过滤条件。但我说个更重要的经验向量库选型不是核心检索策略才是核心。客服场景的知识库检索有几种类型需要区分FAQ式问答高频比如“怎么退款”这类问题用向量召回FAQ条目就够了文档式问答低频但复杂比如“你们的售后政策是什么”这类需要先做文档切片、摘要化处理再按层次检索动态数据查询比如“我的订单到哪了”这类向量检索解决不了必须走参数抽取API查询返回结果再生成自然语言回复。如果你不分青红皂白就把所有知识都灌进向量库那召回结果一定是一锅粥。先对知识分类再设计检索路径这是知识库建设的核心方法论。5. 多轮对话优化从“能聊”到“聊明白”的三级跳标题里提到了“多轮对话优化”这是客服Agent体验的生死线。用户能容忍AI答错一次但不能容忍每次都在同一个地方兜圈子。我把多轮对话的优化路径拆成三个阶段每个阶段解决不同问题。5.1 第一级上下文管理别让模型失忆多轮对话最基础的问题就是“失忆”。用户第5句话提到“刚才那个订单”如果Agent还记得第2句里的订单号这个对话才成立但模型上下文窗口有限、不同系统之间信息还不同步很容易丢。我们的解决方案是分层记忆机制会话级记忆存在Redis里key是会话IDvalue是结构化的对话状态包含槽位、上轮回复、未解决问题等每次消息进来先读Redis处理完再写回保证无状态服务也能恢复会话摘要级记忆当对话超过一定轮数用LLM把前面的对话压缩成摘要避免Token超限。摘要要保留关键槽位和未解决事项这个Prompt需要专门调优全局级记忆读用户画像比如VIP等级、历史订单偏好这部分来自CRM数据不属于模型上下文放在流程里让LLM按需读取。这里有个关键点上下文并不是越长越好。上下文太长一方面推理成本暴涨延迟变高另一方面模型会“迷失在中间”反而不关注最新消息。我们的经验是对话上下文默认保留最近10轮超过的部分做摘要。10轮足够覆盖绝大多数客服场景的连续对话又不至于拖慢推理。5.2 第二级槽位填充与主动澄清多轮对话的第二个核心问题是槽位缺失。用户说“我要退货”系统需要知道订单号、商品ID、退货原因。如果槽位不全就不能调退货API。这里最容易犯的错误是拼命追问让用户一次性把信息说完。产品经理喜欢这种设计因为“效率高”但用户会觉得像在填表体验很差。我们优化后的策略是一轮只问一个关键槽位优先问最缺的、最影响流程推进的那一个问题中带上已知道的信息和引导性选项比如“查到你有一笔9月12日的订单是这件商品要退货吗”这比“请输入订单号”的体验好得多允许用户连续补充多个槽位比如用户说“订单号是12345裙子尺码大了要退”一个句子就填充了两个槽位状态跟踪器要做多槽位一次抽取设置槽位确认节点对高风险操作退款、改地址必须让用户明确确认才能执行防止模型误抽导致错操作。5.3 第三级策略性兜底承认不会比硬答更好再怎么优化总有模型答不上的情况。过去很多团队的默认策略是模型不能确定就随便生成一句“我理解你的意思”然后继续编下去。这是大忌。我们的兜底策略分了三个层级低置信度转人工当意图识别置信度低于阈值、或者用户连续两次表达不满时自动进入转人工流程并把当前对话摘要发给人工客服让人工不用重复问知识无答案时澄清知识库召回没有相关内容时不是直接说“不知道”而是用澄清话术“你问的问题我暂时没有查到准确答案你要不问一下是否指……”给用户一个台阶也有助于判断是知识库没覆盖还是用户表述不清楚情绪升级拦截检测到用户情绪低落或愤怒比如出现投诉词、激烈词不再回复业务内容而是切换为安抚模式和紧急转人工这条规则是硬编码的任何情况下不能绕过去。兜底策略的终极目标是别让用户觉得在跟一个自以为是的AI对话。承认不会、及时转人工往往比硬撑着答错更让用户满意。6. 实操过程从零搭建一个客服Agent的最小可用版本前面聊了架构和策略这里给一套可以直接上手的实操路径。我会按步骤来每一步都附带选型建议和注意事项。这套方案是我备注的“最小可用版本”不是说生产就够而是让你在2-3周内先跑通一条主链路。6.1 环境准备与依赖清单假设你的技术栈是Python这套方案的基础依赖如下# 核心依赖 pip install fastapi uvicorn # API服务框架 pip install openai # LLM调用大多数兼容OpenAI协议 pip install langchain langgraph # Agent框架用于快速验证落地可替换 pip install qdrant-client # 向量库客户端 pip install redis # 上下文状态存储如果你是纯新手我的建议是FastAPI不熟的先看一遍官方教程很容易上手LangGraph不熟的不用强求可以用最原始的if-else先跑通再换。6.2 构建会话管理服务先搭最核心的会话管理这是多轮对话的基石# session_manager.py import redis import json import uuid class SessionManager: def __init__(self, redis_urlredis://localhost:6379/0): self.redis redis.from_url(redis_url) self.expire_time 1800 # 会话有效期30分钟 def create_session(self, user_id): session_id str(uuid.uuid4()) session_data { user_id: user_id, status: open, slot: {}, # 槽位数据 history: [], # 对话历史 summary: , # 摘要历史 intent: None, # 当前意图 turn_count: 0 # 轮数统计 } self.redis.set(fsession:{session_id}, json.dumps(session_data), exself.expire_time) return session_id def get_session(self, session_id): data self.redis.get(fsession:{session_id}) if not data: return None return json.loads(data) def save_session(self, session_id, session_data): self.redis.set(fsession:{session_id}, json.dumps(session_data), exself.expire_time)这个小代码解决一个问题让Agent变成无状态服务每轮请求都能从Redis恢复会话状态。后面加机器、做负载均衡都不会有状态丢失问题。6.3 意图识别与状态跟踪意图识别和状态跟踪是核心控制逻辑。这里给出一个基于LangGraph的示例框架先把主流程写清楚# agent_controller.py from langgraph.graph import StateGraph, END from typing import TypedDict, Optional class AgentState(TypedDict): session_id: str user_input: str intent: Optional[str] slot: dict response: str need_human: bool # 定义节点函数 def intent_recognition(state: AgentState): # 这里可以调用大模型也可用规则先过滤常见意图 # 返回意图和抽取的槽位实践中是结构化JSON intent, slot llm_parse_intent(state[user_input]) return {intent: intent, slot: slot} def slot_check(state: AgentState): required_slots get_required_slots(state[intent]) missing [s for s in required_slots if s not in state[slot]] if missing: state[response] ask_for_slot(missing[0]) else: state[response] return {response: state[response]} def api_call(state: AgentState): # 调用实际业务API得到执行结果 result call_business_api(state[intent], state[slot]) return {response: format_result(result)} def human_handoff(state: AgentState): return {need_human: True, response: 正在为你转接人工客服请稍候……} # 构建图 graph StateGraph(AgentState) graph.add_node(intent, intent_recognition) graph.add_node(slot_fill, slot_check) graph.add_node(api, api_call) graph.add_node(handoff, human_handoff) graph.set_entry_point(intent) graph.add_conditional_edges(intent, lambda s: slot_fill if s[intent] else handoff) graph.add_conditional_edges(slot_fill, lambda s: api if not s[response] else end) graph.add_conditional_edges(api, lambda s: END) graph.add_edge(handoff, END) app graph.compile()这段代码演示了最核心的流程控制结构——意图识别 → 槽位校验 → 业务API → 回复。实际生产中这个图会有更多节点比如知识库召回、情绪检测、多轮追问、摘要生成等但骨架逻辑就这一条线。6.4 知识库管理与召回策略知识库召回是整个客服Agent最容易被低估的部分。我们直接给一套落地配置离线阶段把FAQ和文档统一导入按类别切片。FAQ一条一个条目文档按段落切片每段不超过200字保留段落标题作为元数据向量化阶段用Embedding模型批量生成向量存进Qdrant。记住要同时存原文和元数据不能只存向量在线召回用户问题向量化后在Qdrant里做相似度检索返回Top5候选。如果最高相似度低于阈值我们默认0.7需要调优就进入兜底流程重排阶段向量召回的结果再用一个轻量级rerank模型或LLM打分排除掉语义相似但实际无关的条目。这一步能显著提升知识命中准确率强烈推荐别省。6.5 回复生成与安全护栏最后一步是回复生成。这个环节的核心不是“生成得漂亮”而是“生成得安全”。我们加了三层安全护栏第一层输入侧过滤。用户输入先过敏感词库和正则规则命中则直接降级不再走LLM。第二层输出侧校验。LLM生成的回复再过一遍关键词和规则防止模型输出违规内容。第三层行为控制。流程代码里写死哪些操作绝对不能做比如不能承诺无法兑现的赔偿、不能辱骂用户、不能泄露隐私信息。这三层护栏看起来“很土”但恰恰是它们保证了Agent在真实环境里不会出大事故。AI的错误往往是搞笑的客服场景的错误可能是要赔钱的。7. 常见问题与排查技巧实录整理几个我在落地过程中实际碰到的问题每个都是真金白银换来的经验。7.1 多轮对话轮数多了就乱怎么办现象对话超过10轮后Agent开始答非所问甚至把之前说过的话重复一遍。排查思路先查上下文管理看Redis里的会话状态是否完整再查摘要逻辑。大概率是摘要把关键槽位丢了。我们优化后的摘要Prompt明确要求每条摘要必须保留所有已填槽位、当前未解决问题的意图、以及待确认事项。格式化为结构化文本而不是自然语言总结。还有个细节很多团队直接把所有对话记录塞进Prompt导致模型“迷失在中间”反而忽略最近几轮内容。用最新消息摘要槽位状态的组合模型效果远好于把所有历史原封不动塞进去。7.2 用户死活不说订单号怎么引导现象槽位缺失Agent反复问“请提供订单号”用户不配合说“你自己不会查吗”对话卡死。排查思路引导话术太生硬。优化后的做法是如果用户提供了手机号或用户名可以先查用户所有在途订单然后主动问“你是要处理哪个订单是9月12日这件连衣裙还是9月20日这双运动鞋”把开放性问题变成选择题用户回答成本大幅降低槽位填充率明显上升。7.3 模型偶尔输出不负责任的承诺现象用户问“你们能保证明天送到吗”模型回复“可以的”但实际配送时效根本不受控业务方炸了。排查思路这是大模型“讨好用户”的通病。解决办法是高危承诺词表规则拦截包含“保证”“一定”“绝对”“赔偿”“免费”等词的场景强制降级为不承诺话术。同时对意图分类加一个“时效咨询”类型走FAQ精确回答而不是让LLM自由发挥。7.4 转人工后信息断档人工客服重复问现象AI聊了8轮转人工后人工客服完全不知道之前聊了什么让用户重新说一遍用户火大。排查思路必须在转人工时把会话摘要、已填槽位、未解决问题一次性传给人工工作台。这个靠Agent控制层完成不是人工客服系统自己猜。我们实现了一个标准的“交接包”格式内容包括用户ID、意图、已收集的槽位、AI已经说过的承诺、未解决的问题、推荐下一步动作。人工客服拿到这个包基本不需要让用户重复任何信息。7.5 知识库命中率低用户问的答案明明有现象知识库里明明有答案用户换个说法就检索不到。排查思路核心在Embedding模型的相似度阈值和重排策略。我们的经验是第一扩展同义词和别名比如“退款”“退钱”“还钱”其实是同一件事在知识点里维护别名列表第二问题改写用LLM把用户问题先改写成多个候选问法再分别向量检索能显著提高命中率第三阈值不要一刀切不同类别设置不同阈值比如退换货类问题可以放宽阈值财务类问题要严格阈值。8. 效果评估与持续优化上线只是开始Agent上线不是结束是新一轮迭代的开始。客服Agent的效果评估我建议分三层做。对话层指标意图识别准确率、槽位填充率、多轮任务完成率。这些是过程指标关注Agent“有没有听懂”。我建议每周抽300-500条对话做人工标注和系统的自动识别结果对比计算准确率和召回率。这个环节看起来费人力但它是发现系统瓶颈的最直接手段。业务层指标转人工率、首响时长、问题解决率、用户满意度。这些是结果指标关注Agent“有没有解决问题”。特别关注“转人工率”的曲线变化如果上线后转人工率不降反升说明Agent要么答非所问让用户烦了要么兜底策略太激进动不动就转人工。成本层指标单次会话平均Token消耗、单次会话平均成本、API调用失败率。LLM的API费用在客服场景里是会让人肉疼的尤其是高峰期。我们的优化手段有几个缓存高频问答完全相同的问题不重复调用大模型精简Prompt模板减少无用Token小模型做初筛非复杂问题用小模型回答大模型只处理复杂对话。8.1 持续优化的两条主线主线一是知识库运营每周分析转人工的前10个主题把高频问题补充进知识库和意图库。客服场景里知识覆盖提升一个点转人工率就能降一点这是最划算的优化路径。主线二是对话策略调优用线上对话数据做Bad Case分析找到模型“明明理解了但回复不好”的场景针对性调优Prompt模板或流程节点。比如我们发现用户在问“退货流程”时如果附带“裙子”这个实体Agent直接推荐退货方式比让用户确认商品更顺畅于是调整了槽位校验顺序。9. 最后分享一个实用经验先在内部用起来在文章的最后我分享一个实际体会客服Agent的落地最忌讳一上来就面对真实用户流量。我的建议是先在内部试点——让公司自己的员工、兼职客服、业务运营人员用真实的业务问题去测Agent。内部试点的好处是第一问题真实且覆盖业务全貌比测试用例有效得多第二反馈链路极短发现问题当天就能修第三没有外部舆论压力模型说错话也只是内部消化。我们在内部试点阶段跑了两周收集了几千条真实对话修掉了十几个流程Bug、几十个知识盲区。等到正式灰度上线时第一天转人工率就直接低于预期值这在没有内部试点的项目里几乎是不可能的。另有一个小技巧灰度上线不要按流量比例随机放量而是按“用户类型”放量——先让低价值、低纠纷风险的用户走AI客服等高价值用户的对话也积累了足够准确率再全量放开。这里的关键指标是各用户群组的转人工率和满意度如果新放开的用户群组数据下滑明显赶紧回滚到人工模式。客服Agent这条路没有终点。语义理解在变强模型能力在升级业务形态也在变化但底层的那套架构思路——边界清晰、流程可控、兜底可靠、数据闭环——是稳定的。希望这篇文章能给正在这条路上探索的你一些参考。如果你准备动手做一个客服Agent的Demo别急着堆Prompt先画一张架构图哪些环节用大模型、哪些环节用代码、哪些环节用规则想清楚了再写代码。动手了遇到问题随时再交流。 客服Agent架构设计与多轮对话优化：从Demo到生产的完整落地指南
1. 从Demo到生产为什么客服场景是Agent的试金石先抛一个很多人问过我的问题AI Agent在2025年还有哪些场景是真正能算清ROI、敢上生产的我的答案里客服一定排前三。原因不复杂。客服场景有几个天然优势第一对话边界相对收敛不像通用助手那样天马行空第二业务价值直接可见人力成本、响应时长、转人工率都是硬指标第三数据闭环容易建立每通对话都是天然的标注样本。说白了客服是少数“投入产出能算明白账”的Agent落地场景。但我得先泼一盆冷水你看到的那些客服Agent Demo和真正能上生产的客服Agent完全是两个物种。Demo只需要用大模型套一层Prompt能聊就行生产环境则要考虑并发链路、状态管理、工单系统对接、敏感词拦截、抽检审计、降级兜底……这一堆东西加起来才是完整的架构设计。这篇文章我打算从实际落地角度把客服Agent从架构设计到多轮对话优化的完整链路拆一遍。内容会包括我自己的选型思路、踩过的坑、以及一些可以直接抄作业的配置方案。适合正在做客服智能化、或者准备在企业内部推Agent落地的人参考也适合那些刚从Prompt工程转向Agent工程、想找个真实场景练手的人。先说清楚这里讨论的范围基于大型语言模型LLM的在线文本客服Agent。不涉及语音机器人那套VAD、ASR、TTS的链路是另一套复杂度但对话管理、意图识别、知识库召回这些核心模块是通用的语音场景同样能复用。2. 大模型不是Agent客服Agent的边界在哪里很多团队第一次做客服Agent犯的最大错误是把大模型当成Agent写一段Prompt就直接上。结果呢上线第一天就被用户绕晕答非所问第二天被安全团队约谈因为模型输出了不该输出的内容第三天业务方要求加十几个对话流程你发现光改Prompt已经改不动了。问题出在哪在于没有理解“大模型”和“Agent”的分工。大模型的本质是一个概率语言模型它的强项是“生成”。你给它上下文它给你接话。但客服场景需要的不是“接话”而是“解决问题”。解决问题需要的是流程控制、状态管理、工具调用、知识检索、风险判断——这些都是LLM不擅长、甚至根本做不到的。所以我的经验里客服Agent的架构设计有一个核心原则让大模型做决策让代码做执行让规则做兜底。三者缺一不可。以大模型做决策指的是意图识别、槽位抽取、情感判断、回复生成这些“需要理解力”的环节交给LLM来做让代码做执行指的是查订单、建工单、退换货流程、知识库检索这些“确定性操作”必须由程序代码来控制不能让大模型自由发挥让规则做兜底指的是敏感词过滤、黑名单、风险拦截、限流降级这些“不能出错”的环节必须用硬规则来保证100%执行。这个三角色分离的架构能回答一个关键问题AI客服到底能做什么、不能做什么。能做的是理解用户意图、检索知识、生成拟人化回复、引导用户提供必要信息不能做的是直接操作系统完成高风险操作或者说能设计但需要多层审批和审计不能跨出知识边界胡说八道不能在极端情绪下继续激化矛盾。所以我们内部定了一条架构红线Agent只负责“对话”和“决策”不直接负责“执行”——所有涉及订单、支付、退款的系统操作必须走API网关由后端触发并且每一步都要留审计日志。3. 整体架构设计四个核心模块和一条控制链聊完了边界来看具体的架构设计。我们的客服Agent架构经历了三轮迭代从最早的单体Prompt到后来的多Agent协作最终定型为现在的**“中心控制器专家Agent工具层”**三层结构。这套架构的核心思路是把对话理解和业务处理解耦让专业模块做专业事。3.1 整体分层结构最上层是接入层负责对接不同渠道的消息——网页聊天窗、微信公众号、小程序、企业微信、API开放接口。各渠道的消息格式、会话保持、异步回调差异很大接入层的职责是把这些差异抹平统一转换成内部的标准消息结构。中间是核心控制层这是整个Agent的中枢也是多轮对话优化的主战场。它包含会话管理器、意图识别器、状态跟踪器、回复生成器四个关键组件。消息进来后先进入会话管理器读取或创建会话上下文然后交给意图识别器判定用户这次想干什么接着状态跟踪器结合历史状态和当前槽位判断还缺什么信息、该走什么流程最后回复生成器根据当前状态和检索到的知识生成回复内容。最下层是能力支撑层包括知识库FAQ文档、订单系统API、CRM用户信息、工单系统、敏感词库、抽检日志库等。这一层是Agent的“手脚”让Agent不止能说话还能办事。3.2 流程编排为什么不用纯ReAct这里必须聊一个很多人在架构选型时纠结的问题流程编排到底用ReAct自由推理还是用预定义的流程模板ReActReasoningActing模式确实是当前Agent的主流模式优点是灵活、能应对开放性任务。但如果你真的在客服生产环境用过ReAct一定会遇到三个头疼的问题一是不可控模型自己决定下一步做什么很容易跑偏比如用户本来在问退换货模型聊着聊着开始推荐商品二是状态丢失ReAct的每一步都依赖模型对上下文的记忆一旦上下文超出窗口或者被截断整个流程就乱了三是审计困难自由推理的过程没法预定义审核节点安全团队很不放心。所以我们最终选择了混合模式流程骨架用预定义模板流程中的动态决策用LLM。举个例子退换货流程是固定的——确认订单号、确认商品、确认原因、安排退货——这个骨架用代码写死但每一步的“理解用户回答”和“生成引导话术”是动态的交给LLM。这样既保证了流程不走偏又让对话体验足够自然。这套架构里还有一个容易被忽视但极其关键的组件状态跟踪器。它维护一个结构化的对话状态槽位列表比如订单号、商品编号、退货原因、用户情绪等级。每轮对话更新一次状态LLM只负责从用户的话里抽取槽位值状态是否完整、下一步该问什么由代码逻辑判断。这等于把“记忆”从模型上下文里抽离出来放到更可靠的结构化存储中。4. 工具选型解析模型、框架和向量库的取舍说完了架构来聊工具选型。这块我直接给结论再说理由。4.1 模型选型大模型做精度、小模型做拦截模型选型上现在市面上可选的大模型很多海外有GPT-4o、Claude国内有各类开源和商用模型。我的建议是不要迷信某一个模型而是反过来从场景需求倒推核心对话模型负责意图识别、回复生成需要强语义理解能力推荐选择指令遵循能力强、中文效果好的模型。有条件的话可以同时接两个模型做冗余一个主用一个备用一个挂了另一个顶上避免客服通道全断。意图拦截模型不要用大模型做敏感词和风险拦截太贵也太慢。用轻量级规则引擎或者小型分类模型跑第一道拦截大模型只处理正常对话这是成本优化的关键一步。Embedding模型提供给向量检索使用需要把用户问题和知识库文本映射到同一个向量空间推荐使用专门的Embedding模型而不是直接拿对话模型来生成向量。我踩过的一个坑是早期为了省事直接用对话模型来生成Embedding结果知识召回准确率惨不忍睹。后来换成了专门的Embedding模型并做好文本预处理召回效果立竿见影。4.2 Agent框架LangGraph还是自研状态机Agent开发框架现在也很多LangChain、LangGraph、AutoGen、字节的Coze等。我们的实践是调研用了LangGraph生产用了自研状态机。原因不是LangGraph不好而是客服场景的状态流转太有行业特性了——我们需要状态持久化到Redis、需要跟工单系统深度绑定、需要精细控制每个节点的超时和重试策略通用框架在这些方面反而成了约束。自研状态机看似重复造轮子但实际上状态机代码也就几百行换来的是完全可控的流程编排。但如果你是从零起步、团队又不大用LangGraph起步是完全可以的它能帮你快速搭建骨架边跑边改。只是上线前一定要想清楚框架的升级怎么办框架作者不维护了怎么办这些问题在做技术选型时就该有答案。4.3 向量库先想清楚检索什么再选工具知识库召回我们用到了向量检索选型时对比了Milvus、Qdrant、Elasticsearch等。最终选了Qdrant理由是部署轻量、API简洁、支持过滤条件。但我说个更重要的经验向量库选型不是核心检索策略才是核心。客服场景的知识库检索有几种类型需要区分FAQ式问答高频比如“怎么退款”这类问题用向量召回FAQ条目就够了文档式问答低频但复杂比如“你们的售后政策是什么”这类需要先做文档切片、摘要化处理再按层次检索动态数据查询比如“我的订单到哪了”这类向量检索解决不了必须走参数抽取API查询返回结果再生成自然语言回复。如果你不分青红皂白就把所有知识都灌进向量库那召回结果一定是一锅粥。先对知识分类再设计检索路径这是知识库建设的核心方法论。5. 多轮对话优化从“能聊”到“聊明白”的三级跳标题里提到了“多轮对话优化”这是客服Agent体验的生死线。用户能容忍AI答错一次但不能容忍每次都在同一个地方兜圈子。我把多轮对话的优化路径拆成三个阶段每个阶段解决不同问题。5.1 第一级上下文管理别让模型失忆多轮对话最基础的问题就是“失忆”。用户第5句话提到“刚才那个订单”如果Agent还记得第2句里的订单号这个对话才成立但模型上下文窗口有限、不同系统之间信息还不同步很容易丢。我们的解决方案是分层记忆机制会话级记忆存在Redis里key是会话IDvalue是结构化的对话状态包含槽位、上轮回复、未解决问题等每次消息进来先读Redis处理完再写回保证无状态服务也能恢复会话摘要级记忆当对话超过一定轮数用LLM把前面的对话压缩成摘要避免Token超限。摘要要保留关键槽位和未解决事项这个Prompt需要专门调优全局级记忆读用户画像比如VIP等级、历史订单偏好这部分来自CRM数据不属于模型上下文放在流程里让LLM按需读取。这里有个关键点上下文并不是越长越好。上下文太长一方面推理成本暴涨延迟变高另一方面模型会“迷失在中间”反而不关注最新消息。我们的经验是对话上下文默认保留最近10轮超过的部分做摘要。10轮足够覆盖绝大多数客服场景的连续对话又不至于拖慢推理。5.2 第二级槽位填充与主动澄清多轮对话的第二个核心问题是槽位缺失。用户说“我要退货”系统需要知道订单号、商品ID、退货原因。如果槽位不全就不能调退货API。这里最容易犯的错误是拼命追问让用户一次性把信息说完。产品经理喜欢这种设计因为“效率高”但用户会觉得像在填表体验很差。我们优化后的策略是一轮只问一个关键槽位优先问最缺的、最影响流程推进的那一个问题中带上已知道的信息和引导性选项比如“查到你有一笔9月12日的订单是这件商品要退货吗”这比“请输入订单号”的体验好得多允许用户连续补充多个槽位比如用户说“订单号是12345裙子尺码大了要退”一个句子就填充了两个槽位状态跟踪器要做多槽位一次抽取设置槽位确认节点对高风险操作退款、改地址必须让用户明确确认才能执行防止模型误抽导致错操作。5.3 第三级策略性兜底承认不会比硬答更好再怎么优化总有模型答不上的情况。过去很多团队的默认策略是模型不能确定就随便生成一句“我理解你的意思”然后继续编下去。这是大忌。我们的兜底策略分了三个层级低置信度转人工当意图识别置信度低于阈值、或者用户连续两次表达不满时自动进入转人工流程并把当前对话摘要发给人工客服让人工不用重复问知识无答案时澄清知识库召回没有相关内容时不是直接说“不知道”而是用澄清话术“你问的问题我暂时没有查到准确答案你要不问一下是否指……”给用户一个台阶也有助于判断是知识库没覆盖还是用户表述不清楚情绪升级拦截检测到用户情绪低落或愤怒比如出现投诉词、激烈词不再回复业务内容而是切换为安抚模式和紧急转人工这条规则是硬编码的任何情况下不能绕过去。兜底策略的终极目标是别让用户觉得在跟一个自以为是的AI对话。承认不会、及时转人工往往比硬撑着答错更让用户满意。6. 实操过程从零搭建一个客服Agent的最小可用版本前面聊了架构和策略这里给一套可以直接上手的实操路径。我会按步骤来每一步都附带选型建议和注意事项。这套方案是我备注的“最小可用版本”不是说生产就够而是让你在2-3周内先跑通一条主链路。6.1 环境准备与依赖清单假设你的技术栈是Python这套方案的基础依赖如下# 核心依赖 pip install fastapi uvicorn # API服务框架 pip install openai # LLM调用大多数兼容OpenAI协议 pip install langchain langgraph # Agent框架用于快速验证落地可替换 pip install qdrant-client # 向量库客户端 pip install redis # 上下文状态存储如果你是纯新手我的建议是FastAPI不熟的先看一遍官方教程很容易上手LangGraph不熟的不用强求可以用最原始的if-else先跑通再换。6.2 构建会话管理服务先搭最核心的会话管理这是多轮对话的基石# session_manager.py import redis import json import uuid class SessionManager: def __init__(self, redis_urlredis://localhost:6379/0): self.redis redis.from_url(redis_url) self.expire_time 1800 # 会话有效期30分钟 def create_session(self, user_id): session_id str(uuid.uuid4()) session_data { user_id: user_id, status: open, slot: {}, # 槽位数据 history: [], # 对话历史 summary: , # 摘要历史 intent: None, # 当前意图 turn_count: 0 # 轮数统计 } self.redis.set(fsession:{session_id}, json.dumps(session_data), exself.expire_time) return session_id def get_session(self, session_id): data self.redis.get(fsession:{session_id}) if not data: return None return json.loads(data) def save_session(self, session_id, session_data): self.redis.set(fsession:{session_id}, json.dumps(session_data), exself.expire_time)这个小代码解决一个问题让Agent变成无状态服务每轮请求都能从Redis恢复会话状态。后面加机器、做负载均衡都不会有状态丢失问题。6.3 意图识别与状态跟踪意图识别和状态跟踪是核心控制逻辑。这里给出一个基于LangGraph的示例框架先把主流程写清楚# agent_controller.py from langgraph.graph import StateGraph, END from typing import TypedDict, Optional class AgentState(TypedDict): session_id: str user_input: str intent: Optional[str] slot: dict response: str need_human: bool # 定义节点函数 def intent_recognition(state: AgentState): # 这里可以调用大模型也可用规则先过滤常见意图 # 返回意图和抽取的槽位实践中是结构化JSON intent, slot llm_parse_intent(state[user_input]) return {intent: intent, slot: slot} def slot_check(state: AgentState): required_slots get_required_slots(state[intent]) missing [s for s in required_slots if s not in state[slot]] if missing: state[response] ask_for_slot(missing[0]) else: state[response] return {response: state[response]} def api_call(state: AgentState): # 调用实际业务API得到执行结果 result call_business_api(state[intent], state[slot]) return {response: format_result(result)} def human_handoff(state: AgentState): return {need_human: True, response: 正在为你转接人工客服请稍候……} # 构建图 graph StateGraph(AgentState) graph.add_node(intent, intent_recognition) graph.add_node(slot_fill, slot_check) graph.add_node(api, api_call) graph.add_node(handoff, human_handoff) graph.set_entry_point(intent) graph.add_conditional_edges(intent, lambda s: slot_fill if s[intent] else handoff) graph.add_conditional_edges(slot_fill, lambda s: api if not s[response] else end) graph.add_conditional_edges(api, lambda s: END) graph.add_edge(handoff, END) app graph.compile()这段代码演示了最核心的流程控制结构——意图识别 → 槽位校验 → 业务API → 回复。实际生产中这个图会有更多节点比如知识库召回、情绪检测、多轮追问、摘要生成等但骨架逻辑就这一条线。6.4 知识库管理与召回策略知识库召回是整个客服Agent最容易被低估的部分。我们直接给一套落地配置离线阶段把FAQ和文档统一导入按类别切片。FAQ一条一个条目文档按段落切片每段不超过200字保留段落标题作为元数据向量化阶段用Embedding模型批量生成向量存进Qdrant。记住要同时存原文和元数据不能只存向量在线召回用户问题向量化后在Qdrant里做相似度检索返回Top5候选。如果最高相似度低于阈值我们默认0.7需要调优就进入兜底流程重排阶段向量召回的结果再用一个轻量级rerank模型或LLM打分排除掉语义相似但实际无关的条目。这一步能显著提升知识命中准确率强烈推荐别省。6.5 回复生成与安全护栏最后一步是回复生成。这个环节的核心不是“生成得漂亮”而是“生成得安全”。我们加了三层安全护栏第一层输入侧过滤。用户输入先过敏感词库和正则规则命中则直接降级不再走LLM。第二层输出侧校验。LLM生成的回复再过一遍关键词和规则防止模型输出违规内容。第三层行为控制。流程代码里写死哪些操作绝对不能做比如不能承诺无法兑现的赔偿、不能辱骂用户、不能泄露隐私信息。这三层护栏看起来“很土”但恰恰是它们保证了Agent在真实环境里不会出大事故。AI的错误往往是搞笑的客服场景的错误可能是要赔钱的。7. 常见问题与排查技巧实录整理几个我在落地过程中实际碰到的问题每个都是真金白银换来的经验。7.1 多轮对话轮数多了就乱怎么办现象对话超过10轮后Agent开始答非所问甚至把之前说过的话重复一遍。排查思路先查上下文管理看Redis里的会话状态是否完整再查摘要逻辑。大概率是摘要把关键槽位丢了。我们优化后的摘要Prompt明确要求每条摘要必须保留所有已填槽位、当前未解决问题的意图、以及待确认事项。格式化为结构化文本而不是自然语言总结。还有个细节很多团队直接把所有对话记录塞进Prompt导致模型“迷失在中间”反而忽略最近几轮内容。用最新消息摘要槽位状态的组合模型效果远好于把所有历史原封不动塞进去。7.2 用户死活不说订单号怎么引导现象槽位缺失Agent反复问“请提供订单号”用户不配合说“你自己不会查吗”对话卡死。排查思路引导话术太生硬。优化后的做法是如果用户提供了手机号或用户名可以先查用户所有在途订单然后主动问“你是要处理哪个订单是9月12日这件连衣裙还是9月20日这双运动鞋”把开放性问题变成选择题用户回答成本大幅降低槽位填充率明显上升。7.3 模型偶尔输出不负责任的承诺现象用户问“你们能保证明天送到吗”模型回复“可以的”但实际配送时效根本不受控业务方炸了。排查思路这是大模型“讨好用户”的通病。解决办法是高危承诺词表规则拦截包含“保证”“一定”“绝对”“赔偿”“免费”等词的场景强制降级为不承诺话术。同时对意图分类加一个“时效咨询”类型走FAQ精确回答而不是让LLM自由发挥。7.4 转人工后信息断档人工客服重复问现象AI聊了8轮转人工后人工客服完全不知道之前聊了什么让用户重新说一遍用户火大。排查思路必须在转人工时把会话摘要、已填槽位、未解决问题一次性传给人工工作台。这个靠Agent控制层完成不是人工客服系统自己猜。我们实现了一个标准的“交接包”格式内容包括用户ID、意图、已收集的槽位、AI已经说过的承诺、未解决的问题、推荐下一步动作。人工客服拿到这个包基本不需要让用户重复任何信息。7.5 知识库命中率低用户问的答案明明有现象知识库里明明有答案用户换个说法就检索不到。排查思路核心在Embedding模型的相似度阈值和重排策略。我们的经验是第一扩展同义词和别名比如“退款”“退钱”“还钱”其实是同一件事在知识点里维护别名列表第二问题改写用LLM把用户问题先改写成多个候选问法再分别向量检索能显著提高命中率第三阈值不要一刀切不同类别设置不同阈值比如退换货类问题可以放宽阈值财务类问题要严格阈值。8. 效果评估与持续优化上线只是开始Agent上线不是结束是新一轮迭代的开始。客服Agent的效果评估我建议分三层做。对话层指标意图识别准确率、槽位填充率、多轮任务完成率。这些是过程指标关注Agent“有没有听懂”。我建议每周抽300-500条对话做人工标注和系统的自动识别结果对比计算准确率和召回率。这个环节看起来费人力但它是发现系统瓶颈的最直接手段。业务层指标转人工率、首响时长、问题解决率、用户满意度。这些是结果指标关注Agent“有没有解决问题”。特别关注“转人工率”的曲线变化如果上线后转人工率不降反升说明Agent要么答非所问让用户烦了要么兜底策略太激进动不动就转人工。成本层指标单次会话平均Token消耗、单次会话平均成本、API调用失败率。LLM的API费用在客服场景里是会让人肉疼的尤其是高峰期。我们的优化手段有几个缓存高频问答完全相同的问题不重复调用大模型精简Prompt模板减少无用Token小模型做初筛非复杂问题用小模型回答大模型只处理复杂对话。8.1 持续优化的两条主线主线一是知识库运营每周分析转人工的前10个主题把高频问题补充进知识库和意图库。客服场景里知识覆盖提升一个点转人工率就能降一点这是最划算的优化路径。主线二是对话策略调优用线上对话数据做Bad Case分析找到模型“明明理解了但回复不好”的场景针对性调优Prompt模板或流程节点。比如我们发现用户在问“退货流程”时如果附带“裙子”这个实体Agent直接推荐退货方式比让用户确认商品更顺畅于是调整了槽位校验顺序。9. 最后分享一个实用经验先在内部用起来在文章的最后我分享一个实际体会客服Agent的落地最忌讳一上来就面对真实用户流量。我的建议是先在内部试点——让公司自己的员工、兼职客服、业务运营人员用真实的业务问题去测Agent。内部试点的好处是第一问题真实且覆盖业务全貌比测试用例有效得多第二反馈链路极短发现问题当天就能修第三没有外部舆论压力模型说错话也只是内部消化。我们在内部试点阶段跑了两周收集了几千条真实对话修掉了十几个流程Bug、几十个知识盲区。等到正式灰度上线时第一天转人工率就直接低于预期值这在没有内部试点的项目里几乎是不可能的。另有一个小技巧灰度上线不要按流量比例随机放量而是按“用户类型”放量——先让低价值、低纠纷风险的用户走AI客服等高价值用户的对话也积累了足够准确率再全量放开。这里的关键指标是各用户群组的转人工率和满意度如果新放开的用户群组数据下滑明显赶紧回滚到人工模式。客服Agent这条路没有终点。语义理解在变强模型能力在升级业务形态也在变化但底层的那套架构思路——边界清晰、流程可控、兜底可靠、数据闭环——是稳定的。希望这篇文章能给正在这条路上探索的你一些参考。如果你准备动手做一个客服Agent的Demo别急着堆Prompt先画一张架构图哪些环节用大模型、哪些环节用代码、哪些环节用规则想清楚了再写代码。动手了遇到问题随时再交流。