在上一章中，我们已经详细介绍了 MCP（Model Context Protocol）。通过 MCP，智能体终于可以用一种标准、统一的方式，去访问数据库、文件系统、API 服务等外部世界的资源。

换句话说，MCP 解决了一个长期困扰智能体的问题：
👉 “我怎么和真实世界连起来？”

来看一个最常见的使用场景：

from hello_agents import ReActAgent, HelloAgentsLLM
from hello_agents.tools import MCPTool
llm = HelloAgentsLLM()
agent = ReActAgent(name="数据分析助手", llm=llm)
# 连接到数据库 MCP 服务器
db_mcp = MCPTool(server_command=["python", "database_mcp_server.py"])
agent.add_tool(db_mcp)
# 智能体现在可以访问数据库了
response = agent.run("查询员工表中薪资最高的前10名员工")

这段代码非常漂亮：

• 智能体启动
• 通过 MCP 连上数据库
• 成功完成查询

一切看起来都很完美。

但问题往往出现在“第二步”。

当任务开始变复杂

现在，我们把问题稍微升级一点：

response = agent.run("""
分析公司内部谁的话语权最高？
需要综合考虑：
1. 管理层级和下属数量
2. 薪资水平和涨薪幅度
3. 任职时长和稳定性
4. 跨部门影响力
""")

这个问题表面上是“数据分析”，但实际上隐含了大量复杂决策：

• 需要多次 SQL 查询
• 后一次查询要根据前一次结果动态调整
• 需要知道什么叫“话语权”
• 需要把多个维度的数据组合成一个合理的评价体系

这时，很多开发者都会发现：
智能体虽然“连得上数据库”，但并不会“用数据库”。

问题主要集中在两个方面。

两个绕不开的核心问题

问题一：上下文爆炸（Context Explosion）

为了让智能体“什么都能查”，MCP 服务器通常会暴露大量工具：

• 不同表
• 不同查询方式
• 不同参数组合

这些工具的 完整 JSON Schema，会在连接时一次性加载进系统提示词。

社区里有个非常真实的反馈：

仅加载一个 Playwright MCP 服务器，就会占用 200k 上下文窗口的 8%

也就是说，你还没开始对话，token 已经先烧掉了一大截。

在多轮对话中，这种“急切加载”的模式会迅速导致：

• 成本上升
• 推理能力下降
• 上下文被工具定义淹没

问题二：能力鸿沟（Capability Gap）

更本质的问题是：

“能调用工具” ≠ “知道如何使用工具”

MCP 解决的是连接问题，但它并不教智能体：

• SQL 应该怎么写才高效、安全
• 哪些字段代表“当前状态”
• 公司内部有哪些隐含规则和最佳实践

这就像什么呢？

👉 给一个新手程序员开通了所有系统权限，但没给文档、没给规范、没给 SOP。

他“什么都能点”，但不知道“该点什么”。

Agent Skills：补上“知道怎么做”的那一层

这正是 Agent Skills 出现的背景。

2025 年初，在 MCP 推出之后，Anthropic 又提出了一个新概念：Agent Skills。

社区里对它的评价非常直接：

Skills 是领域知识，本质是高级 Prompt
MCP 是工具连接，是基础设施

也有人说得更形象：

MCP 给你“手”，Skills 教你“怎么用这双手干活”

那么，Agent Skills 到底是什么？

什么是 Agent Skills？

一个一句话定义

Agent Skills 是一种标准化的“程序性知识封装”。

如果说：

• MCP 是 USB 接口、驱动程序
• 那 Skills 就是使用说明书、操作手册、SOP

你可以有世界上最先进的打印机驱动（MCP），
但如果没人告诉你：

• 怎么设置双面打印
• 怎么调整页边距
• 怎么批量输出

那你依然效率低下。

职责分离：连接 vs 能力

Agent Skills 的设计背后，有一个非常重要的思想：

连接性（Connectivity）与能力（Capability）必须分离

• MCP 的职责
  👉 让智能体“够得着”外部世界
• Skills 的职责
  👉 告诉智能体“在什么场景下，该如何组合使用这些工具”

这带来了非常清晰的架构分层，也为后面的扩展打下了基础。

渐进式披露：解决上下文困境的关键

Agent Skills 最核心的技术创新，不是“写 Prompt”，而是:

渐进式披露（Progressive Disclosure）

