---

一、问题背景：为什么聪明的 Agent 仍然“不专业”

过去两年，很多团队已经把 AI Agent 深度融入日常工作：写代码、做报表、查资料、起草合同，几乎无所不包。 但真实体验往往是——能用，却远谈不上“放心托付”。

一个非常形象的类比来说明这个痛点：

• Mahesh：智商 300 的数学天才，推理能力超强，但对现实税法完全陌生。
• Barry：经验丰富的税务专家，不一定会证明定理，却能在真实业务中游刃有余。

如果把 AI Agent 类比成 Mahesh，它有三大致命短板：

• 无法高效吸收你的专业经验（行业 know-how 很难被沉淀和复用）。
• 无法随时间自我进化（今天教的东西，明天还要从头说一遍）。
• 起步阶段缺乏关键背景信息（不懂你公司流程、不懂你项目上下文）。

Skills 的使命，就是把一个“聪明但缺经验的 Mahesh”，进化成“懂你业务、可持续进步的 Barry”。

https://www.youtube.com/watch?v=CEvIs9y1uog

---

二、核心理念：为什么是“代码 + 文件夹”

Anthropic 在打造 Claude Code 和 Skills 的过程中，总结出三个关键认知转变，这是理解整个体系设计的基础。

1. 认知一：代码即一切

传统做 Agent 的思路是：

不同领域 = 不同 Agent 架构 + 不同工具链 + 不同脚手架。  

但在 Claude Code 的实践中，Anthropic 发现了一个更“极简”的事实：

• 绝大多数数字任务的共性是：操作文件系统 + 调用程序/脚本 + 调用 API。
• 底层只要提供：一个 Bash 环境 + 一个可读写的文件系统，就足以支撑大量复杂任务的编排。

例如“生成财务报告”这个看上去很业务化的任务，本质可以拆成四步：

1. 调用 API 抓取数据
2. 在文件系统里整理原始资料
3. 用 Python 分析数据
4. 合成特定格式的报告（比如 PPT/Excel）

不再需要为“财务 Agent”“运营 Agent”“法务 Agent”设计截然不同的底层架构，只需要一个通用的代码执行环境，再把领域经验封装在可复用的“技能包”中即可。

2. 认知二：文件是最佳协作单元

Anthropic 对 Skills 的本质给出的定义非常朴素：

Skills = 文件的有序集合 = 一个个结构化的文件夹。

看上去“原始”，但这背后是三条非常现实的设计原则。

• 普适性：任何会用电脑的人都能理解“文件夹”的概念，开发者可以用，AI 也能用，不引入额外认知负担。
• 兼容性：天然融入现有工具链——用 Git 做版本管理，放在 Google Drive 共享，压缩后发给其他团队，都不需要新基础设施。
• 永恒性：几十年软件工程的实践已经证明文件是稳定的协作单位，这种抽象不会轻易过时。

对开发者来说，一个 Skill 更像是：
“一个可以被模型理解和调用的 repo / 目录”，里边装的是过程性知识而不是静态文档。

3. 认知三：代码胜过传统“工具定义”

传统工具调用设计（例如 JSON 的工具 schema）有四个典型问题：

• 指令容易含糊，边界定义不清。
• 无法自我修改，一旦不适配场景就会“卡住”。
• 持续占用上下文，工具描述越多，token 压力越大。
• 难以表达复杂流程和业务逻辑。

而采用代码 + 文件的方式，有几大优势：

• 代码天然“自文档化”，函数名、注释、文件结构就是最好的说明书。
• 可以由 AI 或人类随时修改优化，而不是一次性写死在 prompt 里。
• 平时只是“躺在文件系统里”，需要的时候按需加载，避免挤占上下文窗口。

一个典型例子：Claude 反复写同一个 Python 脚本来调整 PPT 样式，每次都在重新构造脚本，既浪费 tokens，质量也不稳定。
现在改成：第一次写好后保存为一个 Skill，之后只需要“调用脚本”即可，大幅提升稳定性与效率。

---

三、Skills 是什么：一个“可执行的专业经验包”

1. Skill 的组成结构

