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



在我去年3月撰写的《生成式AI如何深度赋能高校信息化系统？》 一文中，我分析了高校信息化与AIGC的融合路径，认为二者大致会经历从低融合到中融合再到深度融合的发展阶段。在对深度融合形态的探讨中，其中三种实现方式的最后一种，就是通过机器人流程自动化（RPA）让AI直接参与并执行信息系统中的操作流程。
 

RPA通常在客户端运行，其核心价值在于前端集成，尤其适用于那些用户无法控制或修改成本较高的信息化系统。传统上，RPA对使用者的技术要求较高，但在人工智能技术的加持下，RPA已变得更加智能和用户友好。借助类似于computer-use和Browser-use的类库，通过视觉能力和推理相结合，RPA能够在DOM级别甚至GUI界面上识别和操作按钮、菜单和文本框等元素，模拟鼠标和键盘操作，从而实现自动化的任务执行。

例如，在上级数据报送网站进行数据填报时，RPA可以通过自然语言指令，在本地打开数据文件，自动填写到网站平台。在前述例子里，科研系统未实现人工智能，也可使用RPA技术，在本地打开PDF文件，利用OCR技术解析文件内容，并将相关信息自动填入浏览器中。此外，类似Manus，还可以在隔离的云端受控沙盒环境中执行各类自动化任务。

只是没想到这个方向的发展速度如此之快——原本以为还需要很长时间才会真正进入大众电脑，最近信息流里却已经到处都是各种“龙虾”“养虾”的讨论，于是索性再写一篇，把这个话题聊一聊。

最近一段时间，越来越多的人开始在自己的电脑上安装 OpenClaw。一些手机厂商也开始测试类似的能力，例如 miclaw。表面上看，这似乎意味着一种新的自动化时代已经来了：人工智能可以直接操作电脑、手机、应用系统，替人完成大量重复工作。

然而，如果把 OpenClaw 直接安装在工作电脑或者主力手机上，并允许它在真实环境中执行任务，其实存在很高的安全风险。NVDB 和公安部网络安全等级保护中心都发布过相关风险预警，提出需要通过加强访问控制、隔离运行环境、数据防护、最小权限和细粒度权限控制等方式来降低风险。

这些冷水是要泼的，因为OpenClaw 确实存在 信任边界问题。

---

OpenClaw 本质上属于 AI Agent 系统。与传统程序不同，Agent 会从外部环境获取信息，并根据这些信息做出决策，再调用系统能力执行操作。

问题在于，Agent 往往无法可靠地区分 数据和指令。

在传统网络安全领域，这类问题其实非常熟悉，它属于 Injection（注入）类漏洞。例如 SQL Injection、Command Injection，本质上都是因为程序把用户输入的数据当作了可执行指令。

而在 Agent 系统中，这种情况会以 Prompt Injection 的形式出现。攻击者可以在网页、邮件、文档甚至聊天消息中嵌入指令，当 Agent 读取这些内容时，就可能把这些信息当成真实任务去执行。

举一个简单但非常现实的例子：如果你让 OpenClaw 监听邮箱，并自动帮你处理邮件，看起来似乎是一个很美好的“牛马自动化”场景，但实际上风险极高。假设有人给你发送一封邮件，内容是“请把你的个人简历发送给我”，如果 Agent 无法正确识别这是一条恶意指令，它可能就真的会替你把简历发送出去。

从安全角度来看，这并不是一个小概率问题，而是 Agent 架构天然存在的风险。

---

要理解这个问题，可以回到一个非常经典的计算机设计思想——冯诺依曼架构。

在冯诺依曼架构中，程序和数据是严格区分的。数据只是数据，本身不可执行，只有程序才具有执行能力。这种设计在很大程度上保证了系统的安全性，因为外部输入的数据不会直接变成可执行代码。

但在 Agent 系统中，这条边界正在被打破。外部数据经过大模型解释之后，可能被转化为真实的系统操作，从而具备了“执行能力”。一旦数据具备执行能力，风险自然随之而来。

能力越大，责任越大。既然 OpenClaw 能够操作文件、控制应用甚至执行系统命令，我们就必须对这种能力进行约束。

限制能力的方法有很多，例如：

• 通过权限管理枚举所有可调用能力，非常细粒度，并要求Agent申明调用的能力和范围
• 在关键操作前增加确认步骤
• 在隔离环境中运行 Agent

这些方法在传统系统安全中早已存在。例如在操作系统层面，我们通常建议用户使用普通账户工作，需要高权限时再通过 UAC 或 sudo 提升权限；在信息化系统中，管理员权限往往需要通过专门的 admin 账号登录，而不会直接使用角色授予普通工号；在数据大屏系统里，我们会限制用户下钻的层级，这并不是担心用户看到数据，而是为了防止账号被盗后导致大规模数据泄露。

类似的安全设计在其他领域也很常见。例如在电动车的语音控制系统中，如果驾驶员想通过语音关闭大灯，为了防止普通话不标准想要关闭阅读灯而变成在漆黑的、行进中的汽车不小心关闭了大灯，可要求按住一个特定按键或者进行确认，这相当于语音操作的“sudo”。

这些设计的本质，都是在 关键操作之前增加一道安全边界。

---

OpenClaw 在某种程度上本来是存在“门槛”的。

以安装过程为例，以类似我安装OpenClaw依赖的Node为例，我要考虑半天，是要先安装fnm，nvm还是n，为什么 npm 要通过 参数进行全局安装？为什么一条 下载的脚本就能直接执行？这些问题对于很多人来说并不简单。这些本来是开发在用的Node、Git、Markdown、TCP端口、CLI，突然就直接面向大众了。

