用ITIL 5的6C模型管理AI智能体：能力越强，授权边界越要清楚

在深圳艾拓先锋最近一期ITIL Foundation（Version 5）课程中，我做过一次服务器诊断演示。

上课过程中，我让AI智能体连接一台服务器，检查系统负载、磁盘空间、SSL证书、数据库配置、访问超时以及异常流量等问题。任务提交以后，我继续讲课，智能体在后台收集信息、分析日志和整理结果。

过一段时间，我切回界面查看，它已经输出了一份诊断清单，并对不同问题进行了说明。

这种体验很像多了一名数字员工。

它不需要坐在教室里听讲，也不会因为我暂时离开界面而停止工作。只要获得工具、数据和权限，它就可以持续执行任务。

但智能体越能干，问题就越不能只停留在“它能做什么”。

还必须回答：

它被允许做什么？

它不能做什么？

它在什么条件下必须停下来询问人？

它执行过哪些动作？

发生错误后能否追溯和回退？

我曾经用“力大无穷的绿巨人”来形容这种状态。比喻虽然轻松，背后的治理问题却非常严肃：力量越大，规则和边界越重要。

6C不是六种工具，而是六个能力层次

ITIL 5把AI能力概括为6C模型：

Creation、Curation、Clarification、Cognition、Communication和Coordination。

按照中文语境，可以理解为创造或生成、整理或策展、澄清、认知、沟通与协调。

PeopleCert的AI治理资料使用这六类能力来识别AI可以承担的工作，并把不同能力与决策权限、伦理、数据、性能、合规和运营风险联系起来。(PeopleCert Community)(PeopleCert Community)织购买六套产品，也不是给模型能力排一个绝对高低顺序。

它更像一套分析语言。

面对一个AI场景，管理者可以逐层判断：智能体究竟只是在生成内容，还是已经开始解释信息、形成判断、与系统交互，甚至调度其他智能体？

能力层次不同，治理要求自然不同。

Creation：能够生成，不代表可以直接采用

Creation是最容易被感知的AI能力。

生成报告、代码、会议纪要、工单摘要、变更说明、测试用例、知识文章和回复草稿，都属于这一类。

服务器诊断完成后，智能体可以根据日志和执行结果生成一份报告，包括问题列表、风险等级、处理动作和前后对比。

生成能力提高了信息生产效率，但它也容易制造一种错觉：只要文字完整、结构清楚，看起来就像已经经过验证。

实际上，生成结果可能存在遗漏、误解或不准确内容。

因此，Creation场景首先需要明确内容用途。

用于内部草稿、头脑风暴或格式转换时，风险通常较低。

用于生产变更、客户承诺、合规报告或关键决策时，就需要更严格的数据校验、来源追溯和人工复核。

治理重点不是禁止生成，而是区分“可供参考的草稿”和“可以正式采用的结果”。

Curation：AI整理的内容是否保留了出处

Curation是从多个来源中选择、汇集、去重、排序、分类和组织信息。

在事件处理中，智能体可能同时读取：

监控告警。

应用日志。

操作系统日志。

工单历史。

CMDB关系。

知识库文章。

历史变更。

供应商公告。

它把这些信息整理成一个事件上下文，让工程师不必在多个系统之间反复切换。

这类能力看似只是整理，实际上已经包含选择。

智能体决定哪些信息进入结果，哪些内容被忽略，哪些记录被认为重复。选择规则不透明时，重要证据可能被排除。

因此，Curation需要保留来源和筛选逻辑。

工程师不仅要看到“智能体整理出了什么”，还应当能够返回原始日志、工单或文档，判断整理过程是否合理。

对于关键任务，摘要不能取代原始证据。

Clarification：澄清不是替人编造缺失条件

Clarification处理的是模糊、冲突或缺失的信息。

