技能机制
先说结论
技能是把一段可复用的任务能力封装成“触发条件 + 操作说明 + 所需上下文 / 工具”的模块，让 Agent 能在合适时机按需加载能力包，而不是每次从零规划。
为什么我会单独记这一篇
纯靠大模型临场推理，会遇到几个问题：
- 高频任务重复规划，成本高且不稳定。
- 工具使用方式不一致，容易误调用。
- 经验难以沉淀，团队协作难复用。
技能机制的目标是把稳定任务抽象成可复用能力，使复杂 Agent 更像“会装配能力”的系统。
核心机制
一个技能通常包含四层：
- 能力声明：我能解决什么问题。
- 触发机制：什么时候应该被选中。
- 执行指导：步骤、约束、边界条件。
- 依赖绑定：需要哪些工具、资源、模板。
常见实现形态有三种：
- Prompt skill：一段专门任务说明。
- Tool bundle：围绕某任务打包的一组工具。
- Workflow skill：一条可复用的执行图或子图。
典型运行流程：
- 用户目标进入。
- 路由器判断是否命中某技能。
- 装载技能上下文。
- 执行单技能或多技能组合。
- 输出结果并回写经验。
与相邻概念的区别
- 技能 vs 工具：工具是最小动作单元；技能是面向任务的能力封装，可能组合多个工具。
- 技能 vs Agent：Agent 有自主规划能力；技能更像 Agent 可装载的能力包。
- 技能 vs 工作流：工作流强调路径，技能强调能力复用与触发条件；一个技能内部完全可以是一条工作流。
设计时真正要权衡什么
- 技能边界宽 vs 窄：太宽会互相冲突，太窄会失去复用价值。
- 静态触发 vs 动态路由：静态易控，动态更灵活。
- 技能内聚 vs 技能组合：内聚高更稳定，组合强更灵活但也更复杂。
容易踩的坑
- 技能定义太宽，多个技能都觉得“我能做”。
- 技能说明过长，模型理解成本高于直接推理。
- 把本该是工具的原子能力硬做成技能。
- 没有“何时不要使用我”的负面提示，导致误触发。
- 技能之间缺少输入输出契约，串联后格式不兼容。
工程落地时我会怎么做
- 每个技能只服务一个稳定任务边界，如“写 SQL”“读设计稿”“生成周报”。
- 明确写清楚：何时使用、何时不要使用、输入要求、输出格式、依赖工具。
- 技能描述尽量短，保留关键判定信号词。
- 高频复杂任务做成技能，低频简单任务留给主 Agent 临场推理。
- 如果技能依赖外部资源，优先通过 MCP 的 prompts / resources / tools 暴露。
如果要对外讲，可以怎么概括
“技能机制本质上是在 Agent 系统里做能力模块化。它解决的是高频任务重复规划和经验难沉淀的问题。一个好的技能不是写很长的 prompt，而是把触发条件、执行边界、输入输出契约和依赖工具都讲清楚，让 Agent 能够稳定调用。”
最后记几条
- 技能是任务级能力封装，不是原子工具。
- 一个技能至少要包含触发条件和执行边界。
- 技能边界过宽会造成路由冲突。
- 高频复杂任务最适合做成技能。
- 技能和 MCP 结合后更容易跨宿主复用。