甄知科技助力制造行业：突破数字化转型困局
2025.09.29
了解详情 >
大模型进入ITSM的第一重价值，是让系统理解自然语言描述的服务问题；接下来的价值，是让具备工具调用能力的智能体在理解的基础上执行任务。
理解是前提，执行是延伸，两者构成一条连续的技术路径。
ITSM的输入问题
传统ITSM的运转依赖两个前提：
结构化输入
预定义规则
工单分类、流程流转的预设条件，派单规则……一套传统ITSM的机制处理标准请求，其适用范围止于"输入本身是规范的"。
但实际的IT服务请求大多不是这样。
用户通过IM、邮件、电话、截图提交的问题，描述方式完全不受控制。
例如：用户说"系统卡住了"，服务台需要人工判断这是网络问题、应用故障还是账号异常，再选择分类、设定优先级、指派处理人。
分类错误会导致工单反复流转，优先级判断依赖个人经验，多业务线并行时，这类环节会成流程瓶颈。
规则引擎同样解决不了这个问题，传统ITSM中，用户描述与系统字段之间需要人工转换，这也是企业ITSM难以突破高效率的主要原因之一。
ITSM的输入问题
大模型带来的变化，首先发生在输入环节。具体来说，是三类NLP能力在工单链路上的组合应用。
意图识别
判断用户表达对应哪类服务请求。比如"登录之后一直转圈"被识别为账号认证类问题，"报销单打印不出来"被识别为设备或打印服务故障。这一步替代了人工选择服务目录的动作。
信息抽取
从描述中提取工单需要的结构化字段：受影响的系统、地点、时间、报错内容、业务影响。
抽取结果直接填充工单，关键字段缺失时，系统向用户追问补齐，而不是依赖服务台逐项询问。
语义匹配
基于向量相似度，在历史工单和知识库中检索相似案例，为分派和解决方案推荐提供依据。
相比关键词搜索，语义匹配能关联表述不同但实质相同的问题，比如"邮箱满了"和"邮件发不出去，提示容量超限"。
这三步完成后，一句非结构化的描述变成一张字段完整、分类明确、附有参考案例的工单。
断质量取决于两个条件：模型的语言能力，以及企业私域数据的质量（如历史工单的分类是否规范、知识库是否与实际环境一致）。
智能理解改变的仅是工单的生成方式，工单生成之后，分类确认、派单、诊断、解决仍然依赖人工。这构成了向下一阶段向智能体（Agent）演进的直接动因。
从理解到执行
理解解决的是"问题是什么"，接下来的问题是"谁来处理、怎么处理"。这个环节的技术方案逐渐集中到智能体（Agent）架构上。
智能体与对话式AI的区别在于运行方式：
对话式AI以"提问—回答"为单位，产出是文本建议；
智能体以"目标—行动—结果"为单位，围绕一个任务目标做规划，调用外部工具，根据返回结果决定下一步，直到任务完成或触发转人工条件。
支撑这种运行方式的是几项具体技术：
Function Calling/Tool-use
模型输出结构化的工具调用指令，由外部系统执行。查询CMDB、检索知识库、创建工单、执行运维脚本，都通过API调用完成。
RAG（检索增强生成）
让模型基于企业私域知识做回答和判断，而不是仅依赖训练时的参数化记忆，降低幻觉风险。
记忆与状态管理
跨会话保存任务上下文和执行状态，支持多步骤任务的连续执行。
把智能理解放进这条链路：NLU完成意图识别和信息抽取，是智能体规划步骤的输入。
一次完整的处理过程大致是：
用户描述→理解层生成结构化工单→智能体根据工单内容规划处理步骤（查知识库、查配置关系、执行诊断）→依次调用工具并检查结果→在授权范围内执行修复动作或输出建议→处理记录沉淀回知识库。
落在ITSM场景
从企业实践看，智能体进入ITSM通常从风险可控、边界明确的场景开始。
服务入口
终端用户以自然语言提出诉求，智能体完成意图识别后，一部分请求直接命中知识库或自动化服务，在前端解决；需要人工的部分自动生成工单并完成分派。
账号与权限管理
入职、转岗、离职触发的人事事件，智能体按岗位规则识别需要开通或回收的权限，发起审批，在多个系统中执行，完成后核验结果，减少漏配和权限残留。
低风险故障处置
告警发生后，智能体关联近期变更、系统依赖和监控指标，先收集证据再给出判断；清理缓存、重启无状态实例等低风险动作，可以按预设条件执行并验证恢复结果。
处理辅助
面向二线人员，智能体从历史工单和知识库中提取相关信息，以对话方式辅助根因分析，缩短平均处理时长；问题解决后提取有效步骤，经审核写入知识库。
这些场景对应的组织变化是：ITSM从"人与人之间的工单通信"变为"智能体参与的双边协作"——
一端是面向提单用户的自助处理，一端是面向处理人员的诊断辅助。
工单不再是协作的唯一载体，处理过程中的信息往来同样被结构化地记录下来。
智能理解所需的私域数据治理，恰好也是智能体落地的前置条件。这是两个阶段真正的连接点：管理工单、知识和处理记录，再向智能体演进。