从实现视角看，一个 Skill 本质上是一个目录，它可以包含：

• Markdown 文件（例如 SKILL.md，负责说明与指令）。
• 软件包（依赖库、环境说明）。
• 各类脚本（Python、Shell 等）。
• 可执行文件与二进制文件。
• 相关资产（模板、配置、示例数据等）。

在演进路径上，大多数 Skill 会经历两个阶段：

• 早期：只是一个简单的 Markdown 文件，几分钟即可写完，负责说明“如何完成某个流程”。
• 成熟期：逐渐演化为综合体，包含完整的脚本、配置、测试、资产等，可能需要数周甚至数月精心打磨。

这很像软件工程从“脚本小工具”逐步演变为“企业级应用”的过程。

2. 逐步披露：如何在成千上万个 Skills 中高效检索

如果给 Agent 装上了 500 个甚至几千个 Skills，一个核心挑战是：上下文窗口不够用。

Anthropic 的解决方案是“逐步披露（progressive disclosure）”策略：

1. 初始状态：模型只看到所有 Skills 的“元数据”（名称、简介、标签等），大约占用 5–10K tokens。
2. 当模型决定使用某个 Skill 时，再加载该 Skill 的 SKILL.md，读入核心指令和目录结构，额外占用约 1–2K tokens。
3. 在执行过程中，按需加载具体脚本、模板或配置文件，用完后可从上下文中“清理”。

例如用户说：“帮我生成一份销售报告”，大致流程会是：

• Agent 浏览元数据，找到 sales_reporting Skill。
• 加载 sales_reporting/SKILL.md，理解它能做什么、需要什么输入。
• 再按需调用 generate_report.py、format_template.json 等资源，完成任务后释放上下文。

这样一来，即使有成千上万个 Skills，系统依然可以保持上下文轻量、能力丰富、组合灵活。

---

四、统一架构：Agent Loop + Runtime + MCP + Skills

经历一年多实践，Anthropic 观察到通用 AI Agent 的架构正在收敛为四个核心组件：

1. Agent Loop（大脑）

   • 负责理解用户意图、拆解任务、规划步骤。
   • 决定何时调用哪些 Skills 或 MCP 工具，并管理上下文窗口。

2. 运行时环境（Runtime）

   • 提供代码执行能力（例如 Bash、Python）。
   • 管理文件系统、进程隔离和安全策略。

3. MCP：Model Context Protocol

   • 负责连接外部世界，例如 API、数据库、第三方 SaaS。
   • 关注“能不能连上”“能不能调用成功”的层面。

4. Skills（知识与经验层）

   • 承载领域专业知识、流程和最佳实践。
   • 关注“该不该这样做”“在这个场景下怎么做更合理”。

可以把这套结构类比为：“操作系统 + 驱动 + 应用”的关系，其中：

• MCP 像“驱动层”和“连接器”，让模型看见更多外部资源。
• Skills 像“应用+脚本库”，封装了可执行的业务经验。

对于开发者而言，这种统一架构的好处是：心智模型更简单，可以在一个一致的框架内思考 Agent 能力扩展，而不是为每个垂直场景重新发明轮子。

---

五、Skills 生态图谱：从基础能力到企业知识库

自 Skills 发布以来，生态中已经涌现出数千个 Skills，大体可以分为三类。

1. 基础 Skills：增强大模型“底盘能力”

这类 Skills 给 Claude 增加了“系统级”能力，例如文档、表格、演示文稿处理等。

代表案例：

• Document Skills：让 Claude 能以专业水准处理 Word、PPT、Excel 等文件，理解文档结构与业务逻辑，真正像一个“高配办公助理”。

对开发者来说，这一类 Skills 更像给操作系统增加新的系统调用——
它们不局限于某一无关紧要的小功能，而是显著扩展模型的通用能力边界。

2. 第三方 Skills：为外部产品定制“AI 使用手册”

第二类是围绕特定产品/平台打造的 Skills，用来让 Claude 更“像熟练用户那样”操作这些工具。

典型示例：

