先讲一个客服主管每天都会头疼的场景。
下午两点，客服小张收到一条用户消息：“我的系统登录不上，一直提示密码错误，急！”小张复制用户ID，打开工单系统，新建一张工单，手动填写问题类型“登录问题”，优先级“高”，然后切换到另一个后台查用户信息，再复制粘贴到工单描述里。提交后，工单进入待分配池。运维主管老李每隔半小时刷新一次待分配池，看到新工单，根据问题类型和当前各工程师的负载，手动指派给小王。小王收到通知，开始处理。处理完后，小王在工单里写解决方案，提交，小张再通知用户“已解决”。
这一套流程走下来，从用户提问到工程师接手，平均耗时47分钟。其中真正干活的时间不到10分钟，剩下的全花在“传话”和“等待分配”上。
后来，我们给客服团队配了一个智能工单Agent。现在用户发来“登录不上”，Agent自动创建工单、自动分类、自动派单给最合适的工程师，全程无人干预。用户提问到工程师收到通知，从47分钟压缩到了90秒。
这篇文章，我把这个端到端自动化工单系统拆给你看：怎么自动创建、怎么智能分类、怎么自动派单、以及怎么保证派单不乱套。
一、传统工单系统的三个“堵点”
在动手改造之前，我们先分析一下传统流程为什么慢：
| 环节 | 操作 | 耗时 | 谁在做 |
| 创建工单 | 复制用户信息、手动填表单 | 3-5分钟 | 客服 |
| 分类打标 | 判断问题类型、选优先级 | 1-2分钟 | 客服 |
| 分配工单 | 查看工程师负载、手动指派 | 10-30分钟（轮询周期） | 主管 |
| 通知工程师 | 发消息、等确认 | 1-2分钟 | 系统 |
核心问题：每个环节都在等人——等客服有空、等主管刷新、等工程师看到通知。而Agent可以做到“不等”。
二、Agent的端到端流程：5步，90秒
我们的Agent把工单流程拆成了5个自动执行的步骤，不需要任何人中途点击或刷新。
用户消息 → Agent接收 → 自动创建工单 → 自动分类 → 自动派单 → 通知工程师
下面逐条拆解。
2.1 自动创建：从“人工填表”到“信息提取”
用户发来消息时，往往是不规范的：“上不去系统了”“密码错误”“APP闪退”。客服以前需要把这些口语翻译成工单字段。
Agent用LLM做信息提取，直接从用户消息中抽取出结构化数据：
| 用户消息 | Agent提取 |
| “我的系统登录不上，一直提示密码错误” | 问题类型=登录问题，现象=密码错误 |
| “订单#12345一直显示处理中，两个小时了” | 问题类型=订单异常，关联订单号=12345 |
| “APP一打开就闪退，手机是iPhone15” | 问题类型=客户端崩溃，设备=iOS |
提取完成后，Agent调用工单系统的创建API，自动填好所有字段。客服全程不参与。
关键设计：如果LLM提取的信息置信度低（比如用户只说“出错了”，没有具体描述），Agent不会瞎猜，而是主动反问：“请问具体是什么问题？登录问题还是功能异常？”收集到足够信息后再创建工单。
2.2 智能分类：规则+模型双保险
工单分类决定了“谁来处理”。分错了，派单就错了，问题会来回转手。
我们用了双层分类：
- 第一层：规则匹配。关键词命中（如“密码”“登录” → 登录问题；“退款”“金额” → 财务问题）。速度快，准确率高，覆盖约60%的工单。
- 第二层：LLM分类。规则匹配不上的，交给LLM判断。LLM输出分类和置信度。置信度低于80%的，不自动派单，标记为“待人工分类”，进入兜底队列。
同时，我们设了一个优先级自动计算规则：
- “紧急”“马上”“不能用了” → 高优先级
- “建议”“后续”“问问” → 低优先级
- 其他 → 普通优先级
客服主管可以自定义这些关键词和阈值。
2.3 自动派单：不是“轮询”，而是“最合适的人”
派单是传统流程里最耗时的环节。主管要查看每个工程师的当前工单数、技能匹配度、是否在休假，然后手动选人。
Agent的派单逻辑基于实时可用性+技能匹配：
def assign_engineer(ticket):
candidates = []
for eng in all_engineers:
if ticket.category not in eng.skills:
continue # 技能不匹配，跳过
if eng.is_on_vacation or eng.is_offline:
continue # 不在线，跳过
# 计算综合得分：技能匹配度 + 当前负载(工单数) + 历史解决速度
score = (
skill_match_score * 0.5 +
(1 - eng.active_tickets / max_load) * 0.3 +
eng.avg_resolution_time_score * 0.2
)
candidates.append((eng, score))
if candidates:
return max(candidates, key=lambda x: x[1])[0]
else:
return None # 无人可派，通知主管
实际运行中，这个算法能把工单派给“会做+不忙+做得快”的人，而不是简单轮询或随机。
派单后的确认：Agent派单后，不是直接“锁死”，而是先发给工程师一条确认消息：“新工单#12345（登录问题）已分配给你，是否接单？”工程师可以点“接单”或“拒绝”。拒绝后，Agent重新派给下一个人。这样既自动化，又保留了人的选择权。
2.4 通知与跟踪：不让工单“沉下去”
工程师接单后，Agent做三件事：
- 在工单系统里更新状态为“处理中”
- 在工程师的IM上推送一条卡片，包含用户信息、问题描述、历史记录
- 设置一个SLA计时器（如普通工单4小时内解决，高优先级2小时内）
如果工单接近SLA时限仍未解决，Agent自动@工程师提醒：“工单#12345剩余30分钟超时，请尽快处理。”如果超时仍未解决，Agent升级通知给主管。
2.5 闭环反馈：解决后自动通知用户
工程师在工单里填写解决方案后，Agent做最后一步：
- 从工单系统读取解决方案
- 生成一条用户友好的回复：“您的问题已解决。解决方案：密码已重置，请使用临时密码登录后修改。”
- 通过原渠道（IM、邮件、短信）发送给用户
- 关闭工单
用户不需要再追问“解决了吗”，客服也不需要再转发消息。整个流程从用户提问到用户收到解决方案，全程由Agent驱动。
三、一个完整的端到端案例
让我们用一个真实工单走一遍流程。
14:00:00 - 用户发消息：“登录不了系统了，一直提示密码错误，我急着提交报告！”
14:00:05 - Agent接收消息，提取信息：
{
"category": "login_issue",
"priority": "high",
"description": "密码错误提示，无法登录",
"urgency_keywords": ["急着"]
}
14:00:08 - Agent创建工单#67890，自动分类“登录问题”，优先级“高”。
14:00:10 - Agent查询工程师列表：
- 小王（擅长登录问题，当前2个工单）→ 得分92
- 小李（擅长登录问题，当前5个工单）→ 得分78
- 小张（不擅长登录问题）→ 跳过
14:00:12 - Agent派单给小王，推送消息：“新工单#67890（高优先级）已分配，请接单。”
14:00:15 - 小王点“接单”，Agent更新工单状态为“处理中”。
14:05:00 - 小王重置用户密码，在工单里填写：“密码已重置，临时密码发送至用户邮箱。”
14:05:10 - Agent读取解决方案，生成回复：“您的问题已解决。密码已重置，临时密码已发送至您的注册邮箱（zhang***@company.com），请登录后修改。”发送给用户。
14:05:15 - Agent关闭工单，记录SLA达标（从创建到解决耗时5分15秒，远低于2小时阈值）。
用户视角：发了一条消息，5分钟后收到“已解决”的通知。中间没有任何等待和追问。
传统流程：用户发消息 → 客服等有空才处理（假设10分钟）→ 客服创建工单（5分钟）→ 主管等轮询（假设30分钟）→ 主管派单（2分钟）→ 工程师处理（10分钟）→ 客服通知用户（2分钟）。总计约59分钟。
Agent提升：从59分钟压缩到5分钟，效率提升12倍。
四、三个必须避开的坑
坑1：自动派单派给了“最闲但不合适”的人
早期算法只看了“当前工单数”，结果把复杂的数据库问题派给了最闲的前端工程师。他接单后发现不会修，只能拒单，工单重新排队。
解决：派单算法加入技能匹配权重（占50%以上）。工程师的技能标签由主管维护，每周更新一次。同时记录历史派单数据，如果某个工程师连续拒单同一类问题，算法自动降低该类问题的匹配分数。
坑2：用户一句话创建了多个重复工单
用户连续发了三条消息：“登录不上”“还是不行”“有人吗”。Agent每条都创建了工单，结果同一个问题产生了3个工单。
解决：会话去重机制。同一用户、同一会话（5分钟内），如果已有“处理中”的同类工单，新消息不再创建新工单，而是追加到原工单的描述里。
坑3：LLM分类把“投诉”误判为“功能咨询”
用户说“你们的APP太难用了”，本意是投诉，但LLM分类成了“功能咨询”，派给了产品组而不是客服主管。
解决：引入情感分析作为分类的辅助特征。负面情感强烈的消息（如包含“差评”“垃圾”“投诉”），强制归入“投诉”类别，派给专人处理。
五、你也可以从两个能力开始
如果你现在就想做智能工单，不需要一步到位。从最痛的两个能力开始：
- 自动创建+自动分类：只做“从用户消息到工单系统”，不做自动派单。工单创建后仍由主管手动指派。这一步能省掉客服的手工填单时间（3-5分钟/单）。
- 自动派单：等分类准确率稳定在90%以上后，再加自动派单。一开始只派低优先级工单，高优先级的仍走人工审核，逐步建立信任。
每加一个能力，先观察一周的准确率。如果派错率超过5%，就别全自动，先做半自动（Agent建议派给谁，人点确认）。
写在最后：工单的终点不是“已解决”，是“用户满意”
智能工单Agent上线三个月后，客服主管告诉我一组数据：
- 平均响应时间（用户发消息到工程师接单）：从47分钟降到2分30秒
- 用户满意度评分：从4.2分提升到4.8分（满分5分）
- 客服团队每天用于“填单、跟单”的时间：从4小时降到30分钟
最让我意外的是工程师的反馈。他们说：“以前每天要刷好几次工单池，看看有没有分给我的。现在不用刷了，Agent会直接告诉我。我只需要专心解决问题。”
智能工单的本质，不是让客服失业，而是让所有人回到自己最擅长的位置上：客服去理解用户的情绪，工程师去解决技术难题，主管去优化流程和团队能力。而填单、分类、派单、通知这些“跑腿活”，统统交给Agent。
下次你的客服团队又在手动复制粘贴用户信息时，不妨问问他们：想不想让一个Agent替你们跑腿？
答案大概率是：想。
