夜雨聆风点击上方 前端Q，关注公众号
回复加群，加入前端Q技术交流群
前面 7 篇文章我从规范、版本、评估、对比、门禁、生命周期一路讲下来。
讲到这里，很多人会有一个朴素疑问：
这套东西，后面到底要靠什么样的系统才能跑得动？
写规范靠人，但执行规范要靠平台。
测正确率靠测试集，但跑评估要靠引擎。
灰度发布、监控告警、生命周期推进，都要靠工程系统兜底。
这一篇我把 Skill Hub 的架构画出来，讲清楚每个组件做什么、跟什么系统对接、设计上有哪些核心取舍。
如果你看完这一篇，能在白板上把企业级 Skill Hub 的架构图画给老板看，那就达成目标了。
这张图把 Skill Hub 拆成五层：接入层、控制平面、数据平面、评估平面、治理平面。每一层做的事不一样，互相之间通过明确接口连接。下面我一层一层讲。
我把五层拆成"职责一句话"：接入管入口、控制管元数据、数据管运行、评估管对错、治理管长期健康。任何一层职责模糊，整个 Hub 就乱。
第一层：接入层（Access Layer）
接入层是 Skill Hub 跟外部世界的边界。
它不做核心计算，但做三件关键的事：
1. 多种调用方接入
Skill 不是只有一种调用场景。常见的有：
接入层要给每种调用方提供合适的协议。
我建议至少支持 4 种：
2. 调用方鉴权与配额
每个调用方都有身份：
不同身份能调用的 Skill 不同：
每个身份还有配额：
配额超限会拒绝调用，避免某个团队把成本拉爆。
3. 调用日志与遥测
每一次调用都进日志：
timestamp: 2026-04-30T15:23:11Z
caller: team-frontend
skill: incident-triage@1.3.0
environment: prod
inputs: {service_name: payment, severity: P0}
outputs: {root_cause_category: backend_dep, ...}
trajectory_ref: t-2026-04-30-12345
duration_ms: 12400
tokens_used: 8200
status: success
这些日志是 后面所有评估和监控的原始数据来源，不能省。
第二层：控制平面（Control Plane）
控制平面负责管理"Skill 的元信息和发布状态"。
它不参与运行时执行，但管理着所有运行时所需的元数据。
Skill Registry
这是控制平面的核心：
Registry 的存储设计建议：
版本管理
每个 Skill 都有完整版本历史：
Skill Hub 应该可以一键查询：
"incident-triage 当前 stable 版本是哪个？过去 6 个月有哪些版本上线过？哪一版被回滚过？"
配置中心
存放跟运行时相关的配置：
这些配置应该可以"热更新"，不需要重启服务。
Webhook 与事件
Skill 状态变化要发事件：
订阅这些事件的系统：
事件驱动让整个 Hub 跟周围生态保持同步。
第三层：数据平面（Data Plane）
数据平面是真正执行 Skill 的运行时。
它的核心职责是：接到调用请求 → 找到对应版本的 Skill → 运行 → 返回结果。
听起来简单，实际有几个关键设计点。
1. Skill 加载
调用进来后，第一件事是加载 Skill：
灰度规则在这里生效：
base_version = registry.get_stable(skill_name)
canary_version = registry.A6E22E">get_canary(skill_name)
F92672">if canary_version F92672">and caller F92672">in A6E22E">canary_allowlist(skill_name):
F92672">return canary_version
F92672">return base_version
2. 工具执行
Skill 的 Steps 里会调用工具。工具执行必须经过权限检查：
工具执行还要经过审计：
3. 上下文与隔离
每个 Skill 调用都是一个独立的执行上下文：
如果是 long-running Skill，要支持 checkpoint，让 Skill 能从中间状态恢复（这点 Hermes Agent 本身设计得不错）。
4. 异常处理
执行过程中可能发生各种异常：
数据平面要把这些异常都映射成结构化错误，方便上层处理：
type: tool_timeout | model_invalid_output | rate_limited | context_overflow
retry_advice: retry | abort | fallback
detail: ...
第四层：评估平面（Eval Plane）
评估平面是 Skill Hub 比"普通工具仓库"多出来的关键能力。
它要回答的问题是：这个 Skill / 这个版本 / 这次改动，到底好不好？
Eval Engine
核心组件，跑评估：
为了减少时间成本，Eval Engine 必须支持：
LLM Judge Cluster
L3 业务正确性需要 LLM 当 judge。
判断要稳定，建议：
Test Set Manager
测试集的全生命周期管理：
Compare Service
负责跨版本对比：
Compare Service 直接对接 PR 系统，让对比报告成为 PR 的一等公民。
第五层：治理平面（Governance Plane）
治理平面负责"让 Hub 长期健康"。
它的工作偏向"巡检 + 干预"，不直接服务运行时。
Health Monitor
持续监控每个 Skill：
异常情况触发告警。
Lifecycle Engine
按生命周期规则推进 Skill 状态：
Lifecycle Engine 是企业 Hub 的"自动管家"，没有它，Hub 一定会变成"僵尸 Skill 仓库"。
Audit Log
所有重要操作的审计：
审计要不可篡改、可查询、可导出。
Policy Engine
集中管理所有"业务规则"：
Policy Engine 让"规则"成为代码，而不是飘在邮件里的口头约定。
关键设计取舍
讲到这里，我想专门说几个我认为最关键的设计取舍。
取舍 1：Skill 内容存哪？Git 还是数据库？
我的选择是：Git + 对象存储。
理由：
把 Skill 内容塞进数据库也能做，但失去了 Git 生态。
取舍 2：评估什么时候跑？
有三个时间点可以跑：
我的建议：三个都跑，但触发条件不同。
不能只在 PR 时跑，否则 Skill 会在长期运行中悄悄退化。
取舍 3：自研 vs 接现有平台
很多公司纠结：是自己造一套 Skill Hub，还是基于现有的工具组合（GitLab + LangSmith + 自己写脚本）？
我的判断：初期接现有平台，规模化之后再考虑自研。
初期：
够用。等规模到了一定量级（比如 200+ Skill、跨 10+ 团队）再考虑自研。
取舍 4：Skill 是文件还是数据结构？
Hermes Agent 把 Skill 当 Markdown 文件用，这有它的好处（可读、可手写、可 PR）。
但企业 Hub 内部存储建议：外面是 Markdown，里面是结构化数据。
也就是说：
两端兼顾，避免选边站。
真实落地路径建议
最后给一个实际落地路径建议，按"规模递进"来分：
阶段 1：< 30 个 Skill，2-3 个团队
成本：1 个工程师兼职
阶段 2：30-100 个 Skill，5-10 个团队
成本：1-2 个工程师全职
阶段 3：100+ Skill，10+ 团队
成本：3-5 人小团队
不要一上来就奔着阶段 3 做，会被工程量压垮。
按规模递进，是最健康的演进路径。
每一个阶段都对应一个真实的"组织规模信号"，不要因为听起来酷就跳级。我见过太多团队跳级最后摔得很惨。
我的判断
很多企业准备做 Skill Hub 时，会有一个误区：
"我们先把架构图画完美，再开工。"
我的经验是反过来：先用最简模式跑起来，再按问题驱动加架构。
第一版可能就是一个 Git 仓库 + 一个评估脚本 + 一个 Slack 通知。
但只要规则立起来了，工程化是自然演进的事。
最忌讳的是：架构搞得很大，规则没立起来，最后变成"工程花了大力气，但 Skill 该乱还是乱"。
下一篇我会真正动手 从 0 搭一个最小可运行的 Skill Hub：用 Python + Git + Markdown + 一份评估脚本，跑通 Skill 注册、版本对比、灰度发布、回滚的完整闭环。让你看完之后能在自己公司从一个 demo 起步。
▎可进一步阅读
往期推荐
