养虾第三周：从智能体可用，到智能体可治理

前两周，我对 OpenClaw 的观察重点，分别是两个层面：

第一周，验证的是能力层——它在 IT 运维场景里到底有没有“准”和“快”；

第二周，思考的是责任层——AI 可以参与执行，但关键判断和最终责任仍然属于人。

到了第三周，实验重点进一步前移：当智能体开始进入真实环境，问题就不再是“能不能用”，而是“能不能被治理”。

所以，这一周我关注的不是单点功能增长，而是围绕 OpenClaw 搭一套初步可运行的治理框架：包括生产变更纳管、安全审查前置、巡检与自愈闭环、知识与流程联动、群体协作以及模型底座判断。

换句话说，第三周开始，“养虾”这件事从工具体验，进入了体系化实践。

1. 生产变更实践：智能体执行必须纳入 ITIL 流程

第三周第一天，我让 OpenClaw 参与了一次真实生产环境中的性能优化变更，对象是在线运行的网站。

这件事的关键不在于“AI 参与了执行”，而在于整个过程是按变更管理逻辑推进的：

问题分析 → 方案提出 → 风险评估 → 人工授权 → 执行变更 → 结果验证 → 后续追踪

这次实践让我更明确了一点：智能体进入生产环境的前提，不是能力足够，而是流程可控。

很多人讨论 AI 运维，容易把视角放在“自动执行”上。但站在治理视角看，更重要的是几个问题：

• 是否纳入正式变更流程
• 是否保留人工审批节点
• 是否具备回滚预案
• 是否有执行后验证
• 是否能形成完整留痕

如果这些问题没有答案，那么所谓“智能体参与生产”，本质上只是把原本的人为风险，换成了自动化风险。

因此，这一周我最大的体感不是“虾更强了”，而是：智能体一旦开始碰生产，治理要求只会比脚本时代更高，不会更低。

2. 安全机制前置：从“信任执行”转向“审查执行”

第二天，我给 OpenClaw 增加了一层前置安全审查机制，让它先学习 skill-vetter 这类能力。

它的意义并不复杂，本质上就是在新技能安装或使用前，先做一轮检查，包括：

• 来源检查
• 代码审查
• 权限评估
• 风险分级
• 输出审查意见

这个动作背后对应的，不只是一个“安全插件”，而是一种治理思路变化：不要默认智能体获得能力之后就可以直接执行，而是要先把审查机制嵌进去。

这和传统 IT 管理里“先上线再补规范”的思路不同。对于智能体，越是接近执行层，越不能缺少前置控制。

因为它的危险不一定来自恶意，更可能来自高效执行下的误判、越权、误操作。

所以第三周我补上的，不是一个功能点，而是一条原则：

AI 不是只要会干活就够了，还必须知道哪些动作需要受限、哪些能力需要审查。

3. 运行架构上的观察：通用智能体与定制智能体不是替代关系

第三天和第四天，我同时体验了飞书内的定制化智能体，以及 OpenClaw 在系统执行侧的能力。

这两类智能体的差异很快就清晰了。

飞书里的定制化智能体，优势是接入快、授权轻、与文档和协同环境结合自然，适合轻量任务和协同场景；但它的边界也很明显，比如模型选择受限、系统级命令能力不足、很难真正承担 OS 层运维职责。

OpenClaw 则不一样，它更接近执行型智能体，能够直接接管一部分自动化动作、巡检任务和系统操作。

因此，从架构上看，我越来越倾向于把它们理解成两个层次：

• 协同与知识层：飞书承接文档、知识库、多维表格、业务协同
• 执行与自动化层：OpenClaw 承接系统动作、脚本执行、巡检恢复

这两层并不是替代关系，而是组合关系。

特别是在企业场景里，真正有价值的不是“再造一个万能 AI”，而是让知识、流程和执行能够串起来。

如果进一步往下走，一套更完整的路径应该是：

知识库沉淀 SOP → 提炼为 Skill → 智能体按 Skill 执行 → 结果回写文档/系统 → 形成复盘与优化