用户说“系统很慢”，这个描述并不足以支持诊断。智能体可以继续询问：哪个系统？从什么时候开始？所有人都慢还是个别用户？页面打开慢还是提交交易慢？是否出现错误信息？

在变更场景中，智能体也可以检查申请内容是否完整：

影响对象是否明确？

实施窗口是否填写？

验证方案是否存在？

回退条件是否清楚？

关联配置项是否准确？

Clarification的价值，是在行动之前减少歧义。

它的风险，则是智能体可能为了让任务继续，擅自补齐一个“看起来合理”的条件。

例如，申请人没有提供回退时间，AI不应自行假设为十分钟；故障范围不明确时，也不应直接认定只影响单一用户。

真正安全的澄清机制，应当把未知项显式暴露出来，并在关键条件缺失时暂停，而不是用生成能力填补事实空白。

Cognition：从解释信息走向形成判断

Cognition涉及识别模式、理解关系、评估影响和形成判断。

服务器诊断中，智能体看到磁盘使用率较高，不只是复述一个百分比，还可能判断：

日志增长速度是否异常？

剩余空间能够支撑多久？

磁盘告警是否与数据库超时有关？

清理哪些目录风险较低？

扩容是否会影响现有服务？

当AI开始形成判断，它就进入了更高风险区域。

因为判断往往会影响后续行动。

对于低风险、可重复、证据明确的场景，智能体可以给出自动分类和优先级建议。例如，根据历史记录识别常见事件，推荐知识文章，或者判断一条告警是否属于已知噪声。

对于影响生产、安全、财务和客户的场景，判断结果应当附带依据、置信程度和不确定项，并由具备责任的人员确认。

不能因为AI使用了大量日志，就默认它比现场人员更了解业务影响。

Communication：AI说出的话代表谁

Communication不仅是和用户聊天。

智能体可能向工程师发送告警，向审批人催办变更，向用户确认故障是否恢复，向供应商提交支持请求，也可能通过API向其他系统传递指令。

一旦AI开始代表组织对外沟通，就会产生身份和责任问题。

它是否清楚表明自己是AI？

它能否作出时间承诺？

它能否确认赔偿、费用或合同内容？

它向用户发送的信息是否经过批准？

用户要求转人工时，能否顺利升级？

在服务台场景中，AI可以完成低风险、标准化的信息沟通，例如收集故障现象、查询工单状态、提供经过审核的知识内容。

但涉及重大事件、敏感投诉、服务承诺和法律责任时，应当及时交给人类角色。

沟通自动化不能只追求减少人工接触，还要保护信任与体验。

Coordination：一个智能体开始调度更多智能体

Coordination是最容易放大能力，也最容易放大风险的一层。

一个主智能体可能把任务拆给多个子智能体：

一个读取监控。

一个分析日志。

一个检查配置。

一个搜索知识库。

一个查询历史变更。

一个生成处置计划。

主智能体汇总结果，确定下一步动作，必要时再调用自动化工具执行。

这种架构可以显著提高复杂任务的并行程度，但也会带来新的治理问题。

哪个智能体拥有最终决策权？

子智能体之间出现冲突时如何处理？

一个错误判断会不会被其他智能体继续放大？

调用链是否完整记录？

任务失败时，系统停在哪里？

人类能否随时中断？

如果主智能体可以直接调度生产工具，那么它实际上已经拥有接近运维控制面的能力。此时，权限设计不能只看“用户登录了什么账号”，还要看智能体代表用户获得了哪些工具权限，以及权限是否随着任务结束而回收。

服务器诊断中，我为什么没有让AI全部修复

在课堂演示里，智能体识别出证书配置、磁盘容量、数据库参数和异常流量等多个问题，并给出了处理方向。

我没有给出“全部修复”的指令。

第一步是要求它区分风险。

哪些操作只涉及读取和分析？

哪些属于可逆、低影响的调整？

哪些会重启服务、修改网络策略或改变数据库行为？

哪些可能造成业务中断？