• Cadence – 科研与生物信息 Skills

  • 使 Claude 能在电子病历（EHR）数据分析场景中表现远超原生模型。
  • 熟练使用 Python 生物信息学库，理解科研数据处理流程。

• Browserbase – 自动化浏览器操作 Skills

  • 针对开源浏览器自动化工具 Stagehand 定制 Skills。
  • 让 Claude 可以更稳健地操控浏览器进行表单填报、数据抓取、流程回放。

• Notion – 工作空间 Skills

  • 帮助 Claude 深度理解用户的 Notion 空间结构。
  • 支持跨文档研究、信息整合和项目管理辅助。

这类 Skills 的价值在于：替你写“如何正确使用这些复杂工具”的说明书，并且能自动执行说明书里的步骤。

3. 企业私有 Skills：组织级“数字老员工”

第三类，也是最具想象力的，是企业为自身场景打造的私有 Skills。

常见用法包括：

• 把公司内部的最佳实践编码成 Skills，新来的 AI 也能按公司习惯办事。
• 把内部系统使用方法沉淀为流程，让 AI 像老员工一样熟悉各类后台工具。
• 在代码层面强制执行内部代码规范、Review 流程和工作流，提升工程一致性。

这样的 Skills 不只是“一个工具”，它更像是“组织记忆的一部分”，
新员工、人类或 AI，只要接入这些 Skills，就能快速共享经验红利。

---

六、趋势：从工程师玩具到全员可用“技能层”

Anthropic 工程师在实践中观察到了三个明显趋势。

1. 趋势一：非技术人员也在写 Skills

Skills 采用文件夹 + Markdown 的形式，门槛相对较低，因此正在吸引大量业务专家参与构建：

• 财务团队、招聘团队、会计师事务所。
• 法律顾问等专业人士。

这些人可能不擅长写复杂代码，但非常清楚“正确的业务流程是什么”。
通过 Skills，他们可以把自己的专业经验转译成 AI 可执行的流程，从而让 Agent 真正进入日常工作主战场。

2. 趋势二：Skills 与 MCP 的分工越来越清晰

很多开发者正在使用 Skills 作为“编排层”，来调度多个 MCP 工具，形成端到端工作流。

在这套范式里，职责大致分为：

• MCP：专注“能不能”，负责连上外部系统、保证调用正确执行。
• Skills：专注“该不该、怎么做”，负责业务策略和流程逻辑。

当你有 N 个 MCP 服务器和 M 个 Skills 时，可以组合出远超传统“单工具调用”的能力空间。
这使得 Agent 能在高度复杂的企业环境中保持灵活而不失可控性。

3. 趋势三：Skills 正在变得越来越复杂

从一开始几分钟写完的 Markdown，到后面包含多种资产、复杂依赖和精细测试的“能力包”，
Skills 的复杂度在迅速提升，这恰恰说明它开始承载真实业务逻辑而不仅是 demo。

复杂化带来的好处包括：

• 能够覆盖更高价值、更高风险的业务场景（例如金融、医疗）。
• 可以被组织当成“软件资产”长期维护和进化，而不是一次性脚本。

---

七、企业实践：从 6–12 个月到数周的垂直 AI 落地

在内部实践中，Anthropic 基于 Skills 推出了至少两个专业方案：

• 金融服务专业方案
• 生命科学专业方案

实现方式是：预装对应的 MCP 服务器和 Skills 包，让 Claude 直接以“行业专家助手”的姿态上线。

与传统“从零打造垂直 AI 产品”的路线相比，优势非常明显：

• 开发周期从 6–12 个月缩短到数周。
• 易于快速试错和迭代，业务团队可以频繁更新 Skills。
• 同一套 Skills 可以跨项目、跨子场景复用，复利效应显著。

对正在考虑“如何把大模型真正落地到本行业”的团队来说，
这提供了一条成本更低、可控性更强的路径：

先构建和积累 Skills，而不是一上来就重造一个“全新的垂直 Agent”。

---

八、工程视角：如何把 Skills 当“软件”来管理

想要在更大规模上使用 Skills，必须引入软件工程思维。

1. 像软件一样工程化管理 Skills

