企业官网建设流程全解析

做智能客服系统，最容易掉进去的坑就是把大模型的 API 接好就当上线了。用户真实发过来的消息，和你测试时敲的几句话完全不是一回事。我之前参与的一个项目，目标很明确：给某个二手交易平台（下称 M 平台）搭一套智能客服答复解决方案，组合方式是“低代码智能体平台（下称 L 平台）+ 云厂商智能体平台（下称 C 平台）”。这套方案解决的核心问题是：怎样让大模型智能体在真实交易场景里不跑偏，能自动答复咨询、售后、纠纷这类高频问题，同时把拿不准的会话安全转给人工。如果你也在用智能体平台搭客服，或者正准备接大模型做售后答疑，这篇文章值得看完。

1. 方案选型：为什么是“双智能体”而不是一套系统走到底

1.1 先把项目需求拆开看

M 平台的业务特点是：商品杂、咨询入口多、用户情绪波动大。订单状态有十多种，从“已拍下”“已发货”到“运输中”“已签收”，还有“退款中”“申诉中”这些特殊状态。同一个问题在不同状态下答案完全不同，比如用户问“货到哪了”，如果订单还没发货，标准答复是催卖家发货；如果已经发货，就要给物流轨迹。

除了订单状态，回答还要区分平台责任和用户责任。商品破损属于物流问题还是卖家包装问题，运费该谁出，这些在规则上都有明确说法，但用户不会按规则提问，他们只会在对话框里发一句“东西坏了怎么办”。所以这个项目从一开始就不是单纯选模型，而是要解决三件事：

• 准确识别用户到底在问什么，包括隐含的售后诉求。
• 把订单数据、商品数据、平台规则这些“外部事实”拉进回答过程。
• 回答语气要像真人客服，不打官腔，也不能随便承诺。

需求梳理完之后，我们发现任何一个单一的智能体平台都很难一次性覆盖全部场景。有的平台强在知识库检索，有的强在流程编排，有的强在模型生成的自由度。与其在一棵树吊死，不如让两个平台分工。

1.2 两个智能体平台各自扮演什么角色

我把这套方案里的两个智能体分成“总调度”和“高级顾问”两个角色。

L 平台承担的是总调度。它负责整个对话流程的编排，包括接收用户消息、判断意图、查询订单信息、命中知识库、决定回复还是转人工。为什么选低代码智能体平台做总调度？因为这类平台在流程可视化、API 接入、变量存储这些环节做得比较成熟。你可以像画流程图一样搭出客服主流程，哪些消息走自动答复，哪些走人工兜底，都一目了然。后续运营人员也能自己调整，不用每次改逻辑都找开发。

C 平台承担的是高级顾问。它不直接面对用户，而是在 L 平台需要的时候被调用，负责两件事：一是复杂语义理解，比如判断用户情绪是否激烈、识别“话里有话”的投诉意图；二是生成需要更强语言组织能力的答复，比如解释平台责任归属的长段落。为什么不让 L 平台自己做这些事？因为每个平台背后接的模型擅长方向不同，C 平台的模型在长文本归纳和意图分类上表现更稳定，实测下来的准确率比直接使用 L 平台默认模型高出大概 8 到 10 个百分点。

1.3 为什么不能只靠“大模型 API 直连”

团队里一开始有人提过，干脆直接调大模型 API，写一个 Prompt 就完事。这个想法听起来简单，落地就会遇到三个麻烦。

第一是不可控。大模型生成的回答天然有随机性，同一个问题在不同时间可能给出两种甚至三种说法。客服场景最忌讳的恰恰是话术不统一，尤其是涉及退款时限、赔偿金额这类敏感信息，一句话说错就可能引发纠纷。智能体平台至少可以加一层规则约束，比如先查订单状态再决定是否开启赔偿话题。

第二是无状态。纯 API 直连，每次请求都是孤立的，你必须在外部维护一个庞大的上下文管理模块，把历史对话、订单信息、用户身份全部自己串起来。而 L 平台天然提供会话级变量存储，可以在流程节点里定义变量，跨节点引用，省掉很多重复劳动。

第三是工具调用能力弱。客服场景必须查订单、查物流、发消息，大模型 API 本身不会调接口，需要你写一套工具调用框架。低代码智能体平台自带 HTTP 请求节点和插件机制，配置一个 API 节点比手写一套调用逻辑快得多。

