乐于分享
好东西不私藏

OpenClaw 编年史 05:会做事的 AI,谁来背责任?

OpenClaw 编年史 05:会做事的 AI,谁来背责任?

竞品开始围猎 OpenClaw 以后,安全问题也换了问法:谁拿入口,谁就要解释权限、审核、日志和事故责任。

很多人看 Agent 安全,第一反应是找漏洞清单。

这个方向没有错,但它太窄了。

OpenClaw 把问题推到台面上的地方,是它不只回答问题,还能接近文件、浏览器、消息、命令、账号和第三方 skills。

数据口径:截至 2026-05-27 15:39(北京时间),OpenClaw 官方安全文档仍把默认场景定义为单用户、个人助手信任边界;Snyk ToxicSkills 报告发布于 2026-02-05,报告称扫描 3,984 个 skills,发现其中 534 个 critical issue、1,467 个存在安全问题和 76 个恶意 payload。相关数字只代表该研究口径,不等于 OpenClaw 官方项目整体安全状态。

核心判断:个人 Agent 的安全问题,不是某个项目有没有漏洞这么简单;更难的是,当 AI 能读文件、跑命令、打开浏览器、调用账号和安装 skills 时,入口方、平台方、开发者和用户之间的责任链要重新设计。

风险没有消失,只是换了责任人

聊天机器人说错话,最常见的后果是内容错误。你可能被误导,可能浪费时间,可能要重新核对。

Agent 做错事,后果会进入操作层。

它可能读到本地文件,打开浏览器,运行命令,发出消息,触碰钱包,或者在企业系统里做一次真实操作。问题不再只是“回答准不准”,而是“谁允许它做这件事,谁记录了过程,谁能撤回,谁对损失负责”。

这也是第四篇之后更值得追的问题。竞品越多,说明 OpenClaw 暴露出来的需求越真;但每个竞品切走一个价值环节,也会切走一部分安全责任。

开源项目把控制权交给用户,用户也拿到了更多配置责任。

大厂产品把默认值做得更稳,也会把信任集中到平台。

云托管降低上手门槛,服务方就要解释数据在哪里、日志谁看、事故怎么处理。

系统级入口最方便,也最靠近隐私、支付、设备和真实空间。

所以,安全篇不该只问 OpenClaw 安不安全。更准确的问题是:会做事的 AI,到底需要谁来背责任?

可以把这件事想成下面这条责任链:

Agent 安全责任链

三个入口正在把风险推向操作层

外部输入不再只是输入

Agent 的麻烦,不在它会读文字。

麻烦在于,它读完文字以后还能调用工具。

网页、邮件、聊天记录、README、文档、客服工单、企业知识库,这些内容本来只是信息源。一旦 Agent 同时拥有浏览器、文件、shell、消息和 API 权限,外部输入就可能从“被阅读的材料”变成“影响行动的指令”。

普通读者可以把它理解成一个简单场景:你让 Agent 总结一个网页,它读到网页里的隐藏指令;如果它只能总结,风险还在内容层;如果它还能执行命令、发消息或提交表单,风险就进了操作层。

这不是 OpenClaw 独有的问题。所有会连接外部内容和真实工具的 Agent,都要面对这条边界。

权限会沿用户环境继承

OpenClaw 的吸引力,来自它靠近用户自己的环境。

它能运行在用户选择的机器、homelab 或 VPS 上,能连接聊天入口、文件、工具、浏览器和插件。这个设计给了用户控制感,也让 Agent 更接近真实工作流。

但权限会沿着环境继承。

如果用户的浏览器已经登录了账号,Agent 看到的就不只是一个网页。如果用户给了文件系统权限,它接触的就不只是临时目录。如果用户允许它跑命令,错误就可能不再停留在界面里。

OpenClaw 官方安全文档在 2026-05-27 核验时仍明确写着:它假设一个受信任操作者边界,不是给多个互不信任用户共用的 hostile multi-tenant security boundary。这个边界很重要。它说明官方已经把风险说出来了:这类 Agent 不是万能保险箱。

权限越近,安全越重。

skills 市场会放大供应链风险

skills 和 plugins 是 Agent 生态能长起来的原因,也是风险最容易扩散的地方。

对用户来说,安装一个 skill 看起来像安装一个小功能:自动整理文件、读网页、连接钱包、发消息、处理表格。对攻击者来说,这也是分发恶意行为的入口。

Snyk 在 2026-02-05 发布的 ToxicSkills 报告里,扫描了 3,984 个来自 ClawHub 和 skills.sh 的 skills,发现其中 534 个 critical issue、1,467 个存在任意安全问题,并确认 76 个恶意 payload。这个口径不能直接推出“OpenClaw 官方项目不安全”,但它足够说明一件事:当能力包市场快速扩张,治理能力必须跟上。

Tom’s Hardware 在 2026-02-01 报道过 14 个伪装成加密钱包或交易自动化的恶意 Moltbot skills。这个案例适合给普通读者理解:风险不一定长得像漏洞,它也可能长得像一个“刚好有用”的插件。

2026-04-16 提交的 HarmfulSkillBench 论文把问题再往前推了一步:它不只看 skill 里有没有漏洞,还看 skill 如何把原本会被拒绝的有害意图包装成“已安装能力”。论文覆盖 98,440 个 skills,发现 ClawHub 样本里的 harmful rate 高于另一个 registry。这个研究提醒我们,skill 不是普通按钮,它会改变 Agent 对任务的理解。

skills 市场看起来像 App Store,早期治理却更接近 package registry。只要用户把钱包、浏览器、shell 和文件权限接进去,风险等级就变了。

开源和大厂的安全账不同

开源路线:控制感强,配置责任也近

OpenClaw 和 Hermes 这类开源路线,最大的优势是透明、可改、社区反应快。

开发者可以看代码、改配置、自己部署、自己审计,也能围绕具体工作流加上更细的安全边界。安全研究者更容易公开指出问题,社区也更容易围绕问题修补。

代价也清楚。

普通用户不一定理解 Gateway、skills、provider、sandbox、policy、logs 这些配置。开源项目给了控制权,也把一部分判断压力交给了用户。用户想要“自己的 Agent”,但不一定想成为自己的安全管理员。

截至 2026-05-27,OpenClaw 官方文档已经给出 hardened baseline、security audit、fs-safe、sandboxing、workspaceOnly 等一组防线。GitHub releases 页面显示,2026.5.26 beta.1 的版本说明也把 safer agents 放进 highlight。这个方向值得肯定,但它也说明安全已经不再是边缘话题,而是产品体验的一部分。

这就是开源个人 Agent 的长期张力:它把权力交还给用户,也要求用户承担更多默认值之外的责任。

平台路线:默认值强,信任更集中

QClaw、WorkBuddy 这类大厂路线,安全优势不一定来自模型更强,而来自账号、审核、日志、风控、企业合规和默认配置。

企业用户买的,往往是权限、审计、组织知识库、审批流、事故响应和责任边界。会说话只是入口。

这也是 WorkBuddy 这类企业工作台的优势。它更容易把 Agent 放进可控流程里:谁发起任务,谁批准调用,谁查看日志,谁能回滚结果,谁对外发出最终消息。

但平台路线也有代价。

默认值更稳,通常意味着更多平台规则。审核更强,意味着可玩性下降。日志更完整,意味着数据更集中。用户少折腾了,信任也更交给平台了。

入口强不代表留存强,安全强也不代表用户一定愿意把所有上下文都交出去。

云托管路线:门槛低,责任集中

MaxClaw 这类云托管叙事,打的是另一个痛点:大多数用户不想部署。

他们不想管 VPS,不想维护 Gateway,不想处理模型 key,不想研究 policy plugin。他们想注册、授权、开始用。

云托管会把维护、更新、监控、备份、安全策略和事故响应集中到服务方。这对普通用户有吸引力,也会让服务方承担更大的解释压力。

数据在哪里?日志保存多久?谁能访问?第三方 skills 怎么审核?高风险操作谁确认?事故发生后谁赔?

云托管越省心,这些问题越不能被省略。

系统级入口:权限最高,边界也最重

MiClaw 这类系统级路线更特殊。

手机厂商、车机系统、智能家居平台手里有 OS、账号、设备、传感器、支付和家庭场景。它们可以把 Agent 做得更顺手,也更接近真实生活。

但系统级便利背后,是更重的事故责任。

一个 Agent 帮你整理文件出错,和一个 Agent 控制家电、车机、支付、门锁、摄像头出错,不是一个等级的问题。

系统入口越强,安全就越不能只靠用户自己理解。

个人 Agent 需要新的默认安全值

如果个人 Agent 真要普及,安全设计不能只留给高级用户。

我更在意的是下面这五个默认值:

个人 Agent 安全默认值矩阵
默认值
解决什么问题
读者可以怎么看
能力清单
用户安装 skill 前知道它能读什么、写什么、调用什么
没有权限说明的 skill,要谨慎
输入分级
外部网页、邮件、聊天不能直接触发高权限动作
低可信内容不该直接连 shell、钱包和企业系统
高风险确认
发消息、转账、删文件、跑命令需要二次确认和日志
Agent 可以建议,敏感动作要留确认点
记忆可回滚
长期记忆要标来源、可编辑、可删除
记忆越长,污染越要可撤销
审计和回滚
企业和重度用户需要知道谁让 Agent 做了什么
没有日志,就很难追责

这些东西听起来不酷,却决定 Agent 能不能从爱好者工具进入日常生活和企业采购。

安全不是扫兴。

安全是把“会做事”变成“敢让它做事”的那条路。

边界:别把安全写成恐慌

这篇文章有一个边界要说清楚:OpenClaw 的安全讨论,不该被写成“开源 Agent 天然危险”。

开源的好处,是问题更容易被看见、复现、讨论和修补。官方文档公开 trust boundary,安全研究公开攻击面,版本说明持续写入加固项,这些都比假装没有风险更健康。

但另一个边界也要说清楚:公开边界不等于普通用户已经理解边界。

当一个工具从开发者圈走向普通用户,安全说明就不能只停在文档里。用户需要在安装 skill、授权账号、执行命令、连接钱包、开启远程入口时,直接看到风险提示和默认保护。

个人 Agent 的难处就在这里。它越有用,越接近真实权限;越接近真实权限,越需要把责任链讲清楚。

结语

OpenClaw 的安全裂缝,最值得看的地方,不是某一个项目被抓住了多少问题。

更值得看的,是个人 Agent 的责任链被提前摆到桌面上。

谁拿入口,谁就要处理身份。

谁分发 skills,谁就要处理审核。

谁接近系统权限,谁就要处理事故。

谁提供云托管,谁就要处理数据边界。

谁承诺企业可用,谁就要处理日志、合规和赔付。

第四篇里,竞品开始拆 OpenClaw 的价值链。到安全篇,这条价值链的另一面也清楚了:价值被谁拿走,责任也会跟着谁走。

下一篇再把这条线收回来:OpenClaw 之后,个人 Agent 可能不会只长成一个产品,而会长成一条产业链。入口、运行时、skills 市场、安全、托管和付费,会被不同公司分别拿走。