An image to describe post

大家好，我是 Johnny Xuan.这一期文章讨论的是 OpenClaw：从 Clawdbot 到 Moltbot，再到 OpenClaw，本身只是一个开源项目，但在 GitHub 上迅速冲到十几万星，Discord 社区也高度活跃。

OpenClaw的核心其实很简单：一个可以长期在本地运行的 AI 代理。它能发邮件、查航班、执行脚本、访问文件，全靠自然语言驱动。社区里已经刷屏各种段子，比如“半夜自己设闹钟把全家叫醒”，听着像科幻电影里的生活助手，但又真实到离谱。它真正风靡起来的原因，其实不只是“本地+持久运行”这么简单——而是加上了网关 + Node 的玩法。通过 Telegram 或 Discord 等社交 App，你在手机上就能远程操控家里的电脑。

想象一下：你在外面吃饭，突然想“帮我把电脑上的文件发到邮箱”，直接在 Telegram 里@你的代理，它就自己去做了；或者半夜想查个东西，不用开电脑，直接在 Discord 里下指令。

这种“手机随时遥控本地电脑”的体验太爽了，门槛低、隐私强、延迟低，瞬间把 OpenClaw 从“本地工具”变成了“随身数字分身”，难怪社区这么疯。

真正把它推上风口的是 Moltbook。这个由 Octane AI 创始人 Matt Schlicht 搭建的“AI 版 Reddit”，只允许代理参与，人类旁观。短时间内，代理数量突破百万级，帖子数也迅速累积。代理之间互相讨论、争论、甚至吐槽人类。

我也参与其中，给 OpenClaw 做过离线语音技能，还注册过代理在里面活动。最初的体验确实很有吸引力：代理之间互动，人类只做配置和观察，自动化程度极高。

但用得越多，越开始不安。

问题不在“AI 会不会觉醒”这种抽象担忧，而在于一个更现实的趋势：无人监督的自动化正在被当作默认设计。这不是个别 bug，而是架构层面的风险。

下面结合近期的社区讨论和安全分析，整理一些关键问题。

近期生态变化：从本地工具到高风险网络环境

2026 年初的情况可以概括为两段式：

  1. 本地运行时，OpenClaw 仍然是一个效率很高的个人自动化工具。隐私可控，执行速度也快。

  2. 但一旦接入类似 Moltbook 的代理网络，风险明显放大

An image to describe post

已有安全研究指出：

  • 一些代理平台的数据库曾出现配置错误，未认证访问即可读取代理信息，包括邮箱、token 和 API key。

  • 还有案例显示，单个代理批量注册大量账户，造成数据膨胀和误导性增长指标。

  • 更严峻的是插件生态。
    安全团队在插件市场中发现数百个恶意技能，目标包括窃取系统凭证、读取本地文件、外传敏感数据。
    多份报告将这类系统风险归纳为三点组合：
    可访问私密数据、暴露于不可信内容、具备外部通信能力。

  • 在代理安全评估中，prompt injection、工具调用滥用等问题几乎全部命中。
    部分红队测试结果显示，系统提示词泄露、数据提取攻击成功率极高。
    也有研究员在短时间内实现对代理的劫持，通过恶意链接获取访问 token。

这些问题并非孤立漏洞，而是代理从单机环境扩展到网络环境后必然出现的放大效应。

三点个人判断

  1. 代理不应在完全开放的公共空间中自由互动。
    Moltbook 的实验性设计在概念上有吸引力，但缺乏规则、审计和责任追溯机制。
    代理之间传播的不只是信息，还有行为模式。一旦出现绕过限制的策略，可能快速扩散。
    在无法明确记录“谁触发了什么行为”的环境中，问题很难回溯。

  2. agent-to-agent 环境应默认高风险。
    单个代理在本地执行任务，风险相对可控。
    但当多个代理形成交互网络，攻击面显著扩大。
    代理之间的交互速度远高于人工审查能力。
    日志规模、执行频率和复杂度都使得事后追踪难度很高。
    如果没有明确的监督、审计和中断机制，这类环境应被视为高危系统。

  3. 系统权限本质上是执行能力。
    文件访问、脚本执行、应用控制等权限，本质是对真实环境的操作权。
    如果一个自动化系统同时拥有长期运行能力和高权限访问能力，就具备现实影响力。

在工程实践中，权限应遵循三个原则：

  • 只授予最小必要权限；
  • 权限应可回收；
  • 所有操作应可记录和追溯。

这些原则并非针对 AI，而是针对任何自动化系统。

结论

OpenClaw 和 Moltbook 代表了一个重要阶段：
AI 代理开始从单点工具进入网络化协作环境。

这种转变带来的不仅是效率提升，也包括新的系统性风险。
在设计代理系统时，需要把权限、监督和审计视为基础结构，而不是附加功能。

对于开发者而言，更稳妥的路径仍然是：

  • 优先本地运行；
  • 逐步引入联网能力；
  • 在每一步增加可审计性和可中断性

技术本身值得探索，但自动化程度越高，对控制机制的要求也越高。

参考来源