深度重构：Agent Skills——从 Prompt 工程到能力工程

深度重构：Agent Skills------从 Prompt 工程到能力工程

当 Skills 进入 Agent 六要素，AI 的使用才真正从"每次重训实习生"进化为"随时调度虚拟专家团"。

阅读本文你将获得：

一个定义：Skill 不是 Prompt，是"能力蒸馏"
一个协议：SKILL.md 的工程密码（description 即路由）
一个闭环：从意图捕获到评测治理的完整生命周期
一套面试框架：概念辨析 + 机制深挖 + 场景设计 + 口述金句

一、定义：何为 Skill？

1.1 一句话定义

Skill（技能） 是把专业人士处理某类复杂任务的方式，蒸馏进一个文件夹，并用 SKILL.md 标准化表达的可复用能力包。

1.2 它不是什么（对比矩阵）

易混概念	核心问题	生命周期	Skill 的边界
临时 Prompt	这一次怎么说	单次会话	Skill 是可复用的长期资产
System Prompt	你是谁、全局规则	全局生效	Skill 是专项岗位 SOP，不是人格设定
Tool / MCP	能不能做这个原子动作	长期可用	Skill 编排多个 Tool，解决"怎么做才专业"
RAG	私有知识在哪、怎么找	长期检索	Skill 可调用 RAG，但不等同于知识本身
Subagent	是否拆分给另一个执行体	任务级委派	Skill 是能力说明，可被 Subagent 加载执行

💡 面试金句：Skill 是能力的产品化封装，不是 Prompt 的文件化保存。

二、定位：Skills 在 Agent 六要素中的坐标

回到 v033 的 Agent 公式：

ini 复制代码

Agent = LLM + Memory + Tool + RAG + MCP + Skills

一句话分工：

LLM：推理与生成（大脑）
Memory：跨会话记住你是谁、上次聊到哪（工牌与日志）
Tool / MCP：执行原子动作，统一工具接口（手脚与插座）
RAG：检索私有知识，按需取用（说明书库）
Skills：按专业标准编排上述一切，完成复杂任务（老师傅的手艺）

2.1 一个类比：Skills 是"岗位说明书 + 工作流引擎"

Tool = 螺丝刀
MCP = 统一的工具插座标准
RAG = 说明书资料库
Memory = 工牌与工作日志
Skill = 老师傅教你"什么时候用哪把螺丝刀、按什么顺序装、验收标准是什么"

没有 Skill，模型是"什么都懂一点、什么都不专业"的聊天机器人；有了 Skill，它才成为"问出专业问题、干出专业结果"的虚拟岗位员工。

三、协议：SKILL.md 的工程密码

3.1 最小单元：一个文件夹

bash 复制代码

meeting-minutes/
├── SKILL.md                 # 必需：元数据 + 主流程
├── scripts/                 # 可选：确定性步骤代码化
├── references/              # 可选：长文档按需加载
├── assets/                  # 可选：模板、样式、样例
└── evals/                   # 可选：评测集

文件夹即能力单元------这体现了软件工程的模块化思想。

3.2 头部：YAML Frontmatter（路由层）

yaml 复制代码

---
name: "meeting-minutes"
description: "Generates structured meeting minutes from a transcript. Invoke when the user provides meeting text and asks to organize, summarize, or produce meeting minutes."
---

Description 是第一生产力。 Agent 先扫描所有 Skill 的元数据，再决定加载哪个。写 description 像写网关匹配条件：

✅ 强：Invoke when user asks for AI news, daily AI briefing, or says '甜甜AI日报'
❌ 弱：帮助处理会议相关内容

面试金句：Description 不是简介文案，而是路由规则。

3.3 正文：工艺层（工作流 + 边界 + 模板）

高质量 SKILL.md 正文包含：

目标：最终交付什么
工作流程：分步骤，祈使句，可执行
边界与反例：什么不该做、不确定时怎么办
输出模板：固定 Schema，降低自由度
示例：输入 → 输出，校准预期
失败处理：工具挂掉、信息不足时的降级策略
资源指针 ：何时去读 references/ 或跑 scripts/

3.4 核心机制：渐进式披露（Progressive Disclosure）

