OpenClaw 为什么会爆火
本页目录
OpenClaw 真正带来的，不只是一个更能聊天的模型，而是一种更容易被普通人理解的生产力形态。
如果把过去两年的大众认知简单概括一下，大多数人对 LLM 的印象其实一直停留在 chatbot。它当然有用，甚至很好用，但那种有用更多像是“隔壁家的小孩很聪明”式的惊艳：你会赞叹，会羡慕，会觉得它厉害，但你未必会立刻产生强烈的职业危机感。因为一个会聊天、会总结、会写文案的系统，和一个真正能接手任务、调用工具、产出结果的系统，在心理冲击上根本不是同一个量级。
OpenClaw 的爆火，在我看来并不意外。它第一次把 Token 的能力，以一种足够具体、足够可见、足够容易传播的形式，放到了大众面前。不是“模型会回答问题”，而是“模型开始顺着你的聊天入口去做事”。这也是为什么它给很多人的冲击，不像一次功能升级，更像是 vibe coding 初次流行时程序员受到的那种冲击波。
自媒体当然会把这种冲击包装成夸张的情绪商品，但营销噪音盖不住真正值得讨论的问题：究竟什么样的工作可以被 Token 化？当工作被 Token 化之后，产品、组织和个人的工作流会变成什么样？顺着这个问题继续往下问，我更愿意把争论收束成一句话：
OpenClaw 的成功，主要是产品形态的成功；模型智力水平与上下文管理机制的重要性排在第二位。
第一推动力，是产品形态
先说我的判断：OpenClaw 之所以出圈，首先不是因为它把某个单点技术做到极致，而是因为它把 Agent 放进了一个大众已经熟悉的产品入口里。
按照官方文档的描述，OpenClaw 的定位是一套自托管的 AI Agent 平台，可以连接大量聊天渠道，并通过技能系统把能力接到真实世界里。官方站点把它概括为“连接 50+ channels、5700+ skills、任意模型”的平台；它的 skills 和 ClawHub 机制，本质上是在给 Agent 做能力市场；而它的 workspace 与 AGENTS.default 则把记忆、工具和会话组织成了一个持续运行的工作空间。
这套东西最重要的地方，不是“先进”，而是“顺手”。它顺着用户已经存在的习惯走，而不是要求用户迁移到一种全新的交互方式。你可以继续在微信、Telegram、Slack 这一类现成入口里和 Agent 说话，而不是专门为了 Agent 再学习一套新行为模式。这一点非常关键。技术产品最终要进入日常生活，很多时候靠的不是能力边界往外推了多少，而是它有没有压低用户的行为切换成本。
这也是为什么我会想到 SillyTavern。如果长期混过角色扮演和长对话社区，就会知道，很多今天被重新包装成“上下文工程”“长期记忆”“智能体人格管理”的东西，在那边其实早就被摸索得很深入了。SillyTavern 官方文档里的 World Info / Lorebooks 很早就在做按关键词动态注入的上下文管理，后来的 Summarize 与 Smart Context 也已经在尝试摘要记忆、向量检索和超出窗口后的历史召回。
换句话说，很多人以为是这波 Agent 才第一次开始认真思考“怎么让模型记住事情、说对话、像个人”，其实角色扮演社区在 GPT-3.5 时代就已经把这条路走得很远了。世界书、角色行为关键词、记忆分层、前端渲染插件、压缩策略，这些都不新鲜。新鲜的是，OpenClaw 把这套思路从一个小众赛道，重新包装进了一个更主流的叙事里。
SillyTavern 的问题不在于技术探索不够，而在于它的产品赛道太窄。角色扮演天然是小众需求，而且很容易碰到情感依赖这类主流叙事并不欢迎的问题。更现实一点说，它也需要额外部署、需要吃上下文、需要用户迁移自己的使用习惯。相比之下，OpenClaw 抓到的是一个更容易被大众接受的故事：不是“和 AI 扮演角色”，而是“让 AI 替你干活”。
第二推动力，才是模型能力与上下文管理
当然，如果只讲产品形态，也会低估事情的另一半。OpenClaw 并不是只靠包装赢的。它能爆，是因为产品形态踩中了时机，而模型能力、工具调用和上下文工程，刚好发展到了“足够笨拙，但已经能用”的阶段。
我之所以把这一项放在第二位，是因为我并不认为今天的模型和上下文管理已经跨过了真正的临界点。它们距离“稳定地把绝大多数数字化工作 Token 化”还有距离。但这个距离正在快速缩短。
这里面最重要的一点启发是：Agent 自身也是上下文的一部分。
角色扮演系统更强调“如何让模型像一个工作之外的人”，所以它的上下文工程重点是塑造语气、人格和随机性；而面向工作的 Agent 恰好相反，它要的是逻辑一致、流程稳定、能遵循 SOP，甚至最好能把行为显式地写成代码、规则和工具接口。代码天然适合表达这种结构化抽象，而 code agent 又恰好是今天模型商业化最直接的一条主线，这使得一整套“技能安装、技能学习、经验复用、代码自修改”的叙事开始变得合理。
OpenClaw 的 skill 机制，本质上已经在推动这种复用。Hermes 则把这个方向往前推了一步。Nous Research 在 Hermes Agent 的仓库说明 里，直接把它定义成一个带内建 learning loop 的 agent：它会“从经验里创建技能，在使用中改进技能，推动自己持久化知识，并跨会话搜索过去的对话”。这很重要，因为它把很多原来隐式存在的“自进化”倾向，变成了显式产品能力。
我会把这种变化理解为：OpenClaw 更像是在告诉用户，“你可以要求 Agent 学会一个方法”；Hermes 则更进一步，开始尝试让系统自己判断，“这段经验值不值得被固化成 skill”。这仍然不是生物意义上的自我进化，但它已经足够接近一种可操作的、工程化的经验积累机制了。
所谓“进化”，在开放任务里反而很现实
我自己的研究方向里就有进化算法，所以我对“进化”这个词天然有一点 PTSD。因为经典进化算法说到底是受进化论启发的搜索机制：环境给出适应度，群体通过选择、交叉、变异在搜索空间里持续试错。它从来不神秘，本质上是一种利用评价函数驱动的随机搜索。
我以前对这种方法一直谈不上喜欢，原因也很简单：它往往没有漂亮、坚实、针对性很强的底层数学结构，普适性是有了，但可解释性和问题特异性会变弱。可一旦你把视角换到创造型工作、开放任务和很多没有明确数学描述的日常问题上，事情就变了。因为这些任务本来就很难写出精确目标函数，却很适合写出“够不够好”的评价函数。
Google DeepMind 在 AlphaEvolve 的介绍 里，把它概括成一种由大模型提出程序、由自动评估器验证、再由进化框架保留更优方案的系统。这个思路让我重新严肃看待“进化”在 Agent 上的价值。对于大量模糊但可评价的任务，进化式搜索未必优雅，却很实用。尤其是在行为策略、规则探索、提示词变体这些难以一次性写对的对象上，它天然有用。
问题当然也很现实：代价极高。无论是行为进化还是提示词进化，背后烧掉的 Token 都会非常夸张。所以它更适合那些评价明确、回报足够高、而且失败成本可控的探索任务，而不适合被浪漫化成“通用万能药”。
我对 myopenclaw 的一个核心判断：别轻易丢上下文
说回我自己的系统。我最近一直在折腾 myopenclaw 的上下文管理，试过基于窗口的裁剪、裁剪加压缩、裁剪加压缩再接一层 LLM，也试过 RAG。最后我的感受都不算好，因为所有方案都绕不开同一个问题：
在固定 token budget 下，你凭什么知道什么该丢，什么不该丢？
这件事几乎无解。因为你无法预知用户的下一句会和什么相关。你今天丢掉的一段失败尝试，明天可能正好就是防止 Agent 重复犯错的关键线索。丢消息，本质上是一个非常昂贵的操作，因为它意味着这些上下文可能永远不会再回来。
所以我现在更偏向一个保守但可靠的思路：以 session 为单位，尽可能原样存储对话，再把“检索什么”从“预先裁剪什么”里分离出来。既然上下文都存下来了，那么管理的关键就不再是删减，而是检索。
这也是我会去看 OpenViking 的原因。按照它的 GitHub 说明，它把自己定义为“面向 AI Agent 的 Context Database”，核心思想是用文件系统范式统一管理 memory、resources 和 skills，并通过 L0/L1/L2 分层加载、目录递归检索和可视化检索路径来降低 token 成本、提升可观察性。这个抽象非常漂亮，因为它不像传统 RAG 那样把所有东西都打平丢进一个向量池里，而是给上下文本身建立层次结构。
它最打动我的地方，不是“更聪明”，而是“更可见”。你能看到检索路径，能看到是在哪一层丢了信息，也更容易把 Agent 的上下文管理理解成一个显式系统，而不是一团黑箱。
但我最终还是没有把 OpenViking 作为实时主上下文管理器直接接进来。原因也很直接：
- 它解决了“怎么高效检索”，却没有替你解决“为什么要这样检索”。
- 它的很多收益建立在分层摘要和显式提交之上，而实时 Agent 往往不愿意在主链路里承担这么重的交互与时延。
- 一旦你为了实时性做混合方案，本地窗口策略和外部上下文系统就会出现双重抽象，最后你很难判断到底是哪一层真的有效。
所以我现在更相信一种双轨结构：本地轻量窗口管理负责实时性，像 OpenViking 这样的外部上下文系统负责按需深挖。
换句话说，我不想让 OpenViking 代替当前会话的主上下文；我更愿意把它做成一个 skill，在知识库问答、个性化召回、跨会话检索这些真正需要“深挖历史”的场景里主动调用。这样它的分层摘要、RAG 和渐进式披露反而能发挥更稳定的价值。
真正值得继续探索的，不只是 Agent，而是 Agent 的上下文操作系统
也正因为如此，我反而觉得 OpenClaw 和 Hermes 里的那套“自我进化”思路，放在 OpenViking 这一层可能更合适。
原因很简单。OpenViking 原本就把对话、技能、工具和资源组织进了统一的上下文文件系统里，还天然支持摘要、嵌入、关系和多用户多 Agent 管理。那么不管是模式识别、skill 生成、skill 调用统计，还是用户偏好跟踪，它其实都更像是一个合适的“进化土壤”。如果再进一步，我甚至觉得 Agent 在对话过程中应该拥有一个专门管理 OpenViking 仓库的 git。这样上下文不只是被读写，还能被版本化、比较、回滚和审计。
这也是我对 myopenclaw 现在最核心的一个想法：不要迷信某一种完美的上下文管理方案，而是去构造一种快慢分层、可回溯、可调用、可演化的上下文基础设施。
OpenClaw 爆火，不是因为世界突然等到了一个已经完全成熟的 Agent，也不是因为模型忽然跨过了所有关键门槛。更接近现实的解释是：它第一次把 Token 的生产力，以产品化的方式塞进了大众已经熟悉的生活入口；与此同时，技能系统、代码 Agent、上下文工程和经验复用，又刚好发展到了足以让这种形态成立的程度。
它真正让人不安的地方，也不在于“聊天机器人更会聊天了”，而在于我们第一次较大规模地看见：Token 可以开始接手一部分数字劳动，而且这种接手会沿着产品入口、上下文基础设施和技能复用机制不断深化。
接下来真正值得看的，未必只是模型还能再聪明多少，而是我们到底会把怎样的工作流、怎样的上下文系统、怎样的 Agent 演化机制，变成下一代数字生产力的默认接口。