上篇聊了 Tool——Agent 用来操作外部世界的“手脚”。有了手脚之后，下一个问题就来了：Agent 应该怎么用这些手脚？什么时候该做什么、做到什么程度算是“完成”、遇到模棱两可的情况怎么判断？这就是 Skill 解决的问题。它不是告诉 Agent “你怎么用 kubectl”——那是 Tool 的事。Skill 告诉 Agent 的是“做一件事的正确流程和原则”。但很多人对 Skill 有一个根深蒂固的误解，这篇文章聊聊这件事。
一、Skill 是什么：自定义的流程和原则
先回到一个具体场景。你在 Hermes 里写了一个 Skill，叫 code-review。它大概是这样的：
## Code Review Skill
在进行代码审查时，遵循以下流程和原则：
### 审查流程
1. 先理解改动的业务背景（从 PR 描述和关联 Issue 中获取）
2. 检查安全性问题（SQL 注入、XSS、敏感信息泄露）
3. 检查性能瓶颈（N+1 查询、不必要的循环、大对象创建）
4. 检查代码风格和可读性
5. 检查测试覆盖（改动是否包含测试，测试是否覆盖了边界情况）
### 判断原则
- 安全问题是 blocker，必须修复
- 性能问题视影响范围决定是否 blocking
- 代码风格问题建议修改但不强制
- 不确定的地方标记为"建议确认"，不要直接判断
### 输出格式
每个问题标注严重程度：[Blocker] / [Major] / [Suggestion]
注意这个 Skill 里没有任何技术细节——它没告诉你 grep 怎么用、git diff 怎么调。它都在讲流程（按什么顺序检查）、原则（什么算 blocker、什么算 suggestion）、输出规范（怎么标注严重程度）。
这就是 Skill 的本质：把经验变成 Agent 的行为准则。 一个资深工程师做 Code Review 时脑子里自然运转的那些判断——“先查安全、再说性能、最后是风格；安全问题零容忍、风格问题点到为止”——通过 Skill 变成了 Agent 可以遵循的规则。
Skill 不是 Tool 的说明书。 Tool 解决“能做什么”，Skill 解决“怎么做”。两者不在一个维度上，不构成替代或竞争关系。
二、“Skill 越多越好”——最常见的误解
这也是对 Skill 误解最深的一点。
很多人用 Hermes 或者类似的 Agent 工具时，有一个直觉：Skill 装得越多，Agent 越强大。搜到一个“Python 最佳实践”的 Skill，装上；找到一个“K8s 运维规范”的 Skill，装上；“数据库优化”的 Skill，也装上。最后 Agent 的 Skill 列表拉得老长，看着很有安全感——“我的 Agent 什么都会了”。
这个直觉是错的。 Skill 数量的增加，并不线性增加 Agent 的能力。更可能的结果是：Agent 反而变蠢了。
原因有三。
2.1 Context 会爆
Agent 的上下文窗口是有限制的。每次对话，所有 Skill 的内容都要注入到 System Prompt 中——不是“用到了才加载”，而是“全量注入”。你装了 20 个 Skill，每个 500 字，System Prompt 就多了 10000 字。加上对话历史、Tool 定义、文件记忆，上下文很快就被占满了。
被挤掉的不是 Skill，而是Agent 真正需要的必要信息——比如你现在打开的文件的完整内容、你对话的完整上下文。Agent 不得不在“记住 Skill”和“理解你的问题”之间做取舍——这种取舍本身就会降低回答质量。
2.2 Skill 之间可能互相矛盾
一个 Skill 说“函数不应超过 50 行”；另一个 Skill 说“不要为了拆分而拆分，逻辑完整性优先”。Agent 执行时不知道“这两个规则冲突时该听谁的”，因为 Skill 定义里通常不包含优先级。Agent 的处理方式大概率是随机选一个，或者把两个都考虑——结果是一个函数被拆了又合，左右互搏。
你自己维护 20 个 Skill 时，越到后面越不容易发现哪些 Skill 之间存在矛盾。因为 Skill 通常来自不同来源、在不同时间安装——你很难全局 review 一圈检查冲突。
2.3 Agent 的“选择困难”
Skill 不只是“被动的规则”。很多 Skill 还会影响 Agent 的行为模式——比如 code-review Skill 会引导 Agent 进入“审查模式”：说话更谨慎、多问确认性问题、喜欢标记 TODO 而不是直接改。debugging Skill 则引导 Agent 进入“排查模式”：主动运行诊断命令、分析日志、给多种可能性。
当 Agent 同时加载了一堆 Skill 时，它在“该进入什么模式”上变得犹豫。它的行为会不稳定——同一个问题，有时候进入审查模式（只是提建议），有时候进入排查模式（主动执行命令）。这不是 Agent “变聪明了”，是 Skill 过多导致的行为漂移。
三、好的 Skill 应该怎么写
Skill 的“少而精”原则反过来也给出了 Skill 的设计方向。一个好的 Skill 有几个特征：
1. 场景明确。 不要写一个“后端开发最佳实践”的通吃型 Skill——场景太宽，什么都管等于什么都不管。应该是“Code Review”、“部署前检查”、“数据库查询优化”这样场景清晰的 Skill。Agent 在处理对应场景时能立刻识别“这个 Skill 现在该用了”。
2. 有优先级和判断标准。 不是列一堆规则让 Agent 自己选，而是明确告诉它：什么情况是 Blocker，什么情况是 Suggestion，两条规则冲突时谁优先。把人类经验中的“判断力”用结构化的方式写出来。
3. 有正确示例和反例。 纯粹描述规则不如给例子。比如性能检查的原则不是只写“避免 N+1 查询”，而是附上一个改前改后的代码对比。Agent（和人类一样）从例子中学到的比从规则中学到的更牢固。
4. 不与现有 Skill 重叠。 装新 Skill 之前，先过一遍已有的 Skill 列表，确认新 Skill 的功能不是已有 Skill 的子集，也没有明显冲突的规则。
5. 上下文轻量。 能说清楚的规则就不要多写。500 字能讲完的流程，不要为了显得“专业”写成 3000 字的百科全书。Skill 的目标是帮 Agent 做决策，不是帮人查文档。
四、小结
写这篇文章，最核心想传达的就一句话：Skill 是行为准则，不是功能列表；质量远大于数量。
Tool 让 Agent “能做”，Skill 让 Agent “会做”——这是两个完全不同的问题。你有再好的手脚，如果没有一套做事的原则和流程，手脚也只是瞎挥。但反过来，原则太多了、互相打架了，Agent 反而比没有原则的时候更糟——不知道该听谁的、不知道该进哪个模式，甚至连你的问题都记不全了。
Skill 的设计是一个“做减法”的过程。不是你找到了多少条规则，而是你最终留下了几条真正管用的。三条足够清晰的 Skill，比二十条互相矛盾的 Skill 强一百倍。
下一篇聊 MCP 与 CLI——Agent 调用 Tool 的两条路径，以及为什么情况和我们直觉中想象的正好相反。
每天前进一小步，就是一个新的高度！