06｜Skills、Commands、Rules、Hooks 到底各管什么
用 Agent Harness 久了，很多人都会遇到一组容易混淆的概念：Skills、Commands、Rules、Hooks。
乍一看，它们都能“影响 Agent 行为”，但作用的层级和方式其实完全不同。如果混着用，项目配置很快就会变得一团乱麻；但如果能搞清楚各自的边界，它们就能成为团队经验沉淀的利器，帮你打造稳定、高效的工作流。
先来一句话快速区分一下：
Rules 规定长期习惯
Skills 封装复杂流程
Commands 提供快捷入口
Hooks 在固定时机自动执行
接下来，我们逐一拆解。
Rules：长期规则
Rules 是给模型看的长期约定。你可以把它们理解为团队的“行为准则”或“编码规范”。比如：
本项目使用 pnpm，不要使用 npm。
后端接口必须返回统一错误结构。
修改权限逻辑必须补充集成测试。
不要直接修改 generated 目录。
Rules 的特点是持续生效。它们非常适合表达团队规范、项目约定、架构边界和代码风格。
但需要注意，Rules 不是强制执行层。模型会尽量遵守，可一旦规则变得含糊、冲突，或者文件太长，它仍然可能漏掉关键点。所以，Rules 更适合用来“指导”，而不是“硬拦截”。
Skills：可复用工作流
Skills 更像是一套可复用的操作手册。它们定义了一个明确、多步骤的流程。
举个例子，“做一次 PR Review”可能包括：
- 读取 diff；
- 识别风险文件；
- 检查测试覆盖；
- 查找安全问题；
- 输出 Review 结论。
这个流程就很适合做成 Skill。
类似的还有：
写单元测试
排查 CI 失败
分析接口兼容性
生成发布说明
执行前端视觉检查
这些任务都有明确流程，不适合写成一句简单的 Rule。把它们封装成 Skill，不仅逻辑更清晰，还能按需加载，减少上下文噪声，让 Agent 更聚焦。
Commands：入口和快捷方式
Commands 是给用户用的便捷入口。比如：
/review-pr
/fix-ci
/write-tests
/deploy-staging
它们最大的价值是降低使用门槛。团队成员不用费劲去记一大段复杂的提示词，只要调用一个简单的命令就能启动特定流程。
Commands 可以很薄，只是触发某个 Skill；也可以自己包含一段固定提示。但从长期维护的角度看，最好把复杂逻辑沉淀到 Skills 里，让 Commands 保持轻量、清晰。
Hooks：强制执行和自动化
Hooks 和前三个完全不同。Rules、Skills、Commands 主要影响模型的思考过程；而 Hooks 是在工具调用前后、文件编辑后、会话开始等固定生命周期，执行真实的系统命令。
比如：
文件编辑后自动格式化
提交前自动运行 lint
运行 shell 前检查危险命令
禁止修改 protected 文件
会话开始时加载项目状态
Hooks 适合做强约束，因为它们不依赖模型“记不记得”。如果某个安全策略必须被强制执行，就不要只写在 Rule 里，而应该用 Hook 或权限规则来实现。
四者如何配合
来看一个真实的案例：
团队希望 Agent 在修改支付代码时，必须先写测试。
可以这样设计：
- ：支付模块变更必须测试先行；
Rule
- ：
Skill
payment-tdd定义具体的测试流程； - ：
Command
/payment-fix作为入口； - ：提交前强制运行支付测试。
Hook
这样一来，既有宏观的指导，又有具体的流程，还加上了硬性的自动验证，环环相扣，非常可靠。
常见误用
在实际使用中，有几个典型的坑需要注意。
第一，把所有东西都塞进 Rules。
结果就是规则文件越来越长，模型读到后面，前面的重点早就忘了。多步骤流程应该放到 Skills 里，而不是全堆在 Rules 中。
第二，用 Rules 来做强制安全。
比如“不要运行删除命令”，只写在规则里是远远不够的。应该用权限 deny 列表或者 PreToolUse Hook 来直接拦截。
第三，Commands 设计得过于复杂。
一个命令里塞了几百行说明，后期维护起来会非常痛苦。命令本质上应该像“按钮”，负责触发，而复杂逻辑交给 Skill。
第四，Hooks 配置得太重。
每次编辑都跑全量测试，会让 Agent 的反应速度急剧下降。Hooks 需要分级：轻量检查放在高频操作中，重量级检查放在提交前或等待用户确认后再执行。
设计建议
- 只保留那些每次任务都必须知道的明确约定。
Rules 要短小精悍。
- 一个 Skill 解决一类任务，不要试图做成什么都能干的“万能流程”。
Skills 要职责专一。
- 高频任务才值得做成命令，低频任务直接用自然语言沟通即可。
Commands 要少而精。
- 只把那些真正需要自动化或强约束的操作放进去。
Hooks 要稳固可靠。
可以用下面这张表来快速判断，某个功能应该放在哪里：
| 内容 | 放哪里 |
|---|---|
| 项目长期规范 | Rules |
| 多步骤工作流 | Skills |
| 高频快捷入口 | Commands |
| 必须执行的检查 | Hooks |
| 高风险操作拦截 | Permissions + Hooks |
总结
Skills、Commands、Rules、Hooks 都是 Harness 强大的扩展方式，但它们服务的边界完全不同。
一个真正成熟的团队，不会只靠零散的提示词来驱动 Agent，而是会把团队的经验分层沉淀下来：
Rules 管习惯
Skills 管流程
Commands 管入口
Hooks 管强制动作
Permissions 管边界
只有做到这样，Agent 才会越来越像一个真正的团队成员，而不是每次都从零开始学习、反复犯错的新手。
