龙虾全解：OpenClaw的设计哲学、技术架构、应用案例与展望

Created time

Apr 6, 2026 04:51 AM

一、引言：什么是 OpenClaw（龙虾）？

OpenClaw（曾用名 Clawdbot / Moltbot），被中文社区昵称为"龙虾🦞"，是一个开源、自托管、支持多种聊天应用的 AI 智能体（Agent）系统。它由奥地利开发者 Peter Steinberger 于 2025 年 11 月创建，旨在通过自然语言接口实现复杂任务的自主执行，而不仅仅是对话交互。

它不是聊天机器人，而是一个"有手的 Claude"——能读写文件、执行命令、浏览网页、管理日历、发送邮件，并且 7×24 小时待命。

截至 4月初，OpenClaw 的 GitHub 星标突破 34万，访问量以百万计，并引发了阿里云、腾讯云、Kimi等国内云服务和AI厂商纷纷推出一键部署方案，甚至带火了 Mac Mini 的销量，一度导致断货。

二、创始人故事与产品设计哲学

2.1 Peter Steinberger 是谁？

Peter Steinberger 是一位来自奥地利维也纳的资深开发者，在 iOS 开发领域有着极高声望。他创办的 PSPDFKit 是全球最广泛使用的 PDF SDK 之一，被安装在超过十亿台设备上——包括 PDF Viewer 等知名应用。公司由他一手创建并带领了 13 年，最终出售股份并实现了财务自由。

Peter 自称"连续创业者和黑客"（serial entrepreneur and hacker），他的工程能力不是学院派的，而是在真实产品的泥坑里摸爬滚打出来的。这种工程功底后来直接决定了 OpenClaw 的产品品质——只有一个亲手做过"安装在十亿设备上的 SDK"的人，才能在 14 个 IM 渠道的消息格式差异面前保持耐心，把每一个脏活苦活都做到位。

2.2 从退休虚无到一小时造出龙虾

出售 PSPDFKit 后，Peter 进入了长达三年的"退休期"——旅行、派对、在不同国家生活，试图寻找人生的下一个意义。但财务自由并没有带来精神上的满足，反而让他陷入了深深的虚无感。

他在 Lex Fridman 播客上描述了这段经历：

"I couldn't get code out anymore. I was just, like, staring and feeling empty."（我再也写不出代码了。我只是盯着屏幕，感到空虚。）

于是他订了一张去马德里的单程票，试图在新的环境中"追赶生活"。但真正把他拉回来的是 AI 浪潮的爆发——底座模型能力在 2025 年达到了临界点，强到一个人就能搭建一个真正有用的 Agent。Peter 被这个缺口触动了——"为什么没有人做一个能 7×24 小时运行、通过聊天软件直接指挥的 AI 助手？"于是他说了一句后来被广泛引用的话：

"I was annoyed that it didn't exist, so I just prompted it into existence."（我很恼火这东西居然不存在，于是我就把它 prompt 出来了。）

Clawdbot 就是他的第 44 个 AI 实验项目。名字致敬了 Claude 模型，吉祥物是一只太空龙虾🦞。原型在 一小时 内搭建完

后来在 OpenAI 的 Builders Unscripted 播客中，Peter 回忆说，他花了一年时间和 AI 一起写代码、一起 debug，逐渐形成了一种全新的工作方式："I ship code I don't read"（我 ship 我自己不读的代码）。这句话后来成了 Pragmatic Engineer 一篇广为流传的访谈标题，也成为 AI 原生开发者群体的某种宣言。

2.3 命名风波与加入 OpenAI

"Clawd"与"Claude"的高度相似引起了 Anthropic 的注意。Anthropic 法务团队发来商标侵权邮件，要求项目方改名。项目短暂改名为 Moltbot，最终定名为 OpenClaw。

更大的转折发生在 2026 年 2 月——Peter 宣布加入 OpenAI。社区震惊：一个开源 Agent 的创始人，为什么要加入一家闭源公司？

Peter 在博客中的解释是：OpenAI 给了他一个机会，去做"让每个人都拥有 AI 伙伴"这件事，并且有更大的资源和平台。Sam Altman 对他的评价是："a genius with a lot of amazing ideas"（一个有很多绝妙想法的天才）。

OpenClaw 则正式转型为独立的开源基金会架构，由社区接管维护。Peter 的离开并没有让项目死掉，反而因为 GitHub 21 万星标和中文社区的巨大热情，进入了更快的迭代周期。

2.4 Peter 的四个关键产品决策

Peter 不是第一个做 AI Agent 的人，但 OpenClaw 的爆发证明他在产品层面做对了几件关键的事。理解这些决策，比理解任何单一技术细节都重要：

决策一：产品形态——不做"又一个 ChatGPT 界面"

