用 agent 干活久了，总会沉淀出一些反复出现的工作模式：每次都要重复交代的格式要求、每次都要现查一遍的流程步骤、每次都容易踩的坑。Skill 的价值，就在于把这些“程序性知识”从对话里抽出来，变成 agent 可以按需加载的能力——需要时触发，不需要时不占地方。

用了一段时间之后，我对 skill 这个机制本身积累了一些观察。这篇文章不谈任何具体 skill 的内容，只谈使用过程中暴露出的问题，以及我认为值得改进的方向。

Trigger

触发是第一道坎，但目前它更像玄学

现象

同样一个意图，换个说法就触发不了；反过来，无关任务又偶尔被误触发。中英文混合的任务里尤其明显。

本质

触发靠的是 description 的语义匹配。这个 description 是 skill 唯一的“索引”，它同时承担两个职责——检索（用户想要的东西能不能被召回）和决策（agent 判断该不该用）。两个职责挤在一句话里，写起来自然别扭。

改进方向

  • 把 description 当产品文案来写：明确“用于什么、不用于什么”，覆盖常见的同义说法，而不是写一句笼统的定位。
  • 给触发建一个评测集：一组应该触发的正例、一组不应该触发的反例，每次改完描述跑一遍，看召回和误报的变化。触发可靠性目前基本靠手感，应该变成可度量。
  • 触发不必是全有全无的开关。可以设计一种低成本预览：agent 先瞄一眼 skill 的关键段落再决定是否完整加载，避免“为了判断要不要用而不得不用”的窘境。

Context Cost

上下文成本是隐性的，但真实存在

现象

装的 skill 多了之后，每轮对话的系统提示里都堆着一大段元数据。偶发的副作用是 agent 在无关任务上被带偏，或者真正该用的 skill 反而被淹没。

本质

上下文窗口是注意力资源。所有 skill 的元数据在每一轮对话里都在竞争模型的注意力，这个成本不体现在账单上，而体现在“分心”上——而且 skill 越多，单个 skill 分到的注意力越稀薄。

改进方向

  • 渐进式披露要做彻底：常驻上下文的只有名字加一句话；正文按需加载；参考文档和脚本作为二级、三级资源，用到才读。分层越细，常驻成本越低。
  • 对 skill 数量保持克制。技能库是需要“折旧”的资产，定期清理不再用的，比持续新增更重要。
  • 按项目收敛可见范围。个人技能库里的东西，不必在每个工作区全局暴露。

Prompt Craft

SKILL.md 本质是提示工程，应该被迭代而不是被供奉

现象

同一份 skill，改几句措辞，效果差别很大。实践中的规律是：加一节“常见错误与反例”，往往比补三段原理介绍更有用。

本质

SKILL.md 是写给模型看的提示词。模型对指令的响应有自己的规律——命令式的短句、明确的边界条件、正反例，比长篇论述有效。

改进方向

  • 用实际失败驱动改写：agent 在哪一步跑偏，就针对那一步补约束或例子，而不是凭空重写。
  • 建立 eval：固定一组任务，改版前后各跑几遍做对比。注意 agent 的随机性——必须看多次运行的方差，单次成功大概率是运气。
  • 迭代方向应该是越来越短，而不是越来越长。每次复盘都想往里加内容，最终会变成一份没人（包括模型）能读完的大文档。删掉从未起作用的段落，和新增内容一样重要。

Governance

数量上来之后，问题是“资产治理”

现象

skill 一多，开始出现职责重叠、同名遮蔽、搞不清哪个在生效的情况。

改进方向

  • 命名空间和优先级规则要清晰、可查。装了同名的两个 skill，应该能明确知道哪个生效、为什么。
  • 引入版本意识：版本号、变更记录、安装来源可追溯。Skill 会随业务演化，没有版本的资产没法协作维护。
  • 打通组合能力：目前 skill 之间基本是孤岛。一个 skill 能否复用另一个的参考文档、能否声明依赖，决定了技能库是“一堆文件”还是一个“体系”。

Observability

效果好不好，现在基本靠体感

现象

一个 skill 到底有没有帮上忙，全凭事后印象。agent 是不是真的读了、读了哪些部分、哪句指令被无视了，都没有记录。

改进方向

  • 记录触发与后续行为的关联：触发了但没用上、用了但没改变行为、用了且明显改变了走向，这三种情况应该能区分。
  • 对 skill 内容做引用追踪：哪些章节从未影响过 agent 的行为，就是删减候选。这是上一节“越改越短”的数据依据。
  • 把这些记录串成反馈闭环，让 skill 从一份静态文档，变成带遥测、能自我优化的组件。这是整个机制目前最欠缺的一块。

Boundary

不是什么都应该做成 skill

现象

尝到甜头之后，一度什么流程都想沉淀成 skill，后来发现有些场景并不合适。

判断标准

  • 程序性知识——流程、规范、格式约定、踩坑经验——适合 skill；
  • 需要外部状态或实时交互的能力，更适合做成工具接入；
  • 由用户主动发起的固定流程，显式命令比隐式触发更可靠；
  • 一次性的东西写进对话就好，不值得沉淀。

改进方向

在“沉淀能力”的入口处养成分流的习惯。先问“该不该做成 skill”，再问“怎么写好这个 skill”。

EOF

结语

结语

Skill 的本质，是把人的经验编码成 agent 的行为。目前这套机制还年轻：我们很擅长“写”skill，但还不太会“经营”skill。我认为改进的重心不在更炫的功能，而在四件事——

# 改进路线

  • 触发可评测
  • 成本可感知
  • 效果可观测
  • 资产可治理

做到这四点，skill 才能从个人技巧变成可以积累、可以交接的工程资产。

EOF 在 Agent 中使用 Skill 的一些心得 · 2026-08-25