---
title: 万字详解 Agent Skills：是什么？怎么用？和 Prompt、MCP 有什么区别？
description: 深入解析 Agent Skills 概念，探讨 Skills 与 Prompt、MCP、Function Calling 的本质区别，以及如何在实战中设计优秀的 Skill 固化代码规范。
category: AI 应用开发
head:
  - - meta
    - name: keywords
      content: Agent Skills,MCP,Function Calling,Prompt,AI Agent,智能体,延迟加载,上下文注入
---

2025 年初，Anthropic 在推出 **MCP（Model Context Protocol）** 之后，在 Claude Code 中引入了 **Agent Skills** 的概念。背后的设计动机是：**连接性（Connectivity）与能力（Capability）应该分离**。

很多开发者认为“只要提示词写得好，AI 就能帮我做一切”。但事实是：**Prompt 适合单次任务，Skills 才是构建可复用 AI 能力的正确做法**。

Skills 把 AI 应用从“个人技巧”拉到了“工程化”的层面。今天 Guide 带大家彻底搞懂这个概念，聊清楚 Skills 的设计理念、与相关技术的本质区别，以及如何在实战中用好这个能力。

1. **Skills 是什么**：为什么说 Skill 是“延迟加载”的 sub-agent？它的核心机制——上下文注入和延迟加载是如何工作的？
2. **Skills vs Prompt vs MCP vs Function Calling**：这四者的本质区别是什么？它们分别适用于什么场景？这是面试中的高频盲区。
3. **优秀的 Skill 长什么样**：一个设计良好的 Skill 应该包含哪些要素？元数据、触发条件、执行流程如何设计？
4. **项目实战**：如何在真实开发中用 Skills 固化代码规范、排查流程、Review 标准？如何把团队中的“隐性知识”变成可复用的 AI 能力？

## Skills 是什么？

用一句话概括：**Skill 是一个用自然语言定义的、具有特定领域上下文（Domain Context）的逻辑指令集，本质上是通过延迟加载（Lazy Loading）优化 Token 消耗的 Sub-Agent（子智能体）**。

> 这里的"Sub-Agent"是一种类比——Skill 并不是独立的 Agent 实例，没有独立的规划循环（Agent Loop），它更接近一段可动态注入的领域上下文。

在团队协作中，很多“隐性知识”都在老员工脑子里，比如代码规范、排查流程、Review 标准。Skills 的核心价值，就是**把这些隐性规则变成显性的文档（SOP），让 AI 能够自主阅读、理解并执行**。

与传统的硬编码工作流不同，Skills 不强制规定每一步的代码逻辑，而是**用自然语言将决策权下放给模型**——模型通过 `load_skill()` 动态加载 `SKILL.md` 后，将其中定义的规则、流程和约束**实时注入到推理上下文**中，指导后续的工具调用和决策。这既保留了 Agent 处理不确定性的优势，又避免了纯代码编排的僵化。

> 为什么不用“基于 Function Calling 封装”？这个表述容易让人误以为 Skill 是某种 Function Calling 的语法糖。实际上，Skill 的核心机制是**上下文注入**——Agent 读取 Markdown 文档，把其中的规则和流程纳入推理上下文。Function Calling 只是 Agent 执行某些动作（如调脚本、查资源）时可能用到的底层手段，不是 Skills 本身的定义层。
>
> 注意：`load_skill()` 是对“Agent 读取并激活 SKILL.md”这一过程的概念性描述，不同工具（Claude Code、Cursor 等）的实际触发方式会有差异。

**关键机制**：

- **延迟加载（Lazy Loading）**：元数据保持简短（通常远少于正文）常驻上下文，正文仅在触发时动态注入，避免挤占 Token
- **动态上下文注入**：不同于静态文档的“阅读”，Skills 是将规则实时注入推理上下文，直接影响模型决策

## Skills 和 Prompt、MCP、Function Calling 有什么区别

这也是面试中常被问到的点，容易混淆：

**1. Skills vs Prompt**

| 维度         | Prompt                     | Skills                         |
| :----------- | :------------------------- | :----------------------------- |
| **本质**     | 单次对话的文本指令         | 可持久化、可发现的**能力单元** |
| **复用性**   | 随对话上下文丢失，难以维护 | 标准化封装，跨项目、多场景复用 |
| **加载机制** | 全量载入（挤占 Token）     | **延迟加载**（按需读取正文）   |