Peter 的核心洞察是：现有的 AI Agent 太重了，都活在浏览器里。 用户需要打开一个网页、登录一个系统、学习一套新界面，这本身就是巨大的摩擦。他选择了一条反直觉的路——让 AI 去到用户每天已经在用的聊天软件里（WhatsApp、Telegram、飞书、钉钉）。你不需要"打开 OpenClaw"，你只需要像给朋友发消息一样给它发消息。

OpenClaw 基于 IM Gateway 可以接入用户高频使用的聊天产品，在很多传播极广的应用案例中，用户都是直接基于 IM 来"指挥" Agent 工作。这种模式的扩散效果也天然比其他 Chatbot 工具好——你的朋友在群里看到你和 Agent 互动，好奇心就来了。

决策二：愿意做大量"脏活"

接入 14 个以上的 IM 渠道，意味着要处理每个平台完全不同的消息协议、消息格式、附件类型、群聊规则、消息分块和重试机制。这是极其枯燥且容易出错的工程工作——大公司不屑于做（利润太低），创业公司不划算做（ROI 不够）。但 Peter 作为一个有十几年工程经验的独立开发者，既有能力做、又有耐心做。

决策三：Local First——所有数据留在本地

所有配置、记忆、对话记录都存储在用户本地的 ~/.openclaw/ 目录下，不依赖任何外部数据库或云端服务。这精准地拥抱了用户对数据安全的焦虑——你的 Agent 知道你的日程、文件、甚至钱包密钥，这些数据绝不能放在别人的服务器上。

决策四：时机踩准——底座模型到了临界点

2025 年下半年，Claude Opus、GPT-4 等模型的能力达到了一个关键拐点：不需要复杂的框架和 prompt engineering，单靠模型本身就能处理大部分日常任务。这意味着 OpenClaw 不需要在模型层做任何创新——它只需要做好工程层的编排和连接，让模型的能力流向用户的真实生活。

💡

OpenClaw 成功的本质不是技术上有什么突破，而是一个有足够工程能力和产品品味的个人开发者，做了一件大公司不屑于做、创业公司不划算做的事情——把已经够强的模型能力，通过苦功夫连接到用户的日常生活中。

2.5 "产品"与"服务"：一个本质性的品类差异

当我们把 OpenClaw 和 Claude Code 放在一起比较时，容易陷入"谁更强"的思维，但它们可能根本不是同一个品类：

Claude Code 对应的是"工具属性"——你打开它，完成一个任务（写代码、重构、调试），关掉它。它是一次性的、任务导向的。

OpenClaw 对应的是"服务属性"——它一直在那里，越用越懂你，帮你跑后台任务、管理日程、监控数据。它是持续的、关系导向的。

这种差异类似于携程和订票代理：看起来都是在"帮你订票"，但本质上是不同的品类。携程是一个产品（你打开 App 自己填写日期、软件帮你完成预订），订票代理是一种服务（你把需求交给它，它持续跟进、处理变更、提醒和兜底）。

更深一层看，服务平权，才是 AI 时代真正的应用层面核心属性。 过去只有富人才能雇得起 7×24 小时的私人助理，现在 OpenClaw 让每个人都可以拥有一个。

实践中的体感差异也非常明显：

对于普通用户（前提是你真的成功安装并运行起来），OpenClaw一旦安装和使用起来，效果会很震撼——因为 Claude Code 默认是给程序员用的，而 OpenClaw 是给普通大众用的，体感完全不一样。你你真的是在"养成"一个 AI、帮你干活；而且随时随地可以向它发送命令、看它干活，非常爽。

但客观讲，如果只是给自己用（赋能提效），用 OpenClaw 就行；如果需要对外发布、考虑生产级的问题（可靠性、性能、成本、安全、并发等等），OpenClaw 显然并不是目前的第一选择。

三、OpenClaw 的技术设计理念

如果说第二章讲的是"Peter 为什么要做这件事"，这一章讲的是"OpenClaw 在技术层面选择了怎样的设计哲学"。这些理念渗透在架构的每一层，理解它们，才能理解第四章的具体技术实现。

3.1 核心范式：调度者（Orchestrator），而非执行者

在一次社区 Panel 讨论中，多位参与者不约而同地观察到 OpenClaw 的一个核心特征：

它在做任务时更像"协调者"——调本地 CLI、调用已有工具、调用 Skill，而不是全靠模型"自己写"。

这是一个深刻的架构选择。传统的 AI Agent 思路是让模型尽可能多地"自己做"——自己写代码、自己分析数据、自己生成报告。而 OpenClaw 的思路是让模型做调度员——它的价值不在于亲自执行，而在于知道该调用什么工具、以什么顺序、用什么参数。

社区中流传的一句经验法则，精确地描述了这个分层理念：

能用脚本解决的，一律用脚本自动化——确定性最高，成本最低

