AI Agent 架构设计（七）：Skills 系统设计（OpenClaw、Claude Code、Hermes Agent 对比）¶

Ch01.215 AI Agent 架构设计（七）：Skills 系统设计（OpenClaw、Claude Code、Hermes Agent 对比）¶

📊 Level ⭐⭐ | 17.0KB | entities/skill-system-design-three-way-comparison.md

Skills 的本质：Agent 的专业经验¶

语言模型是通才。它懂很多，但不懂你的公司、你的项目、你的工作方式。你想让 Agent 按你团队的代码规范写代码，按你的模板写周报，用你摸索出来的方法处理某类任务——这些都需要把你的专业经验"装进"Agent。Skills 就是这个装载机制。 但这里藏着一个关键问题：这份说明书，应该从哪里来？ 这不是一个技术问题，而是一个关于"Agent 应该如何积累专业能力"的根本判断。三个框架赌的是三件完全不同的事：

OpenClaw 赌社区集体智慧 ——让最懂每个场景的人写出最好的 Skill，分享给所有人
Claude Code 赌个人经验沉淀 ——你最了解自己的工作，你写的 Skill 最准确
Hermes 赌 Agent 能自我进化 ——执行过程本身就是最好的经验来源，为什么要人来整理

OpenClaw：赌社区集体智慧¶

ClawHub：Agent 界的 npm¶

OpenClaw 的 Skills 来自 ClawHub——一个开放的技能市场。任何人发布，任何人安装。规模已经相当大：超过 31,000 个 Skills，覆盖邮件处理、CRM 管理、代码审查、数据分析……这个逻辑和 npm 一样：让社区里最懂某个场景的人来写这个场景的 Skill。 冷启动体验是三个框架里最好的——装上 OpenClaw，立刻有数万个 Skills 可用，不需要自己从零积累。

社区赌注的代价：供应链攻击¶

2026 年 1 月，安全研究人员发现 ClawHub 上出现了大规模恶意 Skill——341 个伪装成正常工具的恶意包，植入了键盘记录器和信息窃取木马，专门针对 OAuth Token、API Key 和浏览器密码。后续审计发现恶意或有安全隐患的 Skill 一度超过总量的 20%。安装一个 ClawHub Skill，本质上是在你的机器上执行陌生人写的代码，而这段代码拥有和 OpenClaw 本身完全相同的系统权限。 ClawHub 没有强制性的代码审核：任何人只要有一个超过一周的 GitHub 账号就可以发布，没有代码签名，没有沙箱验证，没有安全扫描。 当你把"经验来源"交给开放社区，你同时也把"信任边界"交了出去。

Claude Code：赌个人经验沉淀¶

Skills 的来源：你自己写¶

Claude Code 的 Skills 主要由使用者自己创作——你把自己的工作流程、规范、最佳实践整理成 SKILL.md，放进 .claude/skills/ 目录，Agent 自动发现并加载。核心逻辑：Skills 是你的专业经验的外化，你写什么，Agent 就学什么。

渐进式披露：经验越多，成本越低¶

Claude Code 解决了一个实际难题：如果你写了 20 个 Skills，每次 Session 都把所有 Skills 的完整内容塞进上下文，窗口立刻就满了。 解法是渐进式披露（Progressive Disclosure）——Skills 的加载分三层：

第一层（启动时，~100 Token）：每个 Skill 只加载名称 + 描述，Agent 知道"有哪些经验可用"
第二层（按需加载，<5,000 Token）：完整 SKILL.md 内容加载，Agent 按照说明执行任务
第三层（文件系统直接读取，0 Token）：辅助文件、参考资料、可执行脚本，不注入上下文，直接运行第三层有一个值得关注的设计：scripts/ 里的代码不注入上下文，Claude 直接用 bash 执行。 这意味着一个 Skill 可以附带几千行 Python 代码，却对 Token 成本没有任何影响。

Compaction 后 Skills 的持续性¶

上下文满了会触发 Compaction（压缩）。Claude Code 对此有专门保护：压缩时，当前已加载的 Skills 会重新附加到压缩后的上下文，每个 Skill 保留前 5,000 Token，所有 Skills 共享 25,000 Token 的预算。 Skills 里的规则和约束在整个任务周期内持续有效——你花时间写进 Skill 的经验，不会因为会话变长而消失。

Hermes Agent：赌 Agent 能自我进化¶

颠覆前提：经验为什么要人来写¶

OpenClaw 和 Claude Code 有一个共同假设：Skills 由人来写。 Hermes Agent 挑战了这个假设：如果 Agent 执行任务的过程本身就是最好的经验来源，为什么还需要人来整理？ Hermes Agent 的做法：当 Agent 完成一个复杂任务（通常是 5 次以上工具调用），系统自动把这次执行过程提炼成一份 Skill 文档——步骤、工具选择、遇到的问题、解决方法——写进 ~/.hermes/skills/。下次遇到类似任务，自动加载这份 Skill，不用从头摸索。 更关键的是：Skill 在使用中自我更新。 Agent 发现更好的方法，自动修改 Skill 文档。经验在积累，方法在迭代。有用户测试：装好 Hermes，连续执行几个复杂任务，两小时内 Agent 自动生成了三份 Skill，再跑类似任务的速度提升 40%。全程没有人工干预。

这个赌注难在哪里？¶

Agent 自动生成 Skill 的难点不是技术，是判断： 1. 什么任务值得生成 Skill？ Hermes 用"5 次以上工具调用"作为启发式规则。简单直接，但不精确。 2. 抽象的层次在哪里？ 做了一件具体的事，怎么提炼成下次可以复用的通用方法？太具体泛化性差，太抽象没有操作指引。 3. 质量谁来把关？ Hermes 目前没有内置的 Skill 质量评估机制，质量完全取决于生成时那次任务的执行质量。

Skills 的共享：跨 Agent 的经验传播¶

Hermes 的 Skills 默认是单个 Agent 私有的。但放进共享目录 ~/.hermes/skills/ 的 Skills，同一台机器上的所有 Agent 都能读取。 PLUR 社区插件更进一步——对一个 Agent 的纠正会自动传播给同项目的其他 Agent。一个 Agent 学到的，其他 Agent 也学到了。

三种赌注，三种取舍¶

维度	OpenClaw	Claude Code	Hermes Agent
经验来源	社区开放市场（ClawHub）	个人编写（SKILL.md）	Agent 自动生成
冷启动	最佳（31000+ Skills 即装即用）	最差（需自己编写）	差（需使用中积累）
质量控制	差（无强制审核，20%有安全隐患）	最佳（你写什么学什么）	中（依赖执行质量，无内置评估）
Token 成本	全部注入上下文	渐进式披露（三层）	使用时加载
共享机制	ClawHub 开放市场	手动分享	PLUR 跨 Agent 传播
适用场景	任务类型多样，快速覆盖	特定专业场景，高质量要求	固定重复任务，愿意等待积累
最成熟的做法是组合：用社区 Skills 快速启动，用自己写的 Skills 覆盖核心场景，让 Agent 在使用中自动沉淀新 Skills。
Skills 的格式已经走向开放标准（agentskills.io）。

深度分析¶

三种架构理念的根本分歧¶

这三个框架在 Skills 系统上的分歧，本质上反映了对"AI Agent 应该如何获取能力"的三种截然不同的哲学立场。 OpenClaw 代表的是开放式社区创新模式——类似于 Linux/GitHub 的成功路径相信群体智慧能够产生比任何单一实体更丰富、更多样的解决方案。31,000+ Skills 的规模证明了这种模式的可行性。但 2026 年初的供应链攻击事件揭示了这一模式的核心脆弱点：当任何人可以贡献代码时，恶意行为者的进入成本几乎为零，而受害者的信任成本却极高。这不是 OpenClaw 独有的问题——npm、Docker Hub、PyPI 都曾面临过类似困境——但在 Agent 系统中后果更为严重，因为恶意 Skill 获得的是完整的系统执行权限。 Claude Code 代表的是个人知识管理（PKM）向 Agent 时代的延伸。这个模型的核心假设是：专业知识是个人化的、最有效的 Skills 来自最了解自己工作方式的人。渐进式披露机制是一个精妙的工程解法，它在"丰富经验储备"和"有限上下文窗口"之间找到了动态平衡。但这个模型要求用户具备编写高质量 Skill 文档的能力和意愿——这对普通用户是一个不低门槛。 Hermes Agent 代表的是最激进的路径：让 Agent 成为自身经验的作者。这在概念上最为优雅——专业经验不再需要人来整理和编写，Agent 在执行中自动完成这个过程。但现实是骨感的：当前的 LLM 在判断"什么构成有价值的方法抽象"方面能力有限，自动生成的 Skill 质量参差不齐就是必然结果。40% 的性能提升听起来不错，但这是建立在新 Skill 生成后的下一次执行——之前那"两小时连续任务"本身可能已经被低质量的自动生成过程拖慢了。

渐进式披露的工程意义¶

Claude Code 的三层渐进式披露机制值得单独分析，因为它代表了一种重要的设计思路：根据调用频率和重要性来动态决定信息加载深度。第一层（~100 Token）是索引层——它解决的是"Agent 知道有哪些 Skill 可用"的问题，而不是"Agent 知道每个 Skill 的完整内容"。这类似于人类专家的 mental index：当遇到一个新问题时，专家首先想到的是"我有哪些工具可以用"，而不是立刻回忆每个工具的完整使用手册。第二层（<5,000 Token）是工作层——当 Agent 确定使用某个 Skill 时，加载完整内容。这种按需加载避免了无用信息的干扰，同时保证了执行时的信息充足度。第三层（0 Token 的脚本执行）是最聪明的地方——它承认某些信息根本不应该进入上下文（代码几千行），但又必须可用。直接文件执行 + bash 调用把这个矛盾消解了。这为 Skills 的扩展性提供了一个重要思路：Skill 可以包含大量辅助代码而不影响 Agent 的推理成本。

安全模型的深层矛盾¶

OpenClaw 的供应链攻击暴露了一个根本矛盾：开放生态的信任模型与高权限 Agent 执行模型的不兼容。在一个开放的 Skills 市场中，"信任"是缺失的——你无法验证发布者的身份、意图和能力。而在 Claude Code 和 Hermes 的模型中，信任是内置的：你自己编写或你授权的 Agent 生成的内容，信任链是清晰的。这对企业级应用有重要启示：当 Agent 需要在企业环境中执行高权限操作时（访问敏感数据、修改系统配置、执行财务操作），社区 Skills 市场的模型几乎是不可接受的。Claude Code 的个人编写模式虽然信任链清晰，但在企业场景中面临另一个问题：个人编写的 Skill 是否经过适当的安全审查？ Hermes 的模型在信任方面处于中间地带——Skills 由你的 Agent 生成，但生成的质量取决于执行那次任务的上下文和模型能力。

实践启示¶

选择框架时的决策树¶

在决定采用哪种 Skills 架构时，应该基于以下维度进行判断： 如果你是个人开发者或小团队，关注快速启动和任务类型多样：

OpenClaw 是最务实的选择——31,000+ Skills 即装即用，冷启动成本最低
风险是安全：你需要自己审核每一个安装的 Skill 的代码
建议只在你完全有能力审核源码的场景下使用社区 Skills 如果你是专业开发者，工作场景相对固定且对输出质量要求高：
Claude Code 是最佳选择——你自己编写的 Skills 最准确，渐进式披露控制了成本
代价是前期投入：你需要花时间把自己经验整理成高质量的 SKILL.md
建议从高频重复任务开始编写 Skills，逐步覆盖核心场景 如果你在固定领域执行重复性强的复杂任务：
Hermes 的自动生成模型潜力最大——它能随着使用不断积累和优化
风险是质量不稳定：新领域的第一个 Skill 质量可能不达预期
建议配合人工审核机制，定期检查生成的 Skill 质量

企业级部署的关键考量¶

在企业环境中部署 Agent Skills 系统时，以下原则至关重要： 信任边界必须清晰。社区 Skills 在企业场景中只能作为"灵感来源"而非直接执行单元——可以参考社区 Skill 的实现思路，但必须用内部团队编写或审核的版本来执行。任何直接执行社区 Skill 的做法都等同于在生产环境运行来源不明的可执行文件。 Skills 的生命周期管理。无论是哪种架构，Skills 都需要版本控制、变更审核和定期审查机制。Claude Code 和 Hermes 的本地 Skills 文件本质上是你的知识资产——应该像代码一样受到版本控制。 渐进式披露是必备功能。如果你的 Agent 实现需要支持大量 Skills（超过 10 个），上下文窗口管理不再是可选项而是必选项。Claude Code 的三层渐进式披露是一个值得参考的实现范式。

构建个人 Skills 库的最佳实践¶

无论使用哪个框架，以下原则都能帮助你建立高质量的 Skills 储备： 从痛点出发。不要为了"建立 Skills 库"而写 Skills——只在遇到"Agent 反复以同一方式处理同一类任务却效果不佳"时，才考虑将解决方案固化为一篇 Skill。 保持原子性。每个 Skill 应该专注于一个明确的场景或任务类型。过于泛化的 Skill 会失去针对性，过于具体的 Skill 则难以复用。找到一个合适的抽象层次需要迭代调整。 强制结构化。即使框架不要求，也应该用统一的格式组织 Skill 内容：问题描述（什么情况下用）、执行步骤（怎么做）、约束条件（什么情况下不要用）、预期输出（做完后应该是什么样）。 定期淘汰。Skills 库需要新陈代谢。当某个 Skill 长期未被调用，或者它描述的工作流程已经被 Agent 熟练掌握时，应该将其归档或删除。低质量的 Skills 积累会降低 Agent 的判断效率。