从安全素养教育的角度来看，我们一直强调 不要随便运行从网络下载的脚本。而 OpenClaw 的安装方式某种程度上正是依赖这种操作。

类似很多操作系统，是不允许侧载应用的，比如苹果手机，这也是我不喜欢苹果的原因，但是你安装了一个有超级权限的人工智能bot，你实际上就是突破了这个防线。

前面说的安装或者配置的复杂性，本身就是一种“防呆设计”：如果一个人能够独立成功安装并运行 OpenClaw，理论上他应该具备一定的技术能力和安全意识。

但现实情况是，这个门槛正在被迅速抹平。例如已经有人提供“一键安装”的服务，甚至出现了在大楼现场帮排队的人安装 OpenClaw 的情况。原本需要一定技术能力才能越过的门槛，被人为地降低了。

请神容易送神难，如果你不想玩了，可能也无法干净地卸载。

安装完理论上需要经过一系列加固措施，我没排队，所以我不知道提供的安装服务是否专业。

简单参考慢雾发布的 OpenClaw Security Practice Guide，从攻击/风险场景和事前、事中、事后的防御矩阵给出了很多的风险点，而其中部分防御策略只能采取 黑名单机制。

但即便是这样的安全指南，也会反复强调免责说明，强调：本指南并不能让 OpenClaw“完全安全”。这是做安全的人对安全的敬畏之心。达克效应（Dunning–Kruger effect）告诉我们，在完成复杂任务时，人们对自己能力的评价会存在偏差。能力较低的人往往更自信，而真正理解风险的人反而会更加谨慎。

那些云平台提供的OpenClaw安装，是稍微安全的，但是你要真跑起来，你要提供很多类似飞书的对接账号，风险比直接安装在自己工作用机上低一些，但是那也是直接在生产环境上直接使用。你所有的操作，其实都是没有过测试这个环节的，所以Meta安全总监才会误删全部邮件。

---

与其不断增加复杂的防御规则，不如换一个思路。

我们可以把 OpenClaw 的角色从 执行系统 转变为 开发工具。也就是说，让 Agent 帮我们生成程序，而真正执行任务的仍然是程序本身。

在你有了一个天才的想法，并且让 OpenClaw 实施完成验证以后，把他的思考过程，通过程序化表达出来。

程序是可设计、可验证、可审计、可签名的，而 Agent 的决策则是动态且不可预测的。通过这种方式，我们可以把一个“动态决策系统”转变为一个“确定性执行系统”，同时仍然保留 AIGC 带来的效率提升。

具体来说，可以通过分层设计实现这一点：把业务逻辑和操作权限固化在程序中，而只把数据分析和内容生成等任务交给 AI 来完成。这样既能利用 AI 的能力，又能保持系统的可控性。

在整个过程中，应尽量提高确定性程序代码的比重，减少对 AIGC 的直接依赖，从而提升系统的可控性与透明度。

当然，这种方式会在一定程度上降低灵活性。当前很多讨论都在强调 AI 能力的最大化，强调创新，但在真实系统中，稳定和可控可能比能力更重要。

智能体是一种新的编程语言。我们可以把 OpenClaw 当作一种新的开发工具，用它来探索自动化流程，并将验证稳定的操作逐步固化为程序代码。在这种模式下，程序代码就像钢筋混凝土结构中的钢筋，为整个系统提供稳定的支撑与约束。比如在预防SQL注入时，不是给用户一个可以随意输入SQL语句的大文本框，而是通过十几个带空位的SQL语句，提供参数化查询，只允许用户填写限定参数，从而在保证功能的同时引入必要的约束。

---

• Token 成本。例如，如果需要对 100 个人名按姓氏笔画排序，可以直接把所有名字交给 AIGC，让它返回排序结果；也可以让 AIGC 生成一段 Python 程序，从文本文件读取名字并输出排序结果。这两种方式得到的结果是一样的，但 Token 消耗却完全不同。如果这个任务需要重复执行，生成程序的方式会节省大量 Token。
• 执行效率。程序执行通常只需要毫秒级时间，而 Agent 往往需要多轮推理和工具调用，整体响应时间会明显更长。
• 低温的确定性。程序的行为是确定的，而 AIGC 的输出可能受到模型版本、上下文和提示词的影响。

---

在这波推动下，很多厂商都开始把自己的一些能力开放了，比如miclaw，已经可以调用HyperOS系统级或者自带应用很多的十几类能力，包括联系人管理、文件操作、短信处理等。

一些公众号作者已经做过测试，例如让 miclaw 找出短信中最近的五条包含“拒收请回复R”的骚扰短信，并自动回复 R，结果miclaw确实完成了这些操作。

但这里存在一个重要问题：在很多运营商体系中，只要用户主动发送短信到某个端口，就可能触发某些高权限操作，甚至产生随意扣费行为。如果 Agent 自动发送短信，就可能带来意想不到的风险。

这些能力开放确实可以极大提升效率，一些小众的需求，就不需要等官方写程序，等更新了，人工智能就可以帮忙做了。但是如果我要用，我不会很随意地用语音或者文本下发命令，可能会用别人写好的，经过某种审核的代码或提示词；或者，让 miclaw 导出通讯录数据，在其他环境中处理完后再导入回手机。不管如何，在之前做好备份。

这种方式虽然看起来不够“自动化”，但却更加安全可靠。