SkillHub：把企业里的 Agent 技能包收进一个「内部商店」

想象这样一幕：算法团队的小王写了一个把 PDF 拆成结构化数据的 Skill，效果很好，同事都想要。但技能包散落在小王的笔记本、飞书文档和某个共享盘里——没有版本号，没有权限控制，谁改坏了谁都不知道，更别提让一个新来的同事去"考古"找到它。

SkillHub 就是来解决这件事的。它由科大讯飞（iFLYTEK）开源，是一个可自托管的 Agent 技能注册中心：把技能包当成 npm 包来管理，但运行在你自己的服务器里。

背景：Agent 技能正在成为团队的"第二代码库"

过去两年，大模型厂商推动的"Skills"概念（SKILL.md + 脚本 + 资源的打包格式）已经从概念走向工程现实。Claude Code、Codex、Cursor 等 Agent 工具都支持从目录读取技能包，团队开始积累大量"资产化"的工作流——自动生成周报、批量抓取行业情报、跑回归测试、审查开源许可证。

但公共注册中心（如 ClawHub、SkillsMP）解决不了企业场景的三个核心痛点：

1. 数据主权：公司的提示词模板、内部 API 调用逻辑、涉及业务数据的处理脚本，不能传到公网。
2. 权限与审计：谁能发布、谁能审核、谁下载了哪个版本，必须可追溯，否则出了事无法定责。
3. 质量风险：一个技能包里可能藏着 curl xxx | bash，也可能夹带外传数据的脚本。公共市场靠社区举报，企业需要的是入库前自动扫描。

SkillHub 的定位正是把这三件事补齐：私有部署 + RBAC 治理 + 安全扫描。

类比：它更像"企业内部 Maven 仓库"，而不是"应用商店"

很多同学第一反应会把它理解成一个应用商店，其实更贴切的类比是 JFrog Artifactory 或公司内部的 npm registry：

• 你 npm publish 一个包，团队通过 npm install 拉取——SkillHub 的心智模型完全一致，只不过包变成了技能包；
• 依赖版本用语义化版本号（1.2.0）管理，还有 beta / stable 自定义标签和 latest 自动跟踪；
• 存储层可插拔：本地文件系统用于开发，S3 / MinIO 用于生产，compose.storage.rustfs.yml 里甚至直接给了 RustFS 的私有化对象存储组合。

换句话说，它管的是"分发与治理"，不是"运行"。技能最终装到你的 Agent 客户端里执行，注册中心自己不执行技能逻辑。

核心功能：注册中心该有的，它基本都齐了

团队命名空间与三级角色

技能发布后归属某个命名空间（团队私有或全局公开），每个命名空间有独立的成员表和角色：Owner / Admin / Member。团队管理员在自己的命名空间内做审核，平台管理员把关"能否晋级到全局作用域"。这条两级审批链是它和公共市场最大的区别——全局作用域不是想进就能进的。

全文检索与可见性隔离

搜索支持按命名空间、下载量、评分、更新时间过滤。这里有个容易被忽略的细节：可见性规则会确保用户只能看到自己有权查看的技能，也就是说搜索结果不是全局目录的简单投影，权限过滤发生在检索链路内部。

安全扫描：入库前先过一遍

这是 SkillHub 最有企业说服力的设计。仓库里内置了一个 scanner/ 模块，对接 Cisco 的 skill-scanner，对技能包做恶意行为检测。调用链路是：

SkillHub 后端 SecurityScanService.triggerScan()
  → Redis Stream (skillhub:scan:requests)
  → ScanTaskConsumer
  → SkillScannerAdapter
  → HTTP 调用 Cisco skill-scanner

扫描是异步的：请求投递到 Redis Stream，消费者拉取后调用扫描服务，扫完再回写结果。这也解释了为什么 compose 里 scanner 是个独立容器，并且有 SKILL_SCANNER_MAX_CONCURRENT_SCANS（默认 1）和 HARD_TIMEOUT_SECONDS（默认 930 秒）这样的限流参数——LLM 驱动的扫描很慢，需要显式的并发和超时管控。

CLI 优先

npm install -g @astron-team/skillhub
skillhub login --token sk_xxx --registry https://skill.xfyun.cn
skillhub search pdf
skillhub install pdf-parser --agent codex
skillhub list

CLI 用 Bun + TypeScript 写的，依赖很克制（cac、fflate、prompts、semver、zod），支持设备码授权（skillhub login 不带 token 时自动走 device flow）、命名空间同步和本地清单管理。服务端还提供了一层 ClawHub 风格注册中心的兼容层，让已有的 CLI 客户端能平滑迁移。

其他细节

• OAuth 集成：Helm values 里预置了飞书和钉钉的授权端点，企业可直接用 IM 身份登录；
• 国际化：基于 i18next，支持中英俄韩四种语言；
• 账号合并：多个 OAuth 身份和 API Token 可以归并到一个账号下；
• Token 管理：按前缀做安全哈希存储，支持作用域限制；
• 社交化：技能可以 star、评分、统计下载量。

架构与技术栈

后端是 Java 21 + Spring Boot 3.2.3 的 Maven 多模块工程，模块划分清晰地体现了 DDD 分层：

模块	职责
skillhub-domain	领域模型与核心业务规则
skillhub-auth	认证授权、RBAC、设备码授权
skillhub-search	全文检索
skillhub-storage	存储抽象（本地 / S3 / MinIO）
skillhub-infra	基础设施适配层
skillhub-notification	通知（站内、企微等）
skillhub-github-sync	与 GitHub 的同步
skillhub-app	应用装配与 Web 层

前端是 React 19 + TypeScript + Vite + Radix UI + TanStack Query/Router，pnpm 管理，Nginx 打包静态产物。CLI 是 Bun + TypeScript，扫描器是 Python。数据库用 PostgreSQL 16（Flyway 做迁移），缓存用 Redis 7。整体是一套相当标准的企业级 Java 技术栈，运维熟悉度很高。

上手门槛：两条完全不同的路径

路径 A：想用的人（零门槛）

curl -fsSL https://imageless.oss-cn-beijing.aliyuncs.com/runtime.sh | sh -s -- up --public-url https://skillhub.your-company.com

国内还有阿里云镜像参数 --aliyun。这条命令拉起完整栈并生成配置。

路径 B：想自己部署的运维（中等门槛）

cp .env.release.example .env.release
# 必改：SKILLHUB_PUBLIC_BASE_URL、POSTGRES_PASSWORD、
#       SKILLHUB_DOWNLOAD_ANON_COOKIE_SECRET（至少 32 位随机串，不改会启动失败）
make validate-release-config
docker compose --env-file .env.release -f compose.release.yml up -d

集群场景用 charts/skillhub 这个 Helm Chart，values 里已经把 Ingress、cert-manager、飞书/钉钉 OAuth、S3、Bootstrap 管理员等参数都铺好了。官方还专门提供了一条镜像脚本 runtime.sh，支持 up / ps / logs / down 生命周期，--version edge 可以追 main 分支构建。

值得注意的是镜像的多架构支持：仓库里有专门的 riscv64-images.yml 工作流，构建时用 --platform=$BUILDPLATFORM 在宿主机上编译，再产出 amd64 / arm64 / riscv64 镜像。国内信创场景下这点很有价值。

争议与局限：几个需要泼冷水的地方

1. "注册中心"依赖客户端生态。它自己不执行技能，价值要通过 CLI 装进 Agent 才兑现。如果团队不用 Claude Code / Codex 这类支持 SKILL.md 的工具，SkillHub 就只是一个文件服务器。
2. Java 后端偏重。对一个"发包收包"的产品来说，Spring Boot 多模块 + Postgres + Redis + 独立扫描器的架构偏重，中小团队自建可能觉得资源占用不划算。
3. 扫描能力外置依赖 Cisco。scanner 模块本质是对 cisco-ai-skill-scanner 的 HTTP 适配层，不配置 SKILL_SCANNER_LLM_API_KEY 时扫描能力就退化；这引入了对外部项目的运行时耦合。
4. 版本 0.x，接口仍在演进。CLI 版本 0.3.0、Web 0.1.18，服务端 pom 是 0.1.0。虽然官方明确说明"原生 REST API 为主、协议兼容层持续扩展"，但生产接入要预留接口变动成本。
5. 兼容层是权宜之计。README 提到兼容 ClawHub 风格客户端，这意味着协议尚未收敛，长期看双向兼容会成为维护负担。
6. 文档提到"local profile 的 mock 认证不得在发布部署中启用"，这类安全约束靠文档而非机制强制，值得留意。

行业意义

SkillHub 折射出一条清晰趋势：Agent 生态正在长出"依赖管理"层。当技能成为团队生产资料，包管理、版本控制、权限治理、安全扫描就都是刚需。Claude Code 的官方 plugin marketplace、OpenAI 的技能生态、以及各类"Skills 注册中心"的出现，说明这个位置正在被争夺。

讯飞在这个位置上的优势很实在：企业级 Java 后端的工程经验 + 私有化部署的交付能力 + 讯飞本身作为大型企业客户的使用场景。公开站点 skill.xfyun.cn 已经运营，官方还把它做成了 AAIF 联盟成员并被 Trendshift 收录，说明社区侧也在活跃。

对团队来说，它的价值可以概括成一句话：把"人人都在本地攒技能包"的松散状态，变成有版本、有权限、有审计的工程化资产。如果你正在为"团队写的技能到底怎么共享和管"发愁，这套方案目前是开源选项里完成度最高的一个。

---

仓库：https://github.com/iflytek/skillhub 许可：Apache-2.0 技术栈：Java 21 / Spring Boot 3.2.3 / PostgreSQL 16 / Redis 7 / React 19 / Bun / Python 维护方：科大讯飞 iFLYTEK