企业官网建设流程全解析

1. 先想清楚：AI客服Agent到底解决什么问题

有一段时间我特别烦给客服打电话，每次听完语音菜单按完数字，再听一遍欢迎词才能等到人工。后来很多产品把菜单换成了聊天机器人，但体验并没有好多少——它只是把菜单从电话搬到了对话框，用户问“我想改绑手机号”，它回一篇长长的FAQ列表，用户还得自己从里面找答案。

真正的转变，是最近一年“Agent”这个词在客服场景里火起来之后。AI客服Agent不是简单的问答机器人，而是能理解用户意图、管理多轮对话、调用后端查询接口、最终把问题实际解决掉的完整任务系统。它有点像一位刚入职的客服专员：懂得听客户讲完，心里记住前因后果，手上的系统能查订单、能改资料，遇到边界情况知道叫主管来。这篇文章我打算从零讲清楚如何构造一个AI客服Agent，适合后端工程师、产品经理，以及所有对大模型应用落地感兴趣的读者。我会按照从业务定义到架构拆解，再到最小实现和线上调优的顺序来讲，尽量少讲虚的，把每一步的取舍和理由都说清楚。

1.1 从IVR菜单到Agent的演进逻辑

客服系统经历了好几个阶段。最早的IVR（Interactive Voice Response）是按键导航，用户需要按1查订单、按2查物流，看起来高效，其实是把“理解用户的成本”转嫁给了用户。后来出现了FAQ机器人，它做的是关键词匹配，能回答一些高频问题，但没有状态，用户连续问两个不同领域的问题，它基本就断片了。

再往后就是任务型对话机器人。它能通过多轮对话把用户需要的信息凑齐，然后调用接口完成查询。这种机器人在银行、电信、电商场景已经很常见，但实现上非常依赖人工编写对话流程树，一旦场景复杂，流程树变得像盘根错节的榕树，维护成本极高。

AI客服Agent的新意在于：把“对话理解”和“任务执行”之间的连接变得更灵活。它不再严格假设用户会按你设计的流程走，而是能从一个目标出发，在对话中自主决定下一步动作。比如用户说“帮我把地址改一下，顺便看看这个订单到哪了”，传统机器人可能就懵了，但Agent可以把这句话拆成两个意图，先识别出“修改收货地址”和“查询物流”两件事，再通过对话补充缺的参数，然后分别调用两个接口。这个能力，本质上是在机器人之上加了一个“规划器”，能够动态组织对话和动作。

1.2 Agent与普通聊天机器人的本质差别

如果一句话概括，普通聊天机器人是“回答问题”，Agent是“完成任务”。最直观的区别有三个：

• 是否有状态记忆。普通聊天机器人通常每个请求都是独立的，它不记得你五轮之前说过什么；Agent会把用户ID、当前会话、槽位信息、已执行动作放在一个状态上下文里。
• 是否能调用工具。普通聊天机器人只从自己的知识库里检索答案；Agent可以去查订单系统、提交工单、修改设置，它具备影响业务系统的能力。
• 是否能动态规划。普通聊天机器人严格按配置好的分支走；Agent可以基于LLM的推理能力，在面对用户临时改口、补充条件、多意图掺杂时，动态调整下一步。

我见过很多团队做AI客服，一开始只接一个大模型的API，把历史聊天记录一股脑丢进去，让它自由回复。前几个星期demo效果非常好，因为demo里就那么几个问题，模型背下来了。一旦上线面对真实用户，各种脏话、病句、多歧义、方言、夸张的表述涌进来，模型开始一本正经地编造“您的订单已经发货”，但其实订单根本不存在。

所以，真正能落地的Agent，绝不是“大模型壳子”，而是把意图识别、槽位抽取、对话状态管理、工具调用、人工兜底这些工程模块串起来。模型是大脑，但不是全部身体。

1.3 构造前必须回答的三个业务问题

在写第一行代码之前，先回答三个问题。回答不清楚，后面做到一半很可能要推翻。

第一个问题：Agent的问题边界在哪。你不可能让一个客服Agent处理所有问题，至少一开始不行。先圈定一个窄场景，比如“订单查询与售后解释”，或者“账号资料修改”。边界之外的问题，默认转人工。这样可以大幅降低意图体系的复杂度，也更容易做出好体验。

