AI Agent Skill 设计：把重复流程沉淀成可复用的能力

为什么要设计 Skill

用 Agent 做过一段时间任务后会发现一个规律：真正消耗精力的不是偶尔一次的复杂任务，而是那些每天都要重复的固定流程。它们步骤明确、判断标准稳定，却每次都要求你把同样的上下文重新讲一遍。Skill 的价值就在这里——把这些流程从对话里抽出来，写成一份可复用的说明书，让 Agent 每次按同一套标准执行。

Skill 的三个组成部分

第一是元数据。名称和描述决定了 Agent 能不能在正确的时机想起你。描述里必须写清楚两件事：什么时候该用，什么时候不该用。只写"用于处理数据库"是不够的，还要写"不用于缓存实例"，否则 Agent 会在该选别的能力时误触发。

第二是工作流。把流程拆成有顺序的步骤，每一步写清楚输入、动作和产出。例如：读取上下文 → 校验前置条件 → 执行变更 → 验证结果。步骤之间不要含糊其辞，"适当处理"这类描述对执行没有任何约束力。

第三是边界与验证。哪些操作可以自动执行，哪些必须经用户确认，失败时要如何回滚，验证通过的标准是什么。这一部分最容易被忽略，却直接决定了 Skill 是否安全可靠。

一个可落地的结构

---
name: order-report
description: 按周期生成订单报表。用于查询订单与金额汇总，不用于财务对账。
---

# 工作流
1. 确认时间范围与维度
2. 调用查询接口获取原始数据
3. 按维度聚合，输出表格
4. 校验合计与明细是否一致

# 约束
- 只读操作可直接执行
- 金额单位统一为元，保留两位小数
- 数据为空时明确说明，不臆测

这份结构里没有一句废话：元数据负责触发，工作流负责执行，约束负责兜底。

设计时最容易犯的错

一是把 Skill 写成操作手册。大段背景介绍和截图说明只会稀释关键信息。Agent 需要的是可判定的条件与动作，不是阅读材料。

二是触发描述太宽泛。"帮助处理云资源"几乎等于没有约束。好的描述应当像门禁规则，能明确放行，也能明确拦截。

三是忽略失败路径。只写成功流程的 Skill，遇到接口报错、权限不足时就会胡编。把常见的失败原因和应对方式列出来，稳定性会高很多。

如何验证 Skill 有效

验证不靠感觉，靠重复执行。把同一条流程连续跑几次，观察三个指标：触发是否准确、步骤是否稳定、结果是否可复现。如果每次执行都要靠临场发挥，说明流程还没沉淀好，应该回到工作流那一步继续拆解。

另一个实用做法是对比测试：让 Agent 在"有 Skill"和"无 Skill"两种条件下执行同一任务，比较输出的一致性和遗漏率。差异越明显，说明沉淀的价值越大。

小结

Skill 不是写得越长越好，而是让关键判断变得可执行、可验证。把触发条件写严、把步骤写实、把边界写清，重复流程才会真正变成能力，而不是每天重新解释一次的负担。