所以最终架构定为：L 平台做确定性的流程调度，C 平台做开放性的语义理解，M 平台的 API 作为数据底座。两个智能体不是竞争关系，而是各管一段。

2. 搭建前的关键准备：知识库、意图体系和兜底规则

2.1 知识库整理是客服系统的地基

很多人以为建知识库就是把文档传上去，向量化之后完事。这是最大的误解。知识库的颗粒度直接决定机器人的回答质量。M 平台的知识库我们做了将近两周，核心原则是：一个问题一个条目，每个条目只回答一件事。

知识库的字段设计如下：

• 标准问题：客服团队的规范表述，比如“退货的运费由谁承担”。
• 相似问法：收集真实聊天记录里的口语表达，比如“退货的话谁出运费”“寄回去的邮费算谁的”。
• 标准答案：一到三句话，可以直接发给用户，不啰嗦。
• 适用范围：该答案适用的商品类目、订单状态或用户身份。
• 跳转意图：如果该问题需要进一步处理，跳到哪个售后流程。
• 更新时间：方便运营团队定期复查。

举个例子，商品瑕疵类问题的条目是这样的：

这里必须强调，标准答案不是越长越好。很多运营人员喜欢把规则原文塞进答案里，结果用户根本读不下去。客服答复的第一目标不是讲清楚全部条款，而是告诉用户下一步该做什么。书面规则留着人工客服用，机器人的回答尽量口语化、行动化。

2.2 意图识别与答复模板设计

知识库建完之后，要设计意图体系。我们把用户意图分成六个主类：商品咨询、订单查询、物流咨询、售后申请、投诉纠纷、人工客服。每个主类下面再挂子意图，比如售后申请下面有“质量问题”“退款申请”“退货申请”“换货申请”。

意图配置结构如下：

intents: - name: after_sale_quality display_name: 质量售后 trigger_words: - 破了 - 坏了 - 碎了 - 有划痕 - 质量问题 - 用不了 require_field: - order_id reply_template: | 您好，已收到您关于商品质量问题的反馈。 订单编号：{order_id} 您可以在订单详情页发起售后申请，平台会在{processing_time}内审核。

答复模板里大量使用变量，比如订单号、商品名称、订单状态、售后时效。变量由流程中的 API 节点从 M 平台订单接口取回来，取不到值的时候默认不展示那一句，避免输出“您好，您的订单号是 undefined”这种低质量回答。

设计模板时有一条纪律：不承诺结果。所有涉及时效、金额、责任判定的表述，全部写成平台审核后会通知，不给用户留下“机器人已经承诺退款”的把柄。

2.3 敏感词、兜底策略与人工接管规则

敏感词库不是简单封禁，而是分级处理。我们分三级：

• 一级：涉及政治、违法内容，直接结束会话并转人工。
• 二级：涉及辱骂、人身攻击，机器人先安抚情绪，再引导到人工客服。
• 三级：涉及价格承诺、线下交易、兼职刷单等风险行为，只回复固定安全话术，不做任何延伸。

兜底策略更考验设计。用户问的问题如果连意图模型都判不出来，千万不能让大模型自由发挥。自由发挥的后果是看起来很有道理，实际上答案里藏着一堆虚构规则。我们的做法是：置信度低于 0.4 的意图直接走人工，答复固定为“抱歉，这个问题我还需要请教人工专员，已为您转接，请稍候”。

人工接管规则如下：

handover: trigger: - user_sentiment == "angry" - intent_confidence < 0.4 - contains_danger_keyword == true action: - set_human_takeover: true - notify_agent_channel: "客服工作台-售后分组" - reply: "已为您接入人工客服，预计等待时间{wait_time}"

这套规则相当于给智能客服加了一圈护栏。宁可多转人工，也不能让机器人乱答。

3. 实操过程：双智能体从搭建到接入 M 平台

3.1 在 L 平台搭建客服主流程

整个主流程在 L 平台的可视化编排界面里配置。核心节点包括：消息接收、会话 ID 映射、意图判断、订单信息查询、知识库检索、C 平台调用判断、答复输出、人工转接。

我建议先搭一个最简版本，跑通之后再逐步加条件分支。最简版本只需要五个节点：