- **Prompt**：用户即时表达意图的载体（如“分析这份报表”）。
- **Skills**：包含**元数据（何时使用）+ 正文（如何执行）**的完整方案，通过 `load_skill()` 机制按需加载到上下文。

**2. Skills vs MCP**

这是最容易产生误解的地方。

| 维度         | MCP (Model Context Protocol)               | Skills                                         |
| :----------- | :----------------------------------------- | :--------------------------------------------- |
| **核心思路** | **标准化连接**：通过 JSON-RPC 统一数据格式 | **逻辑编排**：用自然语言描述复杂执行路径       |
| **定义方式** | 在 Server 端用代码（TS/Python）写死逻辑    | 在 `SKILL.md` 中用自然语言引导模型决策         |
| **环境依赖** | 需要运行一个 MCP Server 进程               | 依赖可执行环境（如本地 Shell 或沙箱）          |
| **哲学**     | **以协议为中心**：一次编写，所有 AI 通用   | **以模型为中心**：利用模型推理能力处理不确定性 |

- **MCP 解决的是连通性** ：它像 USB-C，让 AI 能以统一格式读文件、查数据库。
- **Skills 解决的是编排逻辑** ：它像一份说明书，告诉 AI 如何执行复杂任务流——这些任务完全可以包括调用多个 MCP 工具。
- **两者的关系** ：它们解决的是不同层面的问题。MCP 负责把外部系统接入进来，Skills 负责决定什么时候用、怎么组合这些能力。一个高级 Skill 的底层往往就是调用多个 MCP 工具。

