简介：Agent Skill 正被越来越多开发者视为下一代提示工程的关键形态。本文从定义出发，系统解释 Skill 是什么、为什么重要、如何工作，并重点厘清它与传统 Prompt、RAG、MCP 的本质区别。读者可以理解 Skill 如何通过渐进式加载降低 Token 消耗、提升输出一致性，并掌握其典型使用场景、选型边界与落地注意事项。
在智能体开发语境下，Agent Skill 可以定义为一组可复用、可组合、可按需加载的“专业知识包”。它不只是一段提示词，也不只是一个工具调用描述，而是一个围绕特定任务或领域经验组织起来的能力单元。
从技术视角看，Skill 通常表现为一组结构化文件，至少包含：
从业务视角看，Skill 是把某个资深员工处理某类问题的方法沉淀为“可复制的能力单元”。例如“合同风险审查”“周报生成”“SQL 性能诊断”“客户投诉分级”等，都可以被封装为独立 Skill。
从使用视角看，Skill 不是每次对话时重新输入的长篇说明，而是一个可以长期保存、反复调用、跨会话复用的能力模块。用户只需要告诉模型“使用某个 Skill 完成某件事”，模型即可按照预置的专业逻辑执行。
在 Skill 被广泛关注之前，开发者通常用三种方式增强模型能力。
第一种是堆叠提示词。把系统提示、少量示例、风格要求、边界条件、输出格式全部塞进上下文。这种方式门槛低，但问题明显：Token 消耗高，长提示动辄几千甚至上万 Token；不同轮次之间风格容易漂移；调好的经验难以沉淀；复杂任务容易因上下文过长而失控。
第二种是外挂检索增强，即 RAG。它解决了一部分“知识更新”和“事实性不足”的问题，但检索回来的内容如果质量不高，反而会干扰模型判断；同时它主要解决“知道什么”，并不直接解决“怎么做得更专业”。
第三种是外部工具调用，典型代表是 MCP。它让模型可以访问外部数据源或执行操作，但配置复杂、维护成本高，工具描述本身也会大量占用 Token。
Skill 的出现，恰好回应了一个更实际的问题：如何把“提示词调优”从一次性劳动，升级为可复用、可组合、可维护的工程资产。
它的核心价值不是“更强”，而是“更稳、更省、更可沉淀”。实际使用中，一个设计良好的 Skill 可以明显减少重复输入的 Token，同时让同一类任务的输出风格和结构保持高度一致。
一个完整的 Agent Skill，通常由以下部分组成。
这部分回答两个问题：这个 Skill 是做什么的？什么时候应该使用它？触发描述通常写得简短而明确，例如“当用户需要审查合同时使用”。模型在初始阶段只读取这些精简信息，决定是否加载完整 Skill。
这是 Skill 的主体，描述完成任务的步骤、判断标准、输出要求、禁止事项等。它可以是一份结构化文本，也可以引用多个子文件。
对于输出格式高度敏感的任务，Skill 会内置少量高质量示例或可直接套用的模板。这样模型在生成内容时有明确参照，减少格式漂移。
Skill 可以声明自己需要访问哪些工具或数据，但它本身不负责实现工具协议。例如一个“数据库慢查询诊断” Skill，可以说明需要读取慢查询日志、查看执行计划，但具体如何连接数据库仍由外部工具层完成。
说明该 Skill 的适用范围、已知局限、更新记录等。这让 Skill 可以像代码一样进行版本管理。
Skill 最核心的运行机制是渐进式披露。
系统在初始化时，只向模型提供所有可用 Skill 的简短描述，而不是全量内容。模型根据用户当前任务，判断需要激活哪一个或哪几个 Skill。一旦决定激活，系统才将该 Skill 的完整内容加载进上下文。
这个过程可以抽象为以下流程：
用户输入↓模型读取可用 Skill 列表（仅名称 + 一句话描述）↓模型判断：是否需要某个 Skill？↓ 否直接使用通用能力回答↓ 是加载该 Skill 的完整内容↓按照 Skill 中的流程与规则执行↓输出结果
这种机制的关键意义在于：模型不是每次都被塞入所有专业知识，而是在需要时才读取。 因此，即使系统里存在几十个 Skill，实际 Token 开销也只与当前任务相关。
例如一个系统同时包含“合同审查”“周报生成”“代码审查”三个 Skill。用户问“帮我看看这段代码有没有问题”，模型初始只看到三个名称和一句话描述，判断需要激活“代码审查”，然后才加载该 Skill 的详细规则。另外两个 Skill 的内容完全不会进入上下文。
Skill 适合那些流程相对固定、经验可以沉淀、需要反复执行的任务。
如周报、月报、项目复盘、测试报告、需求说明等。这类任务通常有固定格式和固定关注点，非常适合封装为 Skill。
如合同条款审查、代码质量检查、数据库慢查询诊断、安全配置核查等。Skill 可以把审查清单、判断规则、输出格式固化下来。
如工单分级、投诉分类、常见问题应答等。Skill 可以内置分类标准和应答口径，保证不同会话之间的一致性。
如从非结构化文本中提取字段、生成 JSON、整理表格等。Skill 可以规定字段定义、缺失值处理方式、输出 schema 等。
如“从需求文档生成测试用例，再生成测试报告”，这类跨步骤任务如果拆成多个 Skill，可以像积木一样组合使用。
传统 Prompt 是“一次性告诉模型怎么做”。每次对话都要重新输入完整要求，经验难以沉淀，风格容易漂移。
Skill 是“教模型成为某个领域的专家”。它把执行知识封装成可复用模块，只在需要时加载，既省 Token，又保证一致性。
两者的关系不是替代，而是升级。Skill 内部仍然包含 Prompt，但它的组织方式、加载机制、复用能力都比普通 Prompt 更工程化。
RAG 解决的核心问题是“模型的外部知识不足”。它通过检索外部文档，把相关内容临时注入上下文，让模型基于最新、更准确的信息回答问题。
Skill 解决的核心问题是“模型做某类任务的专业流程不足”。它提供的是执行逻辑、规则和格式要求，而不是外部事实。
两者可以配合使用。例如一个“政策问答” Skill 可以规定回答结构、引用格式和免责声明，同时调用 RAG 获取最新政策原文。简单地说，RAG 提供“材料”，Skill 提供“做法”。
MCP 是一种工具调用协议，让模型能够连接外部数据源或执行外部操作，例如查数据库、调 API、读取文件等。它的价值在于“给模型外接手脚”。
Skill 是一种能力封装方式，它的价值在于“给模型预置专业经验”。
MCP 的典型问题是配置复杂、工具描述占用 Token、维护成本高。Skill 则相对轻量，通常只需要文件夹和文本文件即可使用。Skill 也可以调用工具，但工具本身由外部协议层提供，Skill 不负责实现连接细节。
| 维度 | 传统 Prompt | RAG | MCP | Agent Skill |
|---|---|---|---|---|
| 本质 | 一次性文本指令 | 外部知识检索 | 工具/数据服务协议 | 可复用专业能力包 |
| 主要解决问题 | 告诉模型怎么做 | 让模型知道更多 | 让模型能操作外部系统 | 让模型做某类任务更专业 |
| Token 消耗 | 高 | 中高 | 高 | 低到中 |
| 输出一致性 | 差 | 中 | 中 | 高 |
| 配置复杂度 | 低 | 中 | 高 | 低到中 |
| 复用性 | 差 | 中 | 中 | 强 |
一个 Skill 不应包罗万象。如果任务流程过于复杂，可以拆分为多个小 Skill 后组合使用。粒度太大容易导致触发不准确，粒度太小又会产生过多调度开销。
模型是否能正确激活某个 Skill，很大程度上取决于触发描述写得好不好。描述应当聚焦于“什么情况下使用”，避免模糊表述。
虽然渐进式加载能显著降低 Token 消耗，但如果同时激活过多 Skill，上下文仍可能膨胀。建议对复杂任务设置优先级或串行执行策略。
Skill 本质上是一种工程资产。像管理代码一样管理 Skill 版本、变更记录和发布流程，可以避免团队协作时出现“谁改了提示词”的混乱。
如果 Skill 需要调用工具或访问数据，应明确权限边界。不要让模型自动执行高风险操作，例如删除数据、发送外部请求等，除非有明确的人工确认环节。
Skill 不是万能方案。对于高度开放、需要大量实时事实核查的任务，仍需要配合 RAG 或外部工具。对于一次性、低频任务，临时写 Prompt 可能比专门维护一个 Skill 更经济。
Agent Skill 的本质，是把“如何做好某类任务”的专业经验，从一次性提示词升级为可复用、可组合、可按需加载的能力包。它通过渐进式披露机制，在保证专业性的同时显著降低 Token 开销，并让输出一致性从“靠运气”变成“靠设计”。
与 RAG 相比，Skill 更偏向“做法”而非“材料”；与 MCP 相比，Skill 更偏向“经验沉淀”而非“工具接入”。它们解决的是不同层面的问题，在实际系统中可以协同使用。
理解 Skill 的关键，不在于记住某个具体实现，而在于理解它背后的工程思路：把提示词从一次性消耗品，变成可持续积累的专业资产。