Skip to content

Market Research on Cloud-Based Skills and AI Agents #283

Open
Open
Market Research on Cloud-Based Skills and AI Agents#283
@TheShigure7

Description

@TheShigure7
TheShigure7
opened on Apr 28, 2026

云端 Skill / Agent 市场调研

调研日期：2026-04-26
调研目标：围绕 AnyClaw 未来的云端 Skill / Agent 市场能力，调研外部相关产品或项目在“目录组织、检索召回、筛选机制、安装方式、自动化程度、治理能力”上的公开实现。
调研范围：OpenClaw + ClawHub、SkillHub、CliHub、CLI-Anything

1. 调研维度

本次调研重点看六个问题：

  1. 检索对象是什么：skill、agent、plugin 还是 CLI tool
  2. 搜索机制是什么：关键词、全文、向量、混合检索还是目录浏览
  3. 筛选机制是什么：是否有标签、分类、权限、环境、评分、去重、优先级
  4. 安装方式是什么：手动安装、命令安装、API 安装还是 agent 可调用安装
  5. 自动化程度如何：是“用户自己搜”，还是“agent 可以代搜代装”
  6. 治理能力如何：是否有版本、签名、审批、风险边界、隐藏、举报、回滚

2. 总体判断

外部方案大致分成四类：

类型 代表 核心能力 局限
Registry + Local Runtime OpenClaw + ClawHub 技能市场、安装、版本、运行时本地过滤 最终选哪个 skill 仍主要依赖模型
Search / Recommendation Service SkillHub 语义搜索、推荐、MCP 接入、安装入口 公开资料中治理和自动安装决策链不够完整
Agent-Friendly Tool Directory CliHub 自然语言搜索、JSON 输出、工具安装 主要面向 CLI 工具，不是完整 skill/agent 生命周期
Meta-Skill Auto Supplement CLI-Anything agent 自主发现并安装需要的 CLI 依赖模型推理，治理和确定性较弱

结论上，当前公开方案里：

  • 没有哪一家把“能力建模 + 混合召回 + 风险筛选 + 自动安装 + 热加载继续执行”完整打通
  • 现有项目通常各自只强于其中一段
  • AnyClaw 如果把这些段串起来，会比现有公开方案更完整

3. OpenClaw + ClawHub

3.1 定位

  • ClawHub 是 OpenClaw 生态下的公共 Skills / Plugins 注册中心
  • OpenClaw 是本地运行时，负责加载本地技能、过滤可见技能并驱动模型使用

这一套的特点是“云端目录 + 本地运行时治理”。

3.2 检索对象

  • Skill
  • Plugin
  • 未来可扩展的生态包

公开资料中，它更强调 skills 与 plugins，不是通用 agent marketplace。

3.3 搜索与召回机制

ClawHub 公开说明支持：

  • 搜索
  • 安装
  • 更新
  • 版本化
  • embeddings / vector search
  • tags、stars、comments 等社区信号

这说明它不是纯关键词目录，而是已经具备了语义搜索能力。

但公开文档没有把搜索融合公式完全展开，所以无法确认：

  • 是纯向量排序
  • 还是先 lexical 召回再重排
  • 还是多路融合打分

3.4 筛选机制

OpenClaw 真正有价值的地方在于“本地过滤层”，而不是远端排名层。

它对 skill 的筛选主要靠以下机制：

1. 同名冲突优先级覆盖

同名 skill 不会全部一起参与选择，而是按目录优先级只保留一份生效版本。公开文档给出的优先级是：

  1. <workspace>/skills
  2. <workspace>/.agents/skills
  3. ~/.agents/skills
  4. ~/.openclaw/skills
  5. bundled skills
  6. skills.load.extraDirs

这解决的是“重复安装、多个同名 skill 并存”问题。

2. Agent 可见性控制

通过：

  • agents.defaults.skills
  • agents.list[].skills

控制某个 agent 到底能看见哪些 skill。

3. Load-Time Eligibility Filtering

skill metadata 可声明：

  • requires.bins
  • requires.anyBins
  • requires.env
  • requires.config
  • os

运行时只有在环境满足时才会把 skill 纳入候选。

4. Enable / Disable

可通过配置直接禁用指定 skill。

5. Session Snapshot

session 开始时会快照当前可用 skills，后续同一 session 复用；开启 watcher 时，后续 agent turn 可热刷新。

3.5 最终选择机制

OpenClaw 并没有一个强中心化的“技能排序引擎”去强行选 Top1。

它更像：

  1. 先过滤出 eligible skills
  2. 把紧凑 skill 列表注入 system prompt
  3. 再由模型决定调用哪个

所以它的强项是：

  • 去重
  • 本地可见性控制
  • 环境门控

它的弱项是：

  • 缺少一个明确的跨 skill 排名与置信度决策器

