当 AI 助手变成攻击者跳板——Mercury 想用＂偏执级权限＂来终结这场乱局

先说几个让人坐不住的数字。

OpenClaw 在不到半年内积累了 347,000 个 GitHub Star，同期收获了 138 个 CVE——其中 7 个严重级别，49 个高危。更刺激的是，2026年2月，ClawHub 技能市场里有 12% 的技能被证实是恶意的，目前仍有 824 个以上在野活跃。

这不是概念上的安全威胁，这是真实发生的供应链攻击。

一个点击，满盘皆输

CVE-2026-25253 的攻击链是这样的：攻击者诱导 agent 访问、预览或渲染一个恶意页面——bot 在有漏洞的执行上下文中渲染了攻击者控制的内容——代码逃逸出预期隔离，在本地执行——凭证、API key 悉数外泄，连接的服务全部沦陷。

这个漏洞甚至对运行在 localhost 的实例有效：攻击利用受害者的浏览器作为跳板进入本地网络，完全绕过了”不暴露在公网就安全”的假设。

更荒诞的是——研究人员在全球 82 个国家发现了超过 135,000 个暴露在公网的 OpenClaw 实例，其中超过 15,000 个可被直接远程执行。

这就是当前 AI agent 生态的现实：Star 数暴涨，安全意识滞后，用户在毫不知情的情况下把 root 权限递给了一个随时可能被劫持的黑盒。

三个没被解决的根本问题

OpenClaw 证明了开发者想要一个能真正执行 shell 命令的本地 agent。Hermes 证明了 agent 需要持久记忆和自主能力。但这两个项目都把同一批问题留给了用户：

权限问题。 宽松到”开着大门欢迎攻击者”的默认配置，加上一个几乎没有审查机制的第三方技能市场。

成本问题。 每次对话都把完整的历史记录塞回上下文窗口，用户在月底账单到来之前永远不知道花了多少钱。

身份问题。 agent 的”人格”要么散落在十几个目录里，要么藏在一个不透明的 SQLite blob 里——你读不了，没法版本控制，也没法编辑。

Mercury 的回答：先假设 LLM 不应该有 root 权限

Mercury 由 Cosmic Stack 开发，定位是一个”先问后动”的 agent——权限加固，shell 黑名单（sudo、rm -rf / 等永远不会被执行），文件夹级读写隔离，以及待审批流程。

注意措辞：不是”提示你确认”，是永远不执行。这是架构层面的强制约束，而非提示词层面的软性劝阻。

在成本控制上，Mercury 内置每日 token 预算，跨越 70% 阈值后自动启用 Auto-Concise 模式，收紧上下文并保持 API 账单可控——同时不丢弃正在进行中的任务。

在身份系统上，Mercury 使用四个 Markdown 文件定义 agent 的灵魂：soul.md、persona.md、taste.md、heartbeat.md。你用纯文本写，用 Git 管版本，可以在 taste 文件里直接写上”我偏好深色主题和干净的 UI 组件”。这是一个你真正拥有的身份系统，不是一个你永远看不见内部的黑盒。

Mercury 的现状

Mercury 是一个相对新的项目，npm 上当前版本为 1.0.6，下载量约 2,982，几小时前刚刚更新。它不是 OpenClaw 那种量级的现象级产品，Star 数还差得远。

但这恰恰是值得关注的时间节点。

OpenClaw 的安全危机清楚说明了一件事：agent 生态里存在一个巨大的架构债。在追求功能和 Star 数的过程中，整个行业欠下了一笔权限设计的技术债，现在正在用 CVE 和盗取的 API key 偿还利息。

Mercury 的切入角度不是”更多功能”，而是”更少默认信任”。这在方向上是对的。

Mercury 开源地址：github.com/cosmicstack-labs/mercury-agent

安装：npm i -g @cosmicstack/mercury-agent && mercury