最近，Claude Code 彻底“出圈”了。我们看到越来越多的开发者开始基于 Claude Code 编写代码，甚至基于它构建复杂的 Agent 应用。作为最早提出 MCP 的先驱，Anthropic 的步伐并未停歇，近日又抛出了一个新的概念——Skills，并宣布于 2025 年 12 月 正式将 Agent Skills 作为开放标准发布。
直觉上看，不论是 MCP 还是 Skills，本质上似乎都是大模型驱动的“外挂”能力。那么，为什么在大力推广 MCP 之后，还要推出一个 SKILLS？这究竟是技术演进的必然，还是又一次为了造词而造词的“概念通胀”？
笔者认为，工程的核心在于扩展、可靠、经济，很多技术演进都围绕它们展开。
从这个视角看，Skills 的出现正是为了解决现有技术架构中暴露出的痛点。
为什么有了 MCP，还需要 SKILLS？
之所以在 MCP 生态日渐成熟后又引入 SKILLS，核心原因主要归结于以下两点现实约束与定位缺失：
现实约束：上下文窗口的“通胀”与笨重
我们常听到开发者反馈 MCP 好用，但在实际工程中，它往往会占用过多的上下文窗口（Context Window），显得非常笨重。
举个 Playwright MCP 的例子： 当我们为了让模型具备浏览器自动化能力而挂载 Playwright MCP 时，为了让模型“懂”这个工具，协议往往需要将整个 Playwright 的庞大 API 定义、参数结构甚至当前的 DOM 树信息注入到提示词中。
另一方面，中间工具结果会消耗额外的 token。在标准的 MCP 架构中，模型被迫扮演着“数据路由器”的角色，导致中间结果大量消耗 Token。
就拿官方举的例子来看：假设你要求 Agent “从 Google Drive 下载我的会议记录并将其附加到 Salesforce 线索中”。
在 MCP 模式下，数据的流转方式非常“笨拙”： 第一步（读取）： 模型调用 Drive 工具，Drive 将一份长达 2 万字的会议记录完整地“塞进”模型的上下文窗口中。
第二步（写入）： 模型读取这份长文档，然后再次调用 Salesforce 工具，把这 2 万字作为参数，重新“填入”并发送出去。
这带来了极大的浪费和风险：
Token 消耗翻倍（贵）： 对于一个 2 小时的销售会议，光转录文本可能就高达 50,000 个 Token。在这个流程中，数据进出一遍，意味着模型要处理两次海量数据，额外消耗了 100,000+ 的 Token。
上下文溢出（卡）： 即使是支持长文本的模型，面对大型文档或复杂数据结构时，也容易瞬间挤爆窗口限制，导致工作流中断。
鲁棒性下降（错）： 模型在手动“搬运”大量数据时（类似人类 Copy-Paste），更容易出现幻觉、截断或格式错误。
这不仅导致 Token 消耗激增（直接推高成本），过长的上下文还会稀释模型的注意力，导致其在处理核心逻辑时“变笨”。
定位缺失：工具与方法的割裂
MCP 的本质是对“工具调用”的协议标准化。它的初衷是解决 N 个模型适配 M 个工具 带来的 的复杂度问题。 然而，MCP 仅仅定义了“手”怎么动（工具如何被调用），却没定义“脑”怎么想（业务逻辑如何编排）。在目前的架构中，dify 或 n8n 这样的平台虽然可以方便地集成 MCP 作为工具提供者，但真正的业务逻辑（即 SOP）依然分散在大模型的隐性知识或人工硬编码的工作流中。工具是被动的，而如何组合工具完成复杂任务，依然缺乏一个标准化的载体。
问题如何解决？Anthropic 的 Skills 答卷
为了填补这一空白，Anthropic 推出了 Skills的概念。
所谓 Skill（技能），字面意思即“完成某项特定任务的能力”。如果打个比方，厨师（大模型）拥有了做菜的技能，核心在于他知道如何按照特定的工序和流程，在正确的时机调度正确的厨具来产出结果。
由此可见，SKILL 本质上是一种标准化的 SOP（标准作业程序），它是对某项任务最佳实践的沉淀。它不仅包含了任务的定义，还封装了执行流程及配套资源。
过去： 我们受限于模型能力，必须用 Python/JS 代码或拖拽式的图形化语法（如 Dify 的 YAML）来硬编码业务流。 现在： 随着模型理解力提升，这些定义变成了自然语言。非编程背景的用户也可以将自己的经验固化下来。这种思路的鼻祖虽然可以追溯到 OpenAI 的 GPTs，但 Skill 将其进一步工程化、标准化，使其脱离了单一聊天界面，成为 Agent 可调用的原子能力。
核心设计哲学：渐进式披露（Progressive Disclosure）
虽然模型上下文窗口在不断提升，但实践告诉我们：毫无节制地将抽象层次不一的信息一股脑塞进模型，是性能杀手。
因此，Skill 的设计采用了“专业分工，信息隔离，按需取用”的策略。Anthropic 引入了产品设计中经典的 “渐进式披露”（Progressive Disclosure） 理念：只在用户（或模型）需要的时候，展示当下最必要的信息。
在 Skill 的架构中，这一理念体现为三层结构：
元数据层（始终加载）：技能的名称与简介（告诉模型这是什么，消耗极低 Token）。 指令层（ SKILL.md，在触发时加载）：定义核心工作流程和步骤（告诉模型怎么做，中等 Token）。资源层（按需加载）：完成技能所需的配套脚本、参考文档、模板数据（执行时才调用，Token 消耗大）。
Skill 的标准结构
一个标准的 Skill 以文件系统形式组织（为什么采用文件？Agent原生架构：Claude Code 后时代该如何构建智能体应用），结构如下：
my-skill/
├── SKILL.md # [必需] 核心大脑。包含元数据（name、description）和自然语言编写的指令流程
├── scripts/ # [可选] 执行手脚。存放 Python/Bash 等可执行代码，封装复杂逻辑
├── references/ # [可选] 知识库。存放模型决策所需的参考文档、API 手册等
└── assets/ # [可选] 静态资源。存放输出报告所需的模板、图片、示例数据等
这种分层设计的优势显而易见：
Token 经济性与数据隔离： 模型在规划阶段只需读取 SKILL.md的元数据，决定使用该技能后才读取指令，最后在执行具体步骤时才加载scripts或references。从上到下，Token 占用依次增多，极大程度控制了上下文膨胀。同时，这完美解决了前文提到的 Google Drive 案例中间工具结果会消耗额外的 token的痛点。在 Skill 模式下，模型只需要指挥 scripts 目录下的脚本运行。脚本在后台直接从 Drive 获取数据流并写入 Salesforce，庞大的会议记录根本不需要流经模型的上下文窗口。鲁棒性增强： 通过将复杂的“轮子”封装在 scripts中，避免让模型每次都从零编写代码，减少了幻觉和错误的发生。这与 Manus 或 Cursor 的设计思路异曲同工——将高频、易错的操作固化为工具（Code），将灵活、决策的操作留给模型（Prompt）。
官网提供了skills编写的规范，感兴趣可以访问：https://agentskills.io/specification
上下文管理：从Agent失效到高效运行的完整指南
上下文工程的精髓在于删除？
如何使用？
运行一个 Skill 非常简单且解耦。标准方式是使用 Claude Code 命令行工具，当然，在 Cursor 或 VS Code (配合 Codex) 等环境中，你只需遵循文件协议即可。
通常，将定义好的 skills 文件夹放置在用户目录或项目根目录下的 .claude/skills 文件夹中即可生效。
下面是一个怎么做红烧肉的skill，可以看到开发和管理都是相对比较简单的。
从这个角度看，Skills 带来了一场“配置即代码”的变革。原本我们需要在 Dify 界面上拖拽连线定义的复杂工作流，现在完全可以通过撰写结构化的文本文件来完成。这使得 Agent 的能力可以像代码一样被版本管理、分享和复用。
后记
过去几个月，开发者社区都在热衷于分享各种 MCP 工具，解决了“手”的问题。而现在乃至未来一段时间，Skill 将成为新的宠儿，因为它解决了“脑”和“流程”的问题。
Skill 不仅管理了工具和资源，更将流程标准化。配合大模型日益强大的推理能力，“自主智能体”的拼图终于补齐了关键的一块。
那么，我们应该在哪里找优质的 skill 呢？当然可以去官方库或者 GitHub 上收集。但在这里，我想为大家推荐一个更具前瞻性的平台，类比于当年的 mcp.so，它不仅仅是一个资源站，更代表了一种新的工程化范式：
👉 skill0.atypica.ai
这是由特赞（Tezign）团队带来的探索。他们从 Agent 和 AI 系统底层演进的视角，强势提出了 skill0 这一新范式，并致力于建立以下认知：
skill0 不是一个简单的“工具集合”，而是一次对 Agent 如何管理能力、如何做判断、如何走向工程化的关键回答。
之所以特别推荐这个平台，是因为它具备独特的“血统”：
实战出身： skill0 来自特赞团队的企业级智能体（Generative enterprise agent，GEA）体系，是其底层能力的对外开放。 虽然这个尝试最早源自消费者研究场景，但这套以“判断”为核心、以 Skills 为能力单元的架构，理论上适用于任何复杂的知识型工作。- 痛点驱动： 特赞是少数在真实企业级系统里，被复杂业务场景逼出来的团队。skill0 正是一个“领先于理论暴露出问题答案”的工程实践。
目前，skill0 (alpha) 还是一个非常早期、非常基础的版本。功能尚简，团队也在边用、边改、甚至边推翻重来，保持着高频迭代。
这件事，才刚刚开始。但这正是它的迷人之处。如果你正在构建类似的 Agent 系统，或者你也在痛苦地思考如何让 Agent 拥有“判断力”而非仅仅执行“固定流程”，非常欢迎你来试用、来反馈，与我们一起定义 Agent 的未来。
