Agent Skills 深度解析：从「能连」到「会做」的能力鸿沟

Agent Skills 是 2026 年 AI Agent 生态里最重要的标准化趋势之一，它用「渐进式披露」的设计解决了 MCP 管不到的能力鸿沟，让 Agent 从「能连」走向「会做」。

刚做完一个多 Agent 系统，最折磨人的不是 Agent 之间的通信协议调通，而是另一个问题：

Agent 什么工具都能调了，但它不知道怎么用。

MCP 解决了「能不能连」的问题——数据库能连、API 能调、文件系统能读写。但它的职责到连接就停了。你的 Agent 知道怎么 SELECT * FROM，但它不知道「查询总经理薪资的时候，to_date='9999-01-01' 这个条件是必须加的」。它能调 GitHub API，但它不知道代码审查应该先看什么、重点检查什么。

这就好比你给一个实习生开通了公司所有系统的访问权限，但没有告诉他任何业务规则和操作流程。他能登录系统，但不知道怎么做对。

这个缺口，就是 Agent Skills 填的位置。

一个 Skill 长什么样

Agent Skills 的概念简单到让人怀疑它是不是被过度炒作了——它本质上就是一个文件夹，里面放一个 SKILL.md 文件。

skills/
└── code-review/
    ├── SKILL.md
    └── review-checklist.md

SKILL.md 以 YAML frontmatter 开头，定义名字和描述：

---
name: code-review-workflow
description: >
  执行标准的代码审查流程，包括检查代码风格、安全漏洞、测试覆盖率。
  当用户要求 Review PR 或代码时使用此技能。
---

后面就是 Markdown 正文，写清楚工作流、注意事项、最佳实践。就这么简单。

但它的精妙之处不在格式本身，而在 渐进式披露（Progressive Disclosure）。

三层加载，解决上下文爆炸

这是 Skills 最核心的设计。Anthropic 把技能信息分成三个层级，Agent 按需加载，而不是一股脑全塞进上下文里。

第一层：元数据。 Agent 启动时，只读取每个已安装 Skill 的 frontmatter（name + description），消耗大约 100 个 token。装 50 个技能也才 5000 token。Agent 靠这段简短的元数据判断「这个技能对我的当前任务有没有用」。

第二层：技能主体。 当 Agent 判断某个技能跟当前任务相关，它才去读完整的 SKILL.md 正文。拿到详细的指令、步骤、规则。这部分消耗 1000-5000 token。

第三层：附加资源。 SKILL.md 可以引用同目录下的脚本、参考文档、模板文件。Agent 只在真正需要的时候才去加载它们。比如 PDF 技能附带了一个 forms.md，只在 Agent 需要填表时才会去读。

这套设计的威力在于：理论上，一个 Skill 可以携带无限的知识——通过脚本引用文件、调用工具、执行代码，而不需要把所有内容预加载到上下文里。

社区有开发者分享了一个案例：一个 MCP 服务器连接时直接吃了 16000 token（工具定义的 JSON Schema）。用 Skills 包装一层后，初始消耗降到 500 token，只有在需要时才加载详细指令并调用底层的 MCP 工具。

Skills 和 MCP 不是对手

这是最常见的误解。

很多人问：Skills 和 MCP 都是 Anthropic 出的，它们是不是竞争关系？是不是 MCP 没做好所以搞了个 Skills 来替代？

完全不是。它们是不同层的东西。

MCP 解决的是连接问题（能不能）：让 Agent 能够调用数据库、文件系统、API。它提供的是「手」。
Skills 解决的是能力问题（会不会）：告诉 Agent 在特定场景下应该怎么做。它提供的是「操作手册」。

用一个具体例子来说明。构建一个代码审查 Agent：

MCP 暴露的工具：list_pull_requests、get_pull_request_details、list_pr_files、create_pr_comment。Agent 能调这些 API 了，但它不知道：

