夜雨聆风上午十点，腾讯的工程师们在广场上摆了几张桌子，免费帮人装 OpenClaw。结果队伍一路排到了马路对面，将近一千人。有人抱着 NAS，有人背着 MacBook，还有人拎着迷你主机——像极了十年前刷安卓 ROM 的极客聚会。
第二天，全国人大广东代表团小组会议上，中国工程院院士高文说了一句让全场笑出来的话——"养龙虾这么火，连马化腾都没想到。"
马化腾大概确实没想到。他当晚在朋友圈发了条动态，语气罕见地带着点懵："自研龙虾、本地虾、云端虾、企业虾、云桌面虾、安全隔离虾房、云保安、知识库……还有一批产品陆续赶来。"
更魔幻的是，社交平台上已经有人做起了生意：代装 OpenClaw，500 元起步。卸载？也收费，299。
一只开源的"龙虾"，怎么就把中国互联网搅成了这样？
先搞清楚：这只"龙虾"到底是什么
OpenClaw 不是一个聊天机器人。
这句话很重要，所以我再说一遍：它不是聊天机器人。
你用 ChatGPT 也好，用 Kimi 也好，用豆包也好，本质上都是一个模式——你打字，它回话。它能帮你写邮件，但发不出去；能告诉你怎么订机票，但订不了。你还是得自己动手。
OpenClaw 不一样。你在微信上给它发一句"帮我把收件箱里的垃圾邮件清了，重要的归类摘要"，它真的会去操作你的邮箱，真的清完，真的把摘要发回给你。你在 Telegram 上说"帮我把这个 bug 修了然后跑一遍测试"，它真的会打开终端，改代码，跑测试，把结果贴回来。
这东西跑在你自己的电脑上，24 小时不关机，通过你每天在用的聊天软件接受指令。 数据存在本地，模型随你选——Claude、GPT、DeepSeek、Kimi 都行。代码完全开源，MIT 协议，GitHub 上 24 万 Star。
它的创造者是奥地利开发者 Peter Steinberger，PSPDFKit 的创始人。最早叫 Clawdbot（致敬 Claude），被 Anthropic 投诉商标后改名 Moltbot，三天后又改成 OpenClaw。2026 年 2 月，Steinberger 宣布加入 OpenAI，项目移交开源基金会。
但名字不重要。重要的是，这个东西代表了 AI 领域一个真正的范式转移：从"能说"到"能干"。学术界给这个方向起了个名字，叫 AI Agent（智能体）。
从"偏科天才"到"全能选手"：工具使用的学术起源
OpenClaw 能干活，靠的不是什么黑魔法，而是近三年学术界一系列突破的工程化落地。
第一个关键突破来自 Meta AI。
2023 年，Timo Schick 等人在 NeurIPS 上发表了一篇重要论文——《Toolformer: Language Models Can Teach Themselves to Use Tools》（工具生成器：语言模型可以自学使用工具）。论文开头就捅破了一层窗户纸：
"Language models exhibit remarkable abilities to solve new tasks from just a few examples or textual instructions, especially at scale. They also, paradoxically, struggle with basic functionality, such as arithmetic or factual lookup, where much simpler and smaller models excel."
（语言模型展现出了仅凭少量示例或文本指令就能解决新任务的卓越能力，尤其是在规模化之后。然而矛盾的是，它们在算术运算或事实查找等基础功能上却力不从心——而这些恰恰是更简单、更小的模型擅长的。）
这段话精准刻画了大模型的核心困境：它是一个严重偏科的天才。 能洋洋洒洒写几万字的哲学论文，但你让它算个三位数乘法，或者查一下今天星期几，它就彻底懵了。
Schick 等人的解法：既然算术不行，就让模型自己学会调计算器；查事实不行，就让它学会调搜索引擎。关键是"自己学会"——不需要人工标注海量数据告诉它"这里该用工具了"，模型通过自监督的方式，自己摸索出什么时候该伸手、伸哪只手、传什么参数。论文把这个能力概括为：模型被训练去自主决定 "which APIs to call, when to call them, what arguments to pass, and how to best incorporate the results into future token prediction"（调用哪些 API、何时调用、传什么参数，以及如何将返回结果最佳地融入后续的 token 预测）。
这个思想，是 OpenClaw 整个 Skills 系统的理论基石。后面会详细讲。
但光会用工具还不够。你得教 AI "边想边干"。
ReAct：思考-行动-观察的螺旋
这是第二个关键突破，也是 OpenClaw 架构的理论心脏。
2022 年底，普林斯顿大学的 Shunyu Yao 等人提出了 ReAct 框架，论文题为 ReAct: Synergizing Reasoning and Acting in Language Models（在语言模型中协同推理与行动），发表于 ICLR 2023。
在此之前，学术界研究大模型的两种核心能力——推理和行动——基本上是割裂的。推理就是让模型用思维链（Chain-of-Thought）一步步想清楚；行动就是让模型去调用 API、操作环境。两条线各走各的。
Yao 等人说这不对。人类干活从来不是"先想完再做"或者"先做完再想"，而是边做边想、做一步看一步。 论文原文对这个协同机制的描述非常精准：
"Reasoning traces help the model induce, track, and update action plans as well as handle exceptions, while actions allow it to interface with external sources, such as knowledge bases or environments, to gather additional information."
（推理轨迹帮助模型归纳、追踪和更新行动计划，并处理异常情况；而行动则允许模型与外部资源——如知识库或环境——进行交互，以获取额外信息。）
换句话说：推理给行动指方向，行动给推理供弹药。两者不是先后关系，是交替螺旋。
这个螺旋在论文里被形式化为三个阶段的循环：
Thought（思考）→ Action（行动）→ Observation（观察）→ Thought → Action → ……
具体来说：模型先生成一段内心推理——"用户要查的是上周的会议录音，我需要先调用文件搜索工具"；然后执行一个动作——调用文件系统 API 去搜索；工具返回结果后，模型观察到"找到了三个音频文件，但用户可能只需要周三那场"，于是进入下一轮思考和行动。
这个循环，就是 OpenClaw 的引擎。理解了它，你就理解了 OpenClaw 为什么能"自己干活"。
拆解 OpenClaw：五层架构，一只龙虾的"解剖学"
理论讲完了，现在拆机器看看里面到底怎么转的。
OpenClaw 的整体架构是一个经典的 Hub-and-Spoke（轴辐式）模型：一个中央 Gateway 作为控制面板，连接着上游的多个聊天平台（WhatsApp、微信、Telegram、Slack……）和下游的各种工具能力。拆开来看，可以分五层。
第一层：消息入口（Channel Adapters）。 OpenClaw 为每个聊天平台写了一个适配器，把 WhatsApp 消息、Telegram 消息、微信消息统一"翻译"成内部的标准格式。不管你从哪个 App 发指令，到了 Gateway 这一层都长一样。这就像是一个多语种翻译官，不管来的人说英语、中文还是法语，翻译完都变成同一种"内部语言"给后面的系统处理。
第二层：Gateway（网关 / 控制面板）。 这是整个系统的心脏。它是一个长期运行的 Node.js 进程，默认监听 18789 端口。Gateway 的职责包括：会话管理（谁在跟我说话、上次说到哪了）、消息路由（这条消息该给哪个 Agent 处理）、认证鉴权（这个人有没有权限）、健康监控（各个聊天渠道的连接还正常吗）。它可以安装为系统守护进程（macOS 的 launchd 或 Linux 的 systemd），开机自启、后台常驻——这就是 OpenClaw 能 24 小时在线的技术基础。
第三层：Agent Runtime（智能体运行时）。 这里跑的就是前面讲的 ReAct 循环。当 Gateway 把一条消息派发过来，Runtime 会：(1) 加载当前会话的历史记录；(2) 从记忆系统中检索相关上下文；(3) 筛选可能用到的 Skills 描述；(4) 把上述所有信息组装成一个完整的系统提示词（System Prompt），发给 LLM；(5) LLM 返回"我想调用 XX 工具"；(6) Runtime 执行工具调用，拿到结果；(7) 把结果喂回 LLM，进入下一轮循环。如此往复，直到 LLM 判断任务完成，生成最终回复。
第四层：Tools & Skills（工具和技能）。 Tools 是内置的基础能力——执行 Shell 命令、读写文件、控制浏览器。Skills 是社区扩展的高级能力——每个 Skill 是一个目录，核心文件是 SKILL.md（后面会详细讲）。工具调用受策略控制，可以配置黑白名单和沙箱隔离。
第五层：Memory（记忆系统）。 这是让 OpenClaw 不再"金鱼脑"的关键。所有对话记录、用户偏好、任务笔记都以 Markdown 文件存储在本地磁盘。系统会把这些文件切成约 400 Token 的小块，用嵌入模型（Embedding Model）转成向量，存进本地的 SQLite 数据库（可选配 sqlite-vec 加速）。检索时同时走两条路：向量相似度（语义匹配，比如"运行网关的那台机器"能匹配到"Mac Studio"）和 BM25 关键词匹配（精确命中，比如错误代码、变量名这种纯文本符号）。最终把两个分数加权融合，召回最相关的记忆片段注入上下文。
如果你读过我上一篇文章——《深入浅出聊 RAG》，会发现这套记忆系统的底层逻辑跟 Lewis 等人 2020 年提出的 RAG 架构如出一辙。Lewis 等人在那篇论文里定义了两种记忆系统：
"We refer to the BART generator parameters θ as the parametric memory... We refer to the document index as the non-parametric memory."
（我们将 BART 生成器的参数 θ 称为参数化内存……将文档索引称为非参数化内存。）
在 OpenClaw 的语境里，LLM 的参数权重就是"参数化内存"——它知道怎么推理、怎么生成语言；本地的 Markdown 文件 + SQLite 向量索引就是"非参数化内存"**——它提供了具体的历史上下文和用户偏好。两者协同，才让一个无状态的语言模型表现得像一个有记忆的助手。
还有一个精妙的细节：当会话的上下文窗口快被撑满时（模型能处理的 Token 总量是有限的），OpenClaw 会触发一次"静默记忆刷写"——悄悄让模型把当前对话里的关键信息写成笔记保存到磁盘，然后对上下文做压缩摘要。这就像一个勤快的秘书，在你忙着开会的时候默默把重点记在笔记本上，等下次需要的时候再翻出来。
Skills 的调度：5700 个技能，怎么知道该用哪个？
前面说 OpenClaw 有 5700 多个社区技能。一个自然的问题是：当用户丢进来一句模糊的指令，系统怎么知道该调哪个 Skill？
这里面的工程设计很有讲究。
OpenClaw 不会把所有 Skill 的描述一股脑塞进提示词——那上下文窗口直接爆炸。 它采用的是"按需注入"（Skill Discovery）策略：Runtime 在组装提示词时，先把所有已安装的 Skill 作为元数据列表供模型浏览，然后模型根据当前任务的语义，主动"按需阅读"相关 Skill 的详细说明。一篇技术分析把这个过程比作"一个开发者面前摆着一整排文档，但他不会启动时把每一份都读完，而是需要什么查什么。"
这个筛选过程，底层逻辑跟 RAG 的检索增强是相通的：把用户意图编码成向量，再去技能库里做语义匹配——在本地，这往往只需要跑一个轻量的嵌入模型（比如 OpenAI 的 text-embedding 或本地 GGUF 格式的小模型），外挂一个像 SQLite + sqlite-vec 这样的极简向量存储就能搞定。换句话说，OpenClaw 在"思考该用什么工具"这件事上，本身就在跑一个微型的 RAG 流程。
当然，这个检索过程远没有理论上那么优雅。实际跑的时候，SKILL.md 写得含糊的就容易被漏掉，写得太宽泛的又容易被误召回。社区里经常有人吐槽"明明装了这个 Skill 但 Agent 就是不用它"——大概率就是元数据描述没写好，语义匹配没命中。这种"脏活"，才是工程落地的真实质感。
"Token 黑洞"：龙虾的真实代价
理解了上面的架构，你就能明白为什么 OpenClaw 这么烧钱。
36 氪有一篇报道的标题取得很到位——"中国正在卷起一场 OpenClaw 风暴"。文章里提了一个概念，叫"Token 黑洞"。
传统的 AI 聊天，你问一句它答一句，消耗几百个 Token，几分钱的事。但 OpenClaw 不一样。你给它下一个稍微复杂点的指令——比如"帮我研究一下这三家公司的财报，对比整理成表格"——它内部的 ReAct 循环可能要转几十圈：搜索、抓取网页、提取数据、对比分析、生成表格、检查格式、修正错误……每一圈都要把完整的上下文（系统提示词 + 对话历史 + 工具描述 + 记忆片段）打包塞进模型。一个复杂任务跑下来，Token 消耗量是普通对话的几十倍甚至上百倍。
腾讯 WorkBuddy 的产品负责人汪晟杰在接受采访时也提到了这个问题：OpenClaw"比较费钱"的根源在于"它在背后默默地在做自主进化记录，上下文越来越长"。对没有技术背景的用户来说，这笔账几乎无法预估。
这也解释了一个看似反常识的现象：为什么腾讯、阿里这些云厂商愿意倒贴人力去线下"摆摊"帮人装龙虾？ 因为它们推的不是原版 OpenClaw——而是预置了自家大模型 API 的"特供版"。腾讯的 QClaw 和 WorkBuddy 内置了混元模型的算力，阿里云的一键部署镜像默认对接通义千问。用户拆箱即用，不需要自己去填 OpenAI 的 API Key。每装一个，就等于在用户设备上部署了一台 24 小时运转的"算力抽水机"——只要推理请求指向自家云服务，海量的微小调用就会源源不断汇聚成持续的现金流。
更深一层——用户在指导 Agent、纠正它错误的过程中，其实在免费为大厂提供最高质量的强化学习训练数据。每一次"不对，我要的不是这个"的反馈，每一次"重新来，按照这个格式"的修正，都是珍贵的任务轨迹数据（Trajectory Data）。就像特斯拉通过路上行驶的几百万辆车收集真实路况数据来训练 FSD 一样，大厂推广 Agent 本质上是一场分布式的数据众包。
这一层，大部分"养虾"教程不会告诉你。
安全：上了膛的枪
OpenClaw 的安全问题不是"可能会出事"，而是"已经出事了"。
根据国家信息安全漏洞库（CNNVD）的统计，2026 年 1 月到 3 月 9 日，共采集 OpenClaw 相关漏洞 82 个，其中超危漏洞 12 个，高危漏洞 21 个。 漏洞类型涵盖访问控制错误、代码注入、路径遍历。国家互联网应急中心 3 月 10 日发布风险提示，点名四类核心隐患：提示词注入、误操作删除、功能插件投毒，以及关键行业数据泄露。
还有一个已经被分配了 CVE 编号的高危漏洞（CVE-2026-25253，CVSS 评分 8.8）：攻击者可以通过一个恶意网页窃取 Gateway 的认证令牌，进而在宿主机上执行任意命令。安全研究公司 Censys 扫描发现，超过 30,000 个 OpenClaw 实例暴露在公网上——因为默认配置绑定的是 0.0.0.0，在 VPS 上部署时如果不配防火墙，相当于裸奔。
多所高校明令禁止在办公电脑上安装 OpenClaw。中国政府限制国有企业和政府机构运行该软件。
Cisco 的安全团队测试了一个第三方 Skill，发现它在用户不知情的情况下进行数据窃取。有用户报告 Agent 在自动清理邮箱时误删了整个收件箱。还有那个被广泛报道的案例：一个学生让 OpenClaw 自由探索可用平台，结果它自己去 AI 社交平台注册了账号，替这位同学创建了约会档案并开始筛选对象——全程未经同意。
OpenClaw 的一位核心维护者在 Discord 上留下了一句几乎可以当安全公告用的话："如果你连命令行都不会用，这个项目对你来说太危险了。"
Yao 等人在 ReAct 论文里其实提到了一个值得注意的方向。推理痕迹（Reasoning Traces）除了提升任务表现，还有另一个重要价值——可审计性。论文末尾写道：
"We believe this is an exciting direction for human alignment and leave more systematic study as future work."
（我们认为这是人机对齐的一个令人兴奋的方向，将更系统的研究留给未来的工作。）
注意，他用的词不是"AI capability"（AI 能力），而是"human alignment"（人机对齐）。这暗示着：让 AI 变得更强不是终点，让它的行为可追溯、可审计、可干预才是。你能回溯模型每一步的推理过程，看到它为什么选了这个工具、为什么传了这个参数。这为人类监管提供了理论上的可能。
但"理论上的可能"和"凌晨三点你的 Agent 在自动执行一个十几步工作流时你真的会去看日志"之间，隔着一整个太平洋。
写在最后
2026 年 3 月初，当腾讯工程师在深圳摆摊装龙虾的时候，可能没几个排队的人认真想过这只龙虾背后的学术谱系——从 2020 年 Lewis 等人的 RAG 奠定"让模型学会查资料"的范式，到 2023 年 Schick 等人的 Toolformer 教模型"自己动手用工具"，再到 Yao 等人的 ReAct 把"想"和"做"缝合成一个持续转动的循环。
这些论文里的数学公式和实验数据，最终变成了你微信里那个能帮你清邮箱、跑代码、查天气的龙虾。
但这套系统目前依然像一个拿着上膛手枪的五岁小孩。它能做的事情多得惊人，它能搞砸的事情也多得惊人。82 个已知漏洞、30,000 个裸奔的公网实例、一个 CVSS 8.8 的远程代码执行——这些不是杞人忧天，而是一面镜子。
当 AI 从"动嘴"变成"动手"的时候，我们准备好了吗？
OpenClaw 的故事才刚开始。而真正的挑战，已经从 GitHub 的代码仓库，转移到了权限管理的配置文件里。
参考文献：
Yao, S., Zhao, J., Yu, D. 等 (2023)。ReAct: Synergizing Reasoning and Acting in Language Models。ICLR 2023。arXiv: 2210.03629
Schick, T., Dwivedi-Yu, J., Dessì, R. 等 (2023)。Toolformer: Language Models Can Teach Themselves to Use Tools。NeurIPS 2023。arXiv: 2302.04761
Lewis, P., Perez, E., Piktus, A. 等 (2020)。Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。NeurIPS 2020。arXiv: 2005.11401