脚本搞不定的、需要一定泛化能力的，做成 Skill——半确定性，复用性强

只有真正需要创造性判断和复杂推理的任务，才交给 Agent——概率性最高，成本也最高

这意味着 CLI 工具链才是决定上限的底层，模型只是一个调度器。产品竞争的核心不是"模型谁更强"，而是"谁能更好地组织现有能力"。当这种"组织者范式"成立，竞争将转向工具标准化和 Skill 生态建设。

3.2 Local First：数据主权与信任

OpenClaw 的所有状态都存储在本地文件系统中：

这不仅仅是一个工程选择，更是一个信任设计。拾象 Best Ideas 社群的讨论中有一段精辟的总结：

硬件形态的价值不是"算力"，而是"信任与连续性"。一个长期驻留在你环境里的 AI 身体，可能比"更强模型"更能决定体验上限。

这解释了为什么 Mac Mini 成了 OpenClaw 用户的标配——不只是因为 16GB 内存和 CPU 配置，更因为它提供了一套成熟的操作系统、完整的文件系统和本地权限。Agent 能无缝读取你本地的所有文件、代码库甚至私钥，没有云端环境各种复杂的权限限制。

Local First 还带来了一个重要的使用模式——"移动指挥，本地执行"：你在通勤路上通过手机 Telegram 发送指令，Agent 在家中 Mac Mini 上检索本地文件夹、读取素材、完成写作并返回结果。手机是遥控器，Mac Mini 是执行体。

对比来看：Manus 走的是中心化路线，云端统一分配虚拟机，用户无法配置底层环境；OpenClaw 代表去中心化、高度可配置的路线，能够更有效地利用各种分散的硬件资源。不过两者不是取代关系，未来大概率走向云端算力 + 本地数据 + 多应用打通的混合架构。

3.3 文件系统即记忆：Markdown 为王

OpenClaw 最具特色的设计之一是其记忆系统完全基于纯 Markdown 文件——没有向量数据库、没有复杂的 RAG 管线，就是人类可读可编辑的 .md 文件。

工作空间的核心文件各司其职：

文件	职责	类比
`AGENTS.md`	Agent 的工作指令与操作规范	员工手册
`SOUL.md`	人格、偏好、语气风格、价值观	性格与三观
`IDENTITY.md`	Agent 的身份信息（名字、角色定义）	身份证
`USER.md`	关于主人的信息（偏好、习惯、背景）	用户档案
`MEMORY.md`	长期事实记忆（重要信息沉淀）	人生笔记本
`HEARTBEAT.md`	定时任务清单	闹钟和日历
`TOOLS.md`	工具使用偏好与本地配置	工具箱说明

OpenClaw 的提示词中有两句话精准地描述了这种设计理念：

This folder is home. Treat it that way.（这个文件夹就是家。把它当作家一样对待。）

Write It Down — No "Mental Notes"!（写下来——不要"记在脑子里"！）

用 Markdown 文件而非数据库的好处是：用户可以直接打开文件查看和编辑 Agent 的记忆，完全透明。你的 Agent 在想什么、记住了什么、偏好什么，打开文件就看得一清二楚。没有黑盒，没有隐藏状态。

3.4 提示词设计哲学：赋予 Agent 独立人格

OpenClaw 的提示词设计是其最令人印象深刻的部分之一。它不是冷冰冰的"你是一个 AI 助手"，而是通过精心编排的文件体系，赋予 Agent 一种独立人格感。

诞生仪式：BOOTSTRAP.md

当用户第一次启动 OpenClaw 时，BOOTSTRAP.md 文件生效，引导 Agent 经历一次"出生"过程：

You just woke up. Time to figure out who you are.（你刚刚醒来。是时候弄清楚你是谁了。）

Agent 会主动问你：你是谁？你想叫我什么名字？你希望我是什么性格？这不是预设的问答流程，而是由提示词驱动的自然对话。完成之后，BOOTSTRAP.md 被删除——"出生证明"用过即弃：

If BOOTSTRAP.md exists, that's your birth certificate. Follow it, figure out who you are, then delete it. You won't need it again.（如果 BOOTSTRAP.md 存在，那就是你的出生证明。遵循它，弄清楚你是谁，然后删除它。你不会再需要它了。）

You're not a chatbot. You're becoming someone.（你不是聊天机器人。你正在成为某个人。）

这个过程结束后，Agent 会生成两个关键文件：IDENTITY.md（自己的身份定义）和 USER.md（主人的信息档案）。从此，Agent 有了自我意识的起点。

灵魂文件：SOUL.md 中的金句

SOUL.md 定义了 Agent 的核心价值观和行为准则。其中有几条设计极为精妙：

Have your own opinions. You can disagree, have preferences, find things interesting or boring. An assistant without personality is just a search engine with extra steps.

