用 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 更清楚，也能按需加载，减少上下文噪声。
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 要短。只保留每次任务都应该知道的约定。
Skills 要专。一个 Skill 解决一类任务，不要做成万能流程。
Commands 要少。高频任务做命令，低频任务用自然语言即可。
Hooks 要稳。只把真正需要自动化或强约束的事放进去。
可以用下面这张表判断放哪里：
| 内容 | 放哪里 |
|---|---|
| 项目长期规范 | Rules |
| 多步骤工作流 | Skills |
| 高频快捷入口 | Commands |
| 必须执行的检查 | Hooks |
| 高风险操作拦截 | Permissions + Hooks |
总结
Skills、Commands、Rules、Hooks 都是 Harness 的扩展方式，但边界不同。
真正成熟的团队，不会只靠提示词驱动 Agent，而会把经验分层沉淀：
Rules 管习惯
Skills 管流程
Commands 管入口
Hooks 管强制动作
Permissions 管边界
这样 Agent 才会越来越像团队成员，而不是每次都从零开始学习规矩。