简单说就是一句话：
需要多少，给多少；不用的，先别塞进上下文。

三层结构，一步步加载

第一层：元数据（Metadata）

每个 Skill 都放在一个独立目录中，核心文件叫 SKILL.md。

这个文件开头是 YAML Frontmatter，例如：

name: mysql-employees-analysis
description: 将中文业务问题转换为 SQL 并分析员工数据库
tags: [database, sql, analysis]

智能体启动时：

• 只读取这一小段
• 不加载具体指令、不加载示例、不加载脚本

实测下来：

• 每个 Skill 约 100 token
• 50 个 Skill 也只要 5000 token

对比 MCP 的“一上来全给”，这是巨大的差异。

第二层：技能主体（Instructions）

当智能体判断：

“这个任务，和这个 Skill 强相关”

才会加载完整的 SKILL.md 内容，包括：

• 工作流程
• 注意事项
• 示例

这一步，智能体才真正“学会怎么干活”。

第三层：附加资源（Scripts & References）

更复杂的 Skill，还可以携带：

• 脚本
• 模板
• 大型文档

例如：

skills/pdf-processing/
├── SKILL.md
├── parse_pdf.py
├── forms.md
└── templates/

这些资源：

• 只有在真正需要时才加载
• 大文件通过脚本访问，而不是塞进上下文

两个非常关键的优势

1️⃣ 知识容量几乎无限
Skill 可以“携带”1GB 的数据，只要不直接塞进 Prompt。

2️⃣ 确定性执行
复杂逻辑交给代码，避免 LLM 幻觉。

MCP vs Agent Skills：到底差在哪？

一句话总结：

MCP 解决“能不能”，Skills 解决“该不该、怎么做”

---

一个代码审查的例子

MCP 能做什么？

# 连接 GitHub
github_mcp = MCPTool(server_command=["npx", "-y", "@modelcontextprotocol/server-github"])

它暴露了一堆工具：

• list PR
• get PR detail
• comment PR

但它不知道：

• 审查流程是什么
• 公司代码规范是什么
• 什么算严重问题

Skills 做了什么？

Skills 会明确告诉智能体：

• 先做什么
• 重点看什么
• 什么情况必须评论
• 公司特定规则是什么

它本质上就是一份“代码审查 SOP”。

最佳实践：Skills + MCP 的混合架构

结论其实非常明确：

Skills 和 MCP 不是竞争关系，而是天然互补

一个典型流程是：

1. 用户提出业务问题
2. Skills 判断任务类型，加载对应技能
3. Skills 拆解步骤
4. MCP 执行具体工具调用
5. Skills 负责解读与总结

总结一句话

• MCP：让智能体“有手有脚”
• Agent Skills：让智能体“会干活、干对活”

真正强大的智能体，一定是：

MCP 提供能力，Skills 提供智慧

如果你在做企业级智能体，这不是“可选项”，而是必选架构。

技术实现：如何创建和使用 Skills

SKILL.md 规范详解

让我们深入了解 SKILL.md 文件的标准结构：

---
# === 必需字段 ===
name: skill-name
# 技能的唯一标识符，使用 kebab-case 命名
description: >
简洁但精确的描述，说明：
1. 这个技能做什么
2. 什么时候应该使用它
3. 它的核心价值是什么
# 注意：description 是智能体选择技能的唯一依据，必须写清楚！
# === 可选字段 ===
version: 1.0.0
# 语义化版本号
allowed_tools: [tool1, tool2]
# 此技能可以调用的工具列表（白名单）
required_context: [context_item1]
# 此技能需要的上下文信息
license: MIT
# 许可协议
author: Your Name <email@example.com>
# 作者信息
tags: [database, analysis, sql]
# 便于分类和搜索的标签
---
# 技能标题
## 概述
（对技能的详细介绍，包括使用场景、技术背景等）
## 前置条件
（使用此技能需要的环境配置、依赖项等）
## 工作流程
（详细的步骤说明，告诉智能体如何执行任务）
## 最佳实践
（经验总结、注意事项、常见陷阱等）
## 示例
（具体的使用案例，帮助智能体理解）
## 故障排查
（常见问题和解决方案）

编写高质量 Skills 的原则

根据 Anthropic 官方文档和社区最佳实践，编写有效的 Skills 需要遵循以下原则：

1. 精准的 Description