开始 -> 意图判断（使用内置意图识别模型） -> 知识库检索（使用前置字段过滤） -> 组装答复模板 -> 结束

跑通最简版本后，再加入两个关键增强：订单查询节点和 C 平台调用节点。常见的操作顺序是先把 M 平台的订单 API 配置成 HTTP 请求节点，将用户会话 ID 里的订单号作为参数传进去，拉回订单状态和商品信息。然后在意图判断和答复之间插入一个条件分支：如果意图置信度低于 0.7，先调用 C 平台复核一次，再决定答复内容。

模型参数上，L 平台的生成模型建议把温度设到 0.2，最大 Token 设为 500。温度太高容易发散，客服场景不需要创造性回答。知识库检索的相似度阈值设为 0.6 左右，太低了会把不相关内容拉出来。

人设 Prompt 不要写成小作文。越短越好，关键是明确角色边界：

你是 M 平台官方智能客服，你的任务是基于知识库内容和订单信息回答用户问题。 原则： 1. 不编造平台规则。 2. 不做任何承诺。 3. 涉及退款、赔偿、责任判定时，引导用户发起售后流程。 4. 回答控制在 3 句话以内。

3.2 配置 C 平台处理复杂理解任务

C 平台不参与主流程，它以一个“可调用的智能体应用”形式存在。上线前先在 C 平台创建一个客服语义分析应用，输入是一段用户消息和订单上下文，输出是结构化的 JSON，包含意图标签、实体抽取结果、情绪判断和置信度。

Prompt 是这样设计的：

你是客服语义分析助手。请解析用户消息，输出 JSON： { "intent": "售后申请|商品咨询|订单查询|物流咨询|投诉纠纷|人工客服|其他", "sub_intent": "细分意图", "entities": { "order_id": "", "product_name": "", "issue_type": "" }, "sentiment": "平静|不满|愤怒", "confidence": 0.0, "reason": "一句话说明判断依据" } 要求： - 不要猜测缺失字段。 - 用户消息涉及骂人、投诉时，sentiment 必须标记为不满或愤怒。 - 输出必须是合法 JSON。

在 L 平台的工作流里，通过 HTTP 请求节点调用 C 平台的 API。调用时机有两个：一是用户消息命中敏感词时复核情绪；二是主意图判断置信度不足时复核意图。调用超时时间设置为 8 秒，超时后走默认知识库路径，避免因为外部接口拖慢客服响应。

C 平台返回的 JSON 解析后，存入流程变量。后面的回复模板可以直接引用这些变量，比如情绪为“愤怒”时自动切换到更谦卑的开场话术。

3.3 对接 M 平台的订单查询与消息发送接口

接入 M 平台的接口是整个项目最繁琐的一步。重点有三个：鉴权、上下文映射、幂等控制。

M 平台所有接口采用签名鉴权，调用方需要用平台分配的密钥对请求参数进行签名。我们在 L 平台的 API 节点里用脚本节点生成签名。过程其实就是把参数按键排序、拼接、然后做 HMAC 加密，再把签名放进请求头。

会话映射也很关键。M 平台的每个咨询窗口都有一个会话 ID，而 L 平台也有自己的会话 ID，两者要做一张映射表。用户每发一条消息，Webhook 把消息推到 L 平台，L 平台先根据 M 平台会话 ID 查映射表，如果不存在就新建一个会话。

发送消息接口必须做幂等。因为网络抖动可能导致同一条回复被推两次。我们给每条回复生成一个唯一的 message_id，M 平台按这个 ID 去重。这个细节如果前期不做，上线后就会被重复消息投诉淹没。

实际操作里，不建议直接让 L 平台调用发送消息接口，而是通过消息队列中间件异步发送。原因很简单，客服场景要求的响应时间是秒级，如果同一个流程里又查订单又发消息，任何一个下游接口抖动都会让用户等待很久。异步发送让响应状态先返回给用户“正在输入”，后台再真正落库发送。

3.4 端到端联调与上线前验证

联调阶段我拿了一批真实客服聊天记录做回归测试，选了 120 条典型对话，分成六类：正常咨询、物流询问、质量售后、价格议价、情绪投诉、无关闲聊。

测试表结构如下：

