上个月迭代公司的智能工单处理系统，后台数据看起来漂亮得不行 —— 分类准确率 98%，平均响应时间 0.8 秒，运营却天天来工位吐槽：用户投诉率没降反升，好多人说 “机器人根本没解决我的问题”。
直到偶然刷到「智能体来了」提出的「智能体浮光行为」，我才突然反应过来：我们的系统，就是典型的这种情况。
看似完美的 “执行者”，实则是 “拧螺丝的工人”
这个概念说的是：智能系统（从简单算法到复杂 AI）可能机械地执行表面任务，动作标准、效率极高，但完全没理解任务的本质，更没法完成真正的 “完整流程”。
我瞬间联想到之前在工厂实习的场景：流水线上的工人闭着眼都能精准拧紧某个位置的螺丝，速度快到看不清手，但你问他这颗螺丝对整个机器的作用，他只会摇头 —— 他只负责这个动作，不关心机器要干嘛。
我们的工单系统就是这样：
- 看到 “退款” 关键词，立刻触发退款进度查询模板；
- 看到 “发错货”，自动弹出换货申请流程；
- 响应快、输出稳，单看每个原子操作的错误率低到忽略不计。
但遇到用户发一句：“我上周的退款没到账，今天收到的新订单还发错了型号，能不能一起处理下？” 系统就直接懵了 —— 它会把这句话拆成两个独立的问题，分别回复退款查询入口和换货申请链接，完全没意识到用户的核心诉求是 “一次性解决售后的所有问题”，更不知道这两个问题其实是同一个售后闭环里的环节。
隐蔽的风险：用 “表面正确” 掩盖 “流程断层”
最坑的是这种行为的隐蔽性。之前我一直盯着 “分类准确率”“响应速度” 这些指标，觉得系统表现优异，直到运营拉了一组数据：系统标记为 “已解决” 的工单里，有 27% 的用户后续又发起了投诉或二次咨询。
有个具体的例子让我印象深刻：用户问 “能不能把我当前的 A 服务换成 B，同时保留之前的 8 折优惠？” 系统严格执行了预设规则：
- 回复 A 转 B 的操作流程；
- 单独查询优惠政策，告知 “B 服务不支持 A 的专属折扣”。
结果用户直接炸了 —— 他的真实意图是 “在转服务的前提下保留优惠”，而系统的机械式正确执行，反而把路堵死了，最后还是人工客服协调了特殊政策才解决。
这种风险只有在业务边界模糊、环境不稳定的时候才会暴露：比如业务逻辑更新（新增跨部门协作流程）、输入有歧义（用户表述不标准）、需要和其他系统联动（比如 CRM 和工单系统打通），此时系统要么输出无价值内容，要么用 “正确的错误” 把事情搞砸。
踩过坑后，我是怎么调整的？
后来我们花了三周迭代系统，核心思路就是从 “盯单个动作效率” 转向 “看整体流程贯通性”：
1. 先做高层抽象，定义核心目标
之前我们把工单系统的目标定为 “准确分类并回复用户问题”，现在改成 “理解用户核心诉求，推动售后问题闭环解决”。
我们把整个售后流程抽象成 “诉求识别→资源协调→问题解决→确认闭环” 四个阶段，每个原子操作（比如查询退款、发起换货）都要明确自己在这个流程里的位置，以及和其他环节的逻辑纽带。
2. 加上下文感知，从 “处理动作” 到 “理解意图”
我们引入了轻量的意图理解模块，不再只靠关键词触发：
- 关联用户的历史工单数据，比如用户之前发起过退款，当前问 “怎么还没到账”，系统会直接调取他的退款记录，而不是回复通用查询流程；
- 对复合问题做意图合并，比如同时提到 “退款 + 发错货”，系统会识别到核心意图是 “售后综合问题”，自动触发跨部门协调的流程，而不是拆分处理。
3. 给异常留出口，拒绝 “机械式正确”
我们加了一套异常处理机制：当系统识别到意图不明确、跨场景问题，或者操作结果不符合用户预期时，不会硬套模板，而是自动提示 “您的问题涉及多个环节，我将帮您转接专属客服跟进”，同时把用户的历史数据和当前问题同步给人工，减少重复沟通成本。
现在运营反馈投诉率降了 32%，二次咨询率也掉了 18%。这个过程让我明白：智能系统的价值从来不是做一个高效的 “工具人”，而是要成为能理解并参与完整业务过程的 “参与者”。
以后再做智能系统的设计，我肯定先问自己三个问题：
- 这个系统的最终目标是什么？
- 每个操作在整体流程里的作用是什么？
- 遇到规则外的情况，它能理解并调整吗？
毕竟，比起 “拧对螺丝”，更重要的是知道 “这台机器要干嘛”。