description 是智能体决策的关键。它应该：

• 精确定义适用范围

  避免模糊的描述如"帮助处理数据"

• 包含触发关键词

  让智能体能够匹配用户意图

• 说明独特价值

  与其他技能区分开来

❌ 不好的 description：

description
: 
处理数据库查询

✅ 
好的 description
：

description
: 
>
  将中文业务问题转换为 SQL 查询并分析 MySQL employees 示例数据库。
  适用于员工信息查询、薪资统计、部门分析、职位变动历史等场景。
  当用户询问关于员工、薪资、部门的数据时使用此技能。2. 模块化与单一职责

一个 Skill 应该专注于一个明确的领域或任务类型。如果一个 Skill 试图做太多事情，会导致：

• Description 过于宽泛，匹配精度下降
• 指令内容过长，浪费上下文
• 难以维护和更新

建议：与其创建一个"通用数据分析"技能，不如创建多个专门的技能：

• mysql-employees-analysis

  专门分析 employees 数据库

• sales-data-analysis

  专门分析销售数据

• user-behavior-analysis

  专门分析用户行为数据

3. 确定性优先原则

对于复杂的、需要精确执行的任务，优先使用脚本而不是依赖 LLM 生成。例如，在数据导出场景中，与其让 LLM 生成 Excel 二进制内容（容易出错），不如编写一个专门的脚本来处理这个任务，SKILL.md 中只需要指导智能体何时调用这个脚本即可。

4. 渐进式披露策略

合理利用三层结构，将信息按重要性和使用频率分层：

• SKILL.md 主体

  放置核心工作流、常用模式

• 附加文档

  （如 advanced.md）：放置高级用法、边缘情况

• 数据文件

  放置大型参考数据，通过脚本按需查询

实践案例：MySQL 员工分析 Skill 详解

让我们通过 Anthropic 社区的一个真实案例，了解 Agent Skills 的具体应用。这个技能用于分析 MySQL 官方的 employees 示例数据库。

技能文件结构

skills/mysql-employees-analysis/ ├── SKILL.md # 主技能文件（包含元数据和详细指令） └── db_schema.sql # 数据库结构参考（可选，按需加载）

SKILL.md 核心内容示例

这个技能的 Frontmatter（元数据层）：

