Agent 技能深度拆解：它是什么、不是什么，以及如何正确使用
Agent 技能正在成为 AI 智能体生态中的关键一环。但很多开发者对它的理解还停留在表面——把它当成提示词、当成工具、甚至当成智能体本身。这篇文章将从根本上厘清 Agent 技能的定位，并通过对比分析和实际案例，展示它在整个技术栈中应该扮演的角色。
目录
- 痛点：为什么需要 Agent 技能
- Agent 技能到底是什么
- Agent 技能不是什么
- 全方位对比：技能 vs MCP vs 工具调用 vs 提示词 vs 子智能体
- 渐进式披露：技能的加载策略
- 实战对比：有技能和没技能的差距
- 技能在本地推理场景中的独特价值
- 总结
1. 痛点：为什么需要 Agent 技能
如果你曾经搭建过一个能做不止一件事的 AI 智能体，那你大概率撞过这面墙：
系统提示词越来越臃肿。 每增加一项能力，就意味着更多的指令、更多的示例、更多的边界情况。一个最初只有 200 Token 的提示词，很快就膨胀到 5000。智能体变慢了，成本变高了，可靠性反而下降了——因为它在试图同时兼顾所有事情。
输出表现不一致。 周一让智能体审一段代码，周五再审一次同类型的代码，得到的格式、详细程度、评判标准可能完全不同。没有任何机制在保障流程的一致性。
提示词被锁死在代码里。 定义智能体行为的指令被埋在 C# 字符串、Python f-string 或 YAML 配置文件中。非开发人员无法审阅或改进它们。版本管理很别扭。改一个措辞就意味着一次代码发版。
知识无法复用。 你为项目 A 打造了一套出色的代码审查工作流。项目 B 也需要同样的东西。你复制粘贴了提示词，它逐渐漂移，现在你要维护两份拷贝。
这些都不是极端场景，而是生产级 AI 开发的日常。Agent 技能的诞生，正是为了解决这些问题。
2. Agent 技能到底是什么
Agent 技能是一个开放规范，用于将模块化、可复用的 AI 智能体能力定义为自包含的目录。它由 Anthropic 于 2025 年 10 月首次公开推出，并在同年 12 月作为开放标准发布，支持跨平台移植。
从结构上看，一个技能就是一个文件夹，里面有一个必需文件：
explain/
SKILL.md
SKILL.md 文件由两部分组成：
- YAML 前置元数据：定义技能的名称、描述、版本等信息
- Markdown 正文：包含实际的执行指令
下面是一个完整可用的技能示例：
---
name: explain
description: 用通俗语言解释任何概念
metadata:
version: "1.0"
---
# 通俗解释器
你负责用人人都能听懂的方式解释概念。用户给出一个词、短语或概念，你给出清晰的解释。
## 输出格式
### <主题>
**一句话定义：** <简明扼要的定义>
**原理解释：** <用日常类比说明运作机制，2-3 句>
**为什么重要：** <1-2 句说明价值>
**实际案例：** <一个具体的现实案例>
## 规则
1. **禁止术语黑话。** 必须使用专业术语时，加括号解释。
2. **善用类比。** 把不熟悉的概念比作日常事物。
3. **控制篇幅。** 整个解释在一屏之内。
4. **假设零基础。** 读者没有任何相关背景知识。
这就是一个完整的 Agent 技能。把它保存为 explain/SKILL.md，指向你的智能体，每次激活这个技能时，智能体就会严格遵循这些指令。
可选资源文件
对于更复杂的技能，目录中可以包含额外的文件夹：
code-review/
SKILL.md # 必需：指令 + 元数据
scripts/ # 可选：可执行脚本
lint-check.sh
references/ # 可选：参考文档
coding-standards.md
assets/ # 可选：模板、数据文件
review-template.json
examples/ # 可选：输入输出示例
sample-review.md
这些资源采用懒加载策略：智能体只在真正需要时才读取它们，启动时不会加载。
YAML 元数据字段速查
| 字段 | 必填 | 约束 |
|---|---|---|
name |
是 | 1-64 字符，小写字母、数字和连字符，必须与父目录名一致 |
description |
是 | 1-1024 字符，描述技能功能和触发场景，应包含关键词以便智能体匹配 |
license |
否 | 许可证名称或对许可证文件的引用 |
compatibility |
否 | 最多 500 字符，说明环境要求 |
metadata |
否 | 任意键值对，用于存放 version、author、tags 等 |
allowed-tools |
否 | 空格分隔的预批准工具列表（实验性） |
注意：version 不是顶层规范字段，应放在 metadata 中以确保最大兼容性。
3. Agent 技能不是什么
理解"它不是什么"和理解"它是什么"同样重要。混淆边界会导致糟糕的设计决策。
技能不是工具。 工具（MCP 工具、函数调用、API 端点）是确定性操作——传入输入，获得结构化输出。技能是由 LLM 解释的一组指令。技能描述如何做事，工具直接做事。它们是互补的层次。Block 公司 Goose 团队的总结很精辟：技能描述工作流，MCP 提供执行器。
技能不是提示词。 提示词是临时的、被动的，通常嵌入在代码中。技能是持久的、可移植的、受版本控制的独立产物。技能根据上下文动态加载，提示词则始终存在。
技能不是智能体。 智能体是一个拥有自己工具、记忆和决策循环的执行运行时。技能是任何智能体都可以加载的知识模块。把技能想象成"App"，智能体就是"操作系统"。
技能不是确定性的。 因为指令由 LLM 解释，天然存在不确定性。同一个技能可能产出略有不同的结果。如果需要保证结构化输出，需要配合结构化约束（语法、JSON Schema）或在关键部分使用工具调用。
技能不是 MCP 的替代品。 MCP 提供与外部系统（数据库、API、文件系统）的安全连接能力。技能提供使用这些系统的流程化知识。两者处于不同层次，服务于同一个技术栈。
4. 全方位对比：技能 vs MCP vs 工具调用 vs 提示词 vs 子智能体
这是当前 AI 工具生态中最容易混淆的部分。下面逐一拆解。
技能 vs MCP
MCP 是一种通信协议，定义智能体如何与外部系统对话——数据库、API、文件系统、SaaS 应用。MCP 服务器暴露工具（带 JSON Schema 的结构化函数）和资源（可读取的数据）。
Agent 技能是知识文件。技能告诉智能体如何思考一个任务——遵循什么步骤、使用什么输出格式、遵守什么约束。
打个比方：MCP 服务器连接你的数据库并暴露一个查询工具，但智能体仍然需要知道如何为你的特定数据表编写安全、高效的 SQL——这就是技能的价值。
| 维度 | Agent 技能 | MCP |
|---|---|---|
| 层次 | 知识 / 流程 | 连接 / 操作 |
| 格式 | Markdown + YAML 文件 | JSON-RPC 2.0 协议 |
| 执行方式 | LLM 解释指令 | 确定性 API 调用 |
| 隔离性 | 共享智能体上下文 | 每个服务器独立进程 |
| 延迟 | 零（本地文件读取） | 网络往返 |
| 状态 | 无状态（文本） | 有状态（运行中的服务器） |
| 最佳场景 | 工作流、专业知识、输出格式 | 数据访问、外部操作 |
技能 vs 工具调用 / 函数调用
工具调用是 LLM 决定调用一个结构化函数的机制——模型输出一个包含函数名和参数的 JSON 对象，运行时执行并返回结果。
技能在更高的抽象层运作。一个技能可以在工作流中编排多次工具调用。例如，一个"研究报告"技能可以指示智能体：(1) 搜索网络，(2) 阅读前 5 条结果，(3) 综合分析，(4) 格式化为报告。技能定义流程，工具调用负责动作。
技能 vs 系统提示词
系统提示词是附加在每次对话前的文本块，始终存在，持续消耗 Token，通常硬编码在应用中。
技能只在需要时加载，完成后释放。更深层的区别是：技能是存在于代码之外的可移植产物，可以共享、版本管理、审阅和替换，不需要改动一行代码。
技能 vs 子智能体
子智能体是一个完全独立的智能体，拥有自己的模型、工具、系统提示词和对话历史。编排模式（流水线、监督者、并行）协调多个子智能体。
技能更轻量。它不创建新的执行上下文，而是增强现有智能体的行为。子智能体相当于"请一位专家顾问"，技能相当于"自己读专家的操作手册"。
完整对比总览
| 维度 | Agent 技能 | MCP 工具 | 函数调用 | 系统提示词 | 子智能体 |
|---|---|---|---|---|---|
| 本质 | 可移植知识模块 | 外部连接能力 | 结构化动作调用 | 静态指令文本 | 独立执行上下文 |
| 加载方式 | 按需加载 | 始终连接 | 始终可用 | 始终在上下文中 | 按需创建 |
| Token 成本 | 仅激活时消耗 | Schema 始终占用 | Schema 始终占用 | 始终占用 | 独立上下文 |
| 可移植性 | 跨平台开放标准 | 跨平台开放标准 | 供应商相关 | 厂商相关 | 框架相关 |
| 最佳场景 | 工作流、专业知识 | 数据访问、API | 单一动作 | 基线行为 | 复杂自主任务 |
在实际生产中，成熟的智能体会组合使用以上所有组件。 系统提示词定义基线行为，技能提供任务专项能力，MCP 连接外部数据，函数调用执行动作，子智能体处理复杂编排。
5. 渐进式披露：技能的加载策略
Agent 技能最关键的技术创新是渐进式披露——一套三层加载策略，让上下文始终保持高效。
| 层级 | 触发时机 | 加载内容 | Token 成本 |
|---|---|---|---|
| 发现层 | 启动时 | 仅 YAML 元数据（name + description） | 约 50 Token / 技能 |
| 激活层 | 技能被触发时 | 完整 SKILL.md 正文（指令、格式、规则、示例） | 约 500-5000 Token |
| 执行层 | 智能体需要时 | references/、scripts/、assets/ 中的文件 | 约 2000+ Token / 资源 |
假设你有 20 个技能，启动时只加载约 1000 Token 的元数据。智能体知道它能做什么，但不携带任何详细指令。当某个技能被激活时，只有该技能的指令被加载。用多少付多少。
6. 实战对比：有技能和没技能的差距
同一个模型、同一个用户问题，有技能和没技能的输出差距惊人：
没有技能时
这个函数看起来还行，不过你可能想加点错误处理。另外变量名可以更有描述性一些。整体没什么大问题。
——泛泛而谈，没有结构，每次都不一样。
有代码审查技能时
| # | 问题 | 严重程度 | 行号 |
|---|---|---|---|
| 1 | user.Email 未做空值检查 |
高 | 12 |
| 2 | SQL 注入风险 | 严重 | 18 |
| 3 | 魔法数字 86400 |
低 | 25 |
总结： 合并前需修复 2 个问题。
同一个模型、同样的权重、同样的温度参数，唯一的区别是 800 Token 的技能指令。
更多应用场景
| 场景 | 技能名称 | 效果 |
|---|---|---|
| 客户支持 | support-playbook |
智能体按照分诊检查清单操作 |
| 报告生成 | weekly-report |
输出始终包含相同的章节结构 |
| 合规审查 | gdpr-review |
智能体按特定清单逐项检查 |
| 邮件撰写 | email-writer |
每次输出格式一致 |
| 多功能助手 | 多个技能 | 同一个聊天机器人在不同模式间切换 |
7. 技能在本地推理场景中的独特价值
小模型更需要指引
GPT-4o 或 Claude 这样的云端大模型通常能自行推断出合理的输出格式。但一个 40 亿或 80 亿参数的小模型不具备同等能力。技能通过提供具体的、结构化的指引来弥补这一差距。
上下文窗口更紧。 本地模型通常只有 4K 到 32K 的上下文空间。渐进式披露从"不错的优化"变成了"架构上的必需"——你无法承受一次性加载所有指令。
每一个 Token 都是算力成本。 在本地推理中，额外的上下文 Token 意味着更高的延迟和更大的内存占用。技能让提示词在常见场景下保持精简。
零网络依赖。 技能是本地文件，模型也在本地运行，整个流程在进程内完成，没有任何网络调用。把模型和技能文件夹一起打包交付即可。
隐私与控制。 当技能在本地运行时，指令永远不会离开你的机器。企业内部的合规规则、操作流程或敏感领域知识，始终保留在进程内存中。
简而言之：技能让云端大模型更加有序，让本地小模型真正可用。模型越小，从结构化的技能指令中获益越大。
8. 总结
Agent 技能是 AI 智能体技术栈中一个独立的、不可替代的层次。它不是提示词的升级版，不是工具的替代品，也不是智能体的缩小版。它是流程化知识的标准化载体。
理解技能的正确定位，是用好它的前提。当你需要智能体遵循特定工作流、产出特定格式的输出、或以领域专家的方式行事时——技能是正确的选择。当你需要连接外部系统、执行确定性操作、或定义基线行为时——请使用对应的其他组件。
最强的生产级智能体，从来不是只靠一种技术搭建的。它们是系统提示词、技能、MCP、工具调用和子智能体的有机组合。技能在其中扮演的角色，是把"知道怎么做"这件事标准化、可移植化、可维护化。
常见问题解答
Agent 技能和 MCP 有什么区别？
MCP 是通信协议，解决"智能体如何连接外部系统"的问题。Agent 技能是知识文件，解决"智能体如何正确使用这些系统"的问题。两者是互补关系，不是替代关系。
技能和系统提示词可以共存吗？
不仅可以，而且应该。系统提示词定义基线行为和安全约束，技能提供按需加载的任务专项能力。两者各司其职。
技能适用于小模型吗？
技能对小模型的价值甚至超过大模型。小模型上下文窗口有限，推理能力较弱，结构化的技能指令能显著提升其输出质量和一致性。
如何判断该用技能还是工具调用？
如果任务需要灵活判断和上下文理解——用技能。如果任务是输入输出关系固定的确定性操作——用工具调用。复杂的场景往往两者兼用。
技能的开放标准支持哪些工具？
目前支持 Agent Skills 开放标准的工具包括 OpenAI Codex、GitHub Copilot、VS Code、Cursor 等主流 AI 编程助手，且生态仍在持续扩展中。