3.6 安装与自动化

公开 CLI 能力包括：

  • openclaw skills search
  • openclaw skills install
  • openclaw skills update

当前公开使用方式仍偏“用户或 agent 显式发起安装”，而不是平台在缺能力时后台自动补装并继续原任务。

3.7 治理能力

ClawHub 有公开的基础治理：

  • 举报
  • 隐藏
  • 删除
  • ban

并且有默认自动隐藏规则。
OpenClaw 本地侧则有较强的权限/环境过滤能力。

3.8 对 AnyClaw 的借鉴

最值得借鉴：

  • 同名冲突优先级覆盖
  • 本地 eligibility filtering
  • Agent 可见性 allowlist
  • Session snapshot + watcher 刷新

不适合直接照搬的部分：

  • “最终由模型自己选 skill”这一点对 AnyClaw 来说还不够稳

4. SkillHub

4.1 定位

SkillHub 更像一个“云端 Skill 搜索与推荐服务”，而不仅是静态目录。

它公开强调：

  • Semantic search
  • Recommendations
  • One-command install
  • MCP server 接入

4.2 检索对象

  • Skill
  • 面向多个 agent / coding assistant 生态的可安装技能包

4.3 搜索与召回机制

SkillHub API 文档公开了：

  • POST /api/v1/skills/search
  • GET /api/v1/skills/catalog

并且 search 支持：

  • method=hybrid
  • method=embedding
  • method=fulltext

这意味着 SkillHub 至少明确实现了三种召回方式。

Fulltext

  • 基于文本字段做全文/关键词匹配
  • 适合命中明确词项、名字、专有名词

Embedding

  • 基于语义向量匹配
  • 适合自然语言、改写容错和相似意图召回

Hybrid

  • 同时利用 lexical/fulltext 与 embedding
  • 兼顾字面精确度和语义泛化能力

公开资料没有给出融合算法细节，因此无法确认：

  • 是加权求和
  • 先召回后重排
  • 还是多路结果合并再排序

4.4 筛选机制

SkillHub 公开可见的筛选信号包括：

  • category
  • limit
  • sort

其中 catalog 支持排序：

  • score
  • stars
  • recent
  • composite

此外还提供：

  • recommend_skills
  • “LLM graded for efficiency” 的公开文案

所以 SkillHub 的筛选更偏“远端混合召回 + 目录排序 + 推荐服务”。

4.5 安装与自动化

SkillHub 通过 MCP 暴露：

  • search_skills
  • browse_catalog
  • get_skill_detail
  • recommend_skills
  • install_skill

这说明 agent 可以程序化调用 SkillHub 能力。

但从公开文档看，install_skill 更接近“提供安装动作/命令”或“触发安装入口”，并没有完整公开：

  • 自动安装阈值
  • 风险审批
  • 权限边界
  • 回滚策略

4.6 治理能力

公开信息里更强的是：

  • 搜索
  • 推荐
  • MCP 集成

而不是：

  • 风险审批
  • 权限治理
  • 本地能力冲突控制

因此它更像“召回引擎和能力服务”，不完全是“宿主系统内的策略控制器”。

4.7 对 AnyClaw 的借鉴

最值得借鉴：

  • hybrid / embedding / fulltext
  • score / stars / recent / composite
  • search 与 recommend 分离
  • MCP 接口化，便于 agent 调用

不适合直接照搬的部分：

  • 把最终安装决策完全外包给远端服务

AnyClaw 更适合把 SkillHub 当成“召回层”，而不是“最终决策层”。

5. CliHub

5.1 定位

CliHub 更像“AI Agent 可消费的 CLI 工具目录与安装器”。

它分发的核心对象不是 Skill 包，而是：

  • CLI tool

因此它更偏工具生态，而不是完整的 skill/agent 市场。

5.2 检索对象

  • 命令行工具
  • 工具条目包含安装方法与 agent hints

5.3 搜索与召回机制

公开信息显示它支持：

  • 自然语言搜索
  • --json 输出
  • 按 name / description / tags 进行模糊匹配
  • 结果 sorted by relevance

这意味着它的搜索更像：

  • 轻量 registry 搜索
  • relevance 排序
  • 结构化元数据辅助决策

当前公开资料没有像 SkillHub 一样明确披露：

  • embedding search
  • hybrid search
  • 独立 recommendation API

因此更适合把它理解为“目录检索 + 相关性排序”，而不是“重语义召回系统”。

5.4 筛选机制

CliHub 每个条目有较多适合 agent 消费的字段，例如：

  • name
  • description
  • categories
  • tags
  • install method
  • agent_hints.when_to_use
  • agent_hints.example_usage
  • rating
  • verified

它的筛选更偏：

  1. 基于文本字段的 relevance
  2. 结合 rating / verified / installed
  3. 再由 agent 读取 JSON 后自行决策

