在探讨具体的 skill 之前，我们先花些时间厘清 OpenClaw 的 skill 加载机制。不理解这个底层逻辑，安装再多的 skill 也只会是盲目的堆砌。
OpenClaw 的 skill 本质：系统提示词的一部分
这是一个常见的认知误区。OpenClaw 在每次启动一个会话（session）时，其 Agent Runtime 会执行一项关键任务：组装系统提示词。它会读取你的 SOUL.md（定义 Agent 的行为风格）、AGENTS.md（工作流规则）、TOOLS.md（工具集）以及 MEMORY.md（跨会话记忆），然后将你安装的所有 skill 通过 formatSkillsForPrompt 函数压缩成一张“能力清单”注入到提示词中。这张清单会告诉大模型每个 skill 的 SKILL.md 文件位于哪个路径，以便在需要时去读取。
关键在于：这些文件在每一轮对话中都会被重新注入一次，并且全部占用上下文窗口（context window）的令牌（token）数。如果 MEMORY.md 长期未清理，很容易悄然增长至数千 token；SOUL.md 若写得过于冗长也是常见问题；安装二十个用不到的 skill，最终都会成为 token 的负担，轻则拖慢响应速度，重则触发上下文压缩（context compaction），截断你的短期记忆。
因此，选择 skill 的原则不是“多多益善”，而是“精准占位”。理解了这个前提，我们再来看看实际使用中值得占据一席之地的 5 个 skill。
一、self-improving-agent（@pskoett）
这是目前 ClawHub 上星标数最高的 skill（⭐ 2.1k，下载 22 万）。许多人错误地将其仅视为“错误日志工具”，但它更核心的价值在于与 OpenClaw 的工作空间（workspace）文件体系深度联动。
具体来说，这个 skill 会在项目根目录维护一个 .learnings/ 目录，内含三个文件：
.learnings/
├── LEARNINGS.md # 记录被纠正的行为、知识盲区、更优方法
├── ERRORS.md # 记录命令失败、工具报错信息
└── FEATURE_REQUESTS.md # 记录你要求过但暂时缺失的功能
记录本身并不特别，特别的是它的晋升机制（promotion）。当一条 learning 被标记为 Recurrence-Count >= 3 且跨越至少 2 个不同任务时，它就会被提升至 CLAUDE.md、AGENTS.md 或 SOUL.md 中——直接转变为每次 session 启动时注入上下文的永久规则。
换言之，它是在用工程化的方式解决 AI 的跨会话记忆问题。OpenClaw 原生的 MEMORY.md 是平铺式的，随着条目增多，不仅上下文占用越来越大，而且缺乏“权重”区分，AI 难以判断哪些规则更重要。self-improving-agent 的晋升机制本质上是在进行记忆的优先级排序与持久化分流——高频规则进入 CLAUDE.md，项目工作流进入 AGENTS.md，行为风格进入 SOUL.md，低频错误则留在 .learnings/ 中等待复查。同样的错误最多踩三次，之后这条规则便进入系统提示词，永久生效。
它还支持通过 Hook 接入。在 .claude/settings.json 中配置以下两个 hook：
{
"hooks": {
"UserPromptSubmit": [{
"hooks": [{ "type": "command", "command": "./skills/self-improvement/scripts/activator.sh" }]
}],
"PostToolUse": [{
"matcher": "Bash",
"hooks": [{ "type": "command", "command": "./skills/self-improvement/scripts/error-detector.sh" }]
}]
}
}
activator.sh 在每次提交用户提示时触发，注入一段学习评估提醒；error-detector.sh 则在 Bash 工具执行后读取 CLAUDE_TOOL_OUTPUT 环境变量，检测非零退出码，自动将失败信息写入 ERRORS.md。这两个 hook 均在本地运行，不联网，但每次会产生约 50-100 token 的额外开销。若上下文预算紧张，可以仅手动记录，不启用 hook。
二、ontology（@oswalpalash）
这个 skill 下载量约 18,000，其名称令许多人望而却步，但它解决的正是 OpenClaw 记忆体系中的一个结构性缺陷。
OpenClaw 原生的 MEMORY.md 是平铺且线性的——每条记忆之间没有关联，只有时间顺序。当你询问“这周最需要跟进哪个客户”时，AI 可能找到三条独立的记忆：张三是联系人，B 公司是客户，项目截止日是下周五。但它不知道这三件事是相互关联的，需要依靠生成时的推理去“猜测”关联，而非依靠数据结构去“遍历”关联。
Ontology 的做法是在工作空间中引入一个显式的知识图层。它定义了 Person、Project、Task、Event、Document 等核心实体类型，每个实体都有明确的属性和关系约束。当 AI 需要记住“Alice 是 Project X 的负责人，邮箱是 alice@example.com”时，它不再将这句话存储为一段文本，而是创建三个相互关联的节点：
Person: Alice
- email: alice@example.com
Project: Project X
- status: active
Relation: Alice --[owner_of]--> Project X
这种结构带来的最大好处是可遍历性。询问“Project X 现在谁在负责”时，AI 沿着 owner_of 这条边一步即可得出答案，而无需在一大段平铺文本中进行语义搜索。更重要的是，这些结构化的节点本身比同等信息的自然语言描述更节省 token，在上下文窗口中占据的空间反而更小。
在 OpenClaw 的架构中，ontology 与 MEMORY.md 的分工是：MEMORY.md 存储事件流（发生了什么、何时说了什么），ontology 存储事实图谱（谁是谁、什么关系、什么属性）。两者互补，而非替代。
三、self-improving（@ivangdavila）
这个 skill 的名称与第一个高度相似，但功能定位截然不同，务必区分。
其核心在于分层记忆架构。它在 ~/self-improving/ 目录下维护一套比 self-improving-agent 更为精细的文件系统：
~/self-improving/
├── memory.md # 热记忆，始终加载，硬性限制不超过 100 行
├── index.md # 主题索引，带行数统计，用于快速定位
├── heartbeat-state.md # 心跳状态，记录上次维护任务运行时间
├── corrections.md # 最近 50 条修正记录，滚动覆盖
├── projects/ # 项目特定学习，按项目隔离
├── domains/ # 领域知识，按技术域组织
└── archive/ # 冷记忆，自然衰减的低频模式
这个结构背后有明确的设计哲学：热记忆（memory.md）被严格控制在 100 行以内，超出的内容会自动降级至 archive/。这直接对应了 OpenClaw 的上下文预算问题——不加控制的跨会话记忆最终会吞噬掉上下文窗口的大部分空间。
最有意思的是其心跳（heartbeat）机制。OpenClaw 的 Gateway 本身有一个后台守护进程定期运行 heartbeat——读取 HEARTBEAT.md，决定是否需要主动联系用户。此 skill 在此基础上增加了 Agent 对自身行为的周期性自我评估：它会检查本次会话中是否出现了“重复解释同一件事”、“回答偏离任务主线”等模式，并更新 heartbeat-state.md。可以将其理解为一种数字化的记忆巩固过程——在两次主动工作之间，系统在后台进行结构性整理，将短期记忆中的重要部分压缩进长期存储，让低频模式进入 archive/ 自然衰减。
与 self-improving-agent 的最大区别在于作用层级：前者作用于项目层（项目规范、具体错误，存储在项目根目录的 .learnings/ 中），后者作用于工作空间层（Agent 的行为风格，存储在用户主目录下，并会直接修改 AGENTS.md 和 SOUL.md）。两者目录完全隔离，可以同时安装。但需要注意：安装前请备份好 SOUL.md 和 AGENTS.md，因为这个 skill 会主动修改它们。
四、obsidian（@steipete）
steipete 是 OpenClaw 的创始人 Peter Steinberger，这个 skill 可视为官方背书的 Obsidian 集成。
技术上，它依赖 obsidian-cli（通过 brew install yakitrak/yakitrak/obsidian-cli 安装），将 Obsidian 知识库（vault）作为普通文件夹进行操作——搜索笔记、创建新页面、移动文件、更新 [[wikilinks]]。
该 skill 的 SKILL.md 中有一个值得关注的工程决策：它不让你硬编码 vault 路径，而是让 Agent 在运行时去读取 ~/Library/Application Support/obsidian/obsidian.json，动态发现所有 vault 的位置。这也是 ClawHub 的 OpenClaw 扫描将其标记为“Suspicious (medium confidence)”的原因——它访问了用户主目录下的系统配置文件，但在 SKILL.md 的 requires 字段中并未声明此行为。
从工程角度看这是合理决策（vault 路径变更后无需手动修改配置），但你必须清楚其实际的权限边界：此 skill 知道你所有 vault 的位置，并对它们拥有完整的读写权限。如果 vault 中包含高度敏感的内容，需要在 OpenClaw 的沙箱（sandbox）配置中进行相应的路径限制，而非依赖 skill 自身来约束。
在使用场景上，obsidian skill 与 ontology 搭配效果显著。前者负责从 vault 中读取原始笔记，后者负责将笔记中的关键实体和关系结构化存入知识图谱。两者结合，AI 既能“找到”信息，又能“理解”信息之间的关联。对于需要整理大量笔记和构建个人知识库的用户，这是一套值得研究的 技术文档 实践。
五、nano-banana-pro（@steipete）
同样是 steipete 出品，下载量约 11,000。其功能是通过 Google 的 Gemini 3 Pro Image 模型生成和编辑图片，支持文生图（text-to-image）和图生图（image-to-image），分辨率可选 1K / 2K / 4K。
该 skill 的文档中明确建议了一个分阶段的工作流：
第一步：使用 1K 分辨率快速生成草稿，验证构图和风格方向
第二步：小幅调整提示词（prompt），继续用 1K 分辨率迭代，直到方向确定
第三步：提示词完全锁定后，再升至 4K 分辨率生成最终版
这个建议背后有实际的 API 成本逻辑——生成一张 4K 图片所需的时间和 token 消耗大约是 1K 图片的四倍。在提示词尚未稳定前就使用 4K 分辨率，是在浪费等待时间和配额。
配置上，此 skill 需要两个依赖：uv（Python 包管理器）和 GEMINI_API_KEY 环境变量。需要注意的是，ClawHub 的注册表元数据中并未声明这两个依赖（仅在 SKILL.md 中写明），这是文档不一致的问题，并非恶意行为。但这意味着你需要手动在 OpenClaw 的 config.json 中配置 apiKey：
{
"skills": {
"entries": {
"nano-banana-pro": {
"enabled": true,
"apiKey": {
"source": "env",
"provider": "default",
"id": "GEMINI_API_KEY"
}
}
}
}
}
如果你的 Agent 工作流涉及图片生成需求，这个 skill 的接入成本很低，在 Telegram 或 WhatsApp 等场景中发一句话指令就能直接获得结果。如果工作流基本不涉及图片，可以先不安装，待有需求时再添加，也就是几分钟的事。
最后：关于上下文预算管理
在安装任何 skill 之前，建议先做一件事：执行 /context detail 命令，清楚了解你的上下文预算当前被哪些文件占用了多少。MEMORY.md 长期不清理很容易膨胀至数千 token，SOUL.md 写得过于啰嗦也是常见问题。
ClawHub skill 的注入逻辑是，只有 enabled: true 且平台满足 requires.bins 条件的 skill 才会出现在能力清单中——这意味着你可以“只安装不激活”，先装好，等需要时再启用。同时激活上述五个 skill 对上下文的影响在可接受范围内，但如果你的上下文窗口配置本身就比较紧张，可以优先启用 self-improving-agent，其他按需激活。
这五个 skill 各自填补了 OpenClaw 本身尚未完善的一些关键缺口：记忆的持久化与分流（self-improving-agent）、知识的结构化（ontology）、行为的自我校正与记忆分层（self-improving）、外部知识库接入（obsidian）、多模态能力扩展（nano-banana-pro）。ClawHub 上有超过 13,000 个 skill，绝大多数可能并不值得安装。但这五个在切实解决实际问题，这是我经过数周实践后仍保留它们的原因。
发表于 昨天 08:52
|
查看: 5|
回复: 0
