本文整理自 Anthropic 的工程师 Barry 和 Mahesh 在 AI Engineer 做的关于 Skills 的分享：Don’t Build Agents, Build Skills Instead。
Anthropic 这帮工程师真的非常高产，继创造了 MCP 协议、Claude Code 编码 Agent 后，又创造了 Skills。他们的每一次创新都是源于实际工程开发中的真实需求，比如：
- MCP 协议的提出是因为解决模型与异构数据源（如本地文件、SaaS工具）连接的碎片化与标准化难题；
- Claude Code 创造是因为突破对话框的限制，让 AI 直接深入本地开发环境，实现从“阅读代码”到“执行构建”的自主闭环。
- 而 Skills 的创造是因为 将高频、复杂的任务逻辑封装为可复用的标准化模块，让 Agent 拥有长期的“肌肉记忆”，避免在重复任务中反复进行低效的 Prompt 引导。
以下是本次分享的核心内容，由我和 Gemini 3 Pro 共同整理而成。
代码就是这一层通用的接口
以前我们有个误区，觉得不同领域的 Agent 应该长得完全不一样。做金融的 Agent 和写代码的 Agent，肯定需要完全不同的工具和脚手架，甚至得为每个用例单独造一个 Agent。
但后来我们发布了 Claude Code（我们的第一个编程 Agent），搞着搞着发现：原来底下那个通用的 Agent 其实比我们想象的要强大得多。 代码不仅仅是一个使用场景，它其实是连接数字世界的通用接口。
想象一下生成一份财务报告：模型调用 API 拉数据、在文件系统里整理、用 Python 分析、最后输出格式化文件。这一整套流程，其实只需要极薄的一层脚手架（Bash 和文件系统）就能搞定。
智商 300 的天才 vs. 经验丰富的税务师
既然通用脚手架这么好用，为什么我们还需要“技能”？这就是回到开头提到的那个“落差”问题：领域专业性。
举个很形象的例子：你要报税，你会选谁？
是选 Mahes（假设他是个智商 300 的数学天才，但他从没填过税表），还是选 Barry（一位经验丰富的老税务师）？
正常人都会选 Barry。我不需要一个天才从第一性原理去推导 2025 年的税法，我需要的是一个懂行的人能够稳定、合规地把活干完。
今天的 Agent 就像那个智商 300 的 Mahes：极其聪明，但没有任何实战经验。虽然只要你给够提示词，它们也能干得很漂亮，但它们往往缺了最重要的上下文（Context），也无法真正“吸收”你的专业知识。
“技能”（Skills）就是为了解决这个也是为了把那个老专家的经验封装起来。
什么是“技能”？其实就是一个文件夹
我们把“技能”定义为：打包给 Agent 使用的可组合的过程式知识。
听起来很高大上？其实它就是文件夹。
这个设计是故意的。只要你有电脑，你就能创建文件夹。你可以用 Git 管理它，用 Google Drive 分享它，或者打包发给同事。这种“文件”的原始形式我们用了几十年，它依然是最有效的。
在这个文件夹里，最核心的是脚本（Scripts）。
传统的 Agent 工具（Tools）最大的问题是指令模糊，而且全靠自然语言描述，一旦模型卡住了，它改不了工具本身。但**代码（Code）**不一样：
- 代码具有自解释性（Self-documenting）。
- 代码是可以被修改的。
- 代码可以作为文件存在，用到的时候再调取。
比如，我们发现 Claude 总是重复写同一个 Python 脚本来给 PPT 换样式。我们就让 Claude 把这段逻辑存成一个“技能”里的脚本。下次再用，直接运行脚本就行，既稳定又高效。
技术细节：如何保护上下文窗口？
如果往 Agent 里塞几百个技能，上下文窗口（Context Window）不就爆了吗？ 这里我们用了一个**“渐进式披露”（Progressively Disclosed）**的机制：
- 运行时，先只给模型看技能的元数据（Metadata），告诉它“我会这一招”。
- 只有当 Agent 决定要用这个技能时，它才会读取完整的
skill.md（核心说明书）和文件夹里的具体内容。
这样，我们就能让通用 Agent 随身携带成百上千个技能，而不占用宝贵的脑容量。
生态爆发：从 Notion 到企业内部的“怪癖”
发布仅仅五周，我们已经看到了成千上万个技能被创造出来。主要分三类：
- 基础技能： 比如我们需要 Claude 能处理专业文档，就做了 Document Skills。科研机构像 Cadence 做了生物信息学分析的技能，让 Claude 能像科学家一样处理 EHR 数据。
- 产品技能： 第三方公司为自己的产品做技能。比如 Browserbase 做了浏览器自动化的技能，Notion 做了深度搜索工作区的技能。
- 企业内部技能（这是最有趣的）： 每个大公司都有一堆只有自己人懂的“黑话”、流程和那一堆古怪的内部软件。以前通用模型根本不懂这些。现在，企业可以把这些“内部最佳实践”封装成技能。
更有意思的是，很多构建技能的人根本不是程序员。财务、招聘、法务团队的人正在用自己的业务逻辑构建技能，让 Agent 真正融入他们的日常工作。
Agent 的新架构：MCP + Skills
现在，一个成熟的 Agent 架构正在收敛成这样：
- Agent Loop & Runtime: 负责思考和执行代码环境。
- MCP (Model Context Protocol): 负责连接外部世界（工具和数据）。
- Skills: 负责提供专业知识（怎么用这些工具）。
MCP 是手，Skills 是脑子里的操作手册。 开发者正在用 Skills 来编排复杂的 MCP 工作流。MCP 负责连通数据库，Skill 负责定义“如何生成一份符合公司规范的月度报表”。
愿景：Day 30 的 Claude 强于 Day 1
通过 Skills，我们要实现的是持续学习。
你刚开始用 Claude（Day 1），它是个通用的聪明助理。 当你和它工作了一段时间，你可以让 Claude 把你教它的流程写成一个 Skill（我们甚至有专门的 Skill Creator skill 来干这事）。 到了第 30 天，这个 Claude 已经通过文件系统“记住”了你的工作习惯、你团队的代码风格、你的业务流程。这种记忆是可迁移的，因为它是代码和文件。
这就像从处理器到操作系统的进化：
- 模型是处理器（CPU），算力强大但只是一块铁。
- Runtime 是操作系统（OS），管理资源。
- Skills 就是应用程序（Apps）。
处理器的价值在于上面跑了什么应用。未来，每个人都可以通过往文件夹里放点东西，就把自己的独特知识变成了这一层“应用”。
总结
所以，接下来的路很清晰：我们不需要重新去造一个个孤立的垂直 Agent。
我们需要的是一个通用的、强大的 Agent 架构，然后把精力花在构建技能上。去把那些只有你懂的、公司懂的、行业懂的每一分专业知识，都变成 Claude 能看懂、能执行的技能。
别再造轮子了，来和我们一起构建技能库吧。