很多企业在引入AI改造ITSM时，往往会陷入一个怪圈：投入越深入，越早发现AI在现有体系中“水土不服”。
过去两年，几乎所有中大型企业的IT部门都在尝试同一方向：
ITSM + AI
蓝图描绘得总是很美好：
- 智能客服自动解答用户问题
- Copilot辅助工程师处理工单
- 自动生成处理建议、自动填写表单
- 实现自动决策、审批与闭环
然而，经过半年或一年的实践后，现实却异常一致：
- 智能客服使用率极低，最终退回人工通道
- Copilot大多只停留在“查看”建议，不敢让其“动手”操作
- 遇到真正复杂的问题，AI一律转交人工
- 工单总量未降，反而因引入AI增加了运营成本
于是，问题常被简单归结为一句话：“现在的AI技术还不够成熟。”
但如果你曾深入参与ITSM的架构设计、流程规划与系统建设，就会明白一个更深层的原因：问题往往不在于模型本身的能力，而在于传统ITSM的系统形态，从设计之初就与AI的运作模式存在根本性冲突。
本文将从系统结构的角度，剖析一个可能令人不适却至关重要的现实：绝大多数现有的ITSM系统，因其固有设计，注定难以真正融合AI。
一、现实困境：企业“ITSM+AI”实践为何集体失效
1. “ITSM + AI”的业务驱动力
从企业管理层的视角看，引入AI的动机非常明确：
- 人力资源成本持续攀升
- 运维环境复杂度指数级增长
- 系统与服务的数量爆炸
- IT部门面临巨大的“降本增效”与“稳定运营”压力
ITSM作为企业IT运营的“中枢神经系统”，自然成为AI落地改造的首选战场。因此，我们看到了大量相似的实践场景：
- 在工单系统中接入大语言模型
- 构建FAQ知识库+向量检索+智能客服
- 部署工单Copilot，用于自动总结、提供建议
- 实现工单的自动分类、分派与升级
从技术演进趋势来看，这一切似乎顺理成章。
2. 上线半年后的真实数据
然而，观察系统上线半年后的实际运营数据，结论往往令人冷静：
- 智能客服的准确命中率普遍低于30%
- 用户遇到问题时，仍倾向于选择“直接转人工”
- Copilot仅在新手工程师中有零星使用
- 高级工程师几乎从不依赖AI建议
- 真正的自动化处理比例极低
更关键的一点在于：系统负责人内心非常清楚，不能赋予AI真正的“执行权限”。
在现有框架下，AI通常被允许：
但绝不允许：
- 执行实际的配置变更
- 发起关键的操作指令
- 替代最终的人工决策
于是，AI被置于一个极其尴尬的定位：
“看似智能，实则永远只是一个旁观者。”
二、根源剖析：问题不在于AI模型的能力
1. 是AI能力不足吗？
首先必须澄清这一点。如果将AI置于非ITSM的其他技术领域，其表现截然不同：
- AI能够编写复杂的业务代码
- AI可以协助调试系统问题
- AI能够理解技术上下文并进行推理
- AI具备任务规划与分解的能力
在许多研发、数据分析及运维工具链中，AI已经展现了显著的实用价值。那么，为何一旦进入ITSM领域，AI就显得“集体失灵”？
2. 核心矛盾：智能与结构的冲突
问题的症结不在于：
- 模型参数规模不够大
- 逻辑推理能力不够强
- 训练数据不够丰富
而在于：传统ITSM的系统结构，是为“以人为中心的流程”而设计的，并非为“智能体自主执行”而构建。
换言之，AI不应仅仅被视作一个“功能插件”，它本质上代表了一种全新的系统参与者形态。然而，ITSM系统的底层设计假设，从未将这类参与者纳入考量。
三、ITSM的三大结构前提：AI的“天然屏障”
几乎所有的传统ITSM系统，都建立在三个核心前提之上：
- 流程是核心
- 表单是载体
- 人是执行节点
这三点在人力主导的时代完全合理，但在AI驱动时代，却构成了最大的障碍。
（一）流程中心主义：AI被迫遵循“人为预设路径”
传统ITSM的核心是流程引擎，其典型特征包括：
- 预先定义：所有路径在事前规划完毕
- 路径固定：状态迁移路线相对僵化
- 状态驱动：动作触发依赖于特定状态
- 强约束：流程规则不可轻易逾越
例如标准的工单流程：创建 → 分类 → 分派 → 处理 → 验证 → 关闭。每一步都有明确的状态和指定的责任人。
但关键在于：AI并非以“离散状态迁移”的模式进行思考。
AI更擅长的是：
- 理解多维度的上下文信息
- 推理当前的实际情况与局势
- 动态选择最合适的行动
- 根据执行结果灵活调整后续步骤
而非机械地：等待状态A变更后，才能进入状态B。
当你强行将AI嵌入到一个固定的流程节点中，实质上是在要求它：“放弃自主判断，严格按照人类绘制好的路线图行进。” 这直接导致两个后果：AI能力被严重束缚，无法发挥其真正的价值。
（二）表单驱动：字段化思维限制了AI的理解维度
ITSM的第二个核心前提是表单即事实。在系统中：
- 问题描述 → 填写在特定字段
- 影响范围 → 从下拉框中选择
- 优先级 → 设定为枚举值
- 处理结果 → 勾选固定选项
这套设计本质上是为了：便于对“人”进行管理、审计和统计分析。
然而，AI并不通过“离散字段”来理解世界。它更擅长处理：
- 非结构化的自然语言语义
- 信息之间隐含的关联关系
- 连续的历史上下文
- 融合来自监控、日志、拓扑等多源的信息
当你要求AI“必须先填完表单，才能开始行动”，无异于在说：“你必须先将复杂的现实世界压缩成几个有限的字段，然后才能进行思考。” 其结果必然是：AI的判断被过度简化，决策空间被人为阉割，最终只能给出笼统且泛泛的建议。
（三）人工节点假设：系统性地将AI定义为“辅助角色”
几乎所有的ITSM流程都默认一个前提：关键节点必须由人掌控。 审批是人、决策是人、最终确认也是人。从合规与风险控制的角度看，这完全合理。
但这带来了系统性的后果：
- AI永远无法成为“责任主体”
- AI永远无法独立完成处理闭环
- AI永远难以获得充分的信任
于是，我们会看到一个典型场景：AI给出了一个非常合理的处理方案，但系统依然弹出提示：“请等待人工确认”。
长此以往，工程师的心理会演变为：“反正最终决定权在我，我何必多此一举参考AI的意见？”
四、AI与ITSM的深层结构性不兼容
如果将AI仅视为一个“高级建议者”，问题或许不明显。但若真正将AI当作：一个能够理解环境、做出判断并采取行动的自主系统参与者，那么ITSM的结构性冲突便会彻底暴露。
1. AI理解“局势”，而非“流程状态”
流程状态（如“待处理”、“处理中”、“已解决”）是人为设计的抽象概念。而AI真正关心的是：
- 系统当前是否存在异常
- 依赖的服务是否受到影响
- 业务风险是否在持续扩大
- 当下采取哪个动作价值最高
让AI去“等待流程状态变更”，等同于让它：放弃基于实时信息的判断，去服从人为设定的节奏。
2. AI依赖“上下文”，而非“字段”
表单字段是离散且静态的，而AI的判断需要连续且动态的输入。ITSM试图用“工单类型”、“影响等级”、“优先级”等有限字段来描述一个复杂系统的状态。而AI更希望获取的是：实时日志、性能指标、系统拓扑图、历史事件链等丰富上下文。这两种认知世界的方式，本质上是互不兼容的。
3. AI需要“行动权”，而非“建议框”
最致命的一点在于：AI的核心价值在于执行行动，而不仅仅在于语言输出。 但传统ITSM留给AI的空间，往往仅限于：
- 提供一段文本建议
- 生成一份事件总结
- 推荐一个处理方案
却拒绝赋予它：
- 调用执行接口的权限
- 操作失败后的回滚能力
- 行动结果的直接反馈通道
- 清晰的责任与权限边界
这并非出于“审慎”，而是因为：系统从结构设计上就拒绝了AI成为平等的参与者。
五、出路探索：AI需要的是“能力单元”，而非“流程节点”
读到此处，结论已然清晰：问题的关键不在于ITSM没有接入AI，而在于传统ITSM从来就不是为AI设计的。
AI真正需要的不是：
- 在既有流程中新增一个AI节点
- 在表单上增加几个AI专用字段
- 在界面上多放置一个Copilot按钮
而是需要一个以 “能力”为中心的全新系统结构，这涉及到运维系统范式的根本性转变。
什么是“能力单元”？
能力单元不是具体的人，也不是流程中的一个步骤，而是：
- 可独立调用的标准化功能模块
- 具备明确的输入与输出定义
- 能够被灵活组合以完成复杂任务
- 其效果与性能可被量化评估
- 其执行可被安全授权与审计
例如：
- 诊断能力：自动分析日志定位根因
- 分析能力：评估变更风险与影响范围
- 变更执行能力：安全地进行配置下发或服务重启
- 回滚能力：在出现问题后快速恢复
- 风险评估能力：预测操作可能带来的业务影响
AI天生就适合调度和操作这类标准化、原子化的“能力单元”。
这意味着什么？
这意味着未来的智能运维系统，其设计范式将发生转变：
- 流程不再是绝对中心，它只是众多业务约束中的一种。
- 表单不再是唯一入口，它只是众多数据来源的一部分。
- 人不再是唯一执行者，其角色将更多转向监督、审核与策略制定。
这绝非简单的“ITSM系统升级”，而是一场深刻的 运维系统范式的转变。
写在最后
如果你所在的企业正在推进“ITSM + AI”项目，不妨思考一个更本质的问题：我们究竟是在给旧的ITSM系统打上AI补丁，还是在为AI重构一套全新的智能运维体系？
这两者看似只有几字之差，但其背后的系统设计理念、组织认知模型与技术实现路径，却有着天壤之别。
这也将最终决定，你的ITSM是仅仅“看起来有点智能”，还是能够“真正迈入智能运维的新时代”。
发表于 前天 02:28
|
查看: 10|
回复: 0
