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

裸奔的 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」的核心依据。你可以把它理解为技能的「激活词」写得越准确触发越精准。技能市场目前有两个国际开源版的 ClawhHubclawhub.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 KeyTavily 的定位是「为 AI Agent 设计的搜索 API」返回的不是链接列表而是直接可用的结构化内容内置网页正文提取。相比 Multi SearchTavily 的结果质量更高特别适合需要精确信息的场景如实时数据、最新新闻。缺点是需要注册 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— 跳过已有对应平台的代码管理 skillOffice Automation❌ 未找到市场无收录Systematic Debugging❌ 未找到市场无收录技能市场的覆盖度永远跟不上需求到了边界就得自己造。这不是 OpenClaw 特有的问题所有可扩展的 AI 平台都是这样——初期靠官方维护中期靠社区填坑长期靠用户自己补。自制 #1web-reader — Tavily 的免费平替Tavily 的核心价值是两件事联网搜索 网页正文提取返回干净 Markdown方便 AI 处理。搜索部分 Multi Search 已经覆盖了缺的是内容提取这一环。最初打算用 Jina Reader在 URL 前加个前缀就能把任意网页转成 MarkdownGET https://r.jina.ai/https://example.com/article测了一下SSL 握手失败域名被拦了。换思路——OpenClaw 自带的web_fetch工具其实内置了 Readability 解析器能自动过滤广告、导航栏、评论区返回干净正文。于是我做了一个web-readerskill把这个工具的用法规范化并定义好降级策略# 降级链主路径失败时自动切换 第一步: web_fetch(url, extractModemarkdown) # 主路径 第二步: web_fetch(url, extractModetext) # 降级一纯文本模式 第三步: browser-operation skill # 降级二JS 渲染页面兜底配合 Multi Search 的标准工作流• 用 Multi Search 搜索拿到结果 URL 列表• 对感兴趣的 URL 调用 web-reader 提取正文• Agent 综合多篇内容给出答案这个组合基本等价于 Tavily 的能力而且完全免费零 API Key 依赖。唯一的差距是速度——Tavily 是并行抓取web-reader 是串行的。如果你的场景不需要大量并发这个差距可以忽略。自制 #2Ontology — 给 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 决定要不要加载这个 skillbody 只有触发后才读。description 写得模糊skill 永远不会被用到。这里有个反直觉的地方description 不是给人看的是给 AI 看的要用「意图触发」的语言写不是功能说明书。•零依赖优先。能用标准库就不要引入第三方包能用内置工具web_fetch、exec就不要调外部服务。Skills 要能在隔离环境里跑依赖越多越脆别人安装你的 skill 时也更容易出问题。•降级链要写清楚。网络环境千变万化主路径总有失败的时候。在 SKILL.md 里定义好主路径失败走哪条备用路径最终兜底方案是什么。这是 skill 质量的分水岭。•脚本要实际测试。SKILL.md 里写的步骤一定要真正跑一遍。光靠「看起来没问题」上线后大概率会出错。特别是涉及文件路径、API 调用、环境变量的地方。现在的 Skill 配置全景配好之后AI 助手的能力分层是这样的•搜索层Multi Search17 引擎 web-reader正文提取—— 找信息、读内容•记忆层Ontology结构化知识图 self-improving-agent错误学习—— 记事实、学教训•任务层task-tracker进度跟踪—— 管任务、报进展•安全层EdgeOne ClawScan —— 体检环境、防供应链风险•发现层find-skills —— 找更多能力这几层加起来才算把 AI 助手从「问答机器」升级成了「能干活的同事」。搜索→提取→记住→复用基本的知识工作闭环跑通了。接下来最值得探索的是Ontology 和 self-improving-agent 联动。当前这两个 skill 是独立运行的——AI 纠正错误时记在 self-improving-agent 的日志里但这些「正确做法」没有自动沉淀进知识图谱。如果把两者打通AI 不只是记住「我之前错了」而是记住「正确的方法是 X」——那才是真正意义上的越用越聪明。这个方向值得动手试一下。