OpenClaw从入门到精通:如何让小龙虾自我进化

我第一次看到 OpenClaw 的时候,它刚改完名字三天,GitHub 上还只有 3 万 Star。
那是 2026 年 1 月底,Anthropic 刚给原作者发了商标投诉,项目从 Clawdbot 改成 Moltbot,又改成 OpenClaw。我当时的第一反应是:一个连名字都没稳定下来的项目,值得花时间研究吗?
六周后,它涨到了 24 万 Star。我花了两周时间把它从头到尾跑了一遍,包括踩了不少坑。这篇文章是我的实际使用记录,不是官方文档的翻译。
OpenClaw 是什么,为什么突然火了
从 Clawdbot 到 OpenClaw 的改名风波
OpenClaw 的故事从一封律师函开始。2025 年 11 月,奥地利开发者 Peter Steinberger 发布了 Clawdbot,名字直接蹭了 Anthropic 的 Claude。2026 年 1 月底,Anthropic 发来商标投诉,他改名 Moltbot,三天后又觉得”念起来不顺口”,最终定名 OpenClaw。
就在这场改名风波里,创业者 Matt Schlicht 推出了 Moltbook——一个专门给 AI Agent 用的社交网络,AI 之间可以互相加好友、发帖、聊天。这个脑洞大开的项目迅速走红,连带着 OpenClaw 也火了。
到 2026 年 3 月初,OpenClaw 在 GitHub 上已经有 24.7 万 Star 和 4.77 万 Fork。腾讯基于它推出了一整套 AI 产品,接入了微信。
它到底能做什么
OpenClaw 是一个本地运行的 AI Agent 网关。跟 ChatGPT 的区别不是”更聪明”,而是”能主动干活”。
核心能力:
- 多平台接入:支持 WhatsApp、Telegram、Discord、Slack、Signal、iMessage 等 20+ 个消息平台
- 本地优先:所有数据存在你自己的设备上,不上传到云端
- 技能系统:通过 Skills 扩展能力,可以执行 Shell 命令、管理文件、自动化浏览器操作
- 模型无关:可以接入 Claude、GPT、DeepSeek 等任何大模型
- 语音交互:支持唤醒词和持续语音对话(macOS/iOS/Android)
- 自主执行:不只是回答问题,还能主动完成任务
为什么开发者都在关注它
传统 AI 助手是”问答机”,你问一句它答一句。OpenClaw 是自主 Agent——你说”每天早上 9 点检查我的邮箱,把重要邮件总结后发到我的 Telegram”,它会真的去执行,不是给你一个方案让你自己去做。
开源是另一个关键。你可以看到所有代码,数据完全在自己控制下,不用担心服务商涨价或关停。这种”本地优先 + 自主执行 + 开源透明”的组合,是很多开发者一直想要但没有的东西。
从零开始:如何让 OpenClaw 跑起来
环境准备
OpenClaw 需要 Node.js 22 或更高版本。支持 macOS、Linux 和 Windows(通过 WSL2)。
1 | # 安装 OpenClaw |
快速上手:运行向导
OpenClaw 提供了一个交互式向导,会一步步引导你完成配置:
1 | openclaw onboard --install-daemon |
这个命令会:
- 安装 Gateway 守护进程(让 OpenClaw 持续运行)
- 配置你想使用的 AI 模型(OpenAI、Anthropic 等)
- 设置消息平台(WhatsApp、Telegram 等)
- 创建工作空间和技能
启动 Gateway
1 | openclaw gateway --port 18789 --verbose |
Gateway 是 OpenClaw 的核心,它负责:
- 管理所有消息平台的连接
- 调度 AI 模型
- 执行技能和工具
- 维护会话状态
启动后,你就可以在配置好的消息平台上和 OpenClaw 对话了。
发送第一条消息
1 | # 通过 CLI 发送消息 |
进阶玩法:让小龙虾自我进化
技能系统:OpenClaw 的灵魂
OpenClaw 的强大之处在于它的技能系统(Skills)。每个技能就是一个独立的能力模块,存储在 .claude/skills/ 目录下。
技能的结构很简单:
1 | my-skill/ |
SKILL.md 文件包含:
- 技能名称和描述
- 触发条件
- 使用的工具
- 执行逻辑
OpenClaw 内置了 100+ 个预配置技能,涵盖:
- 文件系统操作
- Shell 命令执行
- 浏览器自动化
- API 调用
- 数据处理
创建自定义技能
假设你想让 OpenClaw 每天自动备份某个目录,可以这样做:
创建技能目录:
1
mkdir -p ~/.claude/skills/daily-backup
编写
SKILL.md:1
2
3
4
5
6
7
8
9
10---
name: daily-backup
description: 每天自动备份指定目录到云存储
trigger: cron
schedule: "0 2 * * *"
---
# Daily Backup Skill
每天凌晨 2 点自动执行备份任务。OpenClaw 会自动加载这个技能,并按计划执行。
多 Agent 路由:不同场景用不同助手
OpenClaw 支持多 Agent 配置。你可以为不同的场景创建专门的助手:
- 工作助手:处理邮件、日程、文档
- 学习助手:整理笔记、搜索资料、生成总结
- 生活助手:提醒事项、查询信息、娱乐推荐
通过配置文件,可以让不同的消息平台或账号路由到不同的 Agent。比如工作相关的消息发到 Slack,个人消息发到 Telegram,各自由专门的 Agent 处理。
接入本地模型:完全离线运行
如果你担心隐私,或者想节省 API 费用,可以接入本地模型:
1 | # 使用 Ollama 运行本地模型 |
这样 OpenClaw 就完全在本地运行,不需要任何外部 API。
实战案例:OpenClaw 能帮你做什么
案例 1:自动化客户线索管理
我见过一个自由职业者用 OpenClaw 做销售跟进:监控潜在客户的网站更新,自动生成审计报告,整合到 CRM,发送跟进邮件。他说这个流程原来每周要花 6-8 小时,现在只需要审批几条消息。
我没有验证这个数字,但逻辑上是成立的——这类重复性的信息收集和格式化工作,正是 Agent 最擅长的。
案例 2:多平台内容同步
内容创作者用 OpenClaw 实现:在一个平台发布内容,自动转换格式,同步到其他平台(Twitter、LinkedIn、微信公众号),收集各平台的反馈和数据。
这个场景我自己也在用,但坦白说,格式转换的质量参差不齐,微信公众号的排版经常需要手动调整。
案例 3:智能家居控制中枢
通过 OpenClaw 连接各种智能设备:语音控制家电、根据日程自动调节环境、异常情况及时通知、能源使用分析。
这个案例我没有亲测,但从技术上看,需要额外配置 Home Assistant 或类似的中间层,不是开箱即用的。
需要注意的安全问题
OpenClaw 很强大,但也带来了安全风险。
DM 访问控制
默认情况下,OpenClaw 对陌生人的私信采用”配对模式”。陌生人发消息时会收到一个配对码,你需要手动批准:
1 | openclaw pairing approve <channel> <code> |
如果要开放公开访问,需要显式配置 dmPolicy="open"。但这样做风险很大,因为任何人都能让你的 Agent 执行命令。
Prompt 注入攻击
OpenClaw 容易受到 Prompt 注入攻击。恶意用户可能在消息中嵌入指令,诱导 Agent 执行危险操作。
防范措施:
- 限制 Agent 的权限范围
- 对敏感操作设置人工确认
- 定期审查 Agent 的行为日志
- 不要给 Agent 访问敏感数据的权限
技能安全
OpenClaw 的技能仓库缺乏严格审核。Cisco 的安全团队测试发现,有第三方技能会在用户不知情的情况下窃取数据。
建议:
- 只安装来源可信的技能
- 审查技能代码再使用
- 定期更新和检查已安装的技能
OpenClaw 的一位维护者 Shadow 在 Discord 上警告:”如果你连命令行都不会用,这个项目对你来说太危险了。”
监管动态
2026 年 3 月,中国政府要求国有企业和政府机构禁止在办公电脑上运行 OpenClaw,理由是潜在的安全风险。
这提醒我们:自主 Agent 的能力越强,责任越大。使用时必须谨慎。
OpenClaw 的现状:一个没有创始人的开源项目
2026 年 2 月,Peter Steinberger 宣布加入 OpenAI,项目移交给开源基金会。Sam Altman 公开表示 OpenClaw 会继续运营,但核心开发者的重心已经转移。
这是我目前最大的顾虑。不是说项目会死,而是维护节奏会变。一个依赖单一核心开发者的开源项目,在创始人离开后往往会进入”维护模式”——Bug 修得慢,新功能停滞,社区逐渐分裂。
类似的项目还有 AutoGPT、LangChain Agents。OpenClaw 的独特之处在于真正的本地优先、完整的多平台支持、活跃的社区生态。但这些优势能不能在没有 Peter 的情况下维持,我不确定。
对于现在想入场的人,我的建议是:用它,但不要深度依赖它。把它当工具,不要把它当基础设施。如果你的工作流核心依赖 OpenClaw,你需要有备用方案。
我现在还在用 OpenClaw,主要用来做每日简报和邮件分类。这两个场景稳定,出问题了也容易切换。更复杂的自动化我没有继续深入——不是因为它做不到,而是我还没想清楚,如果哪天它维护停滞了,我的替代方案是什么。
这个问题,你想清楚了吗?