这条链路一旦打通，智能体就不再只是助手，而是进入了治理体系中的可编排节点。

4. 从单体到群体：智能体开始具备“运维对象”属性

第三周还有一个很有意思的变化：七只虾在运行中，逐渐不再只是“七个工具”，而开始像“一个协作集群”。

比如升级时，一只虾可以帮助另一只虾修复问题；某只虾负责定时巡检；某只虾在发现异常后继续触发修复脚本。

这带来了一个很重要的判断：

当智能体开始参与生产流程，它本身也会变成需要被运维和治理的对象。

过去我们谈运维对象，通常是主机、服务、容器、数据库、中间件；但现在还要加上一类新对象：智能体本身。

这意味着后续必须考虑一系列问题：

• 智能体自身如何升级
• 智能体故障如何恢复
• 智能体之间如何协作分工
• 智能体任务如何调度和限权
• 智能体执行结果如何审计

也就是说，未来的治理重点，可能不只是“用智能体去运维系统”，还包括“如何运维智能体体系本身”。

这是第三周一个非常明显的认知跃迁。

5. 事件管理月报：AI 的价值不只是提效，而是重组认知

第五天，我把一个月内的 200 条脱敏事件单交给小龙虾，生成 ITIL 事件管理月度分析报告。

这件事让我更加确认，AI 在 IT 管理里的价值，不能只用“节省多少工时”去衡量。

更大的价值在于，它可以把原本碎片化、事务化的数据重新组织起来，帮助团队看到趋势和结构。

在传统运维团队里，事件单往往停留在“记录处理结果”的层面。今天哪个服务告警，怎么恢复；明天哪个系统异常，怎么临时止血。单条事件都处理了，但系统层面的重复模式、潜在根因和流程缺口，很容易被淹没在日常工作里。

而 AI 的一个强项，就是在大量相似文本、重复事件、相近模式中做归纳和重组。

从这个角度讲，它不是简单替代事件处理人员，而是在强化管理层的观察能力。

也正因为如此，我越来越觉得，智能体最值得投入的方向之一，不是“替团队多干一点活”，而是“帮助团队从持续救火转向趋势治理”。

6. 选型判断：框架重要，但模型底座决定上限

第三周最后，我还做了一个不同方案处理图像任务的对比实验。

实验结果再次印证了一个很现实的结论：

智能体框架可以放大能力，但模型底座决定输出上限。

这点在很多场景里都容易被忽略。因为大家更容易看见的是外层工作流、自动执行、工具链编排这些显性的东西，而对底层模型本身的理解、推理、生成质量稳定性关注不够。

但实际用下来会发现：

• 框架决定的是有没有流程能力
• 工具链决定的是能不能调用外部能力
• 模型决定的是输出质量到底靠不靠谱

所以对企业来说，选型不能只看“这个智能体能接多少工具、能跑多少流程”，还得看底层模型本身是不是足够稳定、足够适配当前场景。

否则，外层架构搭得再漂亮，也可能只是把一个能力不足的底座包装得更复杂。

7. 第三周总结：智能体治理，开始替代“新鲜感”

回看这一周，我觉得“养虾”这件事的性质已经变了。

它不再只是体验一个新工具，也不只是验证一个热门概念，而是在逐步回答一个更长期的问题：

当智能体真正进入 IT 运维体系后，企业要怎么治理它？

第三周里，我开始搭的，其实是一套很初步但方向明确的治理框架：

• 生产执行要纳入变更流程
• 新能力接入要有前置安全审查
• 日常巡检与修复要形成闭环
• 知识库要能转化为执行能力
• 多智能体之间要考虑协同与互助
• 智能体本身也要纳入运维对象管理
• 模型底座要作为核心选型因素看待

第一周，我看到的是效率提升。

第二周，我思考的是人的位置。

第三周，我真正进入了治理视角。

所以这一周最值得记下来的，不是“虾又学会了什么”，而是：

从现在开始，真正考验我的，已经不是怎么养虾，而是怎么管虾。