由腾讯朱雀实验室提供支持的安全扫描工具，专为 AI 环境设计。它能审计已安装的 skill 是否存在供应链风险、数据泄漏隐患，也能在安装新 skill 前先做一遍扫描。相当于给 AI 环境装了一个杀毒软件——平时感知不到它，但没有它你根本不知道自己装了什么。
2. Multi Search — 17 引擎整合搜索
把 Google、Bing、DuckDuckGo、百度、搜狗、WolframAlpha 等 17 个搜索引擎整合在一起，支持高级搜索语法、时间过滤、站点限定搜索。最大的价值是不需要 API Key，开箱即用。对比单一引擎，多引擎并行的召回率明显更高，特别适合「不确定在哪个平台能找到」的查询场景。
3. self-improving-agent — 错误学习与持续进化
这个 skill 解决的是一个本质问题：AI 每次对话都是全新的，不会从错误中学习。self-improving-agent 通过捕获「用户纠正 AI 的时刻」，把正确做法写入持久化文件，下次对话前读取。场景包括：命令执行失败时记录正确用法、用户说「不对，应该是…」时记录偏好、发现工具调用方式过时时更新知识。某种程度上，这是在给 AI 装一个「成长日志」。
4. task-tracker — 任务追踪与每日汇报
在对话中记录任务进度，支持「今天做了什么」「哪些还没完成」的跨会话追踪。每日首次对话自动汇报前一天的任务状态。对于习惯用 AI 助手做项目管理的人来说非常实用——不再需要手动维护 TODO 文件，AI 帮你跟。
配合 Multi Search 的标准工作流： 记忆层：Ontology（结构化知识图） + self-improving-agent（错误学习）—— 记事实、学教训 • 任务层：task-tracker（进度跟踪）
裸奔的 AI 助手和装备齐全的 AI 助手，根本不是同一个东西
你有没有遇到过这种情况：同样是 AI 助手，别人用起来能搜网页、记住上下文、自动执行任务，你的只会聊天？
差距不在模型，在插件。
AI 助手就像一个刚入职的员工——底子再好，没有工具、没有流程、没有记忆，能干的事极其有限。而 Skills（技能插件）就是给它配齐装备的过程：搜索能力、网页提取、任务追踪、本地记忆……每装一个，它能做的事就多一块。
这篇记录我折腾 OpenClaw Agent Skills 的完整过程：从一份「十大核心 Skills」的推荐清单出发，10 个里装上了 5 个，装不了的自己动手造了 2 个。过程比我预想的复杂，但挺值的。
先搞清楚：Skill 到底是什么
OpenClaw 的 Skill 本质上是一个目录，里面放了一个
SKILL.md文件，加上可选的脚本和参考文档。每次对话开始前，Agent 会扫描所有已安装的 skill，根据你说的话决定激活哪个。结构长这样：
skill-name/ ├── SKILL.md # 必须：触发描述 + 使用说明 ├── scripts/ # 可选：Python/Bash 脚本 ├── references/ # 可选：参考文档、API 文档等 └── assets/ # 可选：模板、图片等SKILL.md的 frontmatter 里有个description字段，这是 Agent 判断「要不要用这个 skill」的核心依据。你可以把它理解为技能的「激活词」，写得越准确，触发越精准。技能市场目前有两个：国际开源版的 ClawhHub（
clawhub.ai），以及对应平台的内部市场。可以直接在对话里让 Agent 搜索、安装，不用离开聊天界面。十大核心 Skills：每个都是干什么的
网上流传的推荐清单里有 10 个，我逐一试过。先把每个的功能和典型场景说清楚：
1. EdgeOne ClawScan — 安全体检
由腾讯朱雀实验室提供支持的安全扫描工具，专为 AI 环境设计。它能审计已安装的 skill 是否存在供应链风险、数据泄漏隐患，也能在安装新 skill 前先做一遍扫描。相当于给 AI 环境装了一个杀毒软件——平时感知不到它，但没有它你根本不知道自己装了什么。
2. Multi Search — 17 引擎整合搜索
把 Google、Bing、DuckDuckGo、百度、搜狗、WolframAlpha 等 17 个搜索引擎整合在一起，支持高级搜索语法、时间过滤、站点限定搜索。最大的价值是不需要 API Key，开箱即用。对比单一引擎，多引擎并行的召回率明显更高，特别适合「不确定在哪个平台能找到」的查询场景。
3. self-improving-agent — 错误学习与持续进化
这个 skill 解决的是一个本质问题：AI 每次对话都是全新的，不会从错误中学习。self-improving-agent 通过捕获「用户纠正 AI 的时刻」，把正确做法写入持久化文件，下次对话前读取。场景包括：命令执行失败时记录正确用法、用户说「不对，应该是…」时记录偏好、发现工具调用方式过时时更新知识。某种程度上，这是在给 AI 装一个「成长日志」。
4. task-tracker — 任务追踪与每日汇报
在对话中记录任务进度，支持「今天做了什么」「哪些还没完成」的跨会话追踪。每日首次对话自动汇报前一天的任务状态。对于习惯用 AI 助手做项目管理的人来说非常实用——不再需要手动维护 TODO 文件，AI 帮你跟。
5. find-skills — 技能发现
当你说「我想做 X，有什么工具吗」，这个 skill 会在技能市场里帮你搜索匹配的 skill 并给出安装建议。相当于技能商店的导购员。价值在于你不需要知道「这个功能叫什么名字」，描述需求就够了。
6. Tavily Search — 实时联网搜索（需 API Key）
Tavily 的定位是「为 AI Agent 设计的搜索 API」，返回的不是链接列表，而是直接可用的结构化内容，内置网页正文提取。相比 Multi Search，Tavily 的结果质量更高，特别适合需要精确信息的场景（如实时数据、最新新闻）。缺点是需要注册 API Key，而且有免费额度限制。
7. Ontology — 本地知识图谱（自制，见下文）
把用户偏好、项目信息、实体关系存成本地 JSON 图，跨会话持久化。零依赖，纯本地。
8. GitHub — 代码仓库管理
接入 GitHub API，支持查看 issue、PR、分支、提交记录，甚至可以直接在对话里创建 issue、合并 PR。对于重度 GitHub 用户来说，能减少大量在浏览器和 AI 之间来回切换的时间。
9. Office Automation — 日程/邮件/文档全流程
覆盖日历管理（Google Calendar/Outlook）、邮件起草发送、文档生成，是「把 AI 变成私人助理」的核心 skill 组合。典型场景：「帮我看明天有什么会」「根据这段对话写一封跟进邮件」「把这份需求文档转成项目计划」。
10. Systematic Debugging — 结构化调试法
基于「假设-验证」的调试框架，引导 AI 按结构化流程排查问题，而不是随机猜测。遇到复杂 Bug 时，AI 往往倾向于「试试这个」「再试试那个」，这个 skill 强制它先建立假设、说清楚验证方法，再动手。
10 个里只装上了 5 个
技能市场的覆盖度永远跟不上需求，到了边界就得自己造。这不是 OpenClaw 特有的问题，所有可扩展的 AI 平台都是这样——初期靠官方维护，中期靠社区填坑，长期靠用户自己补。
自制 #1：web-reader — Tavily 的免费平替
Tavily 的核心价值是两件事：联网搜索 + 网页正文提取（返回干净 Markdown，方便 AI 处理）。搜索部分 Multi Search 已经覆盖了，缺的是内容提取这一环。
最初打算用 Jina Reader，在 URL 前加个前缀就能把任意网页转成 Markdown：
GET https://r.jina.ai/https://example.com/article测了一下，SSL 握手失败，域名被拦了。换思路——OpenClaw 自带的
web_fetch工具其实内置了 Readability 解析器，能自动过滤广告、导航栏、评论区，返回干净正文。于是我做了一个
web-readerskill，把这个工具的用法规范化，并定义好降级策略：# 降级链：主路径失败时自动切换 第一步: web_fetch(url, extractMode="markdown") # 主路径 第二步: web_fetch(url, extractMode="text") # 降级一：纯文本模式 第三步: browser-operation skill # 降级二：JS 渲染页面兜底配合 Multi Search 的标准工作流：
• 用 Multi Search 搜索，拿到结果 URL 列表
• 对感兴趣的 URL 调用 web-reader 提取正文
• Agent 综合多篇内容给出答案
这个组合基本等价于 Tavily 的能力，而且完全免费，零 API Key 依赖。唯一的差距是速度——Tavily 是并行抓取，web-reader 是串行的。如果你的场景不需要大量并发，这个差距可以忽略。
自制 #2：Ontology — 给 AI 装一个「长期记忆」
这个需求来自一个让人抓狂的现实：每次新开对话，AI 都是全新的，什么都不记得。你跟它聊了几十次，它对你的偏好、项目、工作习惯依然一无所知。就像有个同事，每天早上你都得重新自我介绍。
有人用 RAG（检索增强生成）解决这个问题，把历史对话塞进向量库，按语义检索。这能用，但对「偏好」「关系」「设定」这类结构化信息来说太重了——你只需要知道「用户偏好 Python」，不需要在向量空间里找它。
Ontology 用的是另一条路：把这些信息存成本地 JSON 知识图谱，精确、轻量、可读。数据结构是这样的：
{ "entities": { "用户": { "type": "person", "偏好语言": "Python", "timezone": "Asia/Shanghai", "updated_at": "2026-03-29" }, "项目A": { "type": "project", "stack": "Android + Kotlin", "status": "进行中", "updated_at": "2026-03-29" } }, "relations": [ { "from": "用户", "relation": "负责", "to": "项目A", "created_at": "2026-03-29" } ] }所有操作都封装在一个 Python 脚本里，Agent 直接调用命令行接口：
# 写入一个事实 python3 ontology.py set "用户" "偏好语言" "Python" # 建立关系 python3 ontology.py relate "用户" "负责" "项目A" # 查询某个实体的所有信息和关系 python3 ontology.py get "用户" # → [用户] (person) # → 偏好语言: Python # → timezone: Asia/Shanghai # → relations: # → → 负责 → 项目A # 统计图谱规模 python3 ontology.py summary # → Knowledge graph: 2 entities, 1 relations文件默认存在
~/.openclaw/workspace/memory/ontology.json，跨 session 持久化，零外部依赖，纯标准库。和 RAG 的关系：两者不冲突，互补。RAG 擅长处理大量非结构化文本（你的历史对话、文档），Ontology 擅长存储确定性强的结构化事实（偏好、关系、设定）。理想状态是两者并存，前者负责「语义召回」，后者负责「精确查找」。
写 Skill 的几个实操建议
折腾下来总结几点，踩过坑的才知道：
• description 字段比 body 更重要。Agent 先看 description 决定要不要加载这个 skill，body 只有触发后才读。description 写得模糊，skill 永远不会被用到。这里有个反直觉的地方：description 不是给人看的，是给 AI 看的，要用「意图触发」的语言写，不是功能说明书。
• 零依赖优先。能用标准库就不要引入第三方包，能用内置工具（
web_fetch、exec）就不要调外部服务。Skills 要能在隔离环境里跑，依赖越多越脆，别人安装你的 skill 时也更容易出问题。• 降级链要写清楚。网络环境千变万化，主路径总有失败的时候。在 SKILL.md 里定义好：主路径失败走哪条备用路径，最终兜底方案是什么。这是 skill 质量的分水岭。
• 脚本要实际测试。SKILL.md 里写的步骤，一定要真正跑一遍。光靠「看起来没问题」，上线后大概率会出错。特别是涉及文件路径、API 调用、环境变量的地方。
现在的 Skill 配置全景
配好之后，AI 助手的能力分层是这样的：
• 搜索层：Multi Search（17 引擎） + web-reader（正文提取）—— 找信息、读内容
• 记忆层：Ontology（结构化知识图） + self-improving-agent（错误学习）—— 记事实、学教训
• 任务层：task-tracker（进度跟踪）—— 管任务、报进展
• 安全层：EdgeOne ClawScan —— 体检环境、防供应链风险
• 发现层：find-skills —— 找更多能力
这几层加起来，才算把 AI 助手从「问答机器」升级成了「能干活的同事」。搜索→提取→记住→复用，基本的知识工作闭环跑通了。
接下来最值得探索的是：Ontology 和 self-improving-agent 联动。当前这两个 skill 是独立运行的——AI 纠正错误时记在 self-improving-agent 的日志里，但这些「正确做法」没有自动沉淀进知识图谱。如果把两者打通，AI 不只是记住「我之前错了」，而是记住「正确的方法是 X」——那才是真正意义上的越用越聪明。
这个方向值得动手试一下。