Agent Skills 智能体技能

使用MCP处理复杂问题时可能会存在的问题：第一个问题是上下文爆炸。为了让智能体能够灵活查询数据库，MCP 服务器通常会暴露数十甚至上百个工具（不同的表、不同的查询方法）。这些工具的完整 JSON Schema 在连接建立时就会被加载到系统提示词中，可能占用数万个 token。据社区开发者反馈，仅加载一个 Playwright MCP 服务器就会占用 200k 上下文窗口的 8%，这在多轮对话中会迅

壮Sir不壮

577人浏览 · 2026-01-30 09:30:00

壮Sir不壮 · 2026-01-30 09:30:00 发布

互补而非竞争：Skills + MCP 的混合架构

Agent Skills

前言

使用MCP处理复杂问题时可能会存在的问题：

第一个问题是上下文爆炸。为了让智能体能够灵活查询数据库，MCP 服务器通常会暴露数十甚至上百个工具（不同的表、不同的查询方法）。这些工具的完整 JSON Schema 在连接建立时就会被加载到系统提示词中，可能占用数万个 token。据社区开发者反馈，仅加载一个 Playwright MCP 服务器就会占用 200k 上下文窗口的 8%，这在多轮对话中会迅速累积，导致成本飙升和推理能力下降。

第二个问题是能力鸿沟。MCP 解决了"能够连接"的问题，但没有解决"知道如何使用"的问题。拥有数据库连接能力，不等于智能体知道如何编写高效且安全的 SQL；能够访问文件系统，不意味着它理解特定项目的代码结构和开发规范。这就像给一个新手程序员开通了所有系统的访问权限，但没有提供操作手册和最佳实践。

这正是 Agent Skills 要解决的核心问题。2025年初，Anthropic 在推出 MCP 之后，进一步提出了 Agent Skills 的概念，引发了业界的广泛关注。有开发者评论说："Skills 和 MCP 是两种东西，Skills 是领域知识，告诉模型该如何做，本质上是高级 Prompt；而 MCP 对接外部工具和数据。" 也有人认为："从 Function Call 到 Tool Call 到 MCP 到 Skills，核心大差不差，就是工程实践和表现形式的优化演进。"

介绍Agent Skills

Agent 是智能体，Skills 是技能的意思，Agent Skills（智能体技能）是将专业知识、工作流规范固化为可复用资产的核心工具。

Agent Skills 本质上是一个模块化的 Markdown 文件，能教会 AI 工具（如 Claude、GitHub Copilot、Cursor 等）执行特定任务，且支持自动触发、团队共享与工程化管理，彻底告别重复的提示词输入。

Agent Skills 的本质不是工具，而是：行为规范 + 专业知识 + 使用时机的组合

可以把Agent Skills看作专业技能包，在大模型需要的时候才使用这些skill：

核心形式：

一个 Skill 就是一个文件夹，里面必须有一个 SKILL.md 文件（包含说明和元数据），可选其他资源文件（如脚本、示例、参考文档）。
Skill 是一个 Markdown 文件（SKILL.md），用于教 Claude 在特定场景下按你的方式做事。
本质是其实就是相当于给 AI 代理发放一本专业手册，AI 不会每次都从零学习，而是根据任务自动调用手册中的知识。
简单来说，过去我们用提示词（prompt）教 AI 做事，现在用 Agent Skills 可以把提示词 + 资源打包成可复用、可共享的技能包，更高效、更可靠。

SKILL.MD内容例子：

以前的做法是通过提示词，列出a、b、c来描述规则，该怎么做，问题是每次对话都会把这些提示词携带进去。上下文会越来越长，模型的注意力会被大量的规则和解释分散，不能聚焦于我们的核心业务。而skills：对于模型来说，可见的内容仅包含SkilI名称与描述。模型平时只知道"我有这项能力"，用于判断何时触发。而具体执行规则、调用方式与细节，只有在任务命中时，才会动态加载到上下文中。

优势：节省Token消耗，同时避免模型注意力被大量的无关规则稀释。

Agent Skills 的工作原理

Agent Skills 的关键是渐进式披露（可以理解为按需调用），分三层加载：

层级 1：技能发现 -- AI 先读取所有技能的元数据（name 和 description），判断任务是否相关，这些元数据始终在系统提示中。
层级 2：加载核心指令 -- 如果相关，AI 自动读取 SKILL.md 的正文内容，获取详细指导。
层级 3：加载资源文件 -- 只在需要时读取额外文件（如脚本、示例），或通过工具执行脚本。

SKILL文件夹

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]
  # 便于分类和搜索的标签
