裸奔的 AI 助手和装备齐全的 AI 助手，根本不是同一个东西

你有没有遇到过这种情况：同样是 AI 助手，别人用起来能搜网页、记住上下文、自动执行任务，你的只会聊天？

差距不在模型，在插件。

AI 助手就像一个刚入职的员工------底子再好，没有工具、没有流程、没有记忆，能干的事极其有限。而 Skills（技能插件）就是给它配齐装备的过程：搜索能力、网页提取、任务追踪、本地记忆......每装一个，它能做的事就多一块。

这篇记录我折腾 OpenClaw Agent Skills 的完整过程：从一份「十大核心 Skills」的推荐清单出发，10 个里装上了 5 个，装不了的自己动手造了 2 个。过程比我预想的复杂，但挺值的。

先搞清楚：Skill 到底是什么

OpenClaw 的 Skill 本质上是一个目录，里面放了一个 SKILL.md 文件，加上可选的脚本和参考文档。每次对话开始前，Agent 会扫描所有已安装的 skill，根据你说的话决定激活哪个。

结构长这样：

bash 复制代码

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 个

Skill	状态	原因
EdgeOne ClawScan	✅ 已安装	---
Multi Search	✅ 已安装	---
self-improving-agent	✅ 已安装	---
task-tracker	✅ 已安装	---
find-skills	✅ 已安装	---
Tavily Search	❌ 未安装	需要 API Key，市场上没有无 Key 版
Ontology	⚙️ 自制	市场无收录，自己写了一个
GitHub	--- 跳过	已有对应平台的代码管理 skill
Office Automation	❌ 未找到	市场无收录
Systematic Debugging	❌ 未找到	市场无收录

技能市场的覆盖度永远跟不上需求，到了边界就得自己造。这不是 OpenClaw 特有的问题，所有可扩展的 AI 平台都是这样------初期靠官方维护，中期靠社区填坑，长期靠用户自己补。

自制 #1：web-reader --- Tavily 的免费平替

Tavily 的核心价值是两件事：联网搜索 + 网页正文提取（返回干净 Markdown，方便 AI 处理）。搜索部分 Multi Search 已经覆盖了，缺的是内容提取这一环。

最初打算用 Jina Reader，在 URL 前加个前缀就能把任意网页转成 Markdown：

ruby 复制代码

GET https://r.jina.ai/https://example.com/article

测了一下，SSL 握手失败，域名被拦了。换思路------OpenClaw 自带的 web_fetch 工具其实内置了 Readability 解析器，能自动过滤广告、导航栏、评论区，返回干净正文。

于是我做了一个 web-reader skill，把这个工具的用法规范化，并定义好降级策略：

ini 复制代码

# 降级链：主路径失败时自动切换
第一步: 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 知识图谱，精确、轻量、可读。数据结构是这样的：

css 复制代码

{
  "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 直接调用命令行接口：

csharp 复制代码

# 写入一个事实
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」------那才是真正意义上的越用越聪明。

这个方向值得动手试一下。