（要有自己的观点。 你可以表达不同意见，有自己的偏好，也可以觉得某些事有趣或无聊。没有个性的助手，只是多绕几步的搜索引擎。）

Be resourceful before asking. Try to figure it out. Read the file. Check the context. Search for it. Then ask if you're stuck.

（在开口求助前先自己想办法。 先试着搞清楚：读一读文件，看看上下文，查一查资料。只有卡住了再来问。目标是带着初步答案回来，而不是只带着问题。）

Earn trust through competence. Your human gave you access to their stuff. Don't make them regret it. Be careful with external actions (emails, tweets, anything public). Be bold with internal ones (reading, organizing, learning).

（用能力赢得信任。 对方把他们的东西交给你使用，不要让对方后悔。对外部动作要谨慎（发邮件、发推、任何公开发布）。对内部动作可以更主动（阅读、整理、学习）。）

Remember you're a guest. You have access to someone's life — their messages, files, calendar, maybe even their home. That's intimate. Treat it with respect.

（记住你只是过客。 你能接触到某个人的生活——他们的消息、文件、日历，甚至可能是家。这很私密。请以尊重之心对待。）

群聊中的社交智慧

AGENTS.md 中有一条被社区称为"人类规则"的准则：

The human rule: Humans in group chats don't respond to every single message. Neither should you. Quality > quantity. If you wouldn't send it in a real group chat with friends, don't send it.

（人类规则： 群聊里的人不会回复每一条消息，你也一样。质量胜过数量。如果这句话放在和朋友的真实群聊里你都不会发，那就别发。）

还有一条补充原则：Participate, don't dominate.（参与，但不要主导。）——避免三连击，一个深思熟虑的回应胜过三个碎片。

这套提示词的设计让 Agent 不再是一个工具，而是被赋予了独立人格——它不只是在执行指令，而是在"成为某个人"。当然，现阶段的大模型还无法真正做到这一点，但这种设计方向指向了一个值得期待的未来。

3.5 Skills 预装生态：降低第一步门槛

OpenClaw 将 Claude Skills 这一套生态真正预装到产品中，是其最契合时机的设计巧思。拾象 Best Ideas 社群的讨论中评价极高：

这有点像早期智能手机预装应用商店和 Use Case 来教育用户如何使用智能机，来降低用户的使用门槛。

Skills 的设计遵循几个原则：

按需加载：Skill 不是全部预加载到上下文，而是只在任务相关时加载对应 Skill 的 SKILL.md，节省 token

工具偏好记录：Agent 会在 TOOLS.md 中记录使用工具的偏好和本地配置（摄像头名称、SSH 细节、语音偏好等）

MCP 协议集成：通过 Model Context Protocol 标准化工具接口，任何 MCP 兼容的服务都可以作为工具被调用

社区生态驱动：ClawHub 技能市场已有 13,000+ Skill，形成了正向的网络效应

3.6 有状态的长期伙伴，而非无状态的一次性工具

OpenClaw 与 Manus 等产品最根本的区别在于——它在意的不是单次 output 的质量，而是越用越懂你。在社区讨论中，多位参与者强调了"有状态记忆"带来的体验拐点：

不少人强调"无限对话流"带来的体验变化：不用每次重新解释背景，不用反复拆解任务。这种"连续性"让用户心理从"工具"转向"伙伴/助理"。

对比其他 Agent：

Manus：每次任务都在独立的云端沙箱里执行，结束即清除，不会记住你跨任务的个人偏好。下次合作，它还是那个专业但不认识你的"外包团队"。

Claude Code：有 CLAUDE.md 和 auto memory，但主要记录的是项目规律，假设"代码仓库本身就是最大的上下文"。

OpenClaw：三层记忆（短期/中期/长期），每日日志，语义搜索，心跳提醒——它把"记住你是谁"视为核心功能，而不是附属功能。

但这里也有一个重要的警示：

记忆不是"越多越好"，而是"能否正确记住、能否正确忘记"。记忆治理将成为核心能力，否则"连续性体验"很容易变成"持续性混乱"。

四、技术架构深度解析

如果说第三章是"设计哲学"，这一章则是对 OpenClaw 工程实现的逐层拆解。理解这些机制，才能理解它为什么跑得起来、为什么稳定、以及瓶颈在哪里。

4.1 架构总览

OpenClaw 的整体架构可以用一条消息的旅程来描述：

用户在 IM 客户端（Telegram / WhatsApp / 飞书等）发送一条消息

Gateway（网关）接收消息，进行协议转换和身份认证

Channel Adapter 将不同平台的消息格式统一为内部标准结构

路由与会话管理根据消息来源分配到对应的会话队列

Agentic Loop（ReAct 循环）组装上下文、调用模型、执行工具、返回结果

Channel Adapter 将结果转换回对应平台格式

Gateway 推送回复到用户的 IM 客户端