---

# 技能标题

## 概述
（对技能的详细介绍，包括使用场景、技术背景等）

## 前置条件
（使用此技能需要的环境配置、依赖项等）

## 工作流程
（详细的步骤说明，告诉智能体如何执行任务）

## 最佳实践
（经验总结、注意事项、常见陷阱等）

## 示例
（具体的使用案例，帮助智能体理解）

## 故障排查
（常见问题和解决方案）

资源文件

除了添加必要的SKILL.md 文件外，还可以添加Reference（参考）、Script（脚本）。SKILL.md文件是按需加载，Reference可以看作按需加载的按需加载，ai模型会判断是否要使用Reference中的markdown文件，如果要使用，那么agent应用会把Reference下的md文件上传给ai模型，ai模型生成内容，传递的这个md文件是会消耗token的。如果需要执行脚本文件，那么agent会去执行，不会把脚本文件上传给ai模型，脚本文件是不需要消耗token的。

可添加资源文件（可选）

我们可以在 .claude/skills/ 下添加以下目录：

在同一文件夹添加：

examples/：存放示例文件。
references/：存放参考文档。
scripts/：存放可执行脚本（例如 Python 处理 PDF）。

然后在 SKILL.md 中引用这些资源文件，必要时才引用或执行这些文件：

查看示例 commit：./examples/good-commit.txt
运行脚本：使用工具执行 ./scripts/process.py

Skills和Mcp比较

Skills模式：脑子里"知道有这项技能"，但只有在用的时候，才去翻说明书。采用渐进式披露，将复杂度藏在幕后,仅在关键决策点呈现必要信息。

渐进式披露：体现了现代软件工程的模块化思维。将复杂度藏在幕后，仅在关键时刻呈现，让模型注意力始终保持高效聚焦。

加载方式：加载"名字+描述"，真正用到时才加载执行细节。节省上下文空间，降低Token成本。

MCP模式：每次做事前，先把所有说明书通通摊在桌子上。采用全量暴露策略，依赖模型自身的注意力机制去处理海量规则。

协议化思维：倾向于一次性暴露所有规则，过度依赖模型自身的处理能力来应对复杂度，缺乏工程上的优雅与灵活性。

加载方式：每次对话都全量加载所有工具规则。不管用不用，规则始终占据上下文，增加成本。

例子

假设你要构建一个智能体来帮助团队进行代码审查：

MCP 的职责：

# MCP 提供对 GitHub 的标准化访问
github_mcp = MCPTool(server_command=["npx", "-y", "@modelcontextprotocol/server-github"])

# MCP 暴露的工具（简化示例）：
# - list_pull_requests(repo, state)
# - get_pull_request_details(pr_number)
# - list_pr_comments(pr_number)
# - create_pr_comment(pr_number, body)
# - get_file_content(repo, path, ref)
# - list_pr_files(pr_number)

MCP 让智能体"能够"访问 GitHub，能够调用这些 API。但它不知道"应该"做什么。

不知道是否正确：MCP的调用流程要智能体自己去结合上下文思考，而skills能够告诉智能体做法流程是什么。

Skills 的职责：

---
name: code-review-workflow
description: 执行标准的代码审查流程，包括检查代码风格、安全问题、测试覆盖率等
---

# 代码审查工作流

## 审查清单

当执行代码审查时，按以下步骤进行：

1. **获取 PR 信息**：调用 `get_pull_request_details` 了解变更背景
2. **分析变更文件**：调用 `list_pr_files` 获取文件列表
3. **逐文件审查**：
   - 对于 `.py` 文件：检查是否符合 PEP 8，是否有明显的性能问题
   - 对于 `.js/.ts` 文件：检查是否有未处理的 Promise，是否使用了废弃的 API
   - 对于测试文件：验证是否覆盖了新增的代码路径
4. **安全检查**：
   - 是否硬编码了敏感信息（密钥、密码）
   - 是否有 SQL 注入或 XSS 风险
5. **提供反馈**：
   - 严重问题：使用 `create_pr_comment` 直接评论
   - 建议改进：在总结中提出

## 公司特定规范

- 所有数据库查询必须使用参数化查询
- API 端点必须有权限验证装饰器
- 新功能必须附带单元测试（覆盖率 > 80%）

## 示例评论模板

**严重问题**：

⚠️ 安全风险：第 45 行直接拼接 SQL 字符串，存在注入风险。
建议改用参数化查询：`cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))`

Skills 告诉智能体"应该"做什么、如何组织审查流程、需要关注哪些公司特定的规范。它是领域知识和最佳实践的容器。