先别急着建意图树。
我们拿一句真实工作里很常见的话，看看数字员工到底应该怎么处理：
昨天那个任务为什么还卡在 80%？
这句话出现在产品答疑群。同一个话题里，用户昨天发过任务截图，但没有贴任务 ID。
如果只做意图识别，这题不难。“进度查询”“执行异常”，选一个都能说得通。
麻烦的是后面：到底查哪个任务？80% 是页面展示还是真实状态？用户只是想问原因，还是希望马上恢复？机器人有没有权限重跑？
所以这次不讨论分类模型，也不画宏大的系统架构。我们就把这一句话处理完。
先把前文捡回来
群聊和工单不一样。
工单通常有标题、分类和字段，群聊往往只有一句“昨天那个”。如果数字员工只看当前消息，它连“那个”是什么都不知道。
开始处理前，我会先把群、话题和前序消息捡回来：
- 这是哪个群，数字员工在群里扮演什么角色；
- 当前消息属于哪个话题；
- 用户前面发过什么；
- 能不能从截图、时间、发起人定位任务；
- 当前角色可以查什么，又不能改什么。
本例里，机器人是产品客服。它可以解释产品规则、查询任务、登记问题、通知责任人，但不能未经授权修改任务配置。
这个边界要先装进脑子里，否则机器人查着查着，顺手就把任务重跑了。听起来很积极，出了问题就不太积极了。
先判断一下：这条消息要不要回。
答案看起来当然是“要”。但别小看这个判断。
群里有不少消息不需要机器人插话：同事已经接手、用户只是表示感谢、同一问题重复发送，或者大家正在讨论一个并不需要它参与的话题。
这里用户主动提问，暂时也没有其他人承接，所以可以响应。
如果已经有人回复“我在查”，数字员工更合适的动作也许不是抢答，而是悄悄跟踪状态，等有结果再补充。
群聊里的好客服，不是每句话都接，而是知道什么时候该开口。
接着，别被“80%”这个数字带偏。
看到进度数字，第一反应很容易是“任务进度查询”。
但用户的意思更接近：任务长时间停在 80%，我怀疑它有问题。
所以这里更合适的任务是执行异常排查。
这个区别不是文字游戏。普通进度查询只要读一次状态；异常排查还要继续看子任务、失败记录和恢复路径。
意图名称好不好，判断标准很简单：它能不能帮助系统决定下一步。如果一个标签命中以后，大家还是不知道要查什么、做什么，那它只是给问题换了个名字。
确认任务类型后，先定位对象，别急着向用户要一整张表。
用户没给任务 ID，是不是应该马上追问？
不一定。
同一个话题里已经有截图、时间和发起人。系统可以先拿这些线索去匹配任务。
如果只找到一个对象，直接查。找到两个，再问一个能把它们分开的信息。
比如：
我先按昨天这张截图定位。现在找到两个相近任务，请确认是尾号 218 还是 436？
这比“请提供任务 ID、账号、项目、时间和截图”友好多了。
用户已经说过的内容，就别让他再说一遍。数字员工如果每次都像第一次见面，不是严谨，是记性差。
先查真实状态，再解释原因
任务定位后，接下来不要急着从知识库里猜原因。
先查真实状态，再按下面的顺序处理：
- 查主任务状态；
- 没完成就继续查子任务；
- 有失败项，再查错误信息；
- 最后用产品规则解释这个状态意味着什么。
为什么实时数据要放在前面？
因为“任务卡在 80%”可能有很多原因。也许还在正常处理，也许五个子任务里失败了一个，也许页面没刷新，也可能任务根本不在当前环境。
知识库只能告诉你有哪些可能，系统状态才能告诉你这次发生了什么。
假设查到的结果是：主任务仍显示执行中，五个子任务里有一个失败，错误发生在数据校验。
这时回复可以这样写：
已定位到任务尾号 218。主任务仍显示执行中，但 5 个子任务中有 1 个在数据校验环节失败，所以页面停在 80%。当前客服角色不能直接修改配置，我先把任务编号、错误信息和查询结果转给对应责任人，处理进展会继续在这个话题更新。
这段话没有炫技，只做了几件实在的事：告诉用户查的是哪个对象，状态是什么，为什么停住，机器人能做到哪一步，后面由谁接。
查询结果别都翻译成“没有数据”
接上系统以后，会遇到几个长得很像、意思完全不同的结果。
无记录，可能是任务 ID 或环境错了。
空结果，可能是查询成功，但当前范围没有明细。
数值为零，是一个真实业务结果。
不支持，说明系统没有这项能力。
无权限，则说明数据存在，但当前身份不能读取。
如果把它们全翻译成“没有数据”，用户下一步就会走错。
执行状态也一样。已入队不是执行中，执行中不是已完成，部分失败更不能只回一句“任务失败”。
数字员工不需要把所有技术状态甩给用户，但它自己必须分得清。对外说人话，对内保留精确状态，这两件事并不冲突。
知道该怎么做，不代表可以直接做
查到失败原因后，很自然会想到“那就重新执行”。
这时要踩一脚刹车。
当前数字员工的角色是产品客服。它可以查询，也可以把恢复建议告诉用户，但没有权限直接修改配置或重跑任务。
比较稳妥的处理方式有三种：
- 低风险查询，直接执行；
- 需要登记或转交，执行后返回真实编号；
- 涉及写操作，先确认权限和用户意图，再由有权限的人或工具处理。
不要因为意图识别很有把握，就顺手把动作也自动化了。
意图回答用户想做什么，权限回答系统现在能不能做。这是两道题。
Microsoft Unified Routing也会把工作分类和人员分配分开：知道是什么问题以后，还要结合技能、队列、可用性和负载决定交给谁。
转人工不是一句“请联系管理员”
机器人做不了时，最省事的回复是：“建议联系管理员。”
这句话基本等于把问题原封不动地还给用户。
一次有效转交，至少要带上对象、状态、错误和已做步骤：
- 用户要解决什么；
- 对应哪个任务；
- 机器人已经查过什么；
- 当前状态和错误是什么；
- 为什么需要人工；
- 希望责任人接下来做什么。
如果系统支持登记，就创建真实记录，并把真实编号和状态反馈给用户。如果登记失败，就明确说失败，别先回复“已记录”再祈祷接口自己恢复。
转人工的目标不是甩锅，而是让接手的人不用把前面的排查再做一遍。
什么时候可以说“处理完了”
这是整条工作流里最容易偷懒的地方。
接口返回 success，不一定代表任务恢复。它可能只表示请求已经进队列。
责任人说“我看一下”，也不代表已经处理。
用户回一句“好的，谢谢”，更不能当成业务闭环。
本例至少要满足下面几个条件，才能关闭：
- 已经定位到唯一任务；
- 真实状态和停滞原因已经明确；
- 如果执行了恢复动作，已经重新读取任务状态；
- 如果转给人工，责任人已经收到完整信息并接单；
- 用户知道当前结果和下一步；
- 还没解决的问题保留跟进，而不是被聊天结束带走。
说白了，结束标准不是“对话没人继续说话”，而是业务对象真的到了可以确认的状态。
把刚才的过程收成一条 SOP
走完一遍后，SOP 不需要写得像论文。能让产品、研发、测试和运营看懂同一件事就够了。
可以收成下面这样：
触发：用户报告任务长时间停在某个进度，或询问任务为什么没有完成。
先看上下文：从群、话题、截图、时间和发起人中寻找任务线索。
补信息：只有无法唯一定位时，才问一个最小必要字段。
查询顺序：主任务 → 子任务 → 失败信息 → 产品规则。
处理分支：
- 正常执行：返回状态，说明何时继续跟进；
- 部分失败：说明成功和失败部分，给出恢复路径；
- 无记录：核对对象和环境；
- 无权限：停止继续查询或写入，带证据转交；
- 状态冲突：保留页面与系统两份证据，交给人工判断；
- 工具失败：明确当前拿不到实时结果，不靠知识库猜。
结束条件：查询结果可验证；恢复动作已回读；或责任人已接单并保留跟进。
这就是一条能进入评审的工作流。没有什么神秘的，难点只是在每一步都别想当然。
再看一个容易改判的例子
用户问：“现在支持按地区筛选吗？”
一开始，这是功能咨询。机器人可以根据产品知识回答当前是否支持。
接着用户说：
我知道现在不支持，帮我提一个，希望下周活动前能用。
任务已经变了。继续重复“当前不支持”没有意义，现在应该转成需求提交。
系统可以复用前文，不再问用户想要什么功能，只补登记所需但尚未提供的信息。登记成功后，返回真实需求编号和当前状态。
这里要特别注意四句话不能混用：
已登记 ≠ 已排期 ≠ 已上线 ≠ 已验证
用户说“希望下周能用”，只是期望时间，不是产品承诺。
这个例子也说明，意图不是贴上去就不动的标签。新消息可能补充原任务，也可能直接把任务带到下一步。
最后怎么测
只用原始案例跑通一次，远远不够。
至少再改几种条件试试：没有任务 ID、有两个候选任务、查不到记录、客服没有日志权限、五个子任务只失败一个、页面和系统状态不一致、用户要求直接重跑、同一句话里又查状态又提需求。
每条测试不用写得很花哨，记清五件事就行：
| 要看什么 | 需要写清楚的内容 |
|---|---|
| 输入 | 用户消息、上下文和已有对象 |
| 预期判断 | 是否响应、当前任务和缺失信息 |
| 预期动作 | 查询、澄清、登记、确认或转人工 |
| 禁止动作 | 不能猜、不能越权、不能提前宣布成功 |
| 结束证据 | 哪个系统状态或真实回执能证明完成 |
第一次试运行，可以先让数字员工给出判断和建议，由客服人工确认。稳定后再开放自动查询、自动登记。高风险写操作则继续保留授权和人工复核。
Salesforce 的分类实践会根据置信度采用推荐、人工选择或自动保存等不同程度的自动化；Atlassian也建议先从低风险、范围清楚、重复出现的请求开始。
具体阈值不用抄别人的。拿自己的案例测，看看误判一次会造成什么后果，再决定自动到哪一步。
回到那句“卡在 80%”
现在再看开头那句话，它已经不只是一条待分类的消息了。
它背后有群场景、历史话题、业务对象、实时状态、权限边界、责任人和结束标准。
所谓七层分流，落到实际工作里没必要天天挂在嘴边。它只是提醒我们：先决定要不要回，再理解正在处理什么，找到正确对象，选择能做的动作，最后确认事情真的结束。
标签只是中间产物。能把任务往前推，才是客服数字员工存在的意义。