跳转到内容

Skill 驱动的 Agent 行为编排

Skill 驱动的 Agent 行为编排

学习目标

读完本章后,你将能够:

  • 理解 Skill 文档如何替代传统硬编码规则来控制 Agent 行为
  • 设计 Skill 的三层优先级体系(用户指令 > Skill > 默认系统提示)
  • 实现 SessionStart hook 的 bootstrap 注入与运行时 Skill 工具调用的双层触发
  • 构建反合理化表格与 Red Flags 列表,防止 Agent 自行绕过纪律
  • 使用 Hard-Gate 机制强制门控关键工作流步骤

核心概念

Skill 作为”行为代码”

传统 AI Agent 的行为由系统提示中的软规则引导,Agent 可以自由选择是否遵循。Skill 系统将纪律编码为结构化的 Markdown 文档,通过两个机制强制执行:

  1. 自动发现:SessionStart hook 在每个会话启动时注入 bootstrap,告诉 Agent 有哪些 Skill 可用以及何时必须调用它们
  2. 强制调用:当任务与 Skill description 匹配时,Agent 必须先调用 Skill 工具获取完整指令,才能执行任何操作

Skill 不是建议,而是行为契约。description 字段定义何时触发,正文定义如何执行

三层优先级体系

用户指令始终最高。Skill 覆盖默认系统提示但不覆盖用户指令。这个设计确保用户始终掌控,同时 Skill 能纠正 Agent 的默认行为偏差。

双层触发机制

第一层:SessionStart bootstrap

会话启动时,hook 脚本检测当前平台(Claude Code / Cursor / Copilot CLI 等),将 using-superpowers Skill 的完整内容注入为系统上下文。这确保 Agent 在第一条用户消息前就知道 Skill 系统的存在。

第二层:运行时 Skill 工具

Agent 在收到用户消息后,根据 description 判断是否有适用的 Skill。“1% 规则”规定:即使只有 1% 的可能性认为某个 Skill 适用,也必须调用它。这防止 Agent 以”这很简单”为由跳过纪律。

反合理化设计

Agent 善于找到绕过规则的理由。反合理化设计预识别这些推理模式并显式封锁:

Agent 的想法封锁对策
”这太简单了不需要设计""简单项目最容易被未检验的假设浪费最多工作"
"我记得这个 Skill 怎么用""Skill 会演进,读当前版本"
"先探索代码再检查 Skill""Skill 告诉你如何探索,先检查"
"这个 Skill 太重了""简单事情变复杂,使用它”

关键原则:不在 Skill 中列出所有可能的例外。使用”没有例外”和”违反字母就是违反精神”等基础原则,切断整类”我遵循的是精神而非字面”的推理。

Hard-Gate 门控

Hard-Gate 是 Skill 中显式声明的强制门控,Agent 不得绕过:

<HARD-GATE>
在呈现设计并获得用户批准之前,不得调用任何实现 Skill、编写任何代码、搭建任何项目或采取任何实现行动。这适用于每一个项目,无论其表面简单程度如何。
</HARD-GATE>

Gate 用 XML 标签标记以增强视觉显著性。门控失败意味着整个 Skill 流程失败。

设计权衡

为什么用文档而非代码

优势

  • 平台无关:Markdown 在任何 AI 编程 Agent 中都可读
  • 人类可审计:任何开发者都能理解和修改 Skill 内容
  • 版本控制友好:diff 清晰,code review 直接
  • 热更新:修改 Markdown 即可改变 Agent 行为,无需重新构建

代价

  • 依赖 Agent 的理解力,不如硬编码可靠
  • 需要反复测试和迭代来堵住 Agent 的绕过路径
  • 无法用类型系统验证正确性

为什么 description 不总结工作流

一个经过验证的教训:当 Skill description 总结工作流时(如”每个任务分派子代理 + 代码审查”),Agent 会遵循 description 而非阅读 Skill 正文。因为 description 是 Agent 首先读取的内容,它提供了一个”捷径”。

对策:description 只写触发条件(when to use),不写执行流程(how to do)。例如:

# 错误:总结工作流
description: 执行计划时每个任务分派子代理,进行规格和代码质量两阶段审查
# 正确:只写触发条件
description: 在当前会话中执行独立任务的实现计划时使用

为什么需要反合理化表格