级别	内容	何时加载	Token 成本
Level 1	Metadata（name + description）	始终可见	~100 words
Level 2	SKILL.md Body	触发后加载	<500 行
Level 3	Bundled Resources	按需读取	不限

工程本质：上下文按需编译，而非无脑堆叠。

假设你有 20 个 Skill，每个 800 tokens：全量塞入 System Prompt = 16000 tokens；渐进式加载 = ~2000 tokens。差距 8 倍。

四、闭环：从意图到评测的工程生命周期

4.1 创建 Skill 的标准流程

bash 复制代码

捕获意图 → 写 description → 起草正文 → 补反例/失败路径
    → 2~3 个真实样例试跑 → 固化硬逻辑 → 按需加 scripts/references
    → 设计 eval 集 → with-skill vs baseline 对比 → 迭代优化

4.2 评测分层

层级	测什么	手段
触发层	该不该加载此 Skill	`should_trigger` 集合
过程层	是否按工作流执行	Transcript 检查
结果层	输出是否达标	Assertions / 人工审阅
成本层	Token / 耗时是否可接受	Timing 监控
回归层	改动是否破坏旧用例	迭代 Benchmark

4.3 好的 Assertion 长什么样（会议纪要示例）

✅ 包含"行动项"表格
✅ 未出现文字稿中不存在的负责人姓名
✅ 不确定时间标记为"待确认"
✅ 输出包含"会议目标"小节
❌ 不写无法客观判定的主观描述（如"文风流畅"）

4.4 触发工程：Undertrigger vs Overtrigger

问题	表现	修复
Undertrigger	该用不用，模型用通用能力凑合	description 补同义词、口语说法、中英触发词
Overtrigger	不该用却加载	description 写清输入形态与意图动词

触发评测最小集：

Query	Should Trigger
"把这段会议转写整理成纪要"	✅ True
"从录音稿提取行动项和负责人"	✅ True
"standup meeting 的最佳实践是什么？"	❌ False
"如何提高会议效率？"	❌ False

五、实战：两个 Skill 的对照解剖

维度	会议纪要 Skill	AI 日报 Skill
输入	用户提供 ASR 转写（口语/噪声）	Agent 主动检索近 24h 资讯
核心难点	噪声过滤 + 事实边界（不编造）	时效性 + 去重 + 信息密度
工具依赖	读文件为主	WebSearch + WebFetch
关键设计	行动项判定规则（明确执行意图才列入）	入选条数（5-8）、摘要写法、标签体系
失败处理	不确定写"待确认"，不猜测	全失败告知用户，不凑旧闻
输出	固定 Markdown 模板	单文件可视化 HTML + 来源清单
OPC 岗位	会议秘书	行业情报官

六、治理：Skills 是代码资产，不是聊天偏好

6.1 生产级检查清单（上线前）

定位：

职责单一，能用一句话说清
与现有 Skills 无严重重叠
确认是 Skill 而非 Tool/RAG 能单独解决的问题

路由：

name 稳定且语义清晰
description 含 what + when
有 should-trigger / should-not-trigger 样例

正文：

工作流可执行（步骤化）
有输出模板或 Schema
有不确定性/失败处理
有至少一个真实示例
解释了关键规则背后的 why

评测与治理：

6.2 质量指标（可上线看板）

指标	含义
Trigger Precision / Recall	触发准确率与覆盖率
人工改写率	输出还需改多少
Assertion Pass Rate	自动验收通过率
p50/p95 Latency	耗时
Tokens / Task	成本
Reuse Count	复用次数（是否真资产）

6.3 反模式大全

反模式	表现	修复
Prompt 搬家	聊天记录原样粘进 SKILL.md	重写成步骤 + 模板
万能 Skill	一个 Skill 包办所有办公	按岗位拆分
只写 what 不写 when	description 像广告语	补 Invoke when
只写 when 不写 how	能触发但不会做	补工作流与示例
无失败路径	工具挂了仍硬生成	写降级策略
无评测	凭感觉迭代	建 Evals
过拟合三样例	只对 Demo 有效	多样化测试
与 Tool 抢活	用自然语言替代脚本化步骤	能代码就代码化
秘密 Skill	私藏关键流程	项目/组织级共享
有惊喜 Skill	做超范围动作	无惊喜原则 + 权限审查