关键措施包括：

• 为 Skills 引入测试与评估机制，确保在关键场景下表现稳定。
• 提供更智能的触发逻辑，确保在正确时间激活正确 Skills。
• 建立输出质量指标体系，用量化方式持续优化。
• 强化版本控制、回滚与变更审计能力。

这意味着：Skills 不再只是“个人脚本收藏夹”，
而是作为一类正式的软件资产进入企业开发治理体系。

2. 管理 Skills 间依赖关系

随着 Skills 数量增长，一个明显课题是：依赖管理。

未来的目标是让一个 Skill 能显式依赖于：

• 其他 Skills（复用已有流程）。
• MCP 服务器（需要外部数据或操作）。
• 特定的环境包（例如特定版本的 Python 库）。

有了清晰的依赖图，Agent 在复杂环境中的行为会更可控、更精准，也更容易组合多个 Skills 来完成高级任务。

---

九、知识库与持续学习：从“堆信息”到“堆经验”

更长期的愿景： Skills 不只是工具，而是迈向“持续学习”与“组织知识库”的重要台阶。

1. 企业内部的能力知识库

理想状态下，企业可以构建一个由“员工 + AI”共同维护的能力知识库：

• 业务流程、操作规范、复盘经验都会沉淀为 Skills。
• 新项目可以复用旧项目的 Skills，并在此基础上增量改进。
• 每次迭代都是对知识库的小幅增强，形成长期复利。

与传统静态知识库相比，Skills 的区别在于：它不仅能被阅读，还能被直接执行。

2. Skills 是“记忆具象化”的载体

在这一框架下，“记忆”不再是模糊的 embedding，而是具体可见的文件和脚本：

• 过去：只是信息堆积（FAQ、文档、wiki）。
• 现在：针对特定任务的过程性知识（步骤、脚本、模板）。

标准化的 Skill 格式保证了一个重要性质：

“今天 Claude 为某个任务创造的经验，明天的 Claude 能够无损继承这些经验。”

这为真正意义上的“持续学习”打下了基础：
与其试图让模型在权重层面不断重训，不如让它通过持续积累 Skills 来扩展能力边界。

---

十、给开发者的实践启发

如果你正在搭建或改造自己的 Agent 系统，可以从以下几个方向思考如何借鉴Skills 思路

1. 以“文件夹 + 代码”的形式组织流程经验

   • 把常复用的脚本、模板、流程说明集中放进一个目录，并用一个 Markdown 说明其用途与调用方式。

2. 设计自己的“逐步披露”机制

   • 不要一股脑把所有工具说明塞进上下文；
   • 先只暴露工具列表与简要说明，真正使用时再加载详细文档和脚本。

3. 从基础 Skills 做起，再上升到组织知识

   • 先实现一批稳固的基础能力（文档、报表、数据处理），
   • 再在此之上为本组织打造“私有 Skills”（流程、规范、内网系统）。

4. 尽早给 Skills 引入测试与版本管理

   • 把 Skills 当作软件来维护，而不是临时脚本；
   • 对重要的 Skill 增加单元测试或集成测试，配合 CI/CD 工具自动回归。

5. 让业务人员参与 Skill 设计

   • 技术人员负责 MCP 和 Runtime，
   • 业务人员负责写清楚“正确的做事方式”，共同完成 Skills。

---

十一、结语：一起从“造 Agent”转向“造 Skills”

“与你共事 30 天后的 Claude，表现应当远优于第 1 天。”

要实现这一点，关键不在于无限堆大模型参数，而在于：
让 AI 拥有可复用、可积累、可共享的专业经验，并以 Skills 为载体持续进化。

从工程实践的角度看，这意味着一个范式切换：

• 少花精力在一次性、场景定制的“超级 Agent”上。
• 多把精力投入到可组合、可管理、可共享的 Skills 生态。

对于开发者、研究者和技术管理者而言， 如果你希望自己的 AI 系统真正走向“专业”“可靠”“可持续”， 那么从今天开始，把“构建 Skills”当作一等公民来设计，可能是一个更长期正确的方向。