第二个问题：成功的标准是什么。建议不要用“机器人回答率”这种虚荣指标，而要用“问题闭环率”，即用户在对话里完成了目标，或者明确表示问题已解决。只有解决了问题，Agent才有业务价值。回答得再好听，用户挂了电话问题没解决，那也是零分。

第三个问题：人工怎么接入。Agent不是替代人工，而是过滤掉那部分重复、低风险、高确定性的事。要提前定义好转人工的触发条件：用户明确要人工、两次以上无法识别意图、Agent连续执行失败、用户情绪激动、涉及高危操作。转人工后，还需要把对话摘要、上下文一并移交，否则人工接管后还得从头问一遍，那体验会被Agent直接毁掉。

2. 整体架构：分层设计是Agent能跑起来的根基

我在刚开始做客服Agent的时候，犯过一个典型错误：把所有逻辑都塞进一段很长的提示词里，让大模型自己看着办。结果就是，它能处理我预先想好的四条对话路径，但只要用户稍微插一句无关的话，整个流程就崩了，甚至开始自作主张地给用户承诺赔偿。

后来我把系统拆成了四层：接入层、大脑层、执行层、数据保障层。每一层只负责一件事，模型只是大脑层里的一个组件。这样一层层拆下来，出了问题能定位，改版也不用推倒重来。

2.1 接入层：把不同渠道的差异关在门外

客服Agent可能挂在网页、小程序、App、微信公众号，甚至电话语音通道上。每个渠道的消息格式、超时机制、加密方式都不一样。接入层要做的第一件事，是定义一套统一的“会话消息模型”。

举个例子，不论从哪个渠道进来，到大脑层的时候都统一成三个对象：用户标识、会话ID、消息内容。用户标识用于多轮记忆归属；会话ID用于追踪一次服务过程；消息内容包含文本和可选的附加字段，比如图片、语音转写文本。所有渠道相关的处理，比如图片上传、语音转语音，都放在接入层完成，不让上层感知。

接入层还负责限流和队列。尤其当Agent被很多人同时使用时，突发流量会把后端的对话管理模块打崩。我建议在入口做两层保护：一是并发限流，每用户每几秒最多发几条；二是消息队列削峰，让对话系统按自己的处理能力消费消息，消费不过来的先排队，或者直接返回“当前咨询较多，请您稍后”。

2.2 大脑层：意图、状态、决策三者协同

大脑层是Agent最核心的部分，负责理解用户当前这句话、结合上下文更新状态，然后决定下一步该做什么。

具体拆开来看，包括四个模块：

• 意图识别模块：判断用户这句话是想查订单、改地址、咨询政策，还是在骂人。
• 槽位抽取模块：从对话中提取订单号、手机号、地址等结构化参数。
• 对话状态管理模块：记录当前处于哪个流程节点、已经收集到了哪些槽位、还剩哪些必填项。
• 决策编排模块：根据状态和意图，决定下一步是继续问问题、调用接口、检索知识，还是转人工。

这四个模块的配合方式，我后面会细讲。这里只想强调一个设计原则：不要让大模型随手写状态，状态必须由确定的代码来管理。什么意思？比如“订单号是否已经填好”，这个判断应该由槽位管理逻辑检查，而不是让模型猜“用户好像给过订单号”。一旦状态被模型“猜”，线上出错的概率会迅速上升。

2.3 执行层：工具调用与回复生成

执行层回答“确定了要做某件事之后，怎么去做”。这里分成两类动作：

一类是业务动作，也就是调用后端API。比如“查询订单状态”需要把订单号传给订单中心；“修改地址”需要把新地址提交给用户中心。这类动作有副作用，必须写清楚参数校验、超时、失败重试、权限控制。

另一类是语言动作，也就是生成对用户说的话。这里又可以细分：标准流程中每个节点返回的确认话术，建议用模板或可配置文案，不要每次都让大模型自由发挥，否则同一件事每次措辞都不一样，用户会困惑；只有开放问题、复杂解释、多条件政策问答，才交给大模型生成，并且尽量提供知识依据。