七、面试题库与答题框架

7.1 基础概念

Q：什么是 Agent Skill？和 Prompt 有什么区别？

Skill 是把某类专业任务的处理流程、质量标准与输出契约封装成可被 Agent 自动触发的能力包。Prompt 是单次指令；Skill 是可复用、可版本化、可评测的模块。Prompt 解决"这一次怎么说"，Skill 解决"这一类事默认怎么做"。

Q：Skill 和 Tool / MCP 有什么区别？

Tool/MCP 提供原子能力；Skill 提供如何组合这些能力完成岗位级任务的 SOP。没有 Tool，Skill 可能"会说不会做"；没有 Skill，Tool 可能"能做但不专业"。

Q：Skill 和 System Prompt 怎么分工？

System Prompt 管全局身份与底线规则；Skill 管专项任务工艺。全局稳定、专项可插拔。

7.2 机制深挖

Q：为什么 description 这么重要？

渐进式披露下，元数据先于正文被看见。description 是路由层，决定 skill 是否进入上下文。写不好就 undertrigger 或 overtrigger。

Q：什么是 Progressive Disclosure？

三级加载：metadata 常驻、body 触发后加载、resources 按需加载。目标是在有限上下文中装配专业能力，同时控制 token 与干扰。

Q：skill-creator 解决什么问题？

把写 skill 从手工作坊变成标准工程：意图捕获、起草、eval、baseline 对比、反馈迭代、description 优化。它本身也是 skill，说明能力可以层级化生产。

7.3 场景设计题

Q：设计一个"前端落地页生成"Skill 的大纲

答题要点：

description：何时做 landing page、包含哪些区块
流程：信息架构 → 文案层级 → 组件结构 → 响应式 → 交付文件
模板：分区输出（Hero/痛点/方案/社会证明/CTA）
边界：无品牌素材时的占位策略
evals：3 个不同行业提示词

Q：线上发现 skill 输出经常被用户大改，怎么排查？

看是否触发了正确 skill（触发层）
看正文规则是否过时（过程层）
看样例是否覆盖新业务（结果层）
看是否该脚本化的步骤仍靠模型自由发挥（成本层）
把高频人工修改沉淀回 SKILL.md
补回归，防修 A 坏 B

7.4 一分钟口述版（终面备用）

Skill 是 Agent 的岗位能力包。Tool 让它能动手，RAG 让它有知识，Memory 让它记得你，Skill 让它按专业流程稳定把事做完。SKILL.md 的 description 负责路由，正文负责工艺，references/scripts 负责细则与确定性，evals 负责回归。好的 Skills 体系是上下文的按需编译器，也是 OPC 把个人经验变成可复制资产的关键基础设施。

八、七句话带走全文

Skill 是能力蒸馏，不是 Prompt 备份。
文件夹 + SKILL.md 是最小工程单元。
description 负责路由，正文负责工艺，资源负责细则。
渐进式披露让专业能力与 token 成本可兼得。
触发工程和正文质量同样重要。
skill-creator + evals 让技能可生产、可回归、可进化。
治理与安全决定 Skills 是组织资产还是个人玩具。

九、能力树更新

AI Native 开发者 / FDE 能力栈（v042 新增）

objectivec 复制代码

能力层：Skills Engineering
  ├─ SKILL.md 协议（YAML Frontmatter + 正文规范）
  ├─ Progressive Disclosure（三级加载）
  ├─ 触发工程（Undertrigger / Overtrigger / Precision / Recall）
  ├─ skill-creator 评测闭环（Evals + Baseline + Regression）
  └─ 生产治理（版本、权限、安全、共享、质量看板）

从用 AI 的阶段看：查字典 → 写提示词 → 封装技能 → 经营能力资产。

第一批人每天重新解释"我是谁、要做什么"；第二批人把解释沉淀成 Skills，把记忆交给 Memory，把动作交给 Tools/MCP，把知识交给 RAG------然后直接开工。

下一次当你发现自己重复粘贴同一段"请按如下格式......"时，别再只是保存聊天记录------把它做成一个 Skill，再给它几条 eval。

那一刻，你才是在"训练"你的 AI 团队，而不只是在"聊天"。