上线前建议做一个 24 小时的影子测试，即所有用户消息同时推给智能体和人工，人工正常回复，智能体的回答只记录不发送。第二天对比人工回答和智能体回答的差异，把偏差大的场景继续补知识库。

4. 上线后的常见问题与排查记录

4.1 高频问题速查表

系统上线后，我们整理了一张问题速查表，覆盖日常运维中最高频的故障类型。

4.2 排查实录一：消息总被误判为“售后申请”

上线第三天，运营反馈很多物流咨询消息被识别成售后申请，回复话术牛头不对马嘴。我查了 L 平台的意图判断日志，发现问题出在知识库的关联词上。知识库里“质量问题”这个意图下挂了大量包含“寄”“退回”词语的相似问法，导致模型会把“我的快递什么时候退回”这类物流问题也归到售后。

排查方法是看意图混淆矩阵。把回流日志里的用户输入与实际判定意图拉成一张透视表，找到“实际为物流查询但判定为售后”的高频问题，逐条看触发原因。最后发现“退回”这个词在双意图下都有很强权重。

修复方案是给意图体系加限制条件。物流查询的触发词里加入订单状态变量，只有订单状态为“退款中”或“售后处理中”时才允许命中售后意图。同时在知识库里把所有包含“退回”的问题改成“退货寄回”，降低歧义。

4.3 排查实录二：C 平台调用超时导致回复延迟

另一个典型问题是一旦用户消息包含图片，整个流程耗时直接从 2 秒涨到 15 秒。原因是 C 平台需要对图片生成描述，再加上输入给大模型，这个链路本身耗时就很长。

我们做了一次耗时拆分，发现大部分时间消耗在图片编码和上传。于是调整策略：图片消息不走复杂理解链路，先走平台内置的智能提取服务，只把提取出的文本结果传给 C 平台。如果图片中根本没有文字，就直接返回“请用文字描述您遇到的问题”，不进入模型调用。

改造之后，带图消息的响应时间降到 4 秒以内。这给我的经验是：智能体的复杂理解能力很强大，但必须控制调用成本，不是每条消息都值得动用大模型做深度理解。

5. 上线后的效果指标与运营维护

5.1 从答复到处置：后续扩展方向

答复只是客服系统的第一层。真正有价值的延伸动作是从答复到处置。比如用户反映商品质量问题，不只是回复一段售后引导话术，而是直接在后台创建一个售后工单，把订单号、问题描述、图片证据一并推给仓储处理组。这套扩展已经在我们内部的模拟流程里测试过了，核心思路是把 L 平台的意图节点和工单系统对接，机器人在发送答复的同时调用建单接口。

扩展的时候要注意权限边界。创建工单、修改订单状态这类写操作，必须有二次确认机制，不能让一条用户消息就触发高危动作。我们加了两个条件：用户必须明确表达售后诉求，并且由人工客服在后台审核后方可生效。

5.2 效果评估指标与知识库运营闭环

客服系统上线后不能只看“机器人回答了百分之多少”，要看真正解决问题的比例。我们内部重点跟踪五个指标：

• 首答解决率：用户第一轮提问后，未再追问即完成答复的比例。
• 转人工率：机器人主动转人工的比例，目标控制在 30% 以内。
• 平均响应时长：用户发出消息到收到答复的时间。
• 用户满意度：会话结束后用户评价打分。
• 知识库覆盖率：用户问题是知识库已覆盖内容的占比。

运营闭环也很重要。每周拉取用户提问的文本，找出“机器人没答明白”的会话，把其中高频问题倒推回知识库新增条目。这么坚持做一个月，知识库覆盖率能从 65% 提到 85% 左右。注意，补知识库不是简单添加答案，要让客服团队一起核对，因为知识库里每一条新答案都可能涉及平台责任边界。

我个人在实际操作中的体会是：智能客服项目的复杂度从来不在模型本身，而在流程的组织。双智能体组合看着复杂，本质上是让一个平台做确定性的事，另一个平台做可能性的事，再把两者的输出在一套流程里接住。最后分享一个小技巧：上线前不要用理想化的测试集来验收，要拿真实人工客服聊天记录去回放。人工客服第一轮都问不清楚的问题，别指望机器人能答好。先把这些底层问题解决掉，你的答复方案才算真正具备可落地性。