很多人谈AI智能体，总喜欢问一个问题：它能不能替人干活？

在我看来，这个问题只问了一半。到了真实IT运维场景，尤其是生产环境里，更关键的问题是：它凭什么被允许干活？谁授权？谁审查？谁承担后果？出了问题怎么回滚？留下什么记录？

我做“养虾实验”到第三周，感受最深的正是这一点。前两周更多是在验证OpenClaw能不能做事，能不能快速响应，能不能把一些重复性运维动作跑起来。第三周开始，我把关注点转向“管理智能体”。因为一旦AI智能体进入生产环境，它就不只是一个工具，而是一个需要被纳入ITIL流程治理的执行单元。

这周最典型的案例，是一次真实生产环境的性能优化变更。目标网站是 itil4hub.cn。当时网站响应异常，OpenClaw在我的监督和授权下完成了完整的变更闭环：问题分析、方案提出、风险评估、人工授权、执行变更、结果验证和后续追踪。最终，响应时间从30秒降到0.6秒，性能提升约97%。

这个结果当然令人满意，但我更看重的是过程。因为它不是“AI发现问题后直接上手改”，而是被放进了ITIL变更管理框架中。回滚方案全程准备就绪，虽然没有用上，但它必须存在。IT运维里最危险的不是一个工具不会干活，而是它太会干活，却绕过了流程。

这也是很多企业引入AI智能体时容易忽略的地方。大家关注效率，关注节省人力，关注自动化率，却不太关注控制点。可真实运维最怕的就是失控。权限过大、审查不足、缺少回滚、没有授权记录，这些问题叠加起来，效率越高，事故可能越大。

所以，我给OpenClaw增加了一道“安全员”机制。它在安装新技能前，会先对技能做来源检查、代码审查、权限评估、风险分级，并生成审查报告。如果风险较高，就提示不建议安装。这件事看起来像是在给AI加限制，实际上是在让它具备进入企业环境的基本条件。

企业并不缺能干活的工具，企业缺的是可控、可审计、可持续的执行机制。智能体如果只会执行命令，而不知道哪些命令不能执行，它就不适合进入核心系统。

第三周另一个有意思的观察，是“通用智能体”和“平台定制智能体”的差异。我体验了一只飞书里的定制小龙虾，几分钟就能开通，几乎零配置，授权也很顺畅。它很适合普通用户在飞书生态里做一些文档、知识库、表格类操作。但它不能切换大模型，不能运行OS级命令，也不能真正承担系统运维任务。免费额度用完后，体验也迅速受限。

这说明一个问题：平台型AI助手的优势在于入口简单、生态顺滑；通用型智能体的优势在于能力边界更宽，能真正接入系统层面的任务。两者不是谁替代谁，而是要组合使用。OpenClaw负责智能体能力落地，飞书负责企业数据、文档、知识和流程流转。这个组合，反而更接近企业级AI应用的样子。

我还用小龙虾处理了一批真实脱敏事件单。一个月200条事件记录，过去人工整理可能要花两三天，现在它能快速形成ITIL事件管理月度分析报告。这里的价值不只是“省时间”，而是把长期隐藏在事件单里的趋势挖出来。哪些系统反复出现问题？哪些故障一直被重启掩盖？哪些问题其实已经具备问题管理的触发条件？这些才是ITIL真正关心的东西。

AI智能体在运维里的价值，不应只停留在“帮我执行一个脚本”，而应该进入事件管理、问题管理、变更管理、知识管理这些体系中。它可以帮团队从救火模式转向改进模式，从经验驱动转向数据驱动。

当然，工具热起来以后，骗局也会出现。我在直播间看到所谓“鼠标龙虾”硬件，声称智能体养在鼠标里。我的判断是，真正运行环境大概率在云端，本地鼠标只是入口或遥控器。这类产品最大风险不是贵，而是数据和控制权不透明。运维人员尤其要警惕：你的脚本、文件、业务数据、账号权限，到底经过了谁？

最后还有一个结论：模型才是核心。我做过几种AI方案生成矢量图的对比，同样是智能体框架，底层模型不同，结果差距巨大。智能体框架再强，如果模型理解、推理、生成能力不足，最后交付质量依然不可靠。

所以，AI智能体进入IT运维，不是装一个工具那么简单。它至少要回答四个问题：能不能干，能不能安全地干，能不能按流程干，能不能持续改进地干。

我第三周养出来的，不只是七只虾，而是一套初步的智能体运维治理框架。

结论很简单：AI智能体的上半场是执行力，下半场一定是治理能力。