1. 售后工单分流，一张工单等了三分钟
一家零售电商的客服中心，每天产生八百张售后工单。工单要分到五条线上：退货、换货、维修、投诉、咨询。分错了来回折腾，分慢了客户再打一次电话。
客服中心第一版的做法是：把整张工单的正文丢给一个智能体，让它判断该分到哪条线。上线一周，冒出来三个毛病。
太慢。工单正文有客户描述、订单信息、聊天记录，智能体读完再推理一遍，平均三分钟才给结果，高峰时段更久。客服要一边接电话一边等。
每次结果不一样。同一张工单隔天再跑一次，上一次分到「换货」，这一次分到了「维修」。理由都说得过去，但分流这件事不能这么飘。
有单子漏了。十七张工单既没有分出去，也没有落进任何一条兜底路径，卡在系统里没人接。客服以为系统处理了，系统以为客服在跟。
三个毛病指向同一处：分流这件事本来就不需要「判断」，它的规则是写在制度里的，硬当成判断来做，慢、不稳、还会漏。
2. 工作流和智能体是两种执行方式
2.1 步骤谁定的
工作流（Workflow）是把步骤、顺序、判断条件事先定好，执行时按图走。走哪条分支由设定好的条件决定，不由执行者临场发挥。
智能体（Agent）是由模型看着当前情况，自己决定下一步做什么、调哪个工具、什么时候停。
两者的差别不在技术上，在「谁决定下一步」。
| 下一步谁定 | 结果稳不稳 | 遇到没见过的情况 | |
|---|---|---|---|
| 工作流 | 事先画好的条件 | 同一输入结果一样 | 走不到任何分支，需要兜底 |
| 智能体 | 模型当场判断 | 同一输入可能不同 | 可以临场处理，也可能编 |
一条流程里两种可以混着用，常见有四种组合。
纯工作流：整条流程都写死，适合规则明确、步骤固定的活。工单分流、报表生成、数据同步都属于这一类。
纯智能体：整条流程交给模型，适合需求模糊、步骤不固定的活，比如「帮我把这份调研材料整理成一份提纲」。
工作流包住智能体：流程的骨架写死，中间某几步交给智能体，比如工单分流流程里，第二步「判断客户情绪是不是需要优先处理」交给模型。
智能体调用工作流：智能体在外面，遇到分流这种事，就把整条工作流当成一个工具调一下。这是企业里最常见的一种接法，原因在 3.4 节讲。
2.2 一张判断表
拿到一个步骤，按下面这张表挑执行方式。
| 这一步的特征 | 走哪条 |
|---|---|
| 规则写在制度里，谁来做结果都一样 | 工作流 |
| 要在一秒内出结果，用户在现场等 | 工作流 |
| 做错的代价高，比如改价、退款、发通知 | 工作流，并加人工确认 |
| 输入是自然语言，说法千奇百怪 | 智能体 |
| 要按上下文判断，比如客户情绪、语言风格 | 智能体 |
| 步骤本身不固定，走到哪算哪 | 智能体 |
| 大部分工单是那几种常见情况，少数是特例 | 工作流打底，特例交给智能体 |
最后一行是企业里最常见的情况。工单分流那八百张单子里，八成以上是「买错了要退」「尺寸不对要换」这类标准情形，剩下不到两成才是需要读上下文判断的。
2.3 两种方式在哪儿看得见
工作流的执行过程看得见。每一步的输入、输出、走向，都在画布和运行记录里，点开哪一步就看得到哪一步的变量。
智能体的执行过程看不见。它的「步骤」是模型自己写出来的推理，两次跑可能不一样，出了问题要从对话记录里往回翻。
这一点直接影响排障的快慢。工单分流改成工作流之后，漏派那十七张单子，在运行记录里一看就知道卡在哪个节点：条件写的是「订单金额大于 5000 且客户等级为 VIP」，两个条件用的是「且」，有一张单子金额够了但等级不是 VIP，两个分支都没进，也没有兜底分支。
3. 该用工作流的四类场合
3.1 要即时出结果
用户在现场等的时候，能写死的步骤就不要交给模型推理。工单分流从平均 180 秒降到 0.6 秒，靠的就是把规则判断从模型手里拿回来。
一条粗略的经验：一秒以内能出结果的，走工作流；用户能接受十几秒甚至几分钟的，才考虑让模型多跑几轮。
3.2 每次结果必须一样
分流、计价、审批、权限判定这几类活，同一个输入跑两次给出不同结果是不能接受的。客户拿着两次不同的答复来问，客服没法解释。
要求结果一致的地方，判断条件要写成明确的规则。规则里尽量少用「大概」「倾向于」这类词，用得上这些词的地方，说明这一段本来就该交给模型，那就别放进工作流。
3.3 出错代价高
改价、退款、发通知、动数据这几类动作，做错一次的代价远大于省下的那点时间。它们至少要满足两个条件：执行路径写死，执行前有人确认。
3.4 工作流怎么接进智能体当工具
工作流搭好之后，通常是包装成一个工具，让智能体来调用，很少单独用。
做法很简单：给这条工作流起一个名字，写清它收什么参数、返回什么，然后把它当成一个工具接到智能体上。客服助手接到一张单子，判断这是售后分流的活，就调用「工单分流」这个工具，把工单号和客户描述传进去，拿回分派结果。
这样接的好处是两边各干各擅长的：智能体负责跟客户对话、理解客户到底想干什么；工作流负责按规则把单子准确分下去。规则改了只改工作流，对话方式改了只改智能体。
4. 路由与分岔
4.1 路由按什么条件分
路由（Routing）是这个场景里最核心的一步：判断这张单子该走哪条路。条件有三种写法。
按规则判断最稳。条件写在工单字段上，比如「售后类型等于退货」「订单金额大于 5000」「客户等级为 VIP」。规则判断快、可复现、好排查，能写成规则的活优先写规则。
用一个小模型做分类。规则覆盖不了的时候，把工单摘要丢给一个小的分类模型，让它输出五个类别里的一个。它比让大模型从头推理快得多，也稳定得多，因为任务窄。
交给大模型判断。工单内容又长又绕、牵涉前后好几通对话的时候才用它。它是三者里最贵、最慢、最不稳的，放在最后面。
三种写法可以依次往下退：先看规则能不能判，判不了给分类模型，还判不了才给大模型。
同一批单子，该由规则、小模型还是大模型来判
先自己判一遍，再点开下面的判定
眼前这批单子和三种写法
- 单号
SO20261011037 - 工单字段售后类型=退货、订单金额=8600、客户等级=普通
- 另一张单子的摘要包装拆了但没坏，这算不算质量问题
- 第三张单子的过程前后通了五轮、中途发过两张照片、客户提了特殊处理
- 三种写法按字段规则判、丢给小的分类模型、交给大模型从头推理
先自己给这三张单子各挑一种写法，再看下面的判定。
看判定
SO20261011037→ 按字段规则判；售后类型、订单金额、客户等级都在字段里，又快又稳- 包装那张单子 → 交给小的分类模型；规则覆盖不了「算不算质量问题」，但类别只有几个
- 通了五轮那张单子 → 交给大模型；内容又长又绕，规则和分类模型都接不住
- 顺序上的规矩先看规则能不能判，判不了给分类模型，还判不了才给大模型
越往下退越贵越慢，能写死在规则里的就别往上交。
路由条件能写成字段规则的就写规则。
4.2 条件分岔要留兜底
分岔写条件的时候，最容易漏的是「都不满足怎么办」。上面那条规则用的是「且」，把金额够但等级不够的单子挡在外面，两个分支都没进，单子就卡住了。
兜底分支挂两个地方：条件分岔的末尾挂一条「其他」，整条流程的末尾挂一条「异常转人工」。两条都要有，缺一条就会出现卡住不动的单子。
条件本身也要注意阈值。阈值取整、取区间端点的位置要写清楚，「金额大于 5000」和「金额大于等于 5000」，差一张单子就是两个走向。
阈值的取数口径跟行业的日历有关。零售电商的「退货时限三天」按自然日算，跨周末照样走；金融的「适当性评估三年有效」按交易日算，节假日不计；医疗的「复诊提醒三个月」按实际就诊日往后推。同一句「超过三天」，在不同行业的库里指的是不同的三天，条件里要把按什么日历算写清。
4.3 循环和回退
流程里有些步骤可以回退，有些不能。
可以回退的是判断类步骤：分类不对，退回去重来一次，代价很小。回退要设上限，比如最多重试两次，超过就转人工，否则会来回空转。
不能回退的是执行类步骤：已经给客户发了通知、已经改了订单状态，这些动作往回退要有补偿动作，不是简单地把上一步重跑一遍。判断一个步骤能不能重跑，看它跑两次会不会产生两个结果。发两次通知就是两条短信，这种步骤要么加幂等处理，要么设成只能跑一次。
5. 触发器和变量
5.1 什么时候自动跑
流程启动有三种方式：定时启动、事件触发、人工发起。
定时启动适合周期性的事，比如每天上午九点生成前一天的售后日报。事件触发适合有人做了某个动作就跟着发生的事，比如工单创建之后自动分流。人工发起适合判断类的事，客服自己决定要不要跑一次。
三种方式的区别不在技术，在于出错的时候谁负责发现。定时任务跑失败了没人知道，要配告警；事件触发跑失败了通常有上游感知；人工发起跑失败了发起的人当场就知道。给定时任务配一个失败告警，是最容易被省掉、也最容易出事的一步。
5.2 变量在步骤之间怎么传
步骤之间靠变量传值。一个步骤输出变量，下一个步骤引用它。
传变量有三件事要写清楚：变量名叫什么、它是什么类型、为空时怎么办。
工单分流这条流程里，第一步输出 工单号、售后类型、订单金额、客户等级 四个变量，第二步引用它们去判断。这里有两个坑：一是类型，订单金额 一旦被传成文本，后面的「大于 5000」就比不了；二是为空，售后类型 字段偶尔是空的，不处理就会走到判断为空的那一条。
5.3 出错了从哪儿查
工作流最大的好处是每一步都留痕。运行记录里能看到：哪张单子、哪个时间点进了哪个节点、这一步的入参和出参分别是什么、走向了哪条分支、各步花了多少时间。
排查按「倒着看」的顺序走：先看最后一步有没有执行，再看它的上游有没有给它值，一直往回找到第一个输出为空或者走错分支的节点。上面那十七张漏派的单子，就是这么找到的。
一张漏派的单子，顺着轨迹往回找
- 单号 SO20261011037
- 入参 工单号=SO20261011037 · 出参 售后类型=空、订单金额=8600、客户等级=普通 · 耗时 0.2 秒
这一步成功，工单信息已经拿到。
- 判定结果「订单金额 8600 > 5000：满足」「客户等级 = VIP：不满足」
- 走向无匹配分支
这一步标着「成功」，可走向是「无匹配分支」，卡点在这里。
- 未收到分派去向，未执行
它没拿到去向，问题不在这一步。
- 未收到处理时限，未执行
- 结论这一步的条件用了「且」，两个条件不都满足时没有出口，请在分岔末尾加一条「其他 → 人工分派」
- 这一批受影响的单子17 张
记录没执行，这张单子从头到尾没人接手。
每一步都留痕，出错才能倒着查到节点。
6. 哪一步不该交给智能体自己判断
前面几节讲的是该怎么选。这一节反过来，列几种「看起来可以让它判断、其实不该」的情况。
步骤本身说得清。制度里写着「金额超过 5000 要主管复核」，这就是一条规则。写成条件，一秒出结果；交给模型判断，三分钟还可能判反。
错了代价高。改价、退款、动库存、发正式通知，这几类动作一旦判错，补起来要花几倍的时间。
要求每次一样。计价、审批、权限判定，同一个输入必须同一个结果。模型的结果带随机性，同一个输入两次跑出两个答案，这件事本身就无法交付。
有明确的完成标准，而且能一条条列出来。能列出标准，就说明能用规则或清单表达，用不着模型临场想。
反过来说，下面这几种才是该交给智能体的：判断依据藏在客户原话里，说法千奇百怪；需要结合前面几轮对话的语气和上下文；情况本身没有固定处理办法，要临场定策略。
7. 售后工单这条流程收口
客服中心那八百张工单最后改成这样。
分流改成了三层往下退，大模型只管最后一层。规则判断接住八成以上：售后类型为退货、换货的直接按字段分流；订单金额超过 5000 的先挂主管复核。规则判不了的，交给一个小的分类模型，只干「五选一」这一件事，平均 0.6 秒出结果。剩下的才给大模型，主要是描述含糊、语气激烈的单子。
条件分岔末尾加了一条「其他 → 人工分派」，整条流程末尾加了「异常转人工」。这两条挂上之后，漏派的单子从十七张降到零。
流程包装成一个叫「工单分流」的工具接到了客服助手上。客服助手负责跟客户对话、理解诉求，判断这是售后流程的活就调用这个工具，拿回分派去向和处理时限。
执行记录留全：每一步的入参、出参、分支走向和耗时都存下来。有一次客服说「这张单子系统没分」，顺着轨迹往回查，两步就定位到是 订单金额 这个字段那次传成了文本，比不了大小。
整条流程的平均耗时从三分钟降到 0.6 秒，规则命中率稳定在八成以上。分流结果的一致性不再靠模型的心情，同一张单子跑十次，落点是一样的。
8. 这一步该写死，还是交给它判断
| 问题 | 答「是」的时候怎么办 |
|---|---|
| 这条规则写在制度里、谁做结果都一样吗？ | 写死成条件，别交给模型 |
| 用户是不是在现场等一秒内的结果？ | 走工作流；确实要模型参与的，放到不影响等待的那一步 |
| 做错的代价是不是很高？ | 写死路径，并在执行前加人工确认 |
| 同一个输入跑两次，结果不一样能接受吗？ | 不能接受的，必须写死 |
| 完成标准能不能一条条列出来？ | 能列出来就用规则或清单，别让模型临场想 |
| 这一步跑两次会不会产生两个结果？ | 会的，要么加幂等处理，要么设成只能跑一次 |
9. 编排里最容易犯的错
什么都交给它自由发挥。 明明是写在制度里的规则，也丢给大模型判断。代价是慢、不稳、还贵。判断一下这条规则能不能写成条件，能写就别让它想。
流程里没有失败分支。 条件用的是「且」，两个条件不都满足的单子就卡在中间。分岔末尾挂「其他」，流程末尾挂「异常转人工」，两条都要有。
出了问题找不到卡在哪一步。 每一步的入参、出参、走向、耗时都没有留痕，只能从头猜。运行记录是工作流最值钱的东西，搭的时候就要打开。
10. 流程定死了，剩下几处还得人点头
把步骤写死之后，要能回答四件事：哪些活按条件走、哪些活交给模型判断、分岔怎么留出口、出错从哪里查。写死的部分越清楚，出问题的地方就越少。
还有一类地方，就算流程写得再清楚，也不能让它自己决定：要动别人东西的动作、要对外发出去的内容、涉及费用的额度。这些地方要停下来等人点一下。下一份材料讲人机分工：哪几步必须有人点头，确认点摆在哪儿，以及怎么让它知道自己不会、会开口求助而不是硬编。