测试表明,即使有清晰的规则,Agent 在压力下(时间压力、沉没成本、疲劳)仍会找到绕过的理由。反合理化表格的价值在于:

  1. 预识别:不等 Agent 发现漏洞,提前封锁常见推理路径
  2. 模式匹配:Agent 可以在自己产生某个想法时快速识别”这是 Red Flag”
  3. 去个性化:将”我在找借口”转化为”这个借口在表格中被列为无效”

陷阱与对策

陷阱表现对策
Skill 过大单个 SKILL.md 超过 500 词,Agent 在每次会话中浪费 token分离参考文件,SKILL.md 保持精简,用交叉引用替代重复
触发描述模糊”处理异步问题时使用” — 什么是”异步问题”?用具体症状描述:“测试有时通过有时失败、涉及 setTimeout 的竞态条件时使用”
Skill 间冲突两个 Skill 对同一情况给出矛盾指令建立明确的优先级体系,用户指令 > Skill > 默认提示
过度工程化Skill 试图预见所有边缘情况只写基线测试中发现的失败模式,不写假设场景

补充:Agent Skills 的全技能反合理化模式库

来源:Addy Osmani / agent-skills v0.6.1,23 个 skills/*/SKILL.md 中的 Common Rationalizations 表,commit 6ce0298

agent-skills 项目将反合理化表标准化为每个 Skill 的必选章节,并积累了跨 23 个技能的反合理化模式库。

跨技能的共性反合理化模式

模式出现频率典型表现
”太简单不需要 X”15+ 技能”这个很简单,不需要规格”、“这是单行修改,不需要审查"
"稍后再做 X”10+ 技能”我会稍后补测试”、“以后再加 feature flag"
"一次全做更快”8+ 技能”一次性写完再测试更快”、“全部实现完再审查"
"我知道 API,不需要查”5+ 技能”我对这个 API 有信心”、“不需要查文档"
"X 会拖慢我们”5+ 技能”规格会拖慢速度”、“启动审查器太贵"
"以后反正会变”3+ 技能”需求反正会变化”、“我们以后再加分页”

反驳论证的设计原则

agent-skills 的反合理化表遵循以下原则:

  1. 具体反驳,不是抽象说教

    • ❌ “测试很重要”
    • ✅ “Bug 会复合。Slice 1 的 Bug 让 Slice 2-5 都错。每片都测试。”
  2. 量化代价,不是模糊警告

    • ❌ “这会花费更多时间”
    • ✅ “15 分钟的规格防止数小时的重做。15 分钟内的瀑布胜过 15 小时的调试。”
  3. 承认有效边界,不是绝对化

    • ❌ “永远不要跳过规格”
    • ✅ “简单任务不需要规格,但仍需要验收标准。两行规格也可以。”
  4. 区分跳过和静默跳过

    • “跳过没问题;静默跳过不行。”
    • 这是一个反复出现的模式——允许用户做出决策,但要求决策可见。

“1% 规则”

agent-skills 的 using-agent-skills 技能中定义了一条元规则:即使只有 1% 的可能性某个技能适用,也必须检查它。这条规则防止了最常见的反合理化——“这个情况看起来不像需要 X 技能”——通过设置极低的触发阈值来覆盖边缘情况。

与 Hard-Gate 的配合

反合理化表是认知层面的防御(改变 Agent 的推理),Hard-Gate 是流程层面的防御(通过 XML 标签强制停止点)。两者缺一不可:

  • 只有反合理化表:Agent 可能找到绕过表格的理由
  • 只有 Hard-Gate:Agent 在 Gate 之间仍然可能跳过步骤

验证的非协商性

每个 Skill 以 Verification 检查清单结束。“看起来对”永远不够——必须有证据。这是 Agent Skills 区别于普通提示工程的核心设计:

每个验证检查框都需要证据(测试输出、构建结果、截图、运行时数据)。没有证据的检查框不算通过。


参考来源

  • Agent Skills Specification — Skill 文档格式规范(name / description 字段要求)
  • Claude Code Hooks 文档 — SessionStart hook 的配置与输出格式
  • Cialdini, R. (2021). Influence — 权威、承诺一致性等说服力原则在反合理化设计中的应用
  • Meincke, et al. (2025). 关于 AI Agent 在压力下合规性的实证研究