1. 前言
最近在学习和开发 AI Agent 的过程中，我发现一个很容易和 Tool、MCP、System Prompt 混淆的概念：Skill。
很多 Agent 系统都会同时出现 Tool、Skill、MCP、Workflow 等概念。刚开始接触时，很容易把 Skill 理解成"另一个 Tool"，或者认为 Skill 只是 System Prompt 的一个别名。
但实际上，它们解决的问题并不相同。
一个简单的理解是：
Tool 解决"Agent 能做什么"，Skill 解决"Agent 如何完成一类任务"。
例如，一个 Agent 需要回答"帮我分析最近 AI Agent 的技术发展"：
-
Web Search Tool：负责搜索网页
-
Fetch Tool：负责获取网页内容
-
Knowledge Base Tool：负责检索本地知识
-
Skill：负责规定什么时候搜索、怎么搜索、如何整理结果、是否需要引用、如何生成最终回答
因此，Skill 并不是一个孤立的工具，而更像是一个可复用的任务能力模块。
本文将从 Tool、Prompt、MCP、Skill 四个概念开始，逐步介绍 Skill 的作用，以及如何在一个个人知识库 Agent 中设计 Skill。
2. Skill 到底是什么？
先给出一个定义：
Skill 是对某一类任务所需的知识、规则、流程和工具调用方式进行封装后形成的可复用能力模块。
这里有几个关键词：
-
任务类型
-
规则
-
流程
-
工具
-
可复用
例如，我们可以设计一个：
WebSearch Skill它并不一定自己去访问互联网，而是告诉 Agent：
什么时候应该搜索？
搜索什么？
如何选择关键词？
需要调用几个搜索工具？
如何处理搜索结果？
最终答案是否需要引用？底层真正完成搜索工作的，还是：
WebSearch Tool因此可以把它简单抽象成：
Skill
↓
任务规则 + 执行流程 + Tool 使用规范
↓
Tool
↓
实际执行动作3. 为什么有了 Tool，还需要 Skill？
这是理解 Skill 最关键的问题。
假设我们给 Agent 提供三个工具：
search_web()
search_knowledge_base()
read_document()从能力上看，Agent 已经什么都能做了。
但用户提出：
"帮我看看最近 AI Agent 中 MCP 的发展情况，并结合我自己的知识库分析一下。"
Agent 现在面临的问题不是"没有工具"，而是：
应该怎么组合工具完成任务？
例如它可能选择：
search_knowledge_base()
↓
发现知识库没有最新信息
↓
search_web()
↓
read_document()
↓
整理答案也可能直接：
search_web()
↓
整理答案甚至可能：
search_knowledge_base()
↓
search_knowledge_base()
↓
search_knowledge_base()不断重复调用。
这说明：
Tool 只是提供能力，并不能天然决定复杂任务的执行策略。
这就是 Skill 的价值。
4. Tool、Skill、Agent 三者的关系
可以用一个简单的分层方式理解。
Agent
│
决定当前任务是什么
│
▼
Skill
任务规则 + 执行策略
│
┌─────────┼─────────┐
▼ ▼ ▼
Tool Tool Tool
│ │ │
▼ ▼ ▼
搜索网页 查询数据库 读取文件例如：
用户：
"总结一下我知识库中的 Go 并发相关内容"Agent 判断：
这是"知识库总结任务"于是加载：
KnowledgeSummary SkillSkill 再规定：
1. 优先检索知识库
2. 获取相关文档
3. 对多个文档进行归纳
4. 避免凭空补充知识库中没有的内容
5. 输出总结并附带引用然后调用：
KnowledgeBaseSearch Tool
DocumentRead Tool所以：
Agent 负责决策，Skill 负责方法，Tool 负责执行。
5. Skill 和 System Prompt 有什么区别？
很多人第一次接触 Skill 时都会产生一个问题：
"这些规则直接放到 System Prompt 不就行了吗？"
从功能上来说，当然可以。
例如直接把所有规则写进 System Prompt：
你是一个个人知识库 Agent。
如果用户询问个人知识：
优先查询知识库。
如果用户询问实时信息：
优先使用联网搜索。
如果需要阅读完整文档：
调用文档读取工具。
回答知识库问题时必须提供引用。
......随着 Agent 能力增加，System Prompt 很容易越来越长：
System Prompt
├── 知识库检索规则
├── 网页搜索规则
├── 文档总结规则
├── 数据分析规则
├── SQL 规则
├── 报告生成规则
├── MCP Tool 使用规则
├── 错误处理规则
└── ...最终会出现两个问题。
5.1 Prompt 越来越庞大
所有能力都塞进去，导致上下文越来越长。
5.2 所有能力都被同时加载
用户只是让 Agent 总结一份文档，却把联网搜索、SQL 分析、代码生成等大量规则全部带进去。
Skill 的一个重要思想就是：
将能力拆分，在需要时加载。
例如：
System Prompt
↓
识别用户任务
↓
选择 Skill
↓
加载对应规则
↓
执行任务这样就从：
一个超大的 Prompt变成：
基础 Prompt
+
按需加载的 Skill6. Skill 和 MCP 有什么区别？
Skill 和 MCP 经常一起出现，因此很容易混淆。
实际上，两者处于不同层次。
MCP 更关注"怎么接入工具"
MCP 可以理解成一种标准化的工具接入方式。
例如 Agent 想使用：
GitHub
数据库
搜索引擎
文件系统
第三方 API可以通过 MCP Server 对外提供 Tool。
结构可以理解成：
Agent
│
MCP Client
│
MCP Server
│
Tool
│
真实服务MCP 解决的是：
Agent 怎么发现和调用外部能力。
Skill 更关注"怎么完成任务"
Skill 解决的是：
当我要完成某一类任务时，应该采用什么策略。
因此：
MCP = 能力接入机制
Tool = 原子执行能力
Skill = 任务执行方法
Agent = 决策与编排它们不是互斥关系，反而可以一起使用。
例如：
Web Search Skill
│
▼
MCP Client
│
▼
Web Search MCP
│
▼
Search Tool这里 Skill 负责"搜索策略"，MCP 负责"工具接入"。
7. 一个实际例子：个人知识库 Agent
假设我们正在开发一个个人知识库 Agent。
它拥有两个核心工具：
KnowledgeBaseSearch
WebSearch用户输入：
"什么是 RAG？另外帮我看看 2026 年 RAG 有哪些新的应用方向。"
这其实包含了两个不同性质的问题：
什么是 RAG？
↓
本地知识问题
2026 年有哪些新的应用方向？
↓
实时信息问题如果没有 Skill，模型可能：
先调用知识库
↓
发现没有最新资料
↓
再调用 Web Search甚至可能反复尝试知识库。
7.1 可以定义两个 Skill
Knowledge Q&A Skill
适用于：
用户询问个人知识库中的内容。
执行规则：
1. 优先检索知识库
2. 根据查询内容生成检索关键词
3. 获取相关文档片段
4. 基于检索结果回答
5. 输出引用
6. 不编造知识库不存在的内容Web Research Skill
适用于：
涉及实时信息、新闻、最新资料的问题。
执行规则：
1. 判断问题是否需要实时信息
2. 构造搜索关键词
3. 调用 Web Search
4. 筛选相关结果
5. 必要时读取原文
6. 整理多个来源
7. 生成带引用的回答这样 Agent 就不需要"每次从零思考应该怎么做"。
8. Skill 可以不仅仅包含 Prompt
这是理解 Skill 时另一个非常重要的点。
如果把 Skill 理解成：
"一段额外的 Prompt"
实际上还是太简单。
一个完整 Skill 可以包含：
Skill
├── Description
├── Instruction
├── Workflow
├── Tool Selection
├── Constraints
├── Output Format
└── Examples例如：
name: web_research
description: >
用于需要实时信息的研究型任务
instructions:
- 判断用户问题是否涉及实时信息
- 优先使用搜索工具
- 对多个来源进行交叉验证
- 输出关键结论和来源
tools:
- web_search
- page_reader
constraints:
- 不得把搜索不到的信息当作事实
- 最终答案必须说明来源所以 Skill 更准确地说是：
任务能力的结构化封装。
9. Skill 的核心价值：能力模块化
当 Agent 越来越复杂时，最重要的问题之一就是：
如何避免所有能力都堆在一个 Agent 里面？
例如一个大型 Agent 可能拥有：
知识库问答
网页搜索
文档总结
SQL 查询
代码分析
报告生成
数据分析
邮件处理如果全部依赖一个超大的 Prompt，维护会越来越困难。
可以拆成：
skills/
├── knowledge_qa/
├── web_research/
├── document_summary/
├── sql_analysis/
├── code_analysis/
└── report_generation/每个目录对应一种能力。
这样带来的一个明显好处就是：
Skill 可以独立开发、测试、迭代。
例如修改：
Web Research Skill不会影响：
Document Summary Skill10. Skill 与 Workflow 的区别
另一个容易混淆的概念是 Workflow。
可以简单理解：
Skill
= "怎么完成一类任务"
Workflow
= "这个任务具体按照什么步骤执行"例如：
报告生成 Skill告诉 Agent：
生成报告需要：
收集资料
分析资料
组织结构
生成正文
检查事实而 Workflow 则可能明确规定：
Step 1：搜索资料
Step 2：读取网页
Step 3：抽取事实
Step 4：生成大纲
Step 5：生成正文
Step 6：执行校验因此：
Skill
↓
定义能力和策略
Workflow
↓
定义具体执行流程Skill 可以包含 Workflow，但二者并不是完全等价的。
11. Skill 如何参与 Agent 决策？
一个比较典型的实现方式是：
User Query
↓
Task Classification
↓
Skill Selection
↓
Skill Loading
↓
Tool Selection
↓
Execution
↓
Result Processing
↓
Final Answer例如：
用户：
"总结我上传的这份 Redis 文档"Agent 判断：
Task = Document Summary选择：
DocumentSummary Skill然后 Skill 告诉 Agent：
1. 读取完整文档
2. 提取章节结构
3. 总结核心概念
4. 保留关键技术细节
5. 输出分层结构然后调用：
DocumentRead Tool最终生成：
总结结果12. Skill 如何解决工具路由问题？
在实际开发 Agent 的时候，一个很常见的问题就是：
Agent 明明知道有 Web Search，却经常先调用知识库工具。
例如：
用户：
"今天有哪些 AI Agent 新闻？"Agent 可能：
KnowledgeBaseSearch
↓
没有结果
↓
WebSearch这虽然最终可能得到正确答案，但存在两个问题：
-
多调用了一次工具
-
增加了延迟和 Token 消耗
更严重的是，如果知识库工具执行成本比较高，问题会更加明显。
这时候可以通过 Skill 明确路由策略。
例如：
Realtime Research Skill
适用条件：
- 新闻
- 今日
- 最近
- 最新
- 当前价格
- 当前政策
- 实时数据
规则：
遇到以上类型问题时，优先使用 Web Search。
不要先尝试 Knowledge Base Search。于是：
用户问题
↓
是否属于实时研究？
↓
是
↓
Realtime Research Skill
↓
Web Search这样可以把"工具选择逻辑"从一个模糊的模型决策变成更加明确的任务策略。
13. Skill 是否一定要由 LLM 选择？
不一定。
这是实际系统设计时非常重要的一点。
可以采用：
LLM Router让模型判断：
Knowledge QA
Web Research
Document Summary
Code Analysis也可以采用：
Rule Router例如：
包含"今天""最新""最近"
→ WebResearch Skill
包含"我的知识库""我上传的文档"
→ Knowledge Skill还可以使用：
Rule + LLM Hybrid例如：
第一层：
规则判断明显场景
第二层：
复杂问题交给 LLM 分类
第三层：
进入对应 Skill对于生产系统来说，这种方式通常更容易控制成本和稳定性。
14. Skill 的另一个价值：约束 Agent
Skill 不只是让 Agent "知道怎么做"，还可以用于限制 Agent "不能怎么做"。
例如：
SQL Analysis Skill可以规定：
只允许 SELECT
禁止 UPDATE
禁止 DELETE
禁止 DROP
单次查询最多返回 1000 行
超过限制必须分页再比如：
Knowledge Base Skill可以规定：
没有检索结果：
不能直接编造答案
有检索结果：
优先依据检索内容回答
需要引用：
必须保留来源信息因此 Skill 其实还承担了一部分：
任务级安全约束和行为规范
15. Skill 的一个简单数据结构
如果自己设计 Skill 系统，可以从非常简单的结构开始。
例如：
type Skill struct {
Name string
Description string
Instructions string
Tools []string
}例如：
webSearchSkill := Skill{
Name: "web_research",
Description: "处理需要实时信息的研究任务",
Instructions: `
1. 判断问题是否需要实时信息
2. 优先使用 Web Search
3. 必要时读取网页原文
4. 综合多个来源
5. 输出引用
`,
Tools: []string{
"web_search",
"page_reader",
},
}Agent 运行时：
skill := skillManager.Get("web_research")
prompt := basePrompt + skill.Instructions再让 Agent 使用：
skill.Tools对应的工具即可。
当然，真正复杂的系统还会加入：
Version
Metadata
Dependencies
Permissions
Examples
Workflow
OutputSchema但对于一个 MVP 来说，没有必要一开始就设计得特别复杂。
16. 一个更完整的 Skill 架构
如果进一步扩展，可以设计成：
Agent
│
Skill Router
│
┌───────────┼───────────┐
▼ ▼ ▼
Knowledge Research Summary
Skill Skill Skill
│ │ │
└───────────┼───────────┘
▼
Tool Manager
│
┌──────────────┼──────────────┐
▼ ▼ ▼
KB Search Web Search File Read
│ │ │
└──────────────┼──────────────┘
▼
Tools如果工具来自外部系统：
Skill
↓
Tool Manager
↓
MCP Client
↓
MCP Server
↓
External Tool这样 Skill 和 MCP 就可以自然结合起来。
17. Skill 的设计原则
在实际开发中，我认为有几个原则比较重要。
17.1 一个 Skill 聚焦一种任务
不要设计一个：
万能 Skill同时负责：
搜索
总结
代码分析
SQL
知识库问答应该拆成多个能力模块。
17.2 Skill 描述"方法"，Tool 描述"动作"
例如：
Tool：
search_web(query)而 Skill 描述：
什么时候搜索
怎么构造 query
搜索几个来源
怎么筛选结果
什么时候停止搜索
如何引用这样职责更清晰。
17.3 Skill 不应该过度依赖某一个 Agent
一个好的 Skill 应该尽可能做到：
Agent A 可以使用
Agent B 也可以使用这也是 Skill 能够复用的原因。
17.4 Skill 中的规则应该尽可能明确
例如：
"适当地使用知识库"这种规则比较模糊。
更好的写法是：
涉及用户个人文档时，优先调用知识库检索工具。
涉及最新信息时，禁止优先调用知识库，
直接进入 Web Research 流程。规则越明确，Agent 的行为越容易稳定。
18. Skill 并不是越多越好
当 Skill 越来越多时，也会产生新的问题。
例如：
30 个 SkillAgent 需要从里面判断到底加载哪些。
如果 Skill 描述非常相似：
Knowledge Query
Knowledge QA
Knowledge Search
Knowledge Research模型反而更容易选错。
因此 Skill 系统同样需要考虑：
能力边界
名称设计
描述清晰度
优先级
依赖关系
冲突处理本质上，这其实已经进入：
Agent 能力管理和路由设计
19. 在我的个人知识库 Agent 中如何设计 Skill？
如果是一个类似个人知识库 Agent 的系统，我会优先拆成下面几个 Skill：
skills/
├── knowledge_qa
├── web_research
├── document_summary
├── knowledge_compare
└── report_generationKnowledge QA
负责：
个人知识查询
知识库检索
引用
多轮上下文Web Research
负责：
实时信息
联网搜索
网页阅读
多来源整合Document Summary
负责：
长文档总结
章节归纳
重点提取
结构化输出Knowledge Compare
负责：
多个知识来源对比
差异分析
优缺点整理Report Generation
负责：
资料收集
结构规划
内容生成
引用整理
最终报告这样整个 Agent 就从：
一个什么都能做的大模型逐渐变成：
基础 Agent
+
多个可组合 Skill
+
统一 Tool 层20. 最终理解：Skill 到底是什么？
学到这里，可以把几个概念放在一起：
Prompt
↓
告诉模型"应该怎么表现"
Tool
↓
提供一个具体动作
MCP
↓
标准化 Tool 的发现和调用
Skill
↓
封装一类任务的知识、规则和执行策略
Workflow
↓
定义任务具体按照哪些步骤执行
Agent
↓
根据用户任务进行决策、规划和执行用一个生活中的例子来类比：
Tool = 一把锤子
Skill = 木工技能
Workflow = 做一张桌子的具体步骤
MCP = 标准化工具接口
Agent = 木匠木匠不是因为"拥有锤子"就会做桌子。
真正决定他能不能完成任务的，是：
知道什么时候用锤子
知道什么时候用电钻
知道先做哪一步
知道什么时候检查
知道最终应该达到什么结果这部分能力，就非常接近 Skill 的概念。
21. 总结
Skill 的核心并不是"多了一层 Prompt"，而是：
把 Agent 完成某一类任务所需要的知识、规则、工具和执行策略封装成一个独立、可复用的能力模块。
因此可以记住下面这句话：
Tool 负责"做什么"
Skill 负责"怎么做"
MCP 负责"怎么接入 Tool"
Workflow 负责"按什么步骤做"
Agent 负责"什么时候做、做什么"对于简单 Agent，Skill 甚至可以只是：
Instructions + Tools但随着系统复杂度提升，它最终可以演化成：
Skill
├── Instruction
├── Tool
├── Workflow
├── Constraint
├── Output Schema
└── Examples这也是为什么在复杂 Agent 系统中，Skill 更适合作为能力模块化和任务路由的抽象层，而不是简单地把它理解成一个 Tool。
对于正在构建个人知识库 Agent、RAG Agent 或 MCP Agent 的开发者来说，一个值得实践的方向就是：
Agent
↓
Skill Router
↓
Skill
↓
Tool / MCP
↓
Execution当 Agent 从"能调用工具"进一步发展到"知道如何稳定地完成任务"时，Skill 就开始体现它真正的价值。