#不用 Postgres，也不用 Redis：我给内网写了个轻量的 AI SkillHub

最近大家都在给 AI Agent 写 skill。写完一个又一个，放在 ~/.agents/skills/ 目录里，隔壁同事问你要你就打个 zip 发过去。过两周你的 skill 更新了，又得重新发一遍。

我们需要一个"技能商店"。不是 App Store 那种上架审核三个月的，是自己部署、团队内部用的那种。搜一下就有了，传上去就能装。

这就是 SkillHub——一个跑在内网、用 SQLite 就能撑住的自托管技能集市。

#skill 到底是什么

先把这个概念说清楚。

AI agent 本质上是个对话接口。它能写代码、能分析数据、能做很多事，但得有人教它怎么做。每次对话都手把手教？太浪费上下文了。skill 就是把"怎么教"这个过程封装成一个包：一段用 markdown 写的指南，加上必要的脚本和模板，放在某个地方，agent 需要的时候自动加载。

就像你不会每次做饭都去菜市场现买锅碗瓢盆——你有一套厨房装备，拿出来就能用。skill 就是 agent 的厨房装备。

SkillHub 管的是这些装备怎么存、怎么找、怎么分发。

#市面上有哪些现成的

动手之前先扫了一圈。选择比我预想的多，但每一类都卡在某个地方。

所以问题不是"有没有得用"，而是没有一个刚好卡在这个量级上：

• 公共平台是别人的地盘，内部的东西不敢放；
• 企业级方案要 Java + PostgreSQL + Redis 一整套，为十几人的团队运维这套东西不划算；
• Agent 自带的 marketplace 绑死在某一个 agent 上；
• 裸 Git 又退回到"能存不能管"。

中间那一档——够用的管理能力，加上几乎为零的部署成本——就是我想填的位置。

#我试过的两条路

在决定自己写之前，这两条路我都试过。

方案一：Git 仓库管理。 建一个仓库，skill 按目录放进去，版本靠 tag 或 commit hash。开源的 skill 放公开仓库没问题，但内部 skill 就尴尬了——放上去等于公开，不放上去就得另起一个私有仓库，两边维护。

更根本的问题是，skill 的消费方不是人，是 agent。agent 需要的是"给定一个名字，拉下最新版并解压到指定目录"，Git 仓库做这件事很重：它不会只 fetch 一个子目录，你得 clone 整个仓库再筛。而且你得给每台机器配 Git 凭证。如果团队里有非技术背景的人想传 skill，教他怎么 clone、commit、push、打 tag，比教他用浏览器拖拽上传多花二十倍时间。

方案二：FTP / 共享目录。 内网搭个 FTP 或者 Samba，skill 打成 zip 往里扔，agent 从共享路径拉。配起来快，某种意义上比 Git 更适合文件分发。

但它天然没有版本概念。你更新了一个 skill，文件名从 skill-v2.zip 变成 skill-v3.zip，agent 怎么知道该拉哪个？写死文件名的话，每次更新都要改 agent 配置。更别提没有搜索、没有元数据、没法按标签筛选。

两条路试下来，结论是一样的：它们都能存文件，但都做不到"管理"。管理意味着元数据、版本、搜索、权限、分发策略——缺一个就是另一个 FTP。

#SkillHub 是什么样的

#搜索、标签、排序

一个集市最重要的是让人找得到东西。关键词搜索走名称和描述，标签做并行筛选，排序支持总下载量和最新发布两种。列表分页，作者维度可以直接筛"我传的"。

#上传：拖进来，或者关联 GitLab 上的 skill

传一个 skill 有两条路。

第一条是拖拽。 把文件夹拖进浏览器窗口，前端直接打包成 zip，再从 SKILL.md 顶部的元信息里读出描述填进表单。skill 的名称取自文件夹名——这是 agentskills 规范的要求，SKILL.md 里的 name 必须和所在目录同名。版本号留空的话，会在上一个版本基础上自动 +0.0.1，省得每次都要想"现在到几了"。

打包用的是一段手写的 CRC32 和 ZIP 生成代码，因为不想在浏览器端引入额外依赖。

