从ITIL服务配置管理，看AI Agent为什么离不开配置数

1. 大模型知道世界，却不知道你的企业---ITIL服务配置管理

过去一年，AI和AI Agent几乎成为数智化领域热门的话题。有人希望它用于智能客服，有人希望它协助运维，还有人希望它像一名数字员工一样，参与分析、判断和执行。随着越来越多企业开始尝试，这些设想正在逐步接近现实。

但是真正在学习AI、使用AI的过程中会逐渐发现，大模型确实很聪明。它知道Linux命令，也知道MySQL原理；能够解释Kubernetes架构，也能够分析一段复杂的程序代码。

但AI真的进入实际的生产环境或业务流程的时候，它却很快暴露出另一个问题：它知道整个世界，却不知道你的企业。这也是很多AI项目进入企业生产环境后，迟迟无法从“回答问题”走向“参与工作”的重要原因之一。

举个运维场景：凌晨两点，监控平台发出一条告jing：服务器CPU持续95%。对于today的大模型来说，它完全可以分析CPU过高可能有哪些原因，也可以给出几十种排查建议。

但它不知道：这台服务器属于哪个业务系统？这个系统支撑哪些客户和业务？它依赖哪些数据库和中间件？如果现在重启，会不会影响正在进行的交易？

如果现在重启，会不会影响正在进行的交易？这些信息，并不存在于公开互联网。它们属于企业自己的数字化知识。

也正因为如此，大模型再聪明，没有这些信息，它也只能回答“可能是什么问题”，却无法真正参与组织的运行。

2. 知识库解决“怎么做”，CMDB回答“面对什么”---ITIL服务配置管理

很多人把这个问题归结为知识库建设。我的观点，并不完全如此。很多运维团队先不谈知识库的建设情况和知识的积累能力，就单单知识库，它只能解决“知道怎么做”的问题。传统知识库更擅长沉淀历史经验、操作方法和解决方案，却不擅长持续反映系统当前的运行状态及其动态依赖关系。

而上述场景要让AI理解系统当前所处的环境，only靠知识库还不够，还需要监控、日志、链路数据以及CMDB提供的配置关系。其中，CMDB承担的是描述系统结构、归属关系和依赖关系的重要作用。

所以在谈论AI落地的过程中，我听到讨论的尤其多的是模型能力、推理能力、RAG、MCP，却很少有人讨论另外一个问题：组织内部的AI到底依赖什么数据才能真正工作？如果一个AI Agent准备帮助运维团队处理故障，它至少需要知道：

• 这台服务器属于哪个应用？

• 这个应用依赖哪些中间件？

• 数据库部署在哪里？

• 哪些业务正在使用它？

• 哪些系统会受到影响？

• 哪些负责人需要通知？

这些都不是AI模型能够推理出来的。它们来自企业长期积累的配置管理能力。用更专业一点的AI领域的话术来说，大模型需要的不只是通用知识，还需要理解本组织系统、业务和资源关系的上下文。只有把这些上下文与组织积累的Know-how结合起来，AI才能真正适配企业环境。

3. CMDB管理的不是台账，而是数字世界的关系---ITIL服务配置管理

谈到配置管理，很多客户的di1反应并不积极。他们认为CMDB维护成本高、管理难度大、实际应用有限，甚至觉得这是一项“食之无味、弃之可惜”的工作。觉得它就是：建个CMDB然后录入资产，再然后就是去维护一大堆配置项。

为什么鲜有CMDB项目是真正成功的？我说的真正的成功是能支持运维团队做故障定位、根因分析、变更风险评估。更多的时候只是一个配置项的台账，甚至一段时间疏于维护，last都不了了之。

究其原因无非就是管理维护成本高、数据更新慢，实际操作部门感觉不到价值，甚至不少客户就把CMDB称为“电子资产台账”。

但如果站在AI发展的角度重新审视，就会发现：配置管理的价值，从来不只是记录和维护配置项，更重要的是管理配置项之间的关系及其所构成的数字化上下文。

4. 没有可信上下文，AI只能给出通用答案---ITIL服务配置管理

我习惯把配置项拓扑图比作企业信息系统的“人体解剖图”，而CMDB则是承载这张图谱的重要数据基础。通过配置管理系统（CMDB），能够了解业务系统是由哪些组件构成的，它们之间的关联关系是什么，哪个组件出了问题会导致其他的组件也无法正常工作。所有这些关系组合在一起，才构成了一张完整的业务系统脉络图，而AI需要的，恰恰就是这张脉络图。

如果说过去的CMDB比较大的服务对象是人。例如运维工程师通过它分析故障影响；那么AI作为数字员工的today，CMDB开始服务另一类新的使用者——AI Agent及其背后的智能运维应用。

举一个很简单的例子：如果没有配置数据，AI收到一条“数据库连接失败”的告警，它顶多只能告诉你：检查网络，检查数据库，检查连接池。

但如果接入了配置数据，它就能够继续推理：这是支付系统的数据库，支付系统关联网上银行；当前有两项he心交易正在运行，因此应优先通知支付团队，并评估是否需要暂停相关批量任务；由于近期三天未实施数据库变更，可以优先排查连接池和资源使用情况。

同样是一条告警。因为拥有了配置关系，AI给出的已经不再只是通用技术建议，而是结合业务影响形成的处置判断和决策支持。

所以如果运维团队要真正地引入AI的能力，让AI真正地赋能实际的生产环境，配置管理就成为AI在运维领域应用的重要基础能力。

切记AI不会主动理解你的系统，它只能理解你提供给它的数据。如果配置数据本身错误或过时，即使AI掌握大量知识文档，也很难稳定地形成可靠判断。

如果系统之间的依赖关系没有维护，AI就无法准确分析影响范围。如果CMDB长期无人维护，那么你让AI分析的是一套过时的系统结构。这就像医生只拿到几年前的检查报告，却要判断患者today的病情，结论很难可靠。

所以我个人越来越觉得：AI时代真正需要关注的，已经不是模型，而是组织背后的数据，而且是动态的数据。而配置管理的实践能力，本质上是组织持续维护数字化上下文的重要能力。

所以我们对ITIL配置管理的实践也要有新的理解，即如何基于现有的CMDB做到持续维护、持续验证、持续提供可信的数据。

当前真正重要的，不是CMDB里面有多少条配置项，而是这些配置数据是否能够支撑事件管理、是否能够支撑问题分析、是否能够支撑变更评估、是否能够支撑AI进行正确判断。配置管理已经从“记录数据”，逐渐演变为“维护数字化上下文”。

5. AI不会淘汰ITIL，反而会重新ji活它---ITIL服务配置管理

Recently在交流ITIL时，大家经常讨论一个问题：AI时代，ITIL会不会被替代？我的答案恰恰相反。AI的发展并没有削弱ITIL的价值，反而让一些过去容易被忽视的管理实践重新变得重要。

因为AI越智能，就越依赖高质量的数据；AI参与的业务越复杂，就越需要清晰的系统关系；AI承担的职责越多，就越需要可信的数字化基础。

从这个角度看，AI Agent finally又把企业带回了一个并不陌生的话题：数据治理。过去我们更多关注数据是否完整、准确和一致，today还需要进一步关注数据能否持续描述企业真实、动态的运行环境。

只是过去我们更多关注数据是否完整、准确和一致，today还需要进一步关注数据能否持续描述企业真实、动态的运行环境。未来，真正有竞争力的企业，未必是earliest部署AI的企业，而是earliest建立数字化上下文管理能力的企业。

数字安全 关注安言