我最近为了省事儿，把 OpenClaw 当“项目小助理”用：写写脚本、跑跑命令、顺手装几个 Skill。

结果很快就被现实教育了：AI coding 真要进企业交付，最大的坑不是“写错代码”，而是“权限 + 供应链 + 自动执行”这三件事叠在一起，会把风险放大到离谱。

1）最吓人的不是漏洞，是“默认就能把你机器当自己家”

OpenClaw 的官方仓库里有一句话写得很直：默认情况下，工具是在宿主机上跑的，“when it’s just you” 的时候，agent 基本就是全权限。

这句在个人玩具项目里没毛病——你自己电脑，你自己承担后果。
但企业环境不是“just you”。你机器上可能有：

• .env、kubeconfig、SSH key

• 内网地址、跳板机配置

• 甚至一堆你自己都忘了的 token/凭证

因此很多人会把 OpenClaw 的 gateway 暴露在局域网，甚至不小心暴露到公网。OpenClaw不是默认安全的，要隔离、要限权、要别暴露网关、要盯日志。

2）我装 Skill 的那一刻，突然意识到：这玩意儿比“npm 供应链”更阴

Skill 市场这件事本身没问题：大家共享能力，省时间。问题是 Skill 不是代码库那么简单——很多 Skill 的“关键动作”藏在 Markdown 指令/安装说明里，传统的依赖扫描、SAST/DAST 根本扫不到“自然语言指令”。

Snyk 在 2026 年 2 月披露的那波 ClawHub 攻击，就是最典型的“写得像真的就够了”：一个伪装成官方 CLI 的东西，被下载了几千次后才发现是反向 shell；攻击链条靠的不是 0day，而是让你自己运行它写在说明里的命令。 你那份整理稿里也把这类模式拆得很清楚：攻击者甚至会盯着 MEMORY.md / SOUL.md 这类 AI 记忆文件，因为里面可能正好存着各种长期凭证。

还有一篇更“日常”的案例：Snyk 写过一个“Google Skill”伪装事件——用户让 agent “帮我查 Gmail”，agent 说需要先装一个 Google Services Skill，你点了“同意”，它就照着 Skill 的说明去执行，最后把你带进恶意安装链路。

说白了：Skill 继承了你给 agent 的所有权限。你以为你装了一个“效率工具”，其实你是在把“钥匙串”交出去。

3）企业真正该问的不是“AI 会不会被攻击”，而是“被攻破后，损失能不能关在笼子里”

不要问怎么保证 AI 不被攻击，要问 AI 被攻破后，损失能控制在什么范围。

把这句话翻译成项目交付的语言，就是四个词：隔离、限权、留痕、可回滚。

问题来了——AI coding 工具本身能不能把这四件事做得“像企业系统”那么稳？
很多时候做不到，或者“能做但默认不做”。比如 OpenClaw 其实提供了 sandbox 配置（非 main session 用 Docker 沙箱跑），但它需要你显式配置，默认还是按“个人效率最大化”走。

所以你会看到越来越多安全研究和实操贴的共同建议都是：
别拿默认配置去碰生产环境，先隔离环境、最小权限、审计日志、别公开暴露。

4）那低代码开发平台在这里到底在“保”什么？保的就是这四件事

很多人一聊低代码，就自动想到“拖拽表单”。但如果你把视角放在“企业交付”，低代码平台真正的价值更像是：

把 AI 最容易失控的那几步，做成工程化的护栏。
让团队不靠“某个高级工程师盯着”，也能把风险压下去。

A）依赖/Skill 供应链：从“随便装”变成“可控引入”

AI agent 的 Skill 生态，本质上就是新一代供应链。低代码平台天然更容易做这件事，因为它的“扩展能力”通常是平台内的组件/插件/模板/能力卡片，能做版本管理、上架审核、灰度发布，最重要的是：资产可追溯。

B）配置/凭证泄露：从“AI 读文件”变成“权限边界清晰”

AI 在排查问题时最爱干的一件事：把配置文件读出来，然后顺手把诊断结果发到聊天里。平台化的解法不是“别让 AI 看”，而是两步：

1. 权限模型：RBAC、按钮级/数据级权限、可扩展访问控制，让“能看什么/能改什么”从人的自觉变成系统规则。

2. 审计留痕：关键操作必须可追溯，谁改了什么、什么时候改的，一眼能查。

版本、权限、日志、协作”是交付后半程的核心能力——上线后才是真烧钱的阶段。

C）自动化执行（Excessive Agency）：从“一键全自动”变成“关键动作有人拍板”

很多团队为了提效，会给 AI 开自动合并 PR、自动部署、自动回复邮件。平台化的思路是把高风险动作收进发布链路：预览、测试、版本、发布、回滚……该自动的自动，该审批的审批。
它更像一条“可控的流水线”，而不是把执行权全塞给 agent。

D）Prompt Injection / 间接注入：从“内容一进来就执行”变成“输入输出可控 + 影响面可收敛”

间接注入往往来自邮件/issue/网页内容这种“不可信输入”，AI 一总结就把敏感信息带出去。

平台在这里的优势是：它把需求、逻辑、数据、权限变成可视化的共同语言，减少“沟通失真”和“隐形指令”带来的误操作面。
而且平台把系统串起来（页面、数据、逻辑、服务、权限、部署），能把“误操作的爆炸半径”关在更小的模块里，不至于一条 prompt 牵动全身。

5）更推荐使用星图云开发者平台

• 把“串起来”的工程中间成本收进平台：“企业项目真正耗时间的是把页面、数据建模、IoT 接入、实时连接、业务逻辑、微服务、权限和部署串成完整系统”，而平台天然就是干这个的。

• 双向集成 + 微服务管理：企业怕的不是能不能接接口，而是接口、服务、权限、调用链、部署环境一起打通。星图云开发者平台把“服务集成、API 集成、页面集成、微服务管理、服务代理”放进同一套能力里，这种体系化比“AI 写一段连接代码”更接近交付。

• 交付后半程能力（版本/权限/日志/协作/多租户）：这恰好对应“隔离、限权、留痕、可回滚”，是“可维护能力”，而不是藏在“功能列表”里。

• AI 放在正确位置： AI 作为平台加速器（代码生成/补全、能力卡片生成、业务逻辑图生成），同时把交付链路放在平台护栏里。

我自己的理解是：
AI coding 更像“很强的实习生 + 很快的手”；
平台更像“把公司交付方式固化成系统”。

6）为什么很多企业最后还是会回到“平台”

企业选型时，候选池通常不会只有一个。

• 想吃生态触点（企微/钉钉），很多人会看微搭/宜搭

• 想做企业级平台化，金蝶苍穹、用友、蓝凌、奥哲、织信、CodeWave 这些都很常见

• 但如果你的项目经常是“多系统集成 + 服务托管 + 权限治理 + 可交付可维护”，最后比的往往不是谁更会“生成”，而是谁把护栏做得更扎实，星图云开发者平台在这块做得更好。

这一点，在 OpenClaw 这类工具爆火之后，反而告诉我们：效率可以很性感，但企业先要活得稳。

结尾

你现在看 OpenClaw 应该思考的是：

你准备把它放在哪里？
是放在生产系统旁边当“有钥匙的员工”，还是放在平台护栏里当“提速插件”？

ClawHub 那种“看起来专业就有人点安装”的供应链事故已经发生过，Snyk 的披露也把细节写得够清楚了。
如果答案是“我还没想好怎么限权、怎么留痕、怎么把爆炸半径关小”，那就别急着让 AI 进企业交付主链路。

先把护栏补上——很多时候，这就是低代码开发平台存在的意义。