加强 OpenClaw 技能安全性的启示：从 VMware 管理skill的改进说起

科技前沿 • 2026-03-31 23:51 • 阅读 0

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

之前文章讲了 VMware-AIops 技能的诞生和功能，本文讲它发布后的 48 小时里，用户反馈如何推动了 4 轮安全加固和一次架构级拆分。

文章发布后，很多用户通过 OpenClaw 和 Skills.sh 安装了 VMware-AIops，接入顺利，体验不错。但紧接着，安全相关的担忧集中涌现，归纳为三类：

担忧 1：AI 会不会"手滑"误操作？

"如果我只是想查看告警，万一 AI 理解错了，把 VM 给关了怎么办？" "我的场景就是日常巡检，能不能把写操作关掉？"

担忧 2：操作没有审计记录

"合规要求所有变更必须有 audit trail，做了什么操作事后能查到吗？"

担忧 3：确认机制不够严格

" 可以跳过确认？这太危险了" "能不能在执行前先让我看看当前状态？"

这些不是 Feature Request，这是信任问题。用户不敢用，再多功能都没意义。

用户说得对：如果只是查看告警，为什么要加载一个包含的技能？

于是设计了双技能架构：

但这只是第一步—— 的"只读"靠提示词约束，底层代码里仍存在破坏性函数。

加入结构化操作流程和审计日志：

每一次操作——成功的、失败的、用户拒绝的——都有记录。

所有破坏性命令——关机、删除、快照、克隆、迁移等——都支持，先看再做。

四轮加固后，双技能架构的局限性暴露了。

号称"只读"，但和共用代码库。里的、仍然存在。用户的质疑完全合理：

"如果 AI 被 Prompt Injection 攻击，绕过 SKILL.md 约束，它是不是仍然可以调用这些函数？"

答案是：理论上可以。提示词约束不等于代码级安全。

于是做了架构级决策：将 VMware-Monitor 拆分为独立仓库。

VMware-Monitor 从零构建，代码库中不存在任何破坏性函数：

测试用例自动扫描整个代码库确保这些函数名不会出现。即使 AI 被攻击，也找不到任何破坏性函数可调用——因为它们从来就不在这个代码库里。

拆分后两个仓库都做了全面清理，消除冗余目录和交叉引用。Monitor 不是"**版"——它和 AIops 一样覆盖 Claude Code、Gemini CLI、Codex、Aider、Trae IDE 等所有主流 AI 平台，是同等的一等公民。

安全性从提示词约束升级到代码级隔离：

发布第一天收到的最有价值的反馈不是"好用"，而是"我不敢用"。

安全不是功能列表上的 checkbox，是用户信任的基础。VMware-Monitor 的独立仓库不是过度设计——当代码库中物理上不存在破坏性函数时，信任就有了坚实的基础。

开源项目最大的价值不在于代码，而在于社区反馈推动的快速迭代。 48 小时内从用户反馈到架构级重构，这在传统软件开发中几乎不可能。

项目地址：

一键安装：

如果你之前因为安全顾虑没有尝试，现在可以从 VMware-Monitor 开始——最小化风险，代码级保障。

欢迎关注 亨利笔记， 👍 点赞 | ⭐ 收藏 | ↗️ 转发。

近期文章：

本公众号聚焦人工智能，云原生和区块链等技术原理，请立即关注亨利笔记 （ henglibiji )，以免错过更新。