---
name: mysql-employees-analysis
description: >
将中文业务问题转换为 SQL 查询并分析 MySQL employees 示例数据库。
适用于员工信息查询（如"工号12345的员工信息"）、
薪资统计（如"平均薪资最高的部门"）、
部门分析（如"各部门人数分布"）、
职位变动历史（如"某员工的晋升路径"）等场景。
version: 1.0.0
allowed_tools: [execute_sql]
tags: [database, mysql, sql, employees, analysis]
---
# MySQL 员工数据库分析技能
## 概述
这个技能专门用于分析 MySQL 官方提供的 `employees` 示例数据库。
该数据库包含约 300,000 名虚拟员工的记录，涵盖 2020-2025 年的数据。
**核心能力**：
- 理解中文自然语言的业务问题
- 转换为高效的 SQL 查询
- 执行查询并解读结果
- 提供业务洞察和数据解读
## 数据库结构
### 核心表结构
| 表名           | 说明         | 关键字段                                                     |
| -------------- | ------------ | ------------------------------------------------------------ |
| `employees`    | 员工基本信息 | emp_no, birth_date, first_name, last_name, gender, hire_date |
| `salaries`     | 薪资历史     | emp_no, salary, from_date, to_date                           |
| `titles`       | 职位历史     | emp_no, title, from_date, to_date                            |
| `dept_emp`     | 员工部门关系 | emp_no, dept_no, from_date, to_date                          |
| `dept_manager` | 部门经理     | emp_no, dept_no, from_date, to_date                          |
| `departments`  | 部门信息     | dept_no, dept_name                                           |
### 关键约定
⚠️ **重要**：`to_date = '9999-01-01'` 表示"当前有效"的记录。
查询"当前"状态时（如现任员工、当前薪资），必须加此过滤条件。
完整的表结构参见：`db_schema.sql`
## 工作流程
### 第一步：理解需求
仔细分析用户的中文描述，识别：
- **查询目标**：要查什么数据？（员工、薪资、部门...）
- **筛选条件**：有什么限制？（特定部门、时间范围、薪资区间...）
- **聚合维度**：需要统计吗？（平均值、总数、排名...）
- **时间范围**：是历史数据还是当前状态？
### 第二步：构建 SQL
根据需求选择合适的查询模式（见下方"常见查询模式"）。
**编写原则**：
1. 使用明确的表别名（如 `e` for employees）
2. JOIN 时优先使用主键/外键
3. 注意日期过滤（特别是 `to_date`）
4. 合理使用索引字段
5. 大结果集要加 LIMIT
### 第三步：执行查询
调用 `execute_sql` 工具执行构建好的 SQL。
```python
# 示例调用（智能体会自动转换为工具调用）
result = execute_sql(query="SELECT ...")
### 第四步：解读结果
将查询结果转化为自然语言回答：
- 用表格呈现结构化数据
- 突出关键数据点
- 提供业务洞察（如趋势、异常）
- 如果结果为空，说明可能的原因
## 常见查询模式
### 模式 1：基础信息查询
-- 查询特定员工的基本信息
SELECT emp_no, CONCAT(first_name, ' ', last_name) AS full_name,
gender, birth_date, hire_date
FROM employees
WHERE emp_no = <员工号>;
### 模式 2：当前状态查询
-- 查询当前薪资最高的员工（TOP 10）
SELECT e.emp_no,
CONCAT(e.first_name, ' ', e.last_name) AS name,
s.salary
FROM employees e
JOIN salaries s ON e.emp_no = s.emp_no
WHERE s.to_date = '9999-01-01'  -- 当前薪资
ORDER BY s.salary DESC
LIMIT 10;
### 模式 3：历史趋势分析
-- 查询某员工的薪资变化历史
SELECT emp_no, salary, from_date, to_date,
salary - LAG(salary) OVER (ORDER BY from_date) AS increase
FROM salaries
WHERE emp_no = <员工号>
ORDER BY from_date;
### 模式 4：跨表关联查询
-- 查询各部门的平均薪资（当前）
SELECT d.dept_name,
COUNT(DISTINCT de.emp_no) AS emp_count,
ROUND(AVG(s.salary), 2) AS avg_salary
FROM departments d
JOIN dept_emp de ON d.dept_no = de.dept_no
JOIN salaries s ON de.emp_no = s.emp_no
WHERE de.to_date = '9999-01-01'  -- 当前在职
AND s.to_date = '9999-01-01'   -- 当前薪资
GROUP BY d.dept_name
ORDER BY avg_salary DESC;
### 模式 5：复杂业务分析
-- 分析"话语权"：综合管理层级、薪资、任职时长
WITH manager_hierarchy AS (
-- 统计每个经理管理的下属数
SELECT dm.emp_no, COUNT(de.emp_no) AS subordinate_count
FROM dept_manager dm
JOIN dept_emp de ON dm.dept_no = de.dept_no
WHERE dm.to_date = '9999-01-01'
AND de.to_date = '9999-01-01'
AND de.emp_no != dm.emp_no
GROUP BY dm.emp_no
),
current_salary AS (
-- 当前薪资
SELECT emp_no, salary
FROM salaries
WHERE to_date = '9999-01-01'
),
tenure AS (
-- 任职时长（年）
SELECT emp_no,
TIMESTAMPDIFF(YEAR, hire_date, CURDATE()) AS years_employed
FROM employees
)
SELECT e.emp_no,
CONCAT(e.first_name, ' ', e.last_name) AS name,
COALESCE(mh.subordinate_count, 0) AS team_size,
cs.salary,
t.years_employed,
-- 简单的话语权评分（可根据业务调整权重）
(COALESCE(mh.subordinate_count, 0) * 10 +
cs.salary / 1000 +
t.years_employed * 5) AS influence_score
FROM employees e
JOIN current_salary cs ON e.emp_no = cs.emp_no
JOIN tenure t ON e.emp_no = t.emp_no
LEFT JOIN manager_hierarchy mh ON e.emp_no = mh.emp_no
WHERE cs.salary > 60000  -- 过滤低薪员工
ORDER BY influence_score DESC
LIMIT 20;
## 注意事项
### ⚠️ 时间字段的正确处理
- <strong>当前状态</strong>：必须使用 `to_date = '9999-01-01'` 过滤
- <strong>历史查询</strong>：注意 `from_date` 和 `to_date` 的范围
- <strong>时间计算</strong>：使用 `TIMESTAMPDIFF`、`DATEDIFF` 等函数
### ⚠️ 性能优化
- <strong>大表 JOIN</strong>：优先使用索引字段（emp_no, dept_no）
- <strong>聚合查询</strong>：合理使用 GROUP BY 和 HAVING
- <strong>结果限制</strong>：对于展示类查询，添加 LIMIT 限制
- <strong>子查询优化</strong>：复杂查询使用 WITH (CTE) 提高可读性和性能
### ⚠️ 数据质量
- <strong>NULL 值处理</strong>：使用 COALESCE 或 IFNULL 处理空值
- <strong>重复记录</strong>：注意员工可能多次调岗，查询时考虑去重
- <strong>数据范围</strong>：数据库只包含 1985-2000 年的数据，查询时注意时间边界
## 故障排查
<strong>问题 1：查询结果为空</strong>
- 检查是否正确使用了 `to_date = '9999-01-01'`
- 验证员工号或部门号是否存在
- 检查日期范围是否合理
<strong>问题 2：查询速度慢</strong>
- 检查是否缺少索引字段的 WHERE 条件
- 考虑将复杂查询拆分为多步
- 使用 EXPLAIN 分析查询计划
<strong>问题 3：统计数据不准确</strong>
- 注意区分"历史"和"当前"状态
- 检查 JOIN 条件是否遗漏
- 验证聚合函数的使用是否正确

技能的使用效果

当用户向支持 Agent Skills 的智能体（如 Claude Desktop、Claude Code）提问时：

用户问题：

“分析公司内部谁的话语权最高？需要综合考虑管理层级、薪资水平和任职时长。”

---

AI时代，未来的就业机会在哪里？

答案就藏在大模型的浪潮里。从ChatGPT、DeepSeek等日常工具，到自然语言处理、计算机视觉、多模态等核心领域，技术普惠化、应用垂直化与生态开源化正催生Prompt工程师、自然语言处理、计算机视觉工程师、大模型算法工程师、AI应用产品经理等AI岗位。

掌握大模型技能，就是把握高薪未来。

那么，普通人如何抓住大模型风口？

AI技术的普及对个人能力提出了新的要求，在AI时代，持续学习和适应新技术变得尤为重要。无论是企业还是个人，都需要不断更新知识体系，提升与AI协作的能力，以适应不断变化的工作环境。

因此，这里给大家整理了一份《2026最新大模型全套学习资源》，包括2026最新大模型学习路线、大模型书籍、视频教程、项目实战、最新行业报告、面试题、AI产品经理入门到精通等，带你从零基础入门到精通，快速掌握大模型技术！

由于篇幅有限，有需要的小伙伴可以扫码获取！

1. 成长路线图&学习规划

要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。这里，我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。

2. 大模型经典PDF书籍

书籍和学习文档资料是学习大模型过程中必不可少的，我们精选了一系列深入探讨大模型技术的书籍和学习文档，它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。（书籍含电子版PDF）

3. 大模型视频教程

对于很多自学或者没有基础的同学来说，书籍这些纯文字类的学习教材会觉得比较晦涩难以理解，因此，我们提供了丰富的大模型视频教程，以动态、形象的方式展示技术概念，帮助你更快、更轻松地掌握核心知识。

4. 大模型项目实战

学以致用 ，当你的理论知识积累到一定程度，就需要通过项目实战，在实际操作中检验和巩固你所学到的知识，同时为你找工作和职业发展打下坚实的基础。

5. 大模型行业报告

行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

6. 大模型面试题

面试不仅是技术的较量，更需要充分的准备。

在你已经掌握了大模型技术之后，就需要开始准备面试，我们将提供精心整理的大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

为什么大家都在学AI大模型？

随着AI技术的发展，企业对人才的需求从“单一技术”转向 “AI+行业”双背景。企业对人才的需求从“单一技术”转向 “AI+行业”双背景。金融+AI、制造+AI、医疗+AI等跨界岗位薪资涨幅达30%-50%。

同时很多人面临优化裁员，近期科技巨头英特尔裁员2万人，传统岗位不断缩减，因此转行AI势在必行！

这些资料有用吗？

这份资料由我们和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

大模型全套学习资料已整理打包，有需要的小伙伴可以微信扫描下方CSDN官方认证二维码，免费领取【保证100%免费】