第二条是关联一个 Git 仓库里的 skill。 内网里很多 skill 本来就维护在 Git 仓库中，让人先下载、再解压、再拖进浏览器，纯属浪费；而且这一步很容易传错——仓库里可能是 skills/code-review/，也可能直接就是 code-review/，人眼一扫就过去了。所以上传表单另有一组字段：仓库地址、分支、skill 在仓库里的路径，填内网能直接访问的公开仓库即可。

这条路不是把仓库搬进来。SkillHub 只存这三个字段，不克隆、不落盘：详情页上的 SKILL.md 是后端通过 GitLab API 实时取回来渲染的，用户下载时也只取那一个目录，不下载整个仓库。好处是仓库里的 skill 更新了，集市上跟着就是新的，不需要谁来重新传一遍。

代价是这类 skill 不参与版本管理——它跟随分支，取到的永远是该分支的当前状态。要严格按版本回滚的，还是走拖拽上传那条路。

#命名：一个名字，一个作者

详情页的地址长这样：

/skills/alice/code-review

作者名写在路径里，不是装饰。

skill 的名字只在同一个作者名下唯一，不同人可以各自拥有一个 code-review。两个部门各写了一个代码审查 skill，在各自看来都合理，没有理由让第二个人传不上去。讯飞的 SkillHub 用的是 @命名空间/技能名 的坐标，思路是一样的。

这条规则会牵连到别的地方。最典型的是"搬运"——把 A 的 skill 转给 B，如果 B 名下已经有同名 skill，这次操作必须拒绝。数据库的唯一约束只管得住新增，管不住这种转移，得单独检查。

详情页上那两行安装命令也必须带上作者名。用户是直接复制粘贴去执行的，少一段路径不会报错，只会安安静静地装成别人的 skill——这种错误比崩溃更难发现。

#版本：随时回滚

上传的 skill 可以追加新版本，旧版本都留着，随时切回去。作者觉得某个版本有问题，删掉就行。

界面上不引入 latest、alpine 这类 tag 概念。版本列表按时间倒序排，最新的那个标一个角标。"装最新的"本来就是默认行为，不需要先理解一套标签规则。

#权限与搬运

不是谁都能往仓库里传东西。新用户注册后默认是待审批状态，管理员点一下"通过"才能用。认证用 JWT + refresh token，密码 BCrypt 加密，前端遇到 401 自动续期，对用户透明。

从外网搬运 skill 到内网时，上传可以填原作者和来源链接，详情页会同时显示"搬运者"和"原作者"，避免拿别人的成果当自己的。

#主题与语言

亮色暗色一键切。中英文界面，默认中文。config.json 里换个 Logo、换个 favicon、换个标题，不用动代码——内网部署做品牌定制够用了。

#三条命令跑起来

pip install skillhub-selfhost
skillhub-selfhost admin-init
skillhub-selfhost server-start

打开 http://localhost:8000，用管理员账号登录，开始传你的第一个 skill。

默认用 SQLite，零配置。想换成 PostgreSQL，在启动目录下建个 config.json：

{
  "db_url": "postgres://user:pass@localhost:5432/skillhub"
}

不需要装数据库管理工具，不需要配 Nginx 反向代理（生产环境建议加一层），更不需要 Redis。前端页面已经打包进 Python 包里了，一条命令就是一个完整的服务。

#它是给谁用的

如果你的团队在用 AI agent，有 3 个以上反复使用的流程——代码审查规则、部署脚本、某个框架的最佳实践——把它们写成 skill，统一放在 SkillHub 上管理。

十几个人、几十个 skill 的内网团队是我设想的场景：部署成本压到最低，管理能力做到够用。 如果你需要的是一整套带 RBAC、审计日志、多租户命名空间的企业级治理，讯飞的 SkillHub 更合适——它不是竞品，是另一个量级的选择。

如果你只有一个人，那可以先不急着搭仓库。但一旦涉及"和别人共享 skill""在多台机器之间同步 skill""想让新人快速上手团队的 AI 工作流"，SkillHub 比 zip 包和 U 盘拷贝要好得多。

源码在 github.com/mikigo/skillhub-selfhost，Apache-2.0 协议。欢迎 Star、提 Issue、交 PR。