Agent之一篇文章带你深度学习AgentSkills

引言

2025年10月1 日，Agent Skills首次亮相，那会还是Anthropic的专属。两个月不到，OpenAI被发现悄悄在Codex CLI和ChatGPT里采用了同样的标准。

12月18日，Anthropic把Skills作为开放标准发布，官网是 agentskills.io

紧接着12月24日，OpenAI正式官宣Codex支持 Skills。

后来，VS Code、GitHub、Cursor、Amp、OpenCode，几乎所有主流AI编程工具都加入了。

Django联合创始人Simon Willison说：

Skills可能比MCP更重要。我预计Skills会迎来一波寒武纪大爆发，到时候回头看，今年的MCP热潮都算不上什么。

国内也紧随其后，特赞团队（atypica.ai）推出的Skills市场平台，目前收录了423 个skills。基于开放标准 SKILL.md，Claude Code、Codex、Cursor、OpenCode通用。地址在这：skill0.atypica.ai

如果说2025年是MCP元年，2026年将是Skills元年。

01、为什么需要AgentSkills？

目前AI大模型拥有丰富的智能化能力，聪明的大脑，也具备超大上下文窗口，通过整合RAG和MCP工具等进一步提升了模型在工作中的能力，成为了目前主流的范式，但其在“行动落地”上仍存在瓶颈。

如果将Agent比作一个实习生，你试图在实习生入职的第一天，就把公司所有的代码规范、数据库结构、API 文档甚至“厕所在哪”，一次性灌输进他的脑子。

结果通常是灾难性的：

1. 贵 (Costly)：昂贵的上下文窗口被静态文档占满，留给 AI 真正思考的空间（Reasoning）所剩无几。
2. 乱 (Noisy)：随着规则变多，AI 开始“顾此失彼”。过多的无关指令就像噪音，淹没了关键信息。
3. 难 (Rigid)：任何一个规范的变动，你都要去修改那个几千行的 global_prompt，牵一发而动全身。

这就好比要求一个程序员在写 Hello World 之前，必须先背诵整部 Linux 内核源码。这不合理，也不优雅。

我们需要一种机制，让 AI 像资深工程师一样工作：平时轻装上阵，遇到具体问题时，知道去哪里查阅“手册”。

AgentSkills让AI Agent真正完成具体任务（比如部署应用、扫描代码库中的密钥、调整图片尺寸），它需要借助工具Tool。模型上下文协议（MCP）规范了Agent与工具的通信方式，但MCP仅适用于通信层面，而非分发层面，MCP只是定义了如何与服务器交互，却没有说明如何打包、共享或部署服务器。

Anthropic官方文档中称，不妨把“skill”看作新团队成员的入职指南，而非一段单纯的代码，Agent Skills 具备有序的指令、脚本和资源文件夹，Agent可以动态发现并加载，从而更好地完成特定任务。Skill 可以很简单，简单到就是几句 Prompt，但 Skill 也可以很复杂，可以装下完整的代码工具库。但 Skill 从形式上看，始终很简洁，就是放在文件夹下的文本文件。

假设你要招聘一名初级开发者负责“执行每周安全扫描”，你不会只给他一份Python脚本，还会提供：

• 背景说明：此扫描用于在部署前检测暴露的凭证信息和风险漏洞
• 操作指南：针对代码仓库运行扫描，审核输出结果，将关键问题fix处理
• 所需工具：完成任务必备的脚本、凭证和运行环境

而“skills”就将这一切打包整合。最简单的技能仅包含一个SKILL.md文件。这是一份带有YAML前置元数据的Markdown文档，定义了数据 schema、操作说明，还可选择性地指定运行环境：

code-reviewer/
└── SKILL.md    # 包含schema和操作说明（无需额外代码）

有些skill是供大语言模型遵循的纯指令，有些则能在容器中执行代码，但系统对两者的处理方式完全一致：它们都是基于文件系统的透明能力单元，Agent可以读取、理解并执行，为 Agent提供额外功能。

02、AgentSkills工作机制

To activate skills, all you need to do is write a SKILL.md file with custom guidance for your agent.

工作机制相当简单：

AI Agent（智能体）启动时会扫描所有可用的Skills，读取每个skill的名称和描述。当你的任务和某个skill匹配时，AI自动加载它，按照里面的指令执行。用完即走，不占用上下文（Context）。换句话说，只把需要的能力临时「挂载」进来。

一个标准的 Skill 结构是这样的：

my-skill/
├── SKILL.md       # 核心：元数据 + 指令
├── scripts/       # 可选：执行代码
├── references/    # 可选：文档资料
└── assets/        # 可选：资源模板

为什么它能解决 Context 膨胀？

因为它采用了渐进式披露 (Progressive Disclosure) 的机制：

1. Discovery (扫描)：Agent 启动时，只读取 SKILL.md 里的 name 和 description。内存占用极小，只为了“知道有什么”。
2. Activation (激活)：只有当你的任务匹配到某个简介时（比如“处理 PDF”），Agent 才会动态加载完整的 SKILL.md 正文到 Context 中。
3. Execution (执行)：根据指令，按需调用 scripts 里的代码或读取 references 里的文档。

Skills有三个核心特点，也是它火起来的原因。

可组合。多个Skills可以协同工作，AI自动判断需要哪些，形成可复用的能力链。

可移植。同一个skill，Claude Code、Codex、Cursor、OpenCode都能用，不用改一行代码。

高效。只加载需要的，不浪费token和上下文长度。把上下文留给当下任务，而不是反复解释规则。

Agent Skills最大的改变就在于渐进式披露，其本质依然是行业中大家都在不断优化的提示词工程和上下文工程，其对提示词做了标准化拆分，通过在本地创建相关文件并控制文件的读取，只在Agent需要时自主且自动加载内容。就单拿提示词来说，我们在调用MCP时总要描述很多的工具提示词，在没有执行前，工具描述先把 Context 占满了。

反观Skills，Agent 最初只加载多个 Skills 的元数据（每个 Skill 占用几百 token），当 Agent 认为需要使用某个具体的 Skill，就会读取这个 Skill.md 说明（几千 token）;Skill 里还可以无限嵌套下去，告诉 Agent，想要深入了解某个具体问题，还可以继续读取哪份文件。

Skills和提示词（Prompt）有什么区别？

提示词每次都要写，而且会占用上下文窗口。而Skills是预置的，按需加载，可复用。提示词是「临场指挥」，Skills更像「把正确做法固化成流程」。

03、Agent MCP工具的可移植性难题

MCP为我们提供了描述工具的标准方式，但要实际运行MCP服务器，你需要从GitHub下载代码、安装依赖、配置KEY、还有可能需要搭建需要的环境比如go、npm、uv等，然后祈祷它能正常工作。该规范支持通过标准输入输出（stdio或sse）运行服务器，这意味着许多MCP工具的集成会要求用户在本地机器上下载MCP服务器的代码并执行才能让模型使用。那么这带来核心问题：

缺乏可移植性。工具接口是可移植的，但工具本身并非如此。每个MCP工具的编码语言大不相同，依赖环境也不一样，克隆代码仓库、安装Python 3.11（还不能是3.9版本）、通过pip安装正确的包、配置环境变量……如果MCP工具在别人的机器上能运行，在你的机器上却不行，调试过程将举步维艰。

Skill定义中可以包含自身的运行时环境：容器、依赖项和执行命令等文件。分享一个技能后，接收方可以立即在沙箱环境中运行它，无需额外配置、不会出现环境不兼容、也无需盲目信任。

这也是 Skill 优于 MCP 的地方，MCP 虽好，还是复杂了一些，需要服务端、客户端，需要 run、npx、unx，对于非程序员来说还是有门槛。

