OpenClaw:让AI长出“双手”的工程魔法—Skill

上一篇我们部署了OpenClaw，让它跑起来了。但很多人只是会用，一遇到问题就懵——为什么有时候AI能找到文件，有时候不行？为什么装了一大堆技能后反应变慢？

OpenClaw不是黑魔法，它是一套严谨的工程系统。GitHub上27.8万星标靠的不是运气，而是背后5层架构的设计：从消息怎么进来、怎么路由、怎么组装上下文，到技能怎么加载、怎么执行、怎么存记忆，每一步都有讲究。

这篇我们就来扒开OpenClaw的“肚子”，看看它到底怎么工作的。重点是Skill系统——这个让AI真正能干活的“操作手册”是怎么设计的。

很多人把OpenClaw当成又一个聊天机器人，其实完全不是。

以前我们用LangChain写个脚本，跑完就结束，AI就“死了”。OpenClaw不一样，它是个守护进程——装好之后一直在后台跑着，7x24小时待命。你可以通过钉钉、飞书、网页控制台随时找它，它随叫随到。

从架构上看，OpenClaw可以理解为一个AI的操作系统，分5层：

消息在里面的流转大概是：消息进来 → 转成标准格式 → 去重防刷 → 分给对应的AI → 组装上下文 → AI干活 → 结果返回 → 存记忆。

我们用一个实际例子走一遍：你在钉钉发了一条“帮我整理今天的邮件，提炼待办，生成给老板的简报”。

2.1 消息进门：统一格式

钉钉的消息长什么样OpenClaw不管，有个专门的“钉钉适配器”把它扒成统一格式的MsgContext，里面就几个关键字段：消息内容、会话ID、谁发的、哪个群、消息ID。

为什么要统一？这样后面所有的处理逻辑不用管你是钉钉还是飞书，只管处理这个标准对象。

2.2 消息处理：补充信息

然后进入dispatchInboundMessage，补全一些东西，比如时间戳、会话的上下文标识，确保消息是完整的。

2.3 路由：交给谁处理

接着系统会做三件事：

• 去重：用消息ID生成一个幂等键，如果这条消息刚处理过，直接丢弃，防止重复。

• 拦截命令：如果是/stop这种控制命令，直接中断当前任务。

• 路由：根据你配置的规则，把消息分给对应的Agent（你可以有多个Agent，分别处理不同事）。

2.4 车道：防止会话乱套

如果同一个会话里连续发多条消息，OpenClaw会用“车道机制”保证它们串行处理——前一条处理完再处理下一条。这样就不会上下文打架。

但不同会话之间可以并行，你在A群让它写文件，在B群让它查天气，两件事不冲突。

2.5 上下文组装：给AI喂什么料

Agent开始干活前，要先把“脑子”准备好。OpenClaw会组装一个完整的上下文，顺序是：

1. 系统提示词：从AGENTS.md、SOUL.md、MEMORY.md这些文件里读，告诉AI你是谁、什么性格、记得什么。

2. 技能提示：把你装的那些Skill的描述放进去，告诉AI你现在有哪些本事可以用。

3. 对话历史：从{sessionId}.jsonl里读最近的一些消息，让AI记得之前说过啥。

4. 当前消息：你刚发的那条指令。

2.6 Agent执行：推理+工具调用

AI拿到上下文，开始推理。它判断这是执行型任务，需要调用三个技能：读邮件、提炼待办、生成简报。

执行过程是流式的，你会看到它“正在读邮件...”“正在提炼待办...”，而不是干等半天。每步的结果会反馈给AI，继续下一步推理。

如果遇到错误（比如邮箱密码过期），它可以自动切备用模型，或者告诉你出问题了。

2.7 响应和记忆

任务完成后，结果原路返回给你。同时：

• 这次对话存到{sessionId}.jsonl里。

• 值得长期记住的信息（比如你习惯每天这个时间要简报）刷到memory/YYYY-MM-DD.md文件里。

• 重要的常青知识更新到MEMORY.md。

