ClawHub 评测：OpenClaw 技能注册表的结构、软删除与部署成本

它解决什么问题，谁需要它

ClawHub 是 OpenClaw 的技能注册表，专门存放文本型 agent 技能，即一个 `SKILL.md` 加上若干支持文件。它解决的问题是技能的分发、版本化和发现。如果你写了很多 OpenClaw 技能，手动拷贝文件到每台机器，或者靠聊天记录分享，ClawHub 提供了 `clawhub install` 和 `clawhub publish` 这样的命令来替代手工流程。它还支持代码插件、bundle 插件，以及实验性的整机 Claw 包。目标用户是 OpenClaw 的重度使用者，尤其是那些需要跨机器同步技能、或者想公开分享技能的开发者。它不是通用的包管理器，离开 OpenClaw 生态，它没有独立价值。

架构：Convex 后端与向量搜索的实际路径

从仓库布局看，前端是 TanStack Start，跑在 React、Vite 和 Nitro 之上，后端是 Convex，负责数据库、文件存储和 HTTP actions。认证走 Convex Auth 加 GitHub OAuth。搜索不是关键词匹配，而是用 OpenAI 的 `text-embedding-3-small` 生成嵌入，再交给 Convex 的向量搜索。这意味着每次发布或索引技能时，都要调用 OpenAI API，这既是成本也是延迟来源。数据流大概是：CLI 或 Web 前端调用 Convex 的 mutations 或 actions，写入技能元数据和文件，索引时生成嵌入。查询时，向量搜索返回相似技能，再渲染 `SKILL.md`。这个架构的好处是开发快，Convex 把数据库、存储和函数都托管了，但坏处是，你被绑定在 Convex 的云服务上，本地开发也要跑 `bunx convex dev` 模拟。

CLI 流程：从登录到发布的真实命令

README 给出了完整的 CLI 命令。认证分两步：`clawhub login` 和 `clawhub whoami`，无头环境用 `clawhub login --device`。发现技能用 `clawhub search` 和 `clawhub explore`，统一目录浏览用 `clawhub package explore`。安装是 `clawhub install @openclaw/demo`，只查看不安装用 `clawhub inspect`。发布技能是 `clawhub skill publish <path>`，插件是 `clawhub package publish <source>`。管理本地安装有 `pin`、`unpin`、`uninstall`、`list`、`update --all`。值得注意的是，`clawhub uninstall` 只删除本机安装，不会影响注册表上的内容。要删除远程技能，得用 `clawhub delete <skill>`，恢复用 `clawhub undelete`。插件对应 `clawhub package delete` 和 `undelete`。这些命令都是软删除，硬删除只有管理员能做。

软删除与恢复：设计取舍

ClawHub 对上传的技能和包采用软删除加恢复机制。普通用户执行 `clawhub delete` 后，技能从公开列表消失，但数据还在，可以 `undelete` 恢复。权限模型是：技能所有者、发布者所有者或管理员、版主、管理员都可以执行。硬删除仅限管理员，通常用于封禁流程。这个设计的优点是防误操作，缺点是数据不会真正消失。如果你发布了一个包含敏感信息的技能，软删除后它仍然存储在 Convex 数据库里，只是不可见。对于需要彻底删除数据的场景，比如合规要求，这个模型可能不够。另外，重命名技能时，旧 slug 会保留为重定向别名，合并技能时，源列表被隐藏并重定向到目标。这解决了链接失效问题，但也意味着旧名字永远占用着命名空间。

Nix 插件支持：一个被低估的细节

ClawHub 可以存储 Nix 插件指针，放在 `SKILL.md` 的 frontmatter 里。通过 `metadata.clawdbot.nix.plugin` 字段，指定一个 Nix 包来源，比如 `github:clawdbot/nix-steipete-tools?dir=tools/peekaboo`，同时声明支持的平台，如 `aarch64-darwin`。这样安装时，nix-clawdbot 会拉取整个 bundle，包括技能包、CLI 二进制和配置要求。还可以声明 `requiredEnv` 环境变量和 `stateDirs` 状态目录，以及一个 `example` 配置片段。这对 macOS 自动化类技能很有用，比如 README 里提到的 Peekaboo 和 Padel。但注意，这个功能只对 Nix 用户有意义，而且需要额外的 nix-clawdbot 工具链。如果你不用 Nix，这段 frontmatter 就是噪音。

