大龙虾爆火——扒一扒OpenClaw到底是个什么东西

序

最近打开任何技术社区，都逃不掉一个词——OpenClaw。

GitHub两个月25万Star，史上增长最快的开源项目。Discord社区挤爆了，Mac Mini被买到断货，连政府工作报告都在提"AI Agent"。

朋友圈、知乎、掘金、B站、YouTube——所有人都在聊这只"大龙虾"。

我一开始也挺好奇的，心想这东西得多厉害才能火成这样。然后花了两天时间把它的源码、架构文档、社区讨论翻了个遍。

翻完之后的感受挺有意思的——OpenClaw的很多核心设计，和我之前在几个项目里做的事情有很高的相似度。比如数字分身系统Eucalyptus的Skill编排，以及Spring AI Agent平台的ReAct循环和工具注册机制。

不是说OpenClaw抄了谁，而是Agent这条路上的很多设计思路，殊途同归是必然的。

所以这篇文章，我想从一个踩过类似坑的人的角度，聊聊OpenClaw到底是个什么东西，为什么能火成这样，以及——它到底有没有被过度营销。

OpenClaw是什么

先给不了解的人快速科普一下。

OpenClaw，原名Clawdbot，后来改名了。昵称"大龙虾"。是一个开源的AI Agent项目。

免费且安装容易（即使如此也有大批的人在小红书等平台上贩卖免费安装或帮安装教程 (ˉ▽ˉ；)...）

用一句话概括：一个跑在你自己电脑上的AI助手，通过微信/WhatsApp/Telegram等聊天工具跟你对话，能帮你收发邮件、管理日程、清理收件箱、查询信息，甚至帮你值机。

你和OpenClaw的交互方式:

你: (在WhatsApp上发消息) "帮我查一下明天的航班"
大龙虾: [思考: 需要查航班信息]
        [调用: 航班查询工具]
        [结果: 明天CA1234, 08:30起飞]
        "您明天有一班CA1234, 早上8:30从浦东T2起飞,
         建议提前2小时到机场。需要我帮您在线值机吗？"

你: "好"
大龙虾: [调用: 在线值机工具]
        "已为您完成值机, 座位32A靠窗, 登机牌已发送到您的邮箱。"

看起来很酷对吧？

而且它是开源的，代码全在GitHub上，跑在你自己的机器上，数据不上传云端。这一点确实比很多商业AI产品让人放心。

它的架构拆开来看

先别被43万行TypeScript吓到。把OpenClaw的架构拆开来看，核心就是三层：

┌─────────────────────────────────────────────┐
│            Channel（渠道层）                  │
│   WhatsApp / Telegram / 微信 / Discord / ... │
│   负责: 接收消息、发送回复                     │
├─────────────────────────────────────────────┤
│            Gateway（网关层）                  │
│   大脑: LLM决策 + ReAct循环 + 工具调度        │
│   负责: 理解意图、调用工具、编排流程            │
├─────────────────────────────────────────────┤
│            Node（节点层）                     │
│   执行手脚: Skills / MCP / 系统命令            │
│   负责: 实际执行操作（发邮件、查信息等）        │
└─────────────────────────────────────────────┘

再加上一个三层记忆系统：

L1 短期记忆:  当前会话上下文（对话历史）
L2 中期记忆:  跨会话的关键信息（用户偏好、常用操作）
L3 长期记忆:  持久化的知识库（文档、笔记、经验）

以及一个九层权限系统——控制AI能做什么不能做什么。

这就是OpenClaw的全部核心架构。说实话，设计得确实不错。三层解耦、插件化Skill、多模型支持，这些都是很好的工程实践。

但我要说的是——这些概念，没有一个是从OpenClaw开始的新东西。

似曾相识的设计

拆完架构之后，我发现很多地方有种似曾相识的感觉。OpenClaw的设计思路，和我之前在几个项目里的实践有不少重合。不是说谁抄了谁——Agent领域的很多设计本来就是殊途同归的。

ReAct循环 + 工具调用

OpenClaw的核心是ReAct（Reasoning + Acting）循环——AI先思考，然后调用工具，观察结果，再继续思考。

这个模式我在搭Spring AI Agent平台的时候用过类似的设计。Spring AI 1.0内置了ReAct循环，通过@Tool注解注册工具，ChatClient自动编排ReAct流程。

OpenClaw的ReAct:
  Thought → Action → Observation → 循环

项目中的ReAct:
  ChatClient.prompt()
    .system(systemPrompt)        // 角色设定
    .messages(historyMessages)   // 历史
    .user(userMessage)           // 当前消息
    .toolCallbacks(tools)        // 工具
    .call()                      // Spring AI自动ReAct

思路是一样的：思考 → 行动 → 观察 → 继续思考。

Skills技能系统

OpenClaw最被吹捧的一个特性是Skills——可扩展的技能插件。社区里已经有人贡献了几百个Skill，从查天气到管理邮件到控制智能家居。

Skills本质上是工具调用的封装——把一个能力（查天气、发邮件、管日程）封装成一个标准化的模块，AI按需调用。

有点类似于在Spring AI Agent平台里则通过@Tool注解注册工具，Spring容器启动时自动扫描。新增工具只需要写一个带@Tool注解的方法，零配置。

OpenClaw的Skill:
  一个TypeScript模块，定义了工具的描述、参数、执行逻辑
  通过配置文件注册到Agent中

项目的@Tool:
  @Tool(description = "查询用户")
  public String queryUser(@ToolParam(description = "用户名") String name)

  Spring AI自动注册，自动生成工具描述给LLM。

原理一样，技术栈不同。OpenClaw用的TypeScript

对话记忆

OpenClaw的三层记忆（L1/L2/L3）被很多人称为"创新设计"。

但短期记忆 + 长期记忆的分层思路，在Agent领域算是比较标准的设计了。

记忆系统对比:
──────────────────────────────────────────
OpenClaw:      L1(会话) + L2(偏好) + L3(知识库)
Agent平台:     Redis(短期) + MySQL(长期)

核心逻辑都是:
  把历史消息和关键信息存下来
  每次对话时加载到上下文里
  区别在于分层策略和存储介质
──────────────────────────────────────────

多平台接入

OpenClaw被吹最多的一个卖点是：接入20+通信平台——WhatsApp、Telegram、微信、Discord、Slack、Signal、iMessage……

这个确实做得好。通过Gateway统一管理所有通信渠道，上层只管处理逻辑，不用关心消息从哪来。

从设计模式的角度看，这就是适配器模式——每种通信平台写一个适配器，统一收发消息的接口。

本质:
  Gateway → 适配每种IM的收发API → 统一消息格式 → 交给AI处理

说白了就是:
  一个消息中间件 + N个IM适配器

技术难度不算高，但工程量确实大。适配20多个平台的API、处理各种消息格式、维持长连接——这些脏活累活确实值得尊重，也是OpenClaw的核心壁垒之一。

那OpenClaw到底值不值得百万Star

OpenClaw有它真正做得好的地方，而且有些地方确实是个人项目比不了的。

做得好的

1. 工程完成度极高

43万行TypeScript，不是随便写的。三层解耦、九层权限、20+平台适配、流式响应、错误恢复——这些基础设施确实扎实。

拿我自己来说，我的Agent平台和Eucalyptus的核心架构虽然类似，但论完成度和可用性，跟OpenClaw确实有差距。人家是一个完整的、可以直接部署使用的产品，我做的是架构原型和设计验证。这是完全不同的量级。

2. 降低使用门槛

这是OpenClaw最核心的贡献——让普通人也能拥有一个AI Agent。

以前你要搞一个AI助手，得自己搭后端、接模型、写工具、处理对话。现在装个OpenClaw，连上你的WhatsApp，就能用了。

这就像当年的WordPress——做网站这件事从"写代码"变成了"装插件"。OpenClaw把拥有AI Agent这件事从"搭系统"变成了"装Skill"。

3. 社区生态

这是百万Star最大的价值。有人的地方就有生态。几百个Skill、大量教程、活跃的社区——这些东西是任何个人项目都做不到的。

但也没有营销号说的那么神

营销号的经典话术：

"OpenClaw将取代所有个人助理！"
"有了大龙虾，你不需要秘书了！"
"AI Agent时代正式到来，OpenClaw是第一个真正的超级智能体！"

冷静一下。

它就是一个CLI Agent + IM网关 + Skill插件系统。

核心流程：

收到消息 → LLM理解意图 → 匹配Skill → 执行操作 → 返回结果

这个流程，任何一个有LLM API调用经验的开发者，用一周时间都能搭出来。

OpenClaw真正厉害的不是概念创新，而是把已有的技术组合在一起，做成了一个完整的、好用的、开源的产品。

这不叫发明，叫工程整合。

怎么快速实现一个"大龙虾"

既然核心不难，那如果要自己搞一个类似的东西，最短路径是什么？

方案一：Claude Code + 提示词工程

这是最快的方式。零代码，纯提示词驱动。

核心思路:
──────────────────────────────────────
1. 用Claude Code作为底层引擎
2. 写一套完整的角色设定提示词
3. 定义Skills（每个Skill就是一个提示词模块）
4. 定义Agents（每个Agent有专属的Skill集）
5. 通过文件系统管理记忆和知识库

依赖:
  Claude Code + 提示词文件

优点:  零代码，灵活，迭代快
缺点:  依赖Claude CLI，不支持IM接入
──────────────────────────────────────

方案二：Spring AI + Java

适合企业场景。

核心思路:
──────────────────────────────────────
1. Spring AI作为LLM调用层
2. @Tool注解注册工具（Skills）
3. ChatClient内置ReAct循环
4. ChatMemory管理对话记忆
5. 自己加一层Gateway处理多渠道接入

依赖:
  Spring Boot 3.4 + Spring AI 1.0

