5.3 完整案例：客服工单分类流水线

5.3 完整案例：客服工单分类流水线

一条完整上线的流：问题进来先过分类器分三路——政策类查知识库作答，投诉类算优先级、调工单接口建单，闲聊类礼貌收尾。本节从需求出发走完全程：画图、搭节点、两轮调试、发布接入，中间包括两次真实的试运行翻车与修复。

零件课（5.2）结业，本节总装。这是第 5 章主线的终点，也是"两周期限"的第二个交付物。案例按五幕展开：背景、操作、结果、解读、变式。

背景：漏单的春节

去年春节大促，客服日志里躺着两百多条小艺没答上的问题，全部无人跟进——因为没有人会去逐条翻日志。客服主管的原话："我要的不是更聪明的回答，是答不上来的每一单都有人接。"这个需求的准确翻译：答不上 → 自动建工单 → 带分类、带优先级 → 进现有工单系统。答复质量是第 4 章的事，本章交付的是"不漏单"。

操作：六步总装

**第一步，画图。**按 5.1 的三步翻译法先出图（成品形态见下图泳道），确定节点清单九个：开始、问题分类器、三路各自的处理链、两个结束节点。**第二步，搭主干。**空画布上先搭"开始→分类器→三条边各自挂一个直接输出"，跑通最小骨架再填肉。**第三步，政策路。**知识检索节点接售后政策库（沿用 4.2 的混合加重排配置），LLM 节点提示词复用 3.2 的四段式精简版。**第四步，投诉路。**代码节点算优先级（5.2 的打分函数）、HTTP 节点建单。**第五步，闲聊路。**模板转换节点拼一句收尾话术直接输出。**第六步，接回聊天。**把这条流作为小艺的工具之一挂进聊天助手（第 6 章展开工具挂载细节），完成"对话触发流程"的闭环。

图 5-2：工单流水线泳道总览

结果：两轮翻车与最终数据

第一轮试运行就吃了红牌。十条例题里四条走了投诉路，工单倒是建了，但优先级全是"低"——大额订单也没加权。点开代码节点看输入：order_amount 全是空字符串。根因在上游：我直接引用了 start.order_id 想当然以为金额也在开始节点，实际金额藏在用户的话里（"我买的两千多的锅有质量问题"）。修复：投诉路入口加参数提取节点，用 LLM 从问题文本里抽订单金额与订单号成结构化字段，再喂给代码节点。这个翻车的教训值钱：变量有没有值，只有试运行知道；LLM 生成的输入永远要在下游校验。

第二轮红牌更隐蔽。工单接口返回 200，流水线绿灯通过，但工单系统里查无此单。翻接口文档才发现：业务失败也返回 200，错误码包在响应体里。修复：HTTP 节点后接条件分支，检查 create_ticket.body.code 是否为成功码，失败边走重试提示。第三轮 50 条样例全绿：政策类 31 条答案带引用、投诉类 12 单全部建成功且优先级分布合理（高 3 中 5 低 4）、闲聊 7 条正确收尾。发布接入，当晚真实流量里第一张自动工单落库。

解读：这条流教会我们的事

三层解读。第一层，确定性的价值：分类可能有边界模糊的题，但一旦进了投诉路，算分、建单、话术全部确定——错误模式从"随机漂移"变成"可枚举的配置错误"，这是可运维性的分水岭。第二层，模型用在刀刃上：全流共三次 LLM 调用（分类、参数提取、政策作答），每次都有明确职责；没有让一个 LLM 节点"把这事全办了"，因为那样等于把确定性需求又交还给运气。第三层，与第 4 章的配合：政策路完全复用知识库与 3.2 的提示词资产——流水线不是推翻重建，而是给已有能力装上流程骨架。

变式：三种延伸改法

**变式一，加质检路。**在投诉路末端加一个 LLM 节点给工单内容做脱敏（隐去手机号），一次调用换合规安心。**变式二，转 Chatflow。**若希望用户在对话里多轮补充信息（没给订单号就追问一句），把整条流迁到 Chatflow 形态，直接回复节点天然支持中途出话——1.2 节"多轮加流程选 Chatflow"的规则在此兑现。**变式三，加人工闸门。**高优先级工单先发到内部群确认再建单：HTTP 节点换向、加一个人工回调入口，流程从全自动变成"机器初审、人工终审"。

复盘要点的三个追问

案例讲完，用三个追问把它钉进长期记忆。

**追问一：为什么参数提取要用独立节点，而不是让 LLM 节点顺手抽？**职责分离。顺手抽的输出格式不可控（今天 JSON 明天散文），下游代码节点就得猜。独立提取节点带结构化输出约束，抽出来就是字段，代码节点直接用。这条原则的通用表述：凡是给确定性节点消费的数据，必须由带结构化约束的节点产出。

**追问二：三条路的成本差多少？**以单次运行估算：政策路两次 LLM（分类加作答）加一次检索；投诉路一次分类一次提取加一次代码执行一次外呼；闲聊路只有一次分类。三路成本近似 3:2:1。分流本身就是降本手段——闲聊量占四成的客服场景，全走重链路等于每天烧掉四成的白烧 token。

**追问三：这条流跑一个月后最先坏的是什么？**外部依赖。工单接口改字段、鉴权 token 过期、网关换域名——流水线自己不会变坏，但它依赖的世界在变。所以 7.3 的巡检清单里要有"外呼成功率"一项，给这条流配的告警阈值是"连续三笔外呼失败即通知"，坏在早晨而不是坏在大促。

问题：工作流的调试数据能复现线上问题吗？

大部分能。试运行可以填入线上出问题的原始输入，逐节点重放——但有两个例外要注意：其一，知识检索节点重放时命中可能不同（知识库已更新），要对照日志里当时的命中记录；其二，HTTP 节点重放会真实再调一次外部接口（比如再建一张单），排查时先把请求指向测试地址。把这两个例外写进团队的排障手册，能避免"复现问题制造了新问题"的尴尬。

⚠️ 常见坑：发布后不监控。流水线最怕静默失败——工单接口哪天改了字段名，流水线照样绿灯（200 就是 200）。第 7 章的日志巡检是这条流的续命机制，别等漏单三个月后才发现。

本节要点回顾

• 六步总装：画图、最小主干、三路填肉、接回聊天，每步跑通再进；
• 翻车一：变量有没有值只有试运行知道，LLM 抽取的字段必须下游校验；
• 翻车二：HTTP 200 不等于业务成功，外呼后必接业务码校验分支；
• 三次 LLM 各司其职：分类、抽取、作答——确定性的事一件不交给模型；
• 资产复用：知识库与提示词直接搬进流程，流水线是骨架不是推倒重来；
• 变式路径：脱敏质检、迁 Chatflow、人工闸门，同一骨架的三种长大方式。

小艺现在会办事了，但只会按图纸办事。第 6 章最后一块拼图：给它工具，让它自己决定查什么、调什么——以及怎么防止它跑飞。