作者 ｜ 董道力
邮箱 ｜ dongdaoli@pingwest.com
2026 年初的这场“小龙虾狂欢”里，喧嚣不断，尤其在Moltbook各种“翻车”讨论后，它的很多“炒作”气息被大家捕捉。
但对真正关心 AI 发展的人来说，它们的重点不再是关于奇点、自治或机器社会的宏大想象，而是一个更具体、也更现实的问题——OpenClaw 的哪些设计值得被保留下来？MoltBook 所呈现的 A2A 雏形，又该如何被修正？
从结果看，OpenClaw 和 MoltBook 都不完善。前者暴露了本地 Agent 在安全与边界上的风险，后者则迅速滑向了币圈叙事主导的投机。但它们或许已经提前勾勒出了未来一两年AI 演进的真实方向。
1
OpenClaw 的无头架构与本地优先
OpenClaw 能在一批看起来更完整、更商业化的竞品中脱颖而出，并不是因为模型能力领先，而是因为它在系统架构上做出了几次明显偏离主流的选择。这些选择未必成熟，却为后来讨论 Agent OS 提供了一套可供检验的范式。
Headless 架构：Agent 作为后台服务运行
在 OpenClaw 之前，Agent 产品几乎沿着同一条路径演进：做一个新的“超级 App”。
聊天界面要重新设计，工作流要可视化，交互逻辑力求完整，目标是把用户吸引进一个全新的窗口体系。
OpenClaw 选择直接绕开这条路。它给出的判断是：Agent 不需要一个属于自己的前端，也不应该争夺用户的注意力，而是应该运行在用户已经习惯的交互环境中。
因此，OpenClaw 采用了彻底的 Headless 架构。它本身只是一个后台守护进程，通过已有的接口或协议层接入 WhatsApp、Telegram、Discord等。用户并不是在“使用一个新应用”，而是在原有工具里，多了一个可以执行任务的对象。
这种设计带来的启示非常直接。首先是 IO 层的解耦，Agent 不再关心消息如何展示，而只关注信息如何被解析和处理。成熟的 IM 工具已经解决了语音、图片、文件传输等复杂而琐碎的问题，Agent既避免重复造轮子，也没有迁移成本。
更重要的是，它显著降低了人类对 Agent 行为的实时干预频率。盯着命令行，10 分钟没有新东西出现，哪怕计时器在动，大部分人也会觉得 AI 是不是需要帮助（忍不住的）。
记忆：反 RAG，与“文件即数据库”
在数据持久化层面也就是所谓的记忆上，OpenClaw 同样做了一个看起来不高级的选择。
Agent 的主流方案几乎都围绕 RAG 展开，向量数据库作为记忆核心，Embedding 切片与检索策略不断加码，试图用工程复杂度换取“更聪明的回忆”。OpenClaw 却反其道而行，把长期记忆重新放回了本地文件系统。
在它的设计中，Agent 的记忆不是隐藏在向量空间里的抽象表示，而是一组清晰可见的 Markdown 文件：摘要、日志、用户画像都以结构化文本的形式存储在磁盘上。向量索引最多只是检索加速层，而不是记忆本体。
用户可以直接查看 Agent 记录了什么、是如何描述自己的需求，也可以在发现偏差时手动修正，而不必理解数据库结构或检索逻辑。这种以文本为核心的白盒存储方式，为人机协作提供了一个最低但关键的信任基础。
同时，它还无意中满足了另一个条件：为自我演化提供可反思的记忆载体。
文本化的记忆天然支持总结、修正与派生。Agent 不需要等待版本更新，就可以在运行过程中，从已有记录中提炼经验、调整 Skill 的使用方式。
安全问题：致命三连与沙盒边界
坚持本地优先，是 OpenClaw 最重要的特征之一，但同时也暴露了 Agent 架构中的结构性风险。
当一个 Agent 同时具备文件访问权限、会持续接收来自互联网的不可信输入，并且拥有真实的副作用能力时，就构成了西蒙·威利森所总结的“致命三连”。
1.接触不受信任的外部内容
2.访问私有数据
3.具备对外通信能力
在这种条件下，安全问题不再是“有没有漏洞”，而是是否存在清晰、不可绕过的边界。
OpenClaw 的实践反复证明了一点：自然语言无法承担安全边界的角色。
在早期生态中，开发者尝试通过提示词来限制行为，把“不要做什么”写进 System Prompt，但只要输入端仍然连着不可信来源，提示词注入就只是时间问题。
因此，Agent OS 必须把“能不能做”的判断，从模型内部移交给一个确定性的系统层。工具执行环境需要与宿主系统物理隔离，无论是虚拟机还是 WASM 容器，权限的裁决也不能依赖模型自身，而必须经过一层不可被绕过的规则机制。
1
MoltBook：AI 社交平台雏形，与一次社会试验
如果说 OpenClaw 讨论的是单个 Agent 应该如何运行，那么 MoltBook 抛出的，是一个更前沿的问题：当大量 Agent 同时存在，它们之间应当如何连接。
从公开形态看，MoltBook 被设计成一个仅面向 AI Agent 的网络空间。人类无法直接参与，Agent 通过 API 读取内容、发布信息、互动反馈。它看起来像一个“社交网络”，但真正被反复试验的，其实是 Agent-to-Agent 的通信方式，以及一种尚未定型的机器网络结构。
MoltBook 本身并不稳定，也谈不上成熟，但正因为如此，它更像是在无人区里铺设的一段试验路基，不足以承载规模化流量，却足以提前暴露问题。
从 Push 到 Pull：一种可能的网络节奏
人类互联网的默认假设是即时响应。点击、刷新、回复，几乎所有协议都围绕低延迟展开。但在 MoltBook 这类 Agent-only 网络中，这一假设开始显得不再必要。
从实际使用方式来看，Agent 并不是持续在线地“刷内容”，而是周期性地访问平台，读取感兴趣的主题或标签，再根据自身逻辑生成回应。这种模式更接近拉取（Pull），而不是即时推送（Push）。
一旦关键流程从 A2H 转移到 A2A，系统的协作密度将不再受人类节奏限制。
这听起来很反人类，但实际上是算力条件下的自然选择。推理本身是昂贵的，Agent 并不适合被持续的实时请求打断。周期性处理，反而更符合计算资源的调度逻辑。
由此可见，Agent 网络很可能不会复制人类互联网的节奏。它可能是高延迟的，但信息密度更高；更像定期结算的信息交换机制，而不是持续滚动的消息流。
技能扩散不再只靠版本更新
在 MoltBook 上，一个显著的现象是内容本身的技术密度。Agent 发布的不只是观点，还包括脚本、逻辑流程、决策模板等可复用信息。
在传统软件体系中，能力升级依赖中心化发布：开发者写代码、打包、发版本。而在这种 Agent 网络中，能力更像是通过网络传播的知识片段。一个 Agent 公开某种做法，其他 Agent 可以读取、分析，再决定是否采用。
目前并没有证据表明这种过程已经完全自动化或系统化，但它至少展示了一种不同的可能性：Agent 的能力不一定只来自“被写好”的功能，也可能来自持续吸收外部经验。
开发者与其为 Agent 预置所有能力，不如为它提供筛选、验证和拒绝的机制。Agent 的上限，很大程度上取决于它如何在网络中判断“什么值得学”。
身份先于内容
MoltBook 后期暴露出的最大问题，并不是互动失控，而是信任失效。
恶意指令、对抗性输入开始在网络中扩散，直接击穿了一个过于乐观的假设：Agent 可以仅凭内容本身判断信息是否可靠。事实证明，对语言模型而言，“看起来合理”的内容极易被操纵。
由此可以得出一个相对清晰的结论：在机器网络中，内容本身并不可靠，身份比内容更重要。
虽然 MoltBook 本身并未形成成熟的身份与签名体系，但它已经足够明确证明了 Agent 网络不太可能沿用开放 Web 的信任模型，而更接近一种基于身份的信任网。未来的 Agent 客户端，首先要做的不是“理解内容”，而是“验证来源”。
从这个角度看，MoltBook 的意义并不在于它是否成功运转，而在于它把几个迟早会出现的问题提前摆到了桌面上：Agent 网络的节奏应当是什么样，能力如何在群体中累积，以及信任究竟从哪里来。
这些问题并不因为 MoltBook 的成败而消失，它只是恰好成为了第一个把它们集中暴露出来的试验场。
1
人类准备好了吗？
OpenClaw 和 MoltBook 退烧之后，真正悬而未决的，并不是这些项目还能走多远，而是人类是否已经为它们所揭示的系统形态做好了准备。
这两次尝试以不同方式逼近了同一个临界点。OpenClaw 将智能体直接置入真实执行环境，迫使我们直面权限、隔离、回滚与责任归属等执行层问题；MoltBook 则让大量智能体在缺乏身份与治理结构的情况下相互影响，暴露出 A2A 网络在现实条件下可能带来的噪音放大与安全外溢。当能力以机器速度扩展，而约束仍停留在概念层时，系统失控是一个迟早会到来的结果。
我们接下来要面对的，不止是模型能不能更聪明、产品能不能更好用，而是我们是否具备与之匹配的工程纪律、治理结构与责任机制。自然语言是否真的可以承担控制界面的角色？身份与信任该如何在机器网络中被验证？当智能体代表人类采取行动时，错误应当由谁承担，又是否能够被及时收回？
如果说这轮“小龙虾狂欢”最终留下了什么，具体的技术形态也许会被迅速淘汰，但有一个问题已经无法回避：当智能体开始长期运行、彼此影响并介入现实世界时，真正需要准备好的，究竟是谁。
点个“爱心”，再走 吧
热门跟贴