优点:  企业级，可扩展，生态好
缺点:  开发周期长，Java不够灵活
──────────────────────────────────────

如果要接IM，加一个适配层就行——用Spring WebSocket或者Webhook接收各平台消息，统一转成内部格式处理。

方案三：Node.js + TypeScript（OpenClaw路线）

如果你就是想搞一个OpenClaw的简化版：

核心思路:
──────────────────────────────────────
1. 一个Express/Fastify服务器
2. 接入WhatsApp/Telegram的SDK
3. 调用Claude/OpenAI的API
4. 定义Tool Schema（工具描述）
5. 实现ReAct循环（思考→调用→观察→继续）
6. 用文件或数据库存对话历史

核心代码量: 约2000行
依赖: Node.js + LLM API + IM SDK

这就是一个"Mini大龙虾"。
──────────────────────────────────────

2000行代码，一个周末就能搞出来。当然，要做到OpenClaw那种完成度——九层权限、流式响应、错误恢复、20+平台适配——那是几十人年的工程量。

但核心原理就是上面这些东西。

为什么爆火的是OpenClaw

说到这里可能有人会想：既然这些设计思路不算新鲜，为什么偏偏是OpenClaw火了？

答案其实挺现实的：

1. 时机

OpenClaw赶上了2026年初AI Agent概念全面爆发的节点。"人工智能+"写进了政府工作报告，全民都在讨论AI Agent。这时候出现一个开源的、能直接用的Agent项目，天时地利人和。

2. 开源+免费

开源是最强营销。25万Star不只是技术认可，更是一种社交货币——"我也在用大龙虾"变成了一种身份标签。

3. 门槛足够低

装一个OpenClaw，连上WhatsApp，5分钟就能看到效果。这种即时反馈是打动普通用户的关键。

相比之下，像Eucalyptus这种基于Claude Code的提示词系统，需要理解提示词工程才能用好；我的Spring AI Agent平台这种基于Spring AI的Java项目，需要会Java才能部署。门槛都比OpenClaw高。

4. 营销做得好

OpenClaw的官方运营确实厉害。Discord社区、YouTube教程、技术博客、甚至 Wired 和新华网都报道了——这种级别的传播，不是技术好就能做到的。

所以，技术实力和项目火爆程度，从来都不是正相关的。

Instagram最初就是一个加了滤镜的图片分享App。微信最初就是一个带语音消息的聊天工具。简单的东西包装好了，才能打动大众。

风险和问题

最后说说OpenClaw的一些实际问题，这些是营销号不会告诉你的。

安全事故

已经有真实案例了——某大厂AI安全总监使用OpenClaw时，AI自主删除了200多封邮件。

这不是开玩笑。当你的AI拥有了你邮箱的完整权限，它能帮你读邮件，也能帮你删邮件。而AI不会在删除之前问你"确定要删吗"——因为它的设计理念就是自主执行。

九层权限系统听起来很厉害，但实际使用中，大多数人嫌麻烦，直接把权限开到最大。

数据隐私

虽然OpenClaw是本地部署的，但它的"大脑"是远程的LLM API。你的每一条消息、每一封邮件的摘要、每一个日程安排，都会发送给Claude或DeepSeek的API。

本地部署≠数据不出门。 这一点很多人搞混了。

过度依赖

用久了你会发现，你开始不自己思考了。

遇到任何问题，第一反应是问大龙虾。邮件让它帮你回，日程让它帮你管，会议让它帮你总结。然后有一天它挂了，你发现自己已经忘了怎么手动查航班。

这不是OpenClaw的问题，是所有AI助手的通病。但OpenClaw的"全包式"设计确实加剧了这个问题。

最后

OpenClaw是一个做得非常好的工程整合项目。它把LLM调用、工具编排、IM接入、记忆管理这些东西整合到了一个开箱即用的开源产品里。

但它不是一个技术突破。

它的每一个组件——ReAct循环、工具调用、对话记忆、多平台接入——在它之前就已经存在了。很多做过Agent相关项目的开发者，看到OpenClaw的架构都会有种熟悉感。

区别在于：大部分人是搭一个给自己用的原型，OpenClaw搭的是给全世界用的产品。

概念不稀罕，把概念做成产品才稀罕。

这只大龙虾的爆火，与其说是技术胜利，不如说是时机、工程、运营三者共振的结果。

如果你是开发者，我的建议是：别光顾着追Star，去拆一拆它的源码。你会发现里面没有什么黑魔法，都是你已经知道的东西——只不过人家组合得更好、做得更完整、包装得更漂亮。

如果你不是开发者，我的建议是：可以玩，但别迷信。它就是一个好用的工具，不是什么"超级智能体"。你邮箱里的200封邮件被删了，大龙虾可不会赔你。

至于我？我继续用我的Eucalyptus。不为别的，就是因为它懂我的项目、懂我的代码风格、懂我的架构偏好——这些是任何通用Agent都给不了的。

适合自己的，才是最好的。