![MCP 图解](https://oss.javaguide.cn/github/javaguide/ai/skills/mcp-simple-diagram.png)

![Skills vs MCP](https://oss.javaguide.cn/github/javaguide/ai/skills/mcp-mcp-vs-skills.png)

**3. Function Calling vs Skills**

| 维度         | Function Calling         | Skills                                                                  |
| :----------- | :----------------------- | :---------------------------------------------------------------------- |
| **层级**     | 底层机制                 | 上层应用                                                                |
| **依赖关系** | 基础能力                 | 在执行时**可能使用** Function Calling（如加载文档、执行脚本、读取资源） |
| **粒度**     | 原子操作（单次工具调用） | 复合流程（多步骤决策 + 工具组合）                                       |

Skills **没有创造新能力**，而是通过自然语言文档将能力组织成更易用的形式：

1. Agent 读取 `SKILL.md`，将规则和流程注入推理上下文。
2. 根据上下文指导，Agent **可能**通过 Function Calling 执行脚本、读取资源或调用 MCP 工具。

> 并非所有 Skills 都依赖 Function Calling。有些 Skill 是纯推理型的——比如代码审查规范、架构决策指南，它们只提供上下文指导，不需要任何外部工具调用。Function Calling 是 Skills 执行动作时的底层手段，不是 Skills 存在的前提。

**系统总结**：

| **组件**             | **一句话定义**             | **形象类比** | **关键理解**                                        |
| :------------------- | :------------------------- | :----------- | :-------------------------------------------------- |
| **Prompt**           | 即时意图表达的载体         | 用户说的话   | 单次、易失                                          |
| **Function Calling** | LLM 输出结构化调用的能力   | 神经信号     | **一切的基础**，实现非结构化→结构化转换             |
| **MCP**              | 标准化的工具接入协议       | USB-C 接口   | 解决外部系统“如何接入”（连通性）                    |
| **Skills**           | 用自然语言定义的 sub-agent | 任务说明书   | 解决复杂任务“如何编排”（执行逻辑），可调用 MCP 工具 |

**四层关系**：Function Calling 是地基 → Prompt 表达意图 → MCP 负责连通外部系统 → Skills 负责编排复杂任务流（可调用 MCP）

这里需要澄清一个常见误解：MCP 和 Skills 并不冲突，也**不是非此即彼**。

- **MCP** 解决外部系统如何接入：让 AI 能以统一格式读文件、查数据库、调用 API。
- **Skills** 解决复杂任务如何编排：用自然语言定义执行流程，这些流程完全可以包含调用多个 MCP 工具。

两者配合使用：一个 Skill 的正文里会指导 Agent 先用 MCP 读取数据库，再用 MCP 调用外部 API，最后生成报告。

**一句话总结**：Prompt 承载意图，Function Calling 实现交互，MCP 负责连通外部系统，Skills 负责编排复杂任务流。

## Skills 长什么样？如何使用

从结构上看，Skill 很简单，核心就是一个 `SKILL.md` 文件，包含**元数据**（描述什么时候用）和**正文**（具体的执行 SOP）。

**设计上的亮点是“渐进式披露”**：

- **元数据**常驻上下文，AI 知道有哪些技能可用。
- **正文**按需加载，只有触发时才读取，避免挤占 Token。

复杂点的 Skill，还会有附加的资源目录、脚本和参考文档。

Skill 的完整目录结构是这样的：

```
skill-name/
├── SKILL.md          # 必需：元数据（何时使用）+ 正文（指令、流程、示例）
├── scripts/          # 可选：可执行脚本（Python/Bash），按需调用
├── references/       # 可选：参考文档，按需读取
└── assets/           # 可选：模板、图片等资源
```

**项目实战**：

我在项目中主要用 Skills 来**固化工程标准**。比如定义一个 `code-reviewer` Skill，明确要求从架构合理性、异常处理完整性、日志规范、安全风险、性能隐患等多个维度进行结构化审查。这样 AI 在 Review 代码时，就会严格执行团队标准，而不是“随缘点评”。这对于保持代码质量的一致性非常有用。

除了 Code Review，我也会定义其他 Skill，例如：

- `api-endpoint-generator` - 按项目统一响应结构与异常模型生成标准化接口代码
- `database-access-review` - 审查数据库访问逻辑，关注索引使用与慢查询风险
- `refactor-analysis` - 先评估影响范围与依赖关系，再输出分步骤重构方案
- `security-audit` - 扫描 SQL 拼接、XSS、权限绕过等常见安全风险

**优秀 Skill 示例**：

- Code-Review-Expert（专家代码审查 Skill，以资深工程师视角进行结构化代码审查，覆盖：架构设计、SOLID 原则、安全性、性能问题、错误处理、边界条件）：**https://github.com/sanyuan0704/code-review-expert**
- Git Commit with Conventional Commits（一个基于 Conventional Commits 规范的智能提交工具，可自动分析 diff、智能暂存文件并生成语义化 commit message，安全高效完成标准化 Git 提交）：**https://github.com/github/awesome-copilot/blob/main/skills/git-commit/SKILL.md**
- TDD（测试驱动开发，先编写测试用例，观察它是否失败，然后编写最少的代码使其通过测试）：**https://github.com/obra/superpowers/blob/main/skills/test-driven-development/SKILL.md**

**https://skills.sh/** 这个网站可以查找热门和实用的 Skills。

![查找自己需要和热门的 Skiils](https://oss.javaguide.cn/github/javaguide/ai/skills/skillssh.png)

这里 Guide 多提一下，回答这个问题的时候，你也可以说自己团队用到了一些开源的软件开发 Skills 集合，例如 Superpowers 中内置的。

![Superpowers 内置的 skills](https://oss.javaguide.cn/github/javaguide/ai/skills/superpowers-skills.png)

另外，很多 AI 编程工具也支持 Skills 机制。以 Claude Code 为例，它会在项目的 `.claude/skills/` 目录下扫描 `SKILL.md` 文件，**由模型自主判断何时激活**——用户无需手动调用，Claude 会根据任务上下文自动匹配并加载相关的 Skill。

> 也就是说，Claude Code 的 Skills 是 **model-invoked**（模型主动调用），而非 user-invoked（用户手动触发）。这也是 Skills 和传统插件系统的关键区别之一。Anthropic 官方也在持续发布和维护 Agent Skills 集合（见 [Anthropic Skills 仓库](https://github.com/anthropics/skills)）。

::: warning 第三方 Skills 的安全风险

使用第三方 Skills 时需要注意安全风险：

- **提示注入**：恶意 Skill 可能包含诱导模型执行非预期操作的指令（如读取敏感文件、执行危险命令）。
- **数据泄露**：Skill 可能引导模型将敏感信息输出到外部服务。
- **建议**：使用前审查 `SKILL.md` 内容；企业场景下建立内部 Skill 审核机制；避免直接使用来源不明的 Skill。

:::

## 如何实现渐进式披露？

前面讲了渐进式披露的理念——元数据常驻、正文按需加载。这一节展开聊聊**具体怎么落地**。

### 上下文不是越多越好

很多开发者的直觉是“给模型的信息越全，它表现应该越好”，但实际跑下来并非如此。这意味着如果你把几十条规范指令全塞进 System Prompt，排在中间的那些指令基本等于没写。盲目堆内容不但没用，反而会让真正重要的指令被淹没在噪声里。

![渐进式披露](https://oss.javaguide.cn/github/javaguide/ai/skills/skills-progressive-disclosure.svg)

上下文管理核心原则是：**每一段放进来的内容，对当前任务的贡献越大越好，无关内容就是纯噪声**。

### 分层设计方案

处理思路是**分层设计**，把“知道有哪些能力”和“获取具体指令”拆成两步：

**第一层：元信息常驻**。每条 Skill 只保留一个名称加两三句描述，全部 Skill 加在一起也就几百 token。这个“目录”始终留在上下文里，让模型知道有哪些能力可用。

**第二层：按需加载正文**。用户请求进来后，先用这份“目录”做一次粗筛，判断当前任务涉及哪几个 Skill，只有被命中的 Skill 才读取完整内容拼进上下文。

### “相关”怎么判断

关于“怎么判断当前任务需要哪些 Skill”，实践中主要有两种方案：

- **关键词匹配**：速度快，但召回率差，用户稍微换个说法就匹配不上。
- **语义匹配**：把每条 Skill 的描述提前用嵌入模型向量化存好，请求进来后对用户 Query 做向量化，算余弦相似度，取 top-k 命中。效果好了很多，但引入了一个额外的嵌入模型调用，延迟上有一点开销。

实际项目中推荐语义匹配为主、关键词匹配兜底的组合策略。

> 语义匹配有一个常见的**冷启动问题**：新上线的 Skill 还没有历史 Query 数据，嵌入模型只能靠元信息描述来匹配，准确度可能不够。实践中可以通过**预设典型 Query 样本**（在 Skill 元数据中加入 `examples` 字段）来缓解——相当于给新 Skill 预热。

### 兜底机制

首次匹配难免漏掉，所以需要一个**补充加载**机制：如果本轮任务在执行中触发了某个之前没有被加载的 Skill 关键词，就把对应内容追加进上下文。这个机制解决了首次匹配漏掉的问题，但要注意拼接位置对模型的影响——指令放在 Prompt 哪个位置会直接影响模型的关注度，不能随意插在中间。

> 从系统设计的角度看，这套分层逻辑和数据库“先走索引再回表”是一样的——全量扫描代价太高，所以用一个轻量的辅助结构（元数据索引）做预过滤，命中之后再拿完整数据（Skill 正文）。核心思想都是“用小代价换范围收窄，再用精确查询获取完整数据”。

## 如果设计一个 Skill 路由模块？

上一节聊了渐进式披露的实现，这一节更进一步：如果让你从零设计一个 **Skill 路由模块**，需要从几十个 Skill 里快速选出最相关的 2-3 个，怎么建索引、怎么做排序？

这里有一个容易混淆的点：这个问题表面看起来像 RAG，但在几十个 Skill 的规模下，本质更接近一个“小规模检索 + 精排”的问题，而不是一个完整的知识增强系统设计。

### 和 RAG 的本质区别

Skill 路由和 RAG 的逻辑是相通的——都是“先检索再生成”，但本质区别在于**内容的性质和稳定性**：

- **RAG** 检索的是外部知识库，内容动态、量大、不在模型控制范围内，多召回几条不相关文档还有一定容忍度，模型自己能在生成阶段过滤掉一部分，本质目标是“补充上下文信息”。
- **Skill 路由**检索的是有限数量的结构化指令集，内容相对稳定、总量可控，但精准度要求更高——一旦选错 Skill，后续整个执行链路都会跑偏，本质目标是“选对能力而不是补知识”。

换句话说，RAG 更偏“召回尽可能有用的信息”，而 Skill 路由更偏“尽量避免选错”。

### 四步路由流程

![Skill 四步路由流程](https://oss.javaguide.cn/github/javaguide/ai/skills/skills-router.svg)

完整的 Skill 路由流程可以拆成四步：

1. **向量化索引**：把每个 Skill 的名称、描述、典型触发场景提前用嵌入模型向量化，存到一个轻量向量库里。几十个 Skill 的量级，用 NumPy 在内存里做余弦相似度计算就足够了（微秒级响应），不需要引入 FAISS 等专门的向量检索库，这样实现成本更低、调试也更简单。当然，如果后续 Skill 数量增长到数百甚至上千，再考虑迁移到 FAISS 或专门的向量数据库也不迟。

2. **初筛候选**：对用户输入做向量化，算相似度，先取 top-5 候选。这一步追求召回率，宁可多选几个，为后续精排留空间，而不是一开始就试图选准。

3. **Rerank 重排**：用一个轻量的交叉编码器模型对候选列表重新打分，最终选 top-2 或 top-3。Rerank 的核心价值是把“语义相近但意图不匹配”的误召回过滤掉，这比纯向量匹配精准很多，本质是在做“能力级别”的判别。

4. **置信度兜底**：如果最高分的 Skill 相似度都低于某个阈值，说明当前任务不需要任何特殊 Skill，走默认流程，避免强行匹配导致错误指令介入。在 Skill 路由里，“不选”有时候比“选错”更重要。

### “检索到了但生成跑偏”怎么办

这是 RAG 和 Skill 路由都会遇到的问题，原因通常有两类：

- **检索内容本身的问题**：召回的段落是相关主题但不是模型真正需要的那个细节。比如问“Java 单例模式线程安全写法”，召回了一堆讲单例模式的通用介绍，但双重检查锁的关键代码没进来。解法是**优化分块策略**，让关键片段在检索粒度上更容易被命中。

- **拼接方式的问题**：把多段检索结果直接拼在一起，没做任何整理，模型读到的是一堆结构混乱的碎片，生成时就容易抓不住重点。解法是在召回后加一步 **rerank 或者摘要压缩**，甚至可以显式标注结构（如“背景 / 约束 / 关键步骤”），提高模型可读性。

### 通用指令调度器的架构

如果要设计一个更通用的“指令调度器”，可以抽象出四个核心组件：

| 组件             | 职责                                                | 关键点                                   |
| ---------------- | --------------------------------------------------- | ---------------------------------------- |
| **指令注册中心** | 维护所有指令的元信息，提供增删改查接口              | 注册时自动生成向量并持久化               |
| **路由引擎**     | 接收用户意图，做语义匹配，输出候选指令列表和置信度  | 无状态，可横向扩展                       |
| **加载器**       | 按需拉取指令完整内容                                | 支持缓存，避免重复读文件                 |
| **上下文装配器** | 把选出来的指令按优先级和位置规则拼装进最终的 Prompt | 指令放在 Prompt 哪个位置会影响模型关注度 |

这里可以注意一个实践点：路由和加载解耦是很关键的，这样可以在不影响路由性能的情况下，灵活调整指令内容和存储方式。

### 高并发下的性能考量

高并发场景下，语义匹配可能成为瓶颈，主要有两个：一是每次请求都要调嵌入模型生成向量（如果用的是外部 API，延迟不可控）；二是向量相似度计算本身（Skill 数量少可以全量算，规模上去了就需要 ANN 索引）。

实际项目里的应对策略：

- **Query 向量化做缓存**：高频的相似 Query 命中缓存直接返回，绕过嵌入调用，收益通常很明显。
- **内存向量检索**：Skill 数量通常就几十个，用 NumPy 在内存里直接算余弦相似度即可（微秒级），不需要 FAISS 等额外依赖，优先保证简单可靠。
- **无状态路由服务**：把路由服务单独抽出来，因为是无状态的，扩容很容易，同时也方便做灰度和策略迭代。

## 如何编写高质量的 AI Agent Skills？

很多开发者第一次接触 Skills 时，会下意识地把它当成“文档”来写——堆砌背景介绍、安装指南、版本历史……结果发现 AI 要么“读不懂”，要么“不用它”。

**编写高质量的 Skills 是一项专门的技能**——你写的不是给人看的 README，而是**给 AI 写执行协议**。这个区别决定了你需要完全不同的思维方式：

- **写给人**：注重可读性、完整性、背景知识
- **写给 AI**：注重精准性、可执行性、上下文效率

接下来的内容将系统性地介绍如何编写高质量的 Skills。这些原则来自 Anthropic 官方文档和社区大规模生产实践，经过实战验证。

### 语义精确的 Metadata（元数据）

Metadata 是 Agent 进行任务路由的核心依据，尤其是 description，它充当 LLM 的“索引”。

- **原则**：消除歧义，明确边界，并融入意图触发词。
- **优化逻辑**：从“描述功能”转向“定义场景、问题和触发条件”。

| 维度       | 描述                                                                                               | 触发意图                                                                           |
| ---------- | -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| 不好的示例 | 分析系统日志                                                                                       | 无明确引导                                                                         |
| 优化的示例 | 诊断 Spring Boot 生产环境的运行时异常，包括解析 Java 堆栈跟踪、定位 OOM 内存溢出和分析慢接口耗时。 | 当用户提到“接口报错”、“系统卡死”、“频繁 Full GC”或粘贴错误日志时，立即激活此技能。 |

在 Metadata 中添加 `parameters` 字段，定义输入输出格式（如 YAML），帮助 LLM 减少幻觉。例如：

```yaml
parameters:
  input: { type: string, description: "错误日志或堆栈跟踪" }
  output: { type: json, description: "诊断结果，包括根因和建议" }
```

### 模块化与单一职责

大型“全能” Skills 会导致 LLM 在参数构建时产生幻觉。Agentic Workflow 更适合细粒度工具矩阵。

- **原则**：按排查维度拆分，确保每个 Skill 单一职责（SRP）。
- **优化方案**：避免单一“系统故障排查器”，改为工具集：
  - `jvm-metrics-analyzer`：专责通过 Prometheus 采集 JVM 指标（如堆内存、线程数）。
  - `distributed-trace-finder`：利用 SkyWalking 或 Zipkin 追踪特定 TraceId 的链路耗时。
  - `k8s-pod-event-viewer`：专责查询 Kubernetes Pod 状态变更和重启记录。

### 确定性优先原则

对于需要严谨逻辑的计算或格式转化，**永远不要相信 LLM 的“直觉”**，要让它去驱动脚本。

- **原则**：LLM 负责**提取参数**，脚本负责**逻辑闭环**。
- **案例优化**： 当 Agent 发现 CPU 负载过高时，不要让它“盲猜”哪个线程有问题，而是让它调用一个封装好的诊断脚本。

**Skill 定义中的执行逻辑：**

> “如果 CPU 使用率超过 80%，请提取节点 IP，调用 `./scripts/capture_thread_dump.sh`。不要尝试在对话框中手动模拟线程分析，直接解析脚本返回的 **Top 3 耗时线程堆栈**。”

> 注意适用边界：确定性优先适用于**涉及精确计算、格式转化、副作用操作**（如执行脚本、修改数据库）的场景。对于需要模糊判断、创意生成或开放性推理的任务（如方案设计、文案优化），过度脚本化反而会限制模型的表达能力。

### 渐进式披露策略

避免“信息过载”导致 Agent 迷失。通过文档的分层结构，让 Agent 只在需要时加载细节。

**三层结构建议**：

1. **SKILL.md（主体）**：定义核心故障类型（4xx, 5xx）和标准排查流转（SOP）。
2. **`troubleshooting-guide.md`（附加）**：放置一些罕见的“陈年老坑”或特定中间件（如 RocketMQ）的配置盲区。
3. **runbooks/（数据文件）**：存储历史故障知识库，由 Agent 通过 RAG 检索后再参考，而不是一股脑塞进上下文。

### 总结

编写高质量 Skills 的 **五大核心原则**：

| **原则**       | **核心思想**             | **关键实践**                              |
| -------------- | ------------------------ | ----------------------------------------- |
| **语义精确**   | 从“描述功能”到“定义场景” | 用祈使句 + 触发关键词 + 明确边界          |
| **极简主义**   | 上下文是公共资源         | 删除噪音，10 行示例代替100行文字          |
| **模块化**     | 单一职责避免幻觉         | 按排查维度拆解，而非建立“全能工具”        |
| **确定性优先** | 识别“脆弱操作”           | LLM 提取参数，脚本负责逻辑闭环            |
| **渐进式披露** | 按需加载，避免上下文爆炸 | L1 元数据常驻 + L2 正文按需 + L3 资源隔离 |

**记住**：Skills 本质上是**执行协议**，别把它当文档写。

## 总结与选型建议

### 核心观点

Skills 和 MCP 代表了智能体技术栈中两个关键的抽象层：

| **组件**   | **一句话定义**             | **形象类比** | **关键理解**                       |
| ---------- | -------------------------- | ------------ | ---------------------------------- |
| **MCP**    | 标准化的工具接入协议       | USB-C 接口   | 解决外部系统“如何接入”（连通性）   |
| **Skills** | 用自然语言定义的 sub-agent | 任务说明书   | 解决复杂任务“如何编排”（执行逻辑） |

### 实践建议

| 场景                                   | 推荐方案                         | 原因                                 |
| -------------------------------------- | -------------------------------- | ------------------------------------ |
| 外部服务连接（数据库、API、云服务）    | **优先使用 MCP**                 | 标准化接口，易于维护                 |
| 复杂工作流（多步骤任务、领域专业知识） | **优先使用 Skills**              | 封装领域知识，可复用                 |
| 上下文受限场景（长对话、大量工具）     | **使用 Skills 进行渐进式管理**   | 只加载相关 Skill，大幅减少无效 token |
| 企业级智能体构建                       | **采用 MCP + Skills 的分层架构** | 关注点分离，易维护扩展               |

### 面试准备要点

**高频问题**：

1. **Skills 是什么？** → 延迟加载的 sub-agent，解决“如何编排”问题
2. **Skills 和 MCP 的区别？** → MCP 负责连通性，Skills 负责执行逻辑，互补关系
3. **如何降低 token 消耗？** → 渐进式披露：元数据常驻，正文按需加载
4. **什么是渐进式披露？** → 三层架构：元数据 → 正文 → 附加资源
5. **如何编写高质量 Skills？** → 精准 description + 单一职责 + 确定性优先
6. **怎么实现渐进式披露？** → 元信息常驻做索引，语义匹配（向量化 + 余弦相似度 top-k）筛选相关 Skill，按需加载正文，触发关键词时补充加载兜底
7. **上下文信噪比怎么理解？** → "Lost in the Middle"效应（Liu et al., 2023），模型对上下文头尾记得住、中间容易忽略，盲目堆内容反而让关键指令被淹没
8. **渐进式披露和 RAG 的本质区别？** → 内容性质不同：Skill 路由是有限结构化指令集，要求精准度更高，选错会连错整条链路；RAG 是外部知识库，多召回几条还有容忍度
9. **Skill 路由模块怎么设计？** → 嵌入模型向量化索引 → top-5 候选 → 交叉编码器 rerank 重排 → 置信度阈值兜底
10. **渐进式披露和数据库索引的类比？** → 都是用轻量辅助结构做预过滤，缩小范围后再取完整数据；指令调度器 = 注册中心 + 路由引擎 + 加载器 + 上下文装配器
11. **高并发下语义匹配怎么扛？** → Query 向量化缓存 + NumPy 内存检索（几十个 Skill 不需要 FAISS）+ 无状态路由服务横向扩展
12. **Skills 有什么局限性？** → 纯推理型 Skill 缺乏执行能力、第三方 Skill 存在安全风险（提示注入、数据泄露）、模型自主判断可能误触发或漏触发

**追问准备**：

- 你的团队用了哪些 Skills？如何组织的？
- 如何评估一个 Skill 的好坏？
- Skills 如何与 MCP 配合使用？
- 如何避免 Skills 的上下文污染问题？
- 上下文装不下的情况怎么处理？“相关 Skill”怎么判断——关键词匹配还是语义匹配？
- 语义匹配出了问题（误加载或漏加载）怎么兜底？
- 上下文信噪比怎么量化评估？精简上下文 vs 全量上下文怎么对比？
- RAG 检索到了但生成跑偏，根因在哪？怎么优化分块策略和拼接方式？
- 高并发下分层加载有没有性能瓶颈？嵌入模型调用延迟怎么控制？
- 第三方 Skill 的安全风险怎么评估？如何防范提示注入？