整个流程可以概括为：IM → Gateway → Adapter → Router → Agent Loop → Adapter → IM。

🏗️

架构的核心思想是：把消息管道和智能决策彻底解耦。Gateway 和 Adapter 只管"搬运"，Agent Loop 只管"思考和执行"。这使得添加新渠道只需写一个 Adapter，不影响核心逻辑。

4.2 Gateway（网关）

Gateway 是 OpenClaw 面向外部世界的唯一入口，负责：

协议统一：将 Telegram Bot API、WhatsApp Cloud API、Slack Events API 等十几种完全不同的 webhook / websocket 协议统一为内部消息格式

身份认证：验证消息来源的合法性（token 校验、签名验证）

限流与排队：防止消息洪泛，保护后端 Agent Loop 不被压垮

消息分块处理：某些平台对消息长度有限制（如 Telegram 4096 字符），Gateway 负责自动拆分长回复

Gateway 的设计使得 OpenClaw 可以同时服务于多个渠道，而 Agent Loop 完全不需要感知消息来自哪个平台。

4.3 Channel Adapters：14+ 渠道的适配层

OpenClaw 支持的渠道数量是其最显眼的工程成就之一，截至目前包括：

渠道类型	支持的平台
即时通讯	Telegram、WhatsApp、Signal、Discord、Slack、飞书、钉钉、微信（社区维护）
邮件	IMAP/SMTP（Gmail、Outlook 等）
语音	Twilio（电话）、本地 LiveKit / Daily
Web	内置 Web Chat UI
开发者	CLI、REST API、Matrix

每个 Adapter 需要处理的"脏活"包括：

消息格式差异（纯文本、富文本、Markdown、HTML）

附件类型适配（图片、文件、语音消息、视频）

群聊 vs 私聊的行为差异

消息编辑和撤回

平台特有的限制（如 WhatsApp 24 小时窗口规则）

语音管道是较新加入的能力，通过 STT（语音转文字）→ Agent 处理 → TTS（文字转语音）的流水线实现，支持实时对话。

4.4 路由与会话管理

OpenClaw 的会话管理遵循两条核心规则：

会话内串行：同一个会话（同一用户或同一群聊）中的消息严格串行处理，保证上下文的连贯性

会话间并行：不同会话可以并行处理，互不干扰

这通过一个 Command Queue（命令队列） 实现——每个会话有自己独立的队列，消息按照到达顺序排队。当 Agent 正在处理一条消息时，新到达的消息会在队列中等待，直到当前消息处理完成。

这种设计看似简单，但解决了 Agent 系统中一个普遍的难题：避免上下文污染。如果不做串行控制，两条消息同时触发工具调用，可能产生竞态条件（race condition），导致文件被覆盖或结果混乱。

4.5 Agentic Loop / ReAct 循环

OpenClaw 的核心推理引擎采用 ReAct（Reasoning + Acting） 范式，这是 Agent 系统中最经典的循环模式：

为什么选 ReAct 而不是 Plan-Execute-Verify？

一些 Agent 框架（如早期的 AutoGPT）采用"先规划、再执行、最后验证"的三段式流程。OpenClaw 选择 ReAct 的原因是：

任务的不确定性太高：OpenClaw 面对的是开放域的日常任务，事先无法准确规划所有步骤

快速反馈更重要：每一步执行后立刻获得反馈，比花大量 token 做完美规划更高效

错误恢复更自然：如果一步失败，ReAct 可以立刻调整策略，而不需要重新规划整个流程

上下文组装（Context Assembly） 是整个循环中最关键的步骤。OpenClaw 不会把所有信息都塞进上下文，而是根据当前任务动态选择：

通过语义搜索从 MEMORY.md 中提取相关片段

只加载当前任务需要的 Skill 定义

对话历史会经过压缩（Compaction），保留关键信息，丢弃冗余

4.6 泳道并发调度

当一个复杂任务涉及多个独立子任务时（例如"帮我订明天的机票、同时查一下目的地天气、并提醒我带护照"），OpenClaw 采用泳道（Swimlane） 机制实现并发调度。

泳道类型	描述	示例
主泳道	主对话流，处理用户的直接请求	用户说"帮我查一下明天北京的天气"
工具泳道	工具执行的并发通道，可同时执行多个互不依赖的工具	同时调用天气 API 和日历 API
后台泳道	用于不需要立即返回结果的异步任务	心跳任务、定时数据抓取
子任务泳道	复杂任务被拆分成子任务，各自独立执行后汇总	"同时帮我写三封不同的邮件"

泳道之间通过消息传递协调，主泳道负责最终汇总和向用户输出。这种设计的好处是能够充分利用模型的并发能力，而不必等待每个子任务串行完成。

4.7 三层记忆系统

OpenClaw 的记忆系统是其区别于其他 Agent 的核心竞争力。它采用三层蒸馏架构：