执行层还要有一个“护栏”：如果工具调用连续失败，或者返回的数据明显不合理，就应该停止当前动作，转入人工，而不是硬着头皮编一个结果出来。这一点我见过太多血的教训。

2.4 数据与保障层：跑得起来之后再看这里

前面三层让Agent能够工作，数据与保障层则让Agent能够稳定工作。这里面包含日志采集、会话追踪、监控告警、评测集、标注平台。

每轮对话，都要把原始消息、意图结果、槽位状态、调用了哪个接口、接口返回、模型生成内容、最终话术完整记录下来。这条链路最好有唯一的trace ID，否则出了问题根本没法排查。

监控方面，至少要盯住几个线上指标：会话数量、意图识别失败率、工具调用失败率、转人工率、平均处理时长、用户主动结束比例。任何一个指标异常，都要能够通过trace ID迅速定位到具体会话。评测集则用来在每次改版前自动跑一遍已知用例，确保改了这个功能，没弄坏那个功能。

3. 核心技术模块逐个拆解：从意图理解到回复生成

架构搭好之后，剩下的就是让每个模块真正工作起来。这一章是全文最重头的部分，我会把每个核心模块的常用实现方案、内部原理和选择理由都讲清楚。

3.1 意图识别：用分类器兜底，用大模型补长尾

意图识别是整个Agent的地基。地基歪了，后面槽位抽取、动作编排全都会歪。

目前比较稳妥的做法是两条腿走路：对于高频、可枚举的意图，用一个轻量级分类模型快速识别；对于长尾、开放式的表述，再用大模型去理解和归类。

为什么不能只靠大模型？一是延迟。客服场景通常要求用户每等两三秒内就有响应，大模型调用一次可能要一两秒，如果每句话都等，体验会非常糟糕。二是稳定性。大模型的语言能力很强，但同一个意图换了好几种说法，它偶尔会判断漂移。用分类器先兜底，不仅快，而且结果稳定可复现。三是成本。高频问题占客服咨询量的七八成，这些用轻量模型处理，每轮成本低到可以忽略，大模型只需要处理剩下的疑难杂症。

意图体系设计上，建议做成树状。第一层分“订单相关”“账号相关”“物流相关”“政策咨询”“人工诉求”，第二层再细分。比如“订单相关”下分“查订单状态”“改收货地址”“申请退货”“催发货”。树的层级不要超过两层，否则训练和维护都是灾难。

同时一定要设计好“拒识”机制。当分类器置信度低，或者大模型判断不落在任何已知意图时，不能硬分配类别，而是要回退到澄清话术，或者直接转人工。拒识阈值如何定？我一般先看历史数据，把分类器输出概率低于某个值的会话抽出来人工看，调到一个“既不经常误拒绝，又不随便乱猜”的位置。这个值通常没什么神秘的，跟着评测集慢慢磨。

3.2 槽位抽取：让对话变成可执行的指令

意图代表用户想干什么，槽位则代表干这件事需要什么信息。还是举“查订单状态”的例子，必须有订单号；如果用户是通过手机号下单的，那么手机号加验证码可以替代订单号。槽位抽取，就是不断从用户的话语中提取这些结构化字段。

实践中，槽位体系要区分必填槽位和可选槽位。比如“改收货地址”，必填槽位是“新地址”和“订单号或用户ID”，“原地址”则是可选，系统可以在确认时展示给用户看。用户在输入新地址时可能同时带出订单号，那要能一次抽出来，不要傻乎乎地一个个问。

多轮填槽时，最怕的是用户中途改主意。用户先说“我要改地址”，等你问到订单号，他又说“算了，你先帮我查查这个订单到哪了吧”。这时系统不能继续卡在改地址的流程里，而要识别出意图切换，把当前槽位缓存起来，跳到查询物流的流程。等查询完，再问一句“您还需要继续修改地址吗”。这种能力，靠状态机配合意图识别可以实现。

槽位抽取的落地方式，可以是规则抽取（比如订单号的正则）、NER模型、或者大模型抽取。我建议对强规则字段如订单号、手机号用正则或小模型，既能保证准确率，又节省时间；地址、商品名这类信息灵活多变，再用大模型抽取。抽取完成后，进入业务API前，必须做一层逻辑校验，比如格式、长度、取值范围，不能让一个非法订单号真的发到订单系统里去。

