Agent 成功完成了一次复杂代码审查。下次遇到同类任务，它仍可能从头搜索、重新试错。问题不在于它没有工具，也不在于它忘了项目事实，而在于那套“应该先做什么、哪里容易出错”的做法没有被保存。
Hermes Agent 把这类知识定义为 skill。它不是一个新的执行器，而是一份可以按需读取的程序性知识。
这篇只回答一个问题：Agent 为什么有了工具和记忆之后，仍然需要一套独立的技能系统？
Hermes 给出的答案是：工具提供动作，记忆保存事实，技能沉淀做法；Hermes 只在系统提示词中展示技能目录，需要时再加载正文，并允许 Agent 在安全检查后创建和改进技能。
工具、记忆、技能，分别解决什么问题
工具回答“系统能做什么”。终端、文件读取、搜索都是可调用动作。记忆回答“系统知道什么”，例如用户偏好、项目约定和历史事实。技能回答“这类任务应该怎么做”，保存步骤、判断条件和踩坑经验。
这三个概念混在一起，产品界面就会失真：用户以为安装了技能就获得了新 API，或者以为记住一条偏好就等于学会一套流程。Hermes 用不同载体保存不同知识类型，让能力、事实与方法各自演进。
渐进加载：先让 Agent 知道，再决定是否读取
如果把二十个技能的全文都塞进 system prompt，几万 token 会在每轮调用中重复出现。技能越多，成本越高，模型反而越难判断当前任务真正相关的内容。
Hermes 只把“名称 + 描述”放进稳定层。模型判断某项技能相关后，再调用 skill_view 读取正文。目录负责发现，正文负责执行指导。这个两阶段结构保住了 prompt cache，也让技能库可以扩张。
Agent 可写技能，价值与风险同时出现
Hermes 不把技能限定为开发者预置文件。Agent 可以把一次成功经验整理成 SKILL.md，也可以改进已有技能。这样，工作结果不只是一份当次交付，还可能成为未来任务的操作资产。
可写意味着必须治理。Agent 生成的内容同样可能包含危险命令或恶意指令，因此不能因为作者是 Agent 就跳过扫描。多来源同名时也要有明确优先级，否则用户不知道最终加载的是哪一份。
技能描述其实是检索入口
目录里只有名字没有清楚描述，模型就不知道什么时候该加载技能。描述不是宣传文案，而是一次匹配判断的入口：任务是什么、适用什么场景、能产出什么。
对产品经理来说，技能管理至少要看四件事：可发现性、按需加载、版本来源和安全状态。只有编辑器，没有这些信息，技能数量增加后很快会变成新的配置负担。
一项技能如何进入下一次任务
把前面的机制串起来，一项技能会经历五个环节：
- Agent 或用户发现某类任务存在可复用做法。
- 通过
skill_manage创建或修改SKILL.md。 - 新技能接受与外部安装技能相同的安全扫描。
- 技能名称和描述进入目录缓存，但正文不进入 system prompt。
- 新任务命中相关场景后，模型调用
skill_view读取正文，内容以 tool result 进入当前上下文。
这里有两个不同的“生效”。技能进入目录，代表 Agent 知道它存在；调用 skill_view，才代表当前任务 真正读取了做法。产品如果只展示“已安装”，用户仍然无法判断模型是否发现并使用了它。
Hermes 还会用 nudge 提醒 Agent 定期审视有没有技能值得创建或改进。nudge 只是提醒，不会绕过判断自动写文件。这个边界避免系统把每次操作都沉淀成低质量技能。
三个容易走偏的地方
- 把所有技能正文永久放进 system prompt，导致上下文和缓存成本持续增加。
- 把 skill 与 memory 混为一类，既无法稳定召回事实，也无法清楚复用流程。
- 把技能当成绝对规则，忽略任务现场仍然需要模型判断。
产品经理可以怎样评审
评审这项能力，可以先检查三条：
- 先明确技能是“流程知识”还是“外部能力”，再设计入口，避免概念包装。
- 技能规模化的前提不是更多文件，而是目录描述足够可检索、正文能够按需加载。
- Agent 自建技能必须与外部安装技能采用同等级别的来源标识和安全检查。
原材料没有展开完整安全扫描规则、Hub 安装过程和缓存失效策略，本文不把这些能力写成已完成的生产方案。