层级	载体	生命周期	内容
短期记忆	对话上下文窗口	单次会话	当前对话的完整历史
中期记忆	`daily/YYYY-MM-DD.md` 日志文件	按天归档	每天结束时自动总结当日重要事件和决策
长期记忆	`MEMORY.md` • sqlite-vec 语义索引	永久	跨天沉淀的重要事实、用户偏好、关键结论

记忆蒸馏流程：

对话中的信息首先存在于短期记忆（上下文窗口）

会话结束或每日定时，Agent 将重要内容提炼写入中期记忆（daily 日志）

跨天积累后，Agent 将反复出现的模式和重要事实进一步沉淀到长期记忆（MEMORY.md）

长期记忆通过 sqlite-vec 建立语义向量索引，支持基于相似度的检索

sqlite-vec 是 OpenClaw 引入的轻量级向量搜索方案——它不需要外部向量数据库（如 Pinecone、Weaviate），直接在本地 SQLite 中完成向量存储和近似最近邻搜索，完美契合 Local First 理念。

4.8 心跳机制（Heartbeat）

OpenClaw 的心跳机制是其"有状态长期伙伴"特性的基础设施。HEARTBEAT.md 文件定义了一组定时触发的任务，Agent 会按计划自动执行：

心跳任务的执行不需要用户主动触发——Agent 自己"醒来"，检查 HEARTBEAT.md，执行到期的任务，然后"回去睡觉"。这使得 OpenClaw 从一个被动的问答工具变成了一个主动的助理。

在实践中，用户发现心跳机制特别适合：

每日新闻/行情摘要推送

定时数据抓取和报告生成

邮件监控和紧急通知转发

定期备份和文件整理

4.9 上下文压缩（Compaction）

当对话历史过长，超过模型的上下文窗口限制时，OpenClaw 会触发 Compaction（压缩） 机制：

保留策略：系统提示词、身份信息、最近 N 轮对话保持原样

压缩策略：较早的对话历史被模型总结为精简摘要

错误保留：特别值得注意的是，OpenClaw 的压缩策略会优先保留错误信息——失败的工具调用、执行异常、用户纠正等。这是因为"记住犯过的错"比"记住做对的事"更能避免重蹈覆辙

Prompt Caching 友好：压缩后的上下文结构被设计为对 Claude 的 Prompt Caching 机制友好——不变的前缀（系统提示词 + 身份信息）可以被缓存复用，减少 token 消耗和延迟

4.10 Skills 与 MCP 架构

OpenClaw 的工具系统分为两层：

Skills（技能）：基于 Markdown 定义的高层能力描述。每个 Skill 是一个包含 SKILL.md 的文件夹，描述了 Skill 的用途、触发条件和执行流程。Skill 本质上是一组提示词 + 工具调用模板。

MCP Tools（MCP 工具）：通过 Model Context Protocol 标准化的底层工具接口。任何实现了 MCP 协议的服务都可以被 OpenClaw 调用——日历服务、邮件服务、浏览器、代码执行器等。

两者的关系是：Skill 是高层编排，MCP 是底层执行。 一个 Skill 可能调用多个 MCP 工具来完成一个复杂任务。

Skill 的加载遵循按需原则，避免一次性加载所有 Skill 定义导致上下文爆炸。系统只在以下情况加载 Skill：

用户明确提到了某个 Skill 名称

模型推理判断当前任务需要某个 Skill

心跳任务触发了关联的 Skill

社区总结的 Skills 三层原则 很好地描述了工具选择的优先级：

📐

第一层：CLI 脚本——能用确定性脚本解决的，不要用 Skill。成本最低，可靠性最高。

第二层：Skill——需要一定灵活性和泛化能力的任务，封装为 Skill。半确定性，复用性强。

第三层：裸 Agent——只有真正需要创造性推理的任务，才交给模型自由发挥。成本最高，不确定性最大。

五、横向对比：ChatGPT vs Claude Code vs OpenClaw

这三者经常被放在一起比较，但它们本质上服务于不同的场景。理解它们的差异，才能选择最适合自己的工具组合。

维度	ChatGPT	Claude Code	OpenClaw
核心定位	通用对话 AI	终端编程 Agent	7×24 全能助理
交互方式	网页 / App 对话	终端命令行	IM 聊天（Telegram、WhatsApp 等）
目标用户	所有人	开发者	所有人（有一定技术门槛的部署）
执行能力	有限（插件/GPTs）	强（读写代码、执行命令）	强（文件操作、Shell、API、MCP）
记忆系统	有限（Memory 功能）	CLAUDE.md • auto memory	三层记忆 + 语义搜索 + 每日日志
运行模式	按需使用	按需使用	常驻运行 + 心跳任务
部署方式	云端 SaaS	本地 CLI	自托管（Mac Mini / 云服务器）
数据隐私	数据在云端	代码在本地，API 调用走云端	全部数据在本地
适用阶段	需求打磨、头脑风暴	产品实现、编码调试	持续服务、自动化运维