3.3 对话策略：状态机、流程编排与LLM自由生成怎么选

这是Agent设计里分歧最大的地方。走纯状态机，灵活度不够；走纯大模型自由生成，可靠性不够。我的推荐是混合架构：让核心业务流转由确定性的状态机或流程编排来控制，让模型负责自然语言理解、话术润色和开放问题回答。

举个例子，售后流程可以定义成这样的状态：

• INIT：会话初始
• COLLECT_ORDER：收集订单号
• QUERY_RESULT：查询订单结果
• HANDLE_RETURN：处理退货
• DONE：完成
• TRANSFER：转人工

用户一进来，状态自动进入INIT。意图识别是“申请退货”，且还没订单号，则迁移到COLLECT_ORDER，给用户发一句话：“麻烦您提供一下订单号或下单手机号。”用户给了订单号，状态迁到QUERY_RESULT，调用订单查询接口，根据返回结果判断是否满足退货条件。如果满足，再问用户退货原因，进入HANDLE_RETURN，生成退货工单。如果接口返回超时或异常，进入TRANSFER。

状态的迁移逻辑用代码写死，绝不交给模型。模型能做的，是在每个状态下帮系统理解用户输入，并选择合法的下一个动作。也就是说，模型的自由被限制在一个动作集合内，它不能随便说“我帮您申请了100元补偿”就把补偿发出去。

为什么这么做？因为客服业务有强合规要求。哪个动作有权限、哪个话术合规、哪个结果需要用户确认，都是确定的业务规则。状态机天然表达这些规则，而大模型的优势在自然语言层面，两者结合才能既灵活又可控。

3.4 RAG知识库问答：检索质量决定体验

客服Agent还有一大块工作是“解释政策、回答问题”。比如“七天无理由退货的条件是什么”“运费谁出”“发票怎么开”。这些内容不适合做成意图后调用接口，更适合用RAG（检索增强生成）来做：先从知识库里检索相关文档，再把检索结果塞给大模型生成回答。

但RAG不是把一堆文档丢进向量数据库就完事。常见的问题是：检索召回了多份相似但条件不同的文档，模型回答得含含糊糊，用户再追问细节就答不出来。

我建议按下面的流程构建客服知识库：

• 清洗：把原始文档里的时间、部门、内部口径等无用信息去掉。
• 结构化切分：不要按固定字数硬切，最好按“问题-条件-结论”来组织。比如一条退换货知识，包含适用人群、商品范围、时间条件、操作入口、特殊情况说明。
• 向量化与索引：用嵌入模型生成向量，存入向量检索库，同时保留关键词索引做混合检索。
• 重排：向量检索召回Top20，再通过重排模型挑出最相关的3到5条。
• 带引用输出：要求模型在回答中引用知识条目标识，这样用户可以点开来源，也方便审核。

还有一个容易忽略的点：知识是分版本、分生效时间的。去年说了运费全免，今年改成满额免运费，如果检索系统没做版本过滤，Agent就会一本正经地给出过时政策。所以每条知识必须有生效时间和适用场景的元数据，检索时先按条件过滤，再做相关性排序。

4. 动手构造一个最小可用客服Agent：选型与实现细节

理论讲完，这一章我们实际做一个最小可用的Agent。场景选“订单状态查询与售后解释”，这是最常见、最不涉及高风险操作的场景。后面说的选型和实现，遵循一个原则：先跑通，再优化。

4.1 技术选型：先别贪多，按需求取舍

很多初学者一上来就搭一堆框架，结果一半时间在解决框架本身的配置问题。我的建议是最小化技术栈，尽量用手边有的工具。

我会这样选型：

选型的核心逻辑是：每个组件都只承担自己最擅长的一件事，不要迷信“全家桶”框架。等业务复杂度上来，清晰的分层边界能让你无痛替换其中任何一层，而不会相互牵扯。

4.2 定义对话流程与提示词：把业务规则织进系统

接下来定义流程图。最小可用版只需要处理三种情况：查询订单状态、咨询售后政策、转人工。

我在代码里用JSON描述流程状态和可用动作：

