在使用 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 命令前检查是否存在危险操作
禁止修改受保护的文件
会话启动时自动加载项目状态信息

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 要稳固可靠。 只把那些真正需要自动化或强约束的操作放进去。

你可以参考下面这张表，快速判断某个功能应该放在哪里：

总结

Skills、Commands、Rules、Hooks 都是 Agent Harness 提供的强大扩展机制，但它们各自的服务边界与适用场景完全不同。

一个真正成熟的团队，不会仅仅依靠零散的提示词来驱动 Agent，而是会将团队的经验进行分层沉淀：

Rules 负责管理行为习惯
Skills 负责管理流程规范
Commands 负责管理调用入口
Hooks 负责管理强制动作
Permissions 负责管理安全边界

只有做到这样，Agent 才会逐步进化成一个真正的团队成员，而不是每次都需要从零学习、反复犯错的新手。