随后，我只授权执行明确范围内的中低风险动作。对于可能影响生产连续性或缺少充分验证的操作，保持不执行状态。

这不是因为AI能力不足，而是因为授权责任不能含糊。

“帮我优化一下服务器”是一条危险的指令。

优化的范围是什么？是否允许删除文件？是否允许重启服务？是否允许修改防火墙？是否允许安装软件？是否允许变更数据库参数？

人类听到这句话，也需要进一步确认。AI更不应该把模糊目标自动解释为无限权限。

人机协作会压缩流程界面，但不会消除控制要求

传统变更管理经常表现为一张变更单：

填写原因、影响、风险、实施步骤、验证计划和回退方案，然后经过评估、授权、实施和回顾。

在智能体场景中，这些活动可能被压缩进一次连续对话。

AI读取数据并完成诊断。

AI生成变更计划和风险分析。

人类确认授权范围。

AI调用工具执行。

AI验证结果并生成记录。

界面变得更紧凑，部分文档由AI自动形成，但关键控制要求仍然存在：

决策是谁作出的？

依据是什么？

执行了哪些命令？

执行前后的状态怎样？

出现问题如何回退？

谁对结果负责？

流程可以更轻，但不能失去证据。

自动化可以更快，但不能失去边界。

CMDB和知识库为什么在AI时代更重要

智能体的判断质量不仅取决于模型，也取决于组织能够提供什么上下文。

AI发现一台服务器磁盘空间不足，但如果不知道这台服务器支持哪些业务、当前是否处于关键结算期，就无法准确判断操作风险。

AI看到一个端口开放，却不知道它与哪个应用、供应商和数据流相关，也无法判断是否应该关闭。

这些关系需要配置管理提供。

同样，通用模型可能知道某个数据库参数的一般含义，却不知道本组织使用的版本、架构、历史故障和操作规范。

这些内容需要知识管理提供。

高质量CMDB、服务模型、SOP、已知错误和复盘记录，是AI从“懂一般技术”走向“理解本组织环境”的基础。

如果组织自己的知识长期缺失，智能体只能依赖通用信息。它的回答可能听起来专业，却未必适合当前环境。

分层授权比一句“谨慎使用AI”更有效

AI治理不应只停留在制度文件。

真正有效的治理，需要落到每一次任务和每一种工具权限中。

只读查询可以自动执行。

报告和脚本草稿可以由AI生成，但正式采用前需要审核。

可逆、标准化、影响范围明确的操作，可以在预设条件下自动执行。

涉及生产重启、数据删除、权限提升、网络策略和重大配置的动作，需要工程师或变更授权角色确认。

影响多个关键服务、缺乏回退方案或处于高峰期的动作，应当进入更严格的评估机制。

每个组织可以根据自身环境调整层级，但必须把边界变成系统能够执行的规则，而不是只靠使用者记住一句“注意安全”。

管住AI，不是把AI关起来

有人听到治理，第一反应是限制。

实际上，治理的目的不是让智能体什么都不能做，而是让它在明确边界内发挥更大作用。

没有权限时，智能体只能提供泛泛的文字。

获得只读数据后，它可以整理上下文和辅助判断。

获得经过控制的工具以后，它可以处理标准化任务。

建立分层授权、审计和回退机制以后，它才有可能安全参与更复杂的生产工作。

ITIL 5的6C模型提供了一种很实用的思考方式：先识别AI正在发挥哪种能力，再决定这类能力需要什么数据、权限、验证和监督。

AI数字员工已经进入IT服务管理现场。

真正成熟的组织不会因为担心风险而拒绝使用，也不会因为追求效率而无限授权。

它会像管理一名能力很强的员工一样，明确岗位、任务、权限、证据、升级路径和责任边界。

力量越大，边界越要清楚。

作者：长河老师

本文根据深圳艾拓先锋ITIL Foundation（Version 5）课堂演示整理。