{ "flow": "after_sales", "states": { "INIT": {"next": ["COLLECT_ORDER", "QUERY_RESULT", "POLICY_QA"]}, "COLLECT_ORDER": {"next": ["QUERY_RESULT"]}, "QUERY_RESULT": {"next": ["HANDLE_RETURN", "POLICY_QA", "DONE"]}, "POLICY_QA": {"next": ["QUERY_RESULT", "DONE", "TRANSFER"]}, "TRANSFER": {"next": []} } }

系统提示词里，我会明确告诉模型当前的可用动作和输出格式。伪代码示意：

你是一名电商售后客服Agent的决策模块。 当前用户状态、槽位和对话历史如下： 状态：COLLECT_ORDER 已收集槽位：{"订单号": null, "手机号": "13800001234"} 对话历史：... 你的任务是从以下合法动作中选择一个，并抽出槽位信息： 可用动作： - collect_order_id: 当用户未提供订单号时，要求用户补充 - query_order: 当订单号已收集，调用查询接口之前的动作 - answer_policy: 当用户询问政策 - transfer_manual: 当用户要求人工或无法处理 只输出JSON，不要输出解释： {"action": "...", "slots": {...}, "reply": "..."}

这里的关键点在于，模型只能从预定义动作里选，不能自己发明动作。好好设计这个提示词，能让系统的不可控范围大幅缩小。

4.3 构建知识与数据：让Agent“懂业务”

客服知识库的初始来源可以有三处：现有FAQ文档、客服团队手里的标准话术、历史工单里的高频问题。

我通常会先把高频问题列成清单，比如：怎么查订单、怎么申请退货、退款多久到账、运费谁承担、是否支持换货。每个问题写成一条结构化知识：

{ "id": "policy_015", "category": "after_sales", "title": "七天无理由退货条件", "content": "商品签收后七天内，在商品保持完好、不影响二次销售的情况下可申请无理由退货。定制类、生鲜类、已拆封的影音产品除外。", "effective_date": "2024-06-01", "apply_condition": "仅限普通商品订单，虚拟商品不适用" }

把这些JSON写入向量库后，我建议先做一轮人工问答验证：拿着二十条业务人员出的测试问题，逐一问一遍Agent，看回答是否准确、是否引用了正确条目。这一步非常花时间，但比上线后被用户投诉要划算得多。

4.4 把Agent接到真实工具和人工兜底

Agent的最后一个环节是执行动作。Mock接口很简单，但真实接口要注意几点。

第一，参数校验在后端再做一遍，不能在模型侧信任所有提取出来的字段。第二，超时时间一定要比用户能等的上限短。如果接口需要三秒以上，就不要同步阻塞，而是告诉用户“正在为您查询，请稍等”，先返回一个正在处理的提示，再异步推送结果。第三，接口异常时要区分是参数问题还是服务问题，别让用户反复重试同一个注定失败的请求。

转人工的兜底，我建议设计成这样：当状态机进入TRANSFER，系统自动创建一个人工工单，把会话摘要、当前槽位、已执行动作、关键日志都附上去。同时给用户一句话：“我已经把您的情况记录并转给人工客服，约1分钟内回复，请留意。您也可以继续在这里描述问题。”如果是在线IM场景，人工接入时应该能看到完整的Agent会话记录，不需要用户重复。

5. 跑通之后的调优：评估指标、翻车点、常见路径

第一个能跑通的Agent和真正好用的Agent之间，隔着大量的线上反馈和迭代。我建议上线后的前两周不追求自动化率，而是把所有失败会话都拿出来看一遍，先治最明显的病。

5.1 三个最容易翻车的地方

第一个翻车点：一句话包含多个意图。用户说“帮我查下订单，对了，退货地址是什么”。如果系统只识别了后一个意图，就会错过查询订单。解法是允许多意图抽取，把一个用户消息拆成多个意图，依次处理，并给用户清晰的确认。

第二个翻车点：槽位收集时用户改主意。这是我在真实会话里最常见的失败原因。用户在填订单号的过程中突然说“这不是我的订单，我是帮朋友问的”，这时如果系统还继续追问验证码，体验非常生硬。解法是建立“意图变更检测”，只输入时发现新的核心意图，就切到新的流程流转。

第三个翻车点：知识库答案过期或条件不匹配。比如库里说“可退货”，但实际订单已经超过七天，Agent照搬知识库回答“可以退”，就会引发投诉。解法是在检索时把订单信息和知识条目的“适用条件”一起做条件过滤，而不是只做文本相似度检索。

5.2 用评测集盯住核心质量

我建议每个客服Agent项目都维护一个“黄金评测集”，里面包含至少一百条真实对话用例，覆盖主要意图、典型槽位组合、异常表达、转人工场景。每次改动任何模块，先跑一遍评测集，看结果对比。

评测维度可以设成这么几项：

注意，指标不能只看平均值，要分场景看。比如退货流程本身复杂，完成率可能只有五成，单独拿出来看才能找到改进空间。

5.3 线上数据回流与迭代

黄金评测集是静态的，真正驱动Agent进化的是线上真实会话。我建议做一个轻量的“失败会话分析”流程：每天从当天的对话日志里选出转人工、用户差评、用户重复提问最多的会话，让运营或产品同学快速标注失败原因。

常见的失败原因包括：意图识别错、槽位漏抽、知识库缺内容、接口返回不完整、话术表达让用户困惑。每类原因单独建一个待办清单。先把影响面最大的一个问题修掉，再跑评测集，再小范围灰度上线。

不要一次性堆一堆改动上线。AI客服Agent的改动不像普通功能上线，失败成本高，线上用户骂一次就很难挽回。灰度策略上，可以新老策略按比例分流，对比转人工率和用户满意度，连续观察几天再全量。

6. 我踩过的那些坑，以及给新手的起步建议

最后分享一些我在实战中积累的经验教训，很多都是文档里不会写的细节。

6.1 几个容易被忽略的工程细节

上下文长度管理是一个大坑。很多人把所有对话历史原封不动地塞给大模型，对话一长，不仅成本直线上升，模型还会被前面的内容带偏。我建议保留最后几轮原始消息，更早的内容交给系统压缩成结构化摘要，每次只把摘要加最近几轮给模型。

成本控制也是一个需要提前思考的问题。不是每一轮都需要调用大模型。高频规则流程里，如果用户输入能命中正则，比如纯数字订单号，系统可以直接走分支，连大模型都不用调。只有遇到模糊表达、复杂开放问题，才调用大模型。这样算下来，整体成本能省很多。

安全与权限是客服Agent最容易出事的环节。Agent能调业务接口，就意味着它有“手”，必须严格控制它的权限范围。只给它查询、改地址、提交工单这类低风险动作，而且要记录每一次动作。涉及退款、优惠券变更等高风险操作，一律转人工并二次确认。

模型幻觉的治理，绝不能靠模型自律。我见过Agent信誓旦旦地告诉用户“您的订单预计明天到达”，实际物流显示还在另一个城市。解决办法有两个方向：一是涉及具体数据时必须从接口拿，不让模型编造；二是知识类回答必须引用知识库来源，没有来源的宁可说“我帮您查一下，稍后人工确认”。

6.2 从最小Demo到完整产品要补的东西

一个能查订单的小Demo，做成产品还差很远。你需要补上运营工具，让业务人员能维护FAQ和知识库；补上人工标注平台，让运营能快速给失败会话打标签；补上监控大盘和告警，让Agent出问题的时候能第一时间知道；还可能需要引入会话摘要、多语种、语音转文字等扩展能力。

按照我个人的实践体会，一条比较务实的路线是：先选一个高频小场景，做成一个“能自动解决80%常见问题”的Agent，把它跑稳；不要一开始就追求所有场景全覆盖。因为客服场景里最后10%的疑难杂症，投入产出比很低，而且很容易把核心场景的体验也拖垮。先把一个点做到让用户“愿意主动用”，比所有点都做到“偶然能用”重要得多。

最后再分享一个小技巧：如果你负责的项目刚起步，可以先不追求技术架构的完美，但一定要把“会话日志”作为一等公民来设计。无论后面的意图模型换了几版，知识库怎么重构，只要日志完整，你就能随时追溯、复盘、找规律。这个习惯，在Agent的整个生命周期里，比任何一个模型选型都更能决定项目的上限。