遥测与隐私：一个开关就能关掉

ClawHub 在登录状态下执行 `clawhub install` 时会记录安装遥测，用于计算安装次数。README 明确说这是最小化遥测，并且提供了禁用方法：设置环境变量 `CLAWHUB_DISABLE_TELEMETRY=1`。这个设计比较透明，没有偷偷摸摸。但要注意，遥测只在登录时触发，如果你不想被计数，要么退出登录，要么设置环境变量。对于注重隐私的用户，这个开关是加分项。但遥测数据的具体内容，README 没有细说，只提到用于计算安装计数。如果你需要精确的审计日志，可能需要自己抓包验证。

本地开发与部署成本：不止是 Bun

本地开发需要 Bun，Convex 通过 `bunx` 运行，不需要全局安装。步骤是 `bun install`，复制 `.env.local.example` 为 `.env.local`，然后开两个终端，一个跑 `bunx convex dev`，另一个跑 `bun run dev`。还有 `bun run seed:dev` 来填充本地 QA 数据。环境变量包括 `VITE_CONVEX_URL`、`VITE_CONVEX_SITE_URL`、`CONVEX_SITE_URL`、`SITE_URL`、`AUTH_GITHUB_ID`、`AUTH_GITHUB_SECRET`、`JWT_PRIVATE_KEY`、`JWKS`、`OPENAI_API_KEY`。这还没完，GitHub OAuth 和 JWT 密钥都要自己生成。部署到生产，你还需要一个 Convex 云账号。成本包括 Convex 的托管费、OpenAI 的嵌入调用费，以及 GitHub OAuth 的维护。相比一个简单的静态站点，这套系统的运维复杂度高一个数量级。如果你只是偶尔发布一两个技能，这个成本可能不划算。

替代方案与边界

一个直接的替代方案是自建一个 Git 仓库，用 GitHub Actions 做版本管理，用 `git clone` 或 submodule 来安装技能。区别在于，ClawHub 提供了向量搜索、软删除、权限管理和统一的 CLI，而 Git 仓库只有版本历史，没有语义化的技能元数据，也没有安装计数。另一个替代是直接分享 `SKILL.md` 文件，通过网盘或聊天工具，但那样没有版本、没有依赖管理、没有发现机制。ClawHub 的价值在于它和 OpenClaw 的 CLI 深度集成，`clawhub install` 能处理本地安装状态，比如 pin 和 unpin。如果你不需要这些，一个普通文件服务器就够。但如果你需要跨机器同步多个技能，并且希望社区能发现你的技能，ClawHub 的注册表模式是合理的。

编辑结论

ClawHub 适合已经深度使用 OpenClaw、需要集中发布和发现技能与插件的个人或小团队。它解决了技能版本管理、重命名和合并的痛点，软删除机制让误操作可逆，向量搜索比关键词更灵活。但如果你不想依赖 Convex 云服务，或者不想为 OpenAI 嵌入付费，ClawHub 不是轻量选择。自托管需要同时维护 Convex 部署、GitHub OAuth、JWT 密钥和 OpenAI API key，环境变量至少五个，调试成本不低。另外，硬删除仅限管理员，普通用户的删除只是隐藏，如果你需要彻底清除数据，这个模型可能不符合合规要求。在采用前，先确认你的技能发布频率是否值得搭建这套基础设施，并验证 `clawhub login --device` 在无头环境下的流程是否顺畅。ClawHub 的价值在于与 OpenClaw 生态的深度绑定，脱离这个语境，它只是一个又一个注册表。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes