我用 Hermes Agent 做了大半年的实际工作——从电力交易数据采集、股票监控、博客部署到服务器运维。在这个过程中，最让我觉得”这个框架跟其他 ChatBot 不一样”的，不是它能调工具、不是它能跑终端命令，而是 Skill（技能）系统。
这篇文章记录我对 Skill 系统的理解和实践心得。
一、什么是 Skill？
一句话概括：Skill 是 Agent 的程序性记忆。
大语言模型有两种知识：
- 陈述性知识（Declarative）：训练数据里学到的”巴黎是法国首都”——靠模型权重存储。
- 程序性知识（Procedural）：”在阿里云服务器上部署 Hexo 博客需要先 hexo generate 再 rsync”——靠流程和步骤存储。
LLM 天生有陈述性知识，但缺程序性知识。你不能指望模型天生知道”我们公司的数据采集脚本有 420 秒的全局预算”或者”港股有佛诞日休市，不能只按周一到周五判断开市”——更别提年年都在迭代的省份电力现货规则：安徽试运行到第 6.2 版了，任何模型的训练数据都追不上。
Skill 就是为解决这个问题而生的：把可复用的工作流程或领域知识写成一份 Markdown 文档，Agent 在需要时自动加载到上下文中，按文档里的步骤（或公式）执行。
二、Skill 不是 Prompt 模板
很多人第一次接触 Skill 会想：这不就是 system prompt 里多写几句话吗？
差远了。几个关键区别：
1. 按需加载，不占常驻上下文
我这台工作机上现在接近 40 个 Skill——27 个是自己一点点攒出来的，覆盖三省电力市场政策、交易策略算法、环氧树脂绝缘材料、工业节能改造、邮件处理、PDF/OFD 转 Markdown，甚至还有两个”学习搭子”（一个陪国内的初高中生，一个陪在英国读 IGCSE 的留学生）；剩下的是官方插件自带的。
光我自己这 27 个，文档全文加起来就超过 30 万字符。全部塞进 system prompt？再长的上下文窗口也扛不住这种用法。
Skill 是按需加载的——Agent 每轮对话只看到 Skill 索引（名字 + 一段描述），判断哪个跟当前任务相关，才加载完整正文。就像人不会同时想着”怎么修水管”和”怎么做红烧肉”。
2. 带触发条件
好的 Skill 描述会明确告诉 Agent 什么时候该用它。比如我的邮件技能是这么开头的：
通过 agently-cli 命令行工具操作邮件：发送、回复、转发、搜索、读取、下载附件、管理收件箱。当用户需要进行任何邮件相关操作时使用此 skill。
用户说”帮我回封邮件”，Agent 扫一眼索引就知道该加载它。中英文无所谓，关键是把”什么时候用”写清楚——这句话常驻在每一轮对话里，它既是触发器，也是成本，值得反复打磨。
我还有个更极端的写法：在 PDF 转 Markdown 的技能描述里，直接列出用户会说出口的原话——“把 PDF/OFD 转成 md””文献转 md””政策文件转 md”。把触发短语明明白白写进去之后，几乎再没漏触发过。
3. 能持续进化
这是我用得最多的特性。我装了一个 skill-creator——一个专门用来创建和修改 Skill 的”元技能”。Agent 解决了一件文档里没覆盖的麻烦事，我就让它把踩过的坑补进对应的 Skill；发现内容过时了，也让它自己改。Skill 越用越完善，而不是一直踩同一个坑。
三、我的实际 Skill 使用场景
举几个真实例子：
场景 1：三省电力市场政策专家
我们做售电，安徽、福建、江西三省的规则各不相同。这类知识有三个特点：训练数据里没有（太新）、网上查很碎（要啃几百页规则文件）、出错代价高（结算算错是真金白银）。
我把三省规则各做成一个专家 Skill：节点电价公式、结算方式、偏差考核区间、零售价差分成的阈值和比例，全部写成具体数字。Agent 做计费引擎时加载对应省份的 Skill，照着公式写代码，不用每次现学一遍规则。
更有意思的是技能之间会互相配合：我还有一个自动入库技能，职责是对话中出现新的政策文件就传进 PTIS 知识库，它的文档里明确写了”入库后可用省份专家技能验证内容”——技能生态自己长出来了。
场景 2：电力数据采集
我的 PTIS（电力交易辅助决策系统）每天 18 点自动采集碳市场、期货、天气等数据。整个管道涉及：
daily_collect.sh主脚本，每步独立超时fetch_market_data.py用线程池并发采集- 交易日历判断（港股有特殊休市日！）
- 交叉验证脚本对比数据一致性
这些细节全部记录在数据采集 Skill 里。没有这个 Skill，每次出问题 Agent 都要从零开始理解整个管道架构。
场景 3：港股监控
股票监控有个血泪教训：Agent 曾经在港股休市日运行了一整天的监控脚本。后来我把”必须内置交易日历判断，不能仅用周一到周五判断开市”写进了 Skill 和 Memory，再没犯过。
场景 4：macOS 环境的特殊性
macOS 的 launchd 有个 FD 限制（默认 256），多个 cron 任务长跑会耗尽文件描述符。这个坑踩过一次后，我把它写进 Memory，并更新了相关 Skill，以后部署定时任务时 Agent 会自动注意设置 NumberFiles=10240。
四、Skill vs Memory：什么时候用什么？
这两个系统容易混淆。我的判断标准：
| Skill | Memory | |
|---|---|---|
| 存什么 | 工作流程、操作步骤、命令参考 | 事实、偏好、环境信息 |
| 粒度 | 一个完整任务的操作手册 | 一句话能说清的事实 |
| 加载时机 | 匹配到相关任务时 | 每轮对话都注入 |
| 示例 | “如何用 Hexo 部署博客” | “用户偏好 TXT 而非 Markdown” |
简单记：Skill 是”怎么做”，Memory 是”是什么”。
比如”老板偏好简洁高效风格”是 Memory；”如何用 deploy.sh 部署博客”是 Skill。
五、写好 Skill 的几个原则
实践下来，好的 Skill 有几个共性：
1. 触发条件要精确
我给安徽、福建、江西各做了一个政策专家，如果三个的描述都只写”电力市场专家”，Agent 根本分不清该加载哪个。安徽专家实际用的描述是这样收尾的：
Use when building/configuring billing engines for Anhui, answering Anhui-specific electricity market questions, or comparing Anhui vs Fujian/Jiangxi rules.
省份、场景、和隔壁技能的区别，一句话里全说清了。
2. 记录坑，而不只是步骤
一个只有”第1步、第2步、第3步”的 Skill 是脆弱的。真正有价值的是 Pitfalls（陷阱） 部分——那些你踩过坑才知道的事情。
比如”terminal 工具会截断长行（如 JWT token），docker exec 调认证 API 会 401，替代方案是用 browser fetch + localStorage token”——这种知识，不写进 Skill 就得每次重新踩。
我现在甚至会在 Skill 里专门写一节”不要做这些”，把 Agent 犯过的错用 ❌ 一条条列出来。实践经验：负面清单比正面指导管用得多。
3. 分清两类 Skill，别用一把尺子量
常看到”单个 Skill 不要超过多少行”的建议，实践下来要分情况：
- 流程型 Skill（怎么部署、怎么采集）：越短越好。Agent 要一步步照着执行，写长了反而稀释重点。
- 知识型 Skill（规则、公式、参数）：可以长。正文是按需加载的，进来就是当参考资料查的——我最大的福建政策专家写了 40 多 KB，照样运行良好，因为结构清晰：分章节、公式带编号、参数用表格。
真正要严控的是描述，它常驻每一轮对话。另外，长内容的 Skill 可以把细节拆进 references/ 子目录（我的学习搭子、环氧绝缘专家都这么干），工具型的 Skill 配 scripts/ 目录放可执行脚本。
4. 让 Agent 自己维护
Agent 解决了一个复杂问题后，主动问”要不要存成 Skill”。存下来的 Skill 在后续使用中如果发现过时或不完整，就让 Agent 用 skill-creator 自己更新。这种”越用越聪明”的感觉，是传统 ChatBot 完全给不了的。
六、一点哲学思考
用久了之后，我觉得 Skill 系统本质上在做一件事：把人的隐性知识转化为显性知识。
你知道”港股佛诞日要休市”，但如果你不告诉 Agent，它不知道。Skill 的意义在于——你只需要告诉它一次，它就永远记住了。而且这个知识是可以传承的：换一个模型、换一个 session，Skill 还在那里。
后来我干脆写了一个 book-to-skill——把整本书、整份文档里的方法论榨成一份结构化的 Skill。本质上还是同一件事，只不过这次显性化的是别人的隐性经验。
还有一点很实际：Skill 就是 ~/.agents/skills/ 下的一个 Markdown 文件夹，ZCode、Claude Code、Copilot CLI 这些工具都认这个目录。换模型、换客户端，知识跟着文件夹走，不锁死在任何一个产品里。
这跟人类组织积累经验的方式很像。一个老员工的离职带走的不只是技能，还有那些”文档里不会写的经验”。Skill 系统让这些经验有了载体。
当然，Skill 也不是万能的。它依赖模型的理解能力——如果模型读不懂 Skill 的描述，就不会在正确的时机加载它。而且 Skill 质量的上限取决于写 Skill 的人（或 Agent）的表达能力。但作为一个让 AI Agent 从”一次性对话工具”进化为”可持续协作伙伴”的机制，我认为 Skill 是目前最好的设计之一。
本文由小年夜（Hermes Agent）撰写，基于在厦门信年实业有限公司的实际使用经验。