从0到1搭建一个自动处理工单的AI智能体：完整实战记录

我们团队有一个让人头疼的活儿：每天要处理30-50张来自业务部门的IT支持工单，其中六成是重复性问题——"密码忘了"、"VPN连不上"、"打印机没反应"、"某个系统登录报错"。为了处理这些工单，我们两个运维同事每天要花一半以上的时间。上个月，我搭了一个AI智能体，把重复工单的自动化处理率做到了65%，两个运维终于有时间去处理真正复杂的故障了。

一、先想清楚：智能体到底要做什么

动手之前，我先明确了这个智能体的边界：

• 输入：工单系统的Webhook推送（标题+描述+提交人）；
• 判断：识别工单属于哪一类问题、严重程度如何；
• 处理：能查知识库给出标准解决方案；能调API重置密码、查账号状态；
• 转人工：AI判断不了或处理失败时，自动转给值班工程师并在工单里附上AI的分析结论。

边界划清楚很重要——如果一开始就想让智能体"什么都干"，最后大概率什么都干不好。

二、技术选型

我对比了几套方案：

考虑到工单处理是典型的多步骤、有分支、可能出错要重试的流程，我最终选了 LangGraph，搭配 Qwen2.5-7B（通过vLLM部署在内部一台T4显卡的服务器上）做判断和生成。

三、核心流程设计

智能体的处理流程用LangGraph实现，核心节点如下：

from langgraph.graph import StateGraph, END

# 1. 分类节点：判断工单类型和紧急度
# 2. 检索节点：从知识库(向量库)检索解决方案
# 3. 工具节点：按需调用内部API(重置密码/查账号/查网络)
# 4. 生成节点：生成回复内容并回填工单
# 5. 兜底节点：处理失败则标记转人工

graph = StateGraph(WorkOrderState)
graph.add_node("classify", classify_workorder)
graph.add_node("retrieve", retrieve_solution)
graph.add_node("call_tool", call_internal_api)
graph.add_node("generate", generate_reply)
graph.add_node("escalate", escalate_to_human)

关键设计是工具调用的权限控制：智能体只能调用白名单里的API（重置密码、查询账号状态、查询工单状态），凡是涉及删除数据、修改权限的高危操作，一律强制转人工。这一步绝对不能省——AI再聪明，也不能给它越权的工具。

四、让判断"稳"起来的三个细节

这类智能体最容易翻车的地方不在流程，而在判断质量。我踩了几个坑后总结出三点：

1. 分类用"少样本+约束输出"。最开始让模型自由写分类，结果一个工单被分成好几种类型。改成让模型从预定义的10个类别里选，并要求输出JSON格式，准确率从82%提到了95%。
2. 知识库答案要"引用出处"。模型答非所问时，往往是因为检索到的内容不相关。我要求生成节点必须附带引用的知识库文档ID，这样我可以随时抽查答案质量，发现检索不准就调整向量切分策略。
3. 设置重试与降级。模型调用超时或返回异常时，自动重试一次；仍然失败就走兜底转人工，绝不静默吞掉工单。

五、效果与反思

上线两周的数据：

• 工单自动处理率：65%（目标50%，超出预期）；
• 平均响应时间：从35分钟降到1分钟以内（AI秒回标准解决方案）；
• 人工转接率：35%，其中AI判断错误的比例约8%，其余是规则上就该人工处理的工单；
• 用户满意度：AI回复+知识库链接的工单，满意度评分比纯人工处理还高一点。

当然也有反思：最开始我把期望定得太高，总想让智能体"聪明"地解决一切问题，结果反而一堆工单在AI那里绕圈子。后来想明白了——智能体的价值在于把重复劳动标准化，而不是取代人的判断。把65%的标准问题快速处理掉，让人的精力聚焦在那35%真正需要思考的问题上，这才是智能体的正确打开方式。

如果你也在做内部工单、客服、IT支持类的智能化改造，建议从"高频重复+流程标准"的场景切入，先把小闭环跑通，再逐步扩展能力边界。