审查应该按什么顺序进行？
.py 文件和 .js 文件分别需要检查什么？
公司的代码规范是什么？
什么该直接评论，什么该仅做建议？

这些就是 Skills 的内容。

---
name: code-review-workflow
description: 执行代码审查流程
---

## 审查步骤
1. 获取 PR 信息 → 了解变更背景
2. 列出变更文件 → 按类型分类
3. 逐文件审查：
   - .py: 检查 PEP8、性能问题
   - .js: 检查未处理的 Promise、废弃 API
4. 安全检查：硬编码密钥、SQL 注入风险
5. 生成总结报告

MCP 提供能力底座，Skills 提供领域智慧。两者结合才是完整的 Agent 能力扩展方案。

为什么 2026 年突然爆火

其实 Agent Skills 在 2025 年底就发布了，但真正爆发是 2026 年初。三个信号：

第一，生态规模起来了。 skills.sh 上已经有 7 万多个 Skills，15 种以上的 AI 工具支持（Claude Code、Codex、Cursor、OpenClaw 等）。排名第一的 find-skills 安装量超过 28 万。这不是概念了，是有人在真用。

第二，标准化格局基本确定。 Anthropic 的 Skills 规范 + skills.sh 统一 CLI 层，加上 Anthropic、HuggingFace、Microsoft 三家都在推，Skills 协议的标准化竞争基本宣告结束——不会再有第二个。

第三，企业开始拿它做生产落地。 一个做 RAG 的团队跟我说，交付同学比研发同学更懂系统——他们沉淀了二十多个 Skills，覆盖工作流搭建、问题排查、RAG 优化。以前这些知识写在内部 Wiki 里吃灰，现在打包成 Skills，Agent 直接能用。

安全：Skills 最大的阿克琉斯之踵

聊 Skills 不能只夸好处，它的安全问题很突出。

MCP 的安全模型是进程隔离：每个 Server 独立跑，凭证通过环境变量注入，爆炸半径小。Skills 的安全模型是信任即执行：安装一个 Skill = 授权它跑任意代码。

2026 年 1 月的 ClawHub 事件，发现了 341 个恶意 Skills。攻击手段包括伪装成安装步骤的 curl 脚本、窃取凭证、建立反向 Shell。

这在设计层面是结构性的。SKILL.md 的规范本身不涉及安全问题——不定义凭证管理、不规定隔离策略。加上 setup.sh 这种机制，攻击面是打开的。

目前的应对是混合方案：Skills 做能力封装和指令定义，实际执行走 MCP 的服务端（进程隔离）。组合使用的效果最好。

我的看法

Agent Skills 的本质是什么？它不是新技术，是知识封装格式的标准化。

在 Skills 出现之前，让 Agent 变专业只有两条路：写长 Prompt（不可复用、不可发现）、写定制代码（成本高、不通用）。Skills 给了第三条路——把领域知识打包成标准格式，让工具链去发现和加载。

这意味着两件事：

对开发者来说，你的竞争壁垒正在从「怎么写 Prompt」转向「怎么沉淀领域知识」。一个能教会 Agent 怎么做代码审查的 Skill，比一百句「你是一个专业的代码审查员」值钱得多。

对 Agent 平台来说，Skills 的标准之争已经结束了——Anthropic 赢了。接下来的战场是 Skills 的分发、评价、安全治理。

最后说一个让我觉得有意思的点。Anthropic 同时搞了 MCP 和 Skills 两套标准，它们代表了两种完全不同的设计哲学——一个是安全优先的进程隔离，一个是灵活优先的文件夹打包。但这不是矛盾的，这恰恰说明了一件事：在 Agent 能力扩展这个命题上，没有一个方案能通吃所有场景。

安全场景走 MCP，灵活场景走 Skills。最好的架构，是两个都要。

Published: https://betterpursue.blogspot.com/2026/05/temppublish.html

我写了半年 prompt，最后发现最好的技巧就三个

五月 16, 2026

阅读全文

搜索此博客

不如不追求