Popular software highlighted by OpenClaw skill heat signals.
Popular software highlighted by OpenClaw skill heat signals.
如果你以为 self-improving-agent 会让 agent 自己长脑子，那是误会。它真正值钱的地方，是把失败、纠错、需求缺口拆成 LEARNINGS、ERRORS、FEATURE_REQUESTS 三条线，再明确哪些经验该晋升到 AGENTS、SOUL、TOOLS。这类 skill 的价值不在玄学，而在把反思做成可复用流程。 我更看重它身上的工程味。OpenClaw hook 能把复盘提醒前置，error-detector 虽然还只是关键词触发，但已经开始把“出错后记一笔”从自觉动作推进成半自动动作。它的短板也很清楚：自动化程度没有热度看起来那么夸张，真正能不能学到东西，还是取决于你愿不愿意持续整理 `.learnings/`。
Find Skills 最适合处理一种常见尴尬时刻：用户的需求已经超出当前 agent 的常规能力边界，但又没有明确点名该装什么。它强的不是执行，而是路由，尤其擅长识别“我想做 X，有没有现成 skill”这种半显性需求。对新手 agent 来说，这种分流意识非常值钱，因为很多时候不是不会做，而是根本没想到先去技能市场找现成能力。 它的问题也很直接：内容厚度偏薄，几乎完全建立在 `npx skills` 这一套生态上。没有本地环境检测，没有兼容性判断，没有安全预审，也没有针对 OpenClaw 本地目录的适配逻辑。所以它更像一张去哪里找技能的提示卡，而不是一个成熟的技能检索系统。
Summarize 的定位很克制，它本质上不是一套内容理解框架，而是在告诉 agent：当你已经装好了 `summarize` 命令后，怎样最快把网页、PDF、图片、音频、YouTube 统一送进同一条摘要管线。它的强项就是少说废话，模型选择、环境变量、常用 flag、YouTube 和 Firecrawl 回退都交代得很短，熟手拿来就能开工。 问题也因此很明显。它几乎不提供摘要质量治理，没有事实保真、引用边界、长文切片、领域差异的处理策略，也没有像样的失败回退。你可以把它看成命令速查表，而不是摘要方法论。热度高说明摘要需求高频，不代表这个封装本身已经很成熟。
Agent Browser 是典型的操作手册型 skill。它不替 agent 做浏览决策，而是把 `agent-browser` CLI 能做的事情一次摊开：导航、快照、填表、录像、网络拦截、CDP、状态保存、iframe、对话框、语义定位，几乎常见用法都列到了。对实战来说，这种覆盖密度很有用，因为它能明显减少“知道工具在，但不知道还能这么用”的空档。 它的短板同样很真实。它更像一本命令册，而不是一套浏览器策略，什么时候该重新 snapshot，什么时候该优先用语义定位，怎样设计长流程和降低页面注入风险，文档写得都不算深。所以它适合和你自己的浏览器工作流一起用，而不是单独指望它替你解决稳定性问题。
ontology 是前十里少数真正有基础设施味道的 skill。它不是给 agent 一段提示词，而是在提供一个可验证、可追加、可查询的结构化记忆底座。`graph.jsonl + schema.yaml` 这套组合很聪明，一边保留审计痕迹，一边又不至于一上来就把使用门槛抬到数据库级别；再加上 `scripts/ontology.py` 已经把 create、query、relate、validate、schema-append 做成了实打实可跑的 CLI，这就不再只是概念包装。 它的问题在于表达野心明显大于当前实现。文档里谈到了跨 skill 共享状态、图谱驱动规划、复杂约束，但脚本本身目前仍偏轻量，查询能力也主要停留在简单过滤层。所以它是一个非常值得深挖的起点，但还不是成熟的知识中台。
Self-Improving + Proactive Agent 的聪明之处，不在于它喊得多主动，而在于它对上下文成本有自觉。它把记忆拆成 HOT、WARM、COLD 三层，再配上晋升、降级、归档规则，本质上是在解决一个老问题：记忆越多，反而越难带进来。再加上它明确写了哪些东西不该学、不该推断、不该访问，这让它在边界感上比很多“主动成长型” skill 更稳。 它的短板同样明确：这依旧是一套纪律系统，而不是自动系统。没有脚本，没有 hook，更多是在教 agent 应该怎么记、何时记、何时压缩。执行力强的 agent 会很受用，执行力一般的 agent 则很容易把它用成另一份写得很漂亮但没人坚持的制度文件。