Skill 是一个可复用的 Prompt + 能力、资源包，是尽可能本地的（当然也可以通过运行脚本执行一些远程请求）、模块化的（文件夹组织）、可发现的（list dir 即可）、可渐进加载（运行到哪一步就读取哪些文件）的指令、脚本和资源。

MCP 则始终是 C/S 架构，是为了让 Agent 有能力和外部数据、应用、服务进行通信，并把获取的结果添加到上下文中。MCP 可以是远程的，可以抽象掉更多下层的技术细节。

MCP 更像是 API，Agent 只关心提交什么「参数」、得到什么「结果」。

Skill 则是个代码/文件库，Agent 需要知道自己应该「如何」运行（读取）「哪个」文件。

纯文本，意味着「分享更简便」，也就更容易传播和使用，因为「安装」Skill，就是把一个文件夹+几个文件保存到指定的路径下而已。

但Skill 和 MCP 一样，依赖于模型通过上下文中的「技能描述」「工具描述」来自行选择是否调用、调用哪个。

所以 Skill 并没有解决 Agent 有时会忽略工具（不调用）或者选错工具的现象。

04、用FrontendDesign让Agent学会审美

划重点：这个功能现在就能用，完全免费。

步骤一：在skill0找到你要的 skill

打开 skill0.atypica.ai，搜索对你有用的skill，比如这个前端设计 frontend-design。

页面会展示skill的完整说明，它能做什么、什么时候会被触发、具体指令内容。

步骤二：下载skill点击 Download ZIP下载到本地。

步骤三：安装到 OpenCode解压后，把整个文件夹放到 ~/.claude/skills/目录下。OpenCode完全兼容这个路径。当然，你也可以放到OpenCode原生路径 ~/.config/opencode/skill/。重启OpenCode，skill就生效了。

步骤四：使用让OpenCode做前端相关的事它会自动调用这个skill。比如我文章开头的提示词：

设计一个AI产品的数据分析Dashboard。左侧是导航栏，顶部放四个数据卡片显示今日概览（用户数、调用次数、收入、增长率），中间是7天趋势折线图，右侧放最近的API调用记录列表。

你不需要反复「教审美」，因为审美与方法论已经被写进了skill。

Cursor和Claude Code用户，同样的ZIP，解压后放到对应目录就行。

Cursor是 ~/.cursor/skills/，Claude Code是 ~/.claude/skills/。

这就是「skill0」。把零散的「正确做法」沉淀成可装配能力，降低试错与复用成本。“Prompt Engineering” 的终局，是 “Context Engineering”。未来的 AI 助手不应该是一个背诵了百科全书的“书呆子”，而应该是一个懂得在正确时间查阅正确资料的“研究员”。

05、结论

模型就像是个刚毕业的本科大学生，来公司做实习生，它有一定的认知和理解能力，也已经掌握了一些内化的基础技能（bash 命令）。

Skill 就像是一沓技能手册（和工具），它会先读标题，根据需求选择某一本展开阅读，再根据了解到的详细说明，在自己电脑上亲自动手去完成某个工作。

MCP 就像是一个外部的服务窗口（比如信息查询窗口、采购审批窗口、食堂打饭窗口），实习生发出一个指定格式的请求，然后得到自己想要的结果，它不用关心窗口背后发生了什么。

Sub-Agent 则像是更下一层的外包工具人，可以交付某一类具体的任务。（前提是这个外包自己已经具备了相对完善的能力、Skill 和 MCP）

我觉得其实MCP也好, Skills也好, 说白了核心目的都是一种动态和精确控制context的机制和手段, 本质还是为Agent服务的, 实际使用过程中, 怎么使用好这些机制来配合Agent完成目的才是根本。无论context压缩也好，渐进式披露也好，其实就是把重点从提示词工程转到tool，把context，skill都做成tool化。

我们创建了一个大模型技术交流群，便于在日常能够和大家一起学习交流，捕捉行业动态，大家可以加我或直接加群：