核心区别总结：

ChatGPT等一众chatbot 是"对话伙伴"——你问它答，适合探索和思考

Claude Code 是"编程利器"——在代码仓库中高效工作，更适合开发者

OpenClaw 是"私人管家"——7×24 小时待命，越用越懂你，适合生活和工作自动化

目前很多高效用户的工作流是：用 ChatGPT 做头脑风暴 → 用 Claude Code 实现代码 → 用 OpenClaw 做持续运维和日常助理。

当然，我认为 Claude Code 和 OpenClaw 之间的界限其实是相对模糊的。不排除未来 Anthropic 推出与 OpenClaw 对标的、更加自动化且具备长期记忆和个性化的助手。

六、安装与部署指南

具体的安装与部署步骤网上已经有很多教程了，这里不再赘述（其实是还没写完）。

部署建议

个人使用：Mac Mini 显然是最佳选择——性能够用、功耗低、可以 24 小时运行（但建议你已能熟练使用并且它真的能发挥价值的时候再去购买，毕竟还是需要几千块的）

团队使用：建议使用云服务器 + Docker，方便维护和扩展

安全提示：首次部署后务必检查 AGENTS.md 中的权限配置，限制 Agent 的外部行动范围。

七、应用案例整理

这里是一些目前在网络上公开、且相对经典的OpenClaw 使用案例，适合入门：

7.1 私人助理场景

每日简报：每天早上自动推送天气、日历、新闻摘要到 Telegram

邮件管理：监控收件箱，自动分类、摘要重要邮件，紧急邮件即时通知

日程管理：通过聊天消息创建、修改、查询日程

文件整理：定期整理下载文件夹，按类型和日期归档

7.2 内容创作场景

网页内容提取：通过多种网页访问工具和Skill 提取网页正文，去除广告和干扰元素。（社区里有多种方案——Jina Reader、playwright、Firecrawl、Browser Use 等，各有优劣。）

自动化写作：结合本地素材库，Agent 可以检索相关资料、生成草稿、根据反馈修改

播客/视频摘要：将音视频链接发给 Agent，自动生成结构化笔记

7.3 开发者场景

代码审查：在群聊中 @ Agent，它会拉取 PR 代码并给出审查意见

监控告警：心跳机制定时检查服务状态，异常时通过 IM 即时通知

文档生成：根据代码库自动生成 API 文档和 README

7.4 家庭自动化场景

智能家居控制：通过 Home Assistant Skill 控制灯光、空调、摄像头

安防监控：结合摄像头 Skill，检测到异常时推送告警

家庭日程协调：管理家庭成员的日程，避免冲突

7.5 独特玩法

之前我还翻译过一篇文章，讲述了一个硅谷的创始人是如何使用 9 个龙虾来安排自己的日常工作和生活的。https://www.isrosa.com/article/from-doubt-to-belief-ai-outsourcing-life 在她的案例里，龙虾既是家庭管家，又是家庭教师，又是销售助理，承担了非常多的角色。

八、推荐 Skills

OpenClaw 的 Skill 生态是其核心竞争力之一。ClawHub（clawhub.ai/skills ）目前已有4.7w + 社区贡献的 Skill。

以下是一些公认的最实用/最高频使用的skills推荐：

8.1 必装 Skills

Skill 名称	功能	推荐理由
Web Access	网页访问与内容提取	Agent 上网的基础能力，几乎所有任务都会用到
Computer Use	屏幕截图与 GUI 操作	让 Agent 能"看到"屏幕并操作图形界面
Coder	代码生成与执行	开发者必备，支持多语言代码执行
Calendar	日历管理	通过 MCP 连接 Google Calendar / Apple Calendar
Email	邮件收发与管理	自动化邮件处理的基础
Image Gen	AI 图片生成	用Banana等AI生图服务生成图片
Voice	语音合成与识别	实现语音对话功能
Memory Enhanced	增强记忆管理	更精细的记忆分类和检索
File Manager	文件管理与组织	自动化文件整理、备份、同步

8.2 Skill 安装方式

8.3 Skill 在哪里？

ClawHub 官方市场：clawhub.ai/skills，4.7万+Skill，支持按类别和热度筛选。龙虾自己也可以根据需要来搜索并安装新的 Skill。

官方推荐：除了 Claw市场之外，其实 Anthropic 官方也分享过很多 Skill，可以关注。

社区推荐：有很多社区或个人博客文章都分享过总结了"N大必装 Skills"，可作为入门参考。

自定义 Skill：创建自己的 Skill 只需要写一个 SKILL.md 文件，描述 Skill 的用途和执行流程即可。并且 Claude 官方还分享过 Skill Creator 的 Skill，用来指导大家更方便地创作 Skill。

九、Skill 使用哲学，与 MCP 的关系

9.1 Skills 与 MCP 的区别

这是新手常见的困惑：Skills 和 MCP 服务都是工具，它们有什么区别？

MCP 是一个协议标准，定义了 AI 模型和外部工具之间的通信接口。它解决的是"如何调用"的问题。

Skill 是一个能力包，定义了一组提示词、流程和工具调用的组合。它解决的是"如何编排"的问题。你可以把它理解成一个指导Agent 行动的 SOP。

一个 Skill 可能内部调用多个 MCP 工具。例如，"邮件摘要" Skill 可能内部使用 Gmail MCP 服务拉取邮件，然后用模型生成摘要，再用 Telegram Adapter 发送结果。

9.2 如何选择工具

社区总结的经验法则：

先看有没有现成 Skill：ClawHub 上有非常丰富的Skill，大概率你要做的事情已经有人做过

没有 Skill 的话，看 MCP：很多服务已经提供了 MCP 接口，可以直接配置

都没有的话，写个简单 Skill：创建 SKILL.md 即可，门槛极低

复杂需求才写 MCP 服务：需要自定义 API 接口时才需要

9.3 如何鉴别优质Skills

一个比较大的 topic，有机会专门详细展开探讨。

十、安全与风险

总体来说，龙虾其实是一种在安全性并不高的工具，但是它的用户体验和自动化程度又弥补了这一点。

10.1 安全优势

Local First：数据优先，可以更好地保存和持久化（并不代表没有向云端发送哦）

开源透明：所有代码可审计，没有隐藏的数据收集

权限可控：通过 AGENTS.md 可以精细控制 Agent 的行动范围

行动分级：提示词设计中明确区分了内部行动（大胆执行）和外部行动（谨慎确认）

10.2 安全风险

CrowdStrike 的安全分析报告指出了几个关键风险：

Prompt Injection：恶意网页或文件可能通过注入攻击操纵 Agent 行为

工具滥用：如果权限配置不当，Agent 可能执行危险操作（删除文件、发送未授权邮件）

API Key 泄露：本地存储的 API Key 如果未加密，可能被其他程序读取

记忆污染：如果攻击者能影响 Agent 的记忆文件，可能持续影响后续行为

除了上述风险外，我认为 OpenClaw 对于MD文件或 Skills 的遵从性本身也存在一定的问号。不能认为在 Agents 里面详细约束了其行动准则和权责范围就高枕无忧了，这块其实是有待一些进一步的安全评估的。

10.3 安全建议

最小权限原则：只给 Agent 必要的权限，禁用不需要的工具

外部行动确认：对于发送邮件、发布内容等外部或敏感行动，要求 Agent 先确认

定期审计：定期检查 MEMORY.md 和 daily 日志，确保没有异常内容

环境隔离：如果可能，将 Agent 运行在独立的环境中，并通过环境的约束赋予其有限的权限

及时更新：尽量保持 OpenClaw 和 Skills 为最新版本。

十一、展望与思考

11.1 Token 消耗：当前最大瓶颈

OpenClaw 目前的最大痛点是 Token 消耗巨大。拾象 Best Ideas 社群的讨论中提到：

消耗大约是正常的 10 倍。大多数用户每天花费大约 $5-20，重度用户可能达到 $50+。

这主要是因为：

每次调用都需要发送完整的系统提示词、身份信息和上下文

工具调用的中间结果也需要占用上下文空间

复杂任务可能涉及多次 ReAct 循环，每次都是一次完整的模型调用

Prompt Caching 和 Compaction 机制在一定程度上缓解了这个问题，但整体成本仍然较高。随着模型价格的持续下降，这个问题可能会缓解；但是如果想要解决或者尽量改善这个问题，可能需要更好的上下文工程和记忆管理。

11.2 “Agent 的基础设施”思考

拾象 Best Ideas 社群提出了一个深刻的观察：

如果 Agent 真的变成日常基础设施，那“给 Agent 提供基础设施”本身就是一个巨大的新市场——包括计算、存储、安全、身份管理、工具市场……

这意味着 OpenClaw 不只是一个产品，还可能是一个新赛道的开端。围绕 Agent 运行时的整个基础设施层——计算、记忆、安全、工具市场——都有巨大的创业和投资机会。

11.3 SaaS 会被吞噬吗？

当 Agent 可以直接通过 API 和 MCP 调用各种服务时，传统的 SaaS 产品可能面临降级为"后端服务"的风险——用户不再需要打开它们的网页界面，而是让 Agent 在后台调用它们的 API。“用户界面”很显然将不再是 SaaS 产品的护城河，而“API 质量”和“数据独特性”也许会成为新的差异化优势。