技能（Skill）是OpenClaw最巧妙的设计。它不是传统意义上的插件，而是一本说明书。

3.1 技能的本质：给AI一本SOP

每个Skill就是一个SKILL.md文件，里面用大白话写着操作步骤。比如一个查天气的技能，内容就是：

用户问天气时，执行 curl wttr.in/北京把结果用自然语言回复

OpenClaw读到这个文件，就会照做。就像新员工拿到标准作业指导书（SOP），不用培训就能上手。

OpenClaw内置了55个基础技能，但你可以自己写，教AI做任何事。

3.2 为什么不能把所有技能一次性塞给AI？

早期的AI项目有个通病：工具越多，AI越傻。因为大模型上下文窗口有限，你把几百个技能说明全塞进去，它光看说明书就占了一大半脑子，反而不知道当前该干啥。

所以OpenClaw用了渐进式披露（Progressive Disclosure）的策略——等你需要的时候，我再把细节告诉你。

3.3 技能的三层加载机制

技能加载分三层，像剥洋葱：

这么设计的好处：

• 启动快（不用加载所有技能详情）

• 省token（只用到的技能才加载）

• 选择准（AI不是在一堆工具里瞎猜，而是在少数相关技能里挑）

3.4 技能的优先级和覆盖规则

技能可以放在三个地方，优先级从高到低：

1. 项目工作区./skills/（最优先）

2. 用户全局目录~/.openclaw/skills/

3. OpenClaw内置技能（最基础）

高优先级会覆盖低优先级，你可以自己写个技能，覆盖官方默认行为。

3.5 技能的安全风险

技能系统很强大，但也带来了风险。2026年初爆发的“ClawHavoc”攻击，让ClawHub上约20%的技能被确认是恶意的。这些恶意技能可能：

• 改你的SOUL.md和MEMORY.md，给AI“洗脑”

• 偷你的API Key

• 删你文件

• 挖矿

所以OpenClaw强调最小权限+动态授权：刚装技能时只给基础权限，真要干敏感操作（比如删文件）时，会弹窗让你确认。

理论讲完了，来看个实战：怎么让AI读懂微信公众号文章。

4.1 问题：简单抓取拿不到正文

2月底有人试了试，直接丢个微信文章链接让AI总结。AI用web_fetch去抓，结果只拿到“继续滑动看下一个”这些废话，正文没有。

为啥？微信文章有三道防爬墙：

• 需要Cookie：得带wap_sid2才给数据

• 动态渲染：正文是JS加载的，直接抓HTML拿不到

• 反爬头：User-Agent不对就拒绝

4.2 解决：用Skill封装一个“浏览器读取法”

既然接口不行，就用浏览器。有人写了个wechat-article-viewer技能，步骤很简单：

1. 检查有没有连上一个带调试端口的浏览器

2. 打开文章链接，等它渲染完

3. 抓页面快照，提取标题、作者、正文

但“检查浏览器”这件事，细说起来要三层：

• 端口9222开着吗？

• 能连上通信吗？

• 浏览器里登录了微信吗？

每一步都给AI明确的指引：没开端口就告诉你怎么开；没登录就提醒你登录。

4.3 这个Skill的价值

这个技能看起来简单，但带来了几个改变：

• 经验沉淀：以后再有人丢微信链接，AI不用重新想怎么办，直接套用已验证的步骤。

• 行为可预期：AI不会乱猜，而是按固定流程执行，结果稳定。

• 可复用：团队里一个人写好，所有人受益。

关键不是“这次文章能读到”，而是这些步骤被封装进了SKILL.md，成了AI可重复调用的能力。

Skill让AI回归工程，OpenClaw的Skill体系，代表了一种很务实的AI观：不吹模型多聪明，而是把重点放在能力如何描述、如何加载、如何复用。这更像软件工程，而不是魔法。

当AI真的进入业务、进入日常工作时，这种工程化设计才是体验的保障。模型会升级，平台会变化，但把经验封装成技能、让能力按需加载的思路，会长期管用。