# 知识载体的标准化问题

## 从 Hermes 的 Skill 设计说起

Hermes 做了一个看起来很朴素的设计决策：把 agent 的能力单元定义为一个文件夹，里面放一份 SKILL.md 加上若干脚本。这个决策朴素到几乎没有设计感，但它跑通了 30 多个产品的兼容性测试。Claude Code、Cursor、Gemini CLI、Roo Code 都能直接读这个格式。

这个结果指向一个容易被忽略的工程事实：知识载体的标准化程度，直接决定了知识能被复用的范围。我认为这是 Hermes 生态中被低估的设计贡献。多数关于 agent 能力的讨论集中在模型推理质量和 prompt 技巧上，但如果知识载体本身没有跨平台的可移植性，所有积累都会被锁死在单一框架里。

在《Harness 工程研究》系列中，我们讨论过 context 是稀缺资源，每个 token 都有隐藏成本。Hermes 的 skill 格式设计恰好在这一点上做了巧妙的分层：扫描阶段只读大约 30 个 token 的元信息（名称、适用场景、触发条件），确认相关后才加载完整内容（500-2000 token）。这种渐进式加载让 agent 在有限的上下文预算内，先浏览目录摘要判断相关性，再选择性地加载完整内容。

Agentic-MCP-Skill 项目报告了 86% 的 token 节省。对比方案是"把所有能力文件一股脑塞进去"和"按需加载"。这不只是省钱的事。上下文窗口就那么大，每多塞一段不相关的内容，留给 agent 真正干活的空间就少一分。本质上，progressive disclosure 把一个容量管理问题转化成了信息检索问题，而后者有更成熟的工程手段可以处理。

不过这里有个容易踩的坑。30 个 token 的摘要需要人写或者自动生成，而摘要措辞直接影响后续的匹配准确度。写太宽泛，agent 会加载一堆没用的 skill 文件；写太窄，又会错过有用的。这个精度问题目前没有好的系统化解法，多数情况下靠编写者的手感。我的判断是，这个问题最终需要一个反馈回路来解决：追踪每次加载后 skill 是否真的被使用，根据使用率反向调整摘要的覆盖范围。

## 自动生成的三条路径

格式统一只解决了"容器长什么样"的问题。里面装什么、怎么装，是 Hermes 生态正在探索的另一层。

第一条路径是从用户的实际操作行为中提取模式，也就是 Hermes 的 Skill Factory。用户反复执行的操作序列被识别、抽象、封装成可复用的 skill。好处是知识来源于真实场景，天然有需求验证。坏处是冷启动阶段几乎产不出东西。用户少的时候容易陷入"数据不够→生成质量差→用户不用→数据更不够"的死循环。这意味着 Skill Factory 更适合已经有一定用户基数的成熟部署，而非绿地项目。

第二条路径走市场化筛选，也就是 Hermes 的 Skill Marketplace。agent 完成任务后，任务记录被分析评估，质量分达到 0.8 的自动发布。这个阈值设定反映了一个务实判断：宁可少收一些有用但不稳定的 skill，也要维护整体信任度。npm 早期遭遇的恶意包问题就是前车之鉴。质量门槛太低，信任一旦崩了，整个生态的网络效应就完了。但 0.8 这个数字本身需要追问：评估维度是什么？跨领域是否适用同一标准？一个代码生成 skill 的质量评估维度和一个安全检测 skill 的评估维度，可能完全不同。

第三条路径从源码中生成，也就是 BMAD Forge。它读代码库，提取函数签名和调用关系，生成带有源码链接的指令。独特价值在于每条指令都能追溯到具体的代码行。但生成质量高度依赖源码本身的注释质量。在那种注释稀疏、函数职责混乱的代码库上，自动生成的结果往往改起来比从头写还累。我认为这条路径的适用场景比较窄：它只在代码库本身质量较高、文档齐全的条件下才有实用价值。

三条路径各自适合不同的场景和阶段，不存在一条通吃所有情况的路径。这本身就是个有意义的工程结论。

## 安全领域的压力测试

这些路径的实际效果需要放到具体领域观察。网络安全是个很好的试金石，因为安全规则犯错的代价特别大。一条误报率过高的检测规则会把真正的告警信号淹没。

Anthropic 的 Cybersecurity Skills 项目积累了 754 个安全能力单元。HermesHub 的安全检测覆盖了 65 条以上的威胁识别规则，分布在 8 个安全类别里。每条规则是一个独立的能力单元，可以单独加载、测试和更新。这种粒度的拆分让安全策略的迭代周期变短了。上线一条新规则后发现误报率太高，单独回退就行，不用动其他规则。

不过粒度拆分也带来了组合复杂度。65 条规则之间可能存在依赖关系和执行顺序约束，而这些关系在当前的标准格式中没有显式表达的位置。随着规则数量继续涨，这种隐式依赖会成为运维上的主要头疼。我观察到一个更深层的问题：安全领域的 skill 需要比通用 skill 更强的版本控制和失效检测机制，因为过时的安全规则不只是无用，它会产生虚假的安全感。一条针对已修补漏洞的检测规则如果还在运行，团队可能误以为"漏洞在监控中"，实际上监控的对象已经不存在了。

## 知识会过期

标准化讨论中经常被遗漏的一个维度是时间。能力描述不是写完就一劳永逸的东西。底层 API 会升级，平台策略会变，攻击手法会演化。

当前的文件夹加 Markdown 结构借用 git 做版本控制，这是个聪明的选择。每个 skill 有自己的提交历史和回滚点。但 git 回答的是"谁在什么时候改了什么"，它回答不了"这条知识还有没有效"。这两个问题之间的差距，恰好是知识管理中最难自动化的部分。

去年写的一条安全检测规则，如果针对的漏洞已经被修补了，这条规则的存在就只是在白白消耗上下文空间。更糟的是，过时的规则可能产生误导性的检测结果。目前的标准格式里没有内置的"保质期"机制，知识库会随时间积累越来越多的僵尸条目。

这个问题不只是安全领域有。任何基于特定 API 版本写的操作指令，都可能因为 API 升级而失效。失效的知识被塞进上下文，造成的损害比不塞更大。agent 可能按照过时指令行动，产生那种特别难调试的错误。我认为"保质期"机制是标准化格式中缺失的最关键组件之一。一个可行的实现方向是：每个 skill 文件包含一个 `valid_until` 字段和一个验证脚本，定期自动执行验证来确认知识是否仍然有效。

## 标准化解决了什么，没解决什么

回到工程决策的层面。agentskills.io 解决的核心问题是降低知识投资的平台锁定风险。你花时间写的 skill，可以在 30 多个产品之间迁移，不会被绑死在某一个框架上。在技术选型变化这么快的当下，这个价值特别实在。两年后谁知道哪个框架还活着。

但格式兼容不等于内容质量。0.8 的质量分阈值是个起点，但评估维度是否够全面、标准能不能跨领域用、不同复杂度的任务该不该用同一把尺子，这些问题都还没有收敛的答案。

我的整体判断是：Hermes 在"容器"层面的设计决策基本正确。文件夹加 Markdown 的朴素方案，恰好落在了"足够简单以至于不会出错"和"足够灵活以至于能适应多数场景"的交叉点上。真正的难题在内容层面，包括质量控制、时效性管理和跨领域评估标准的统一。

从格式标准化到可靠的知识积累体系，中间还有一段路。容器的问题 Hermes 基本解决了。接下来的问题是：容器里的东西什么时候该往 agent 的上下文里塞、塞多少，才不会撑坏推理质量。这正是下一篇要讨论的。