5.5 安装与自动化

它支持：

  • 搜索
  • 输出 JSON
  • 直接安装

因此非常适合 agent 自动化脚本：

  1. 搜
  2. 读 JSON
  3. 选
  4. 安装

但“自动选哪个”主要还是由宿主 agent 自己完成，不是 CliHub 内建强决策器。

5.6 治理能力

CliHub 的治理更偏 registry 质量控制：

  • duplicate 校验
  • 字段校验
  • verified
  • rating

而不是高强度的运行期风控。

5.7 对 AnyClaw 的借鉴

最值得借鉴：

  • agent_hints
  • verified
  • rating
  • categories / tags
  • JSON 输出友好性

AnyClaw 的市场元数据层很适合借这个思路扩展成：

  • when_to_use
  • when_not_to_use
  • risk_level
  • permission_level
  • requires_network
  • requires_secret
  • side_effect

6. CLI-Anything

6.1 定位

CLI-Anything 不是一个传统商店内核，而是一套“meta-skill 驱动的自动补能工作流”。

它的核心思想是：

  • 先给 agent 一个总入口 skill
  • 让 agent 读取 live catalog
  • agent 自己选 CLI
  • agent 自己安装 CLI
  • agent 再读取对应 CLI 的 skill 说明完成任务

6.2 检索对象

  • CLI 工具
  • 与 CLI 关联的 skill 文档

6.3 搜索与筛选机制

CLI-Anything 的重点不在于底层 ranking engine，而在于：

  • live catalog
  • category 组织
  • meta-skill 引导
  • agent 自主推理选择

因此它的筛选机制本质上是：

  • 目录浏览
  • 类别导航
  • 模型自主判断

优点：

  • 很灵活
  • 很容易快速做出“自动补能体验”

缺点：

  • 确定性弱
  • 治理能力弱
  • 结果一致性受模型影响大

6.4 安装与自动化

这是它最强的地方。

公开文档明确写到：

  • agents autonomously discover and install the CLIs they need

它在自动化体验上最接近 AnyClaw 想做的“缺能力就自动补上”。

6.5 治理能力

公开实现更偏 workflow，而不是强制度的市场治理内核。

也就是说它更适合做：

  • MVP
  • 体验验证
  • agent 自动补能演示

不太适合作为长期正式市场内核的唯一实现方式。

6.6 对 AnyClaw 的借鉴

最值得借鉴：

  • market-meta-skill 思路
  • 用 agent 先跑通“搜目录 -> 选能力 -> 安装 -> 继续执行”的闭环

最不适合直接照搬：

  • 把筛选责任完全交给模型

7. 横向对比

方案 核心对象 搜索方式 筛选方式 安装方式 agent 自动化 治理强项 对 AnyClaw 的价值
OpenClaw + ClawHub Skill / Plugin 搜索 + embeddings/vector search precedence、allowlist、eligibility filtering CLI install 中等 本地过滤与可见性治理 本地冲突控制、环境门控
SkillHub Skill hybrid / embedding / fulltext score / stars / recent / composite + recommendation API / MCP / install entry 中高 召回与推荐 远端搜索与推荐层
CliHub CLI tool 自然语言 + fuzzy + relevance name/description/tags + rating + verified CLI install 中高 registry 元数据 目录元数据与 agent hints
CLI-Anything CLI + Meta Skill 目录驱动 类别 + agent reasoning agent 自主安装 高 自动补能体验 MVP 闭环与 meta-skill 方案

8. 对 AnyClaw 的总体建议

AnyClaw 不需要复制任何单一方案，而更适合整合它们的长处：

8.1 从 OpenClaw 借

  • 本地 skill 冲突优先级
  • enable/disable
  • agent 可见性控制
  • 环境与依赖门控
  • session snapshot / hot reload

8.2 从 SkillHub 借

  • hybrid / embedding / fulltext
  • recommendation API 思路
  • catalog 排序字段
  • 把搜索能力服务化

8.3 从 CliHub 借

  • 结构化 registry 元数据
  • agent_hints
  • verified / rating
  • JSON 友好输出

8.4 从 CLI-Anything 借

  • 先用 meta-skill 跑通自动补能 MVP
  • 再逐步下沉成平台原生能力选择器

9. 最终结论

如果只从公开资料看：

  • OpenClaw + ClawHub 最强在本地运行时筛选和治理
  • SkillHub 最强在远端混合检索和推荐
  • CliHub 最强在 agent-friendly 目录元数据
  • CLI-Anything 最强在自动补能体验

而 AnyClaw 最有机会建立差异化的位置是：

  • 不是只做市场
  • 不是只做搜索
  • 不是只做安装
  • 而是做“能力筛选 + 自动安装 + 继续执行”的完整闭环

参考资料

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions