目录
- 前言
- 一、skills背景
- 二、什么是skills
- 三、Skill的核心特征
- [四、Skill如何工作？------ 渐进式披露的三层架构](#四、Skill如何工作？—— 渐进式披露的三层架构)
- [五、何时使用Agent Skill？](#五、何时使用Agent Skill？)
- [六、Skill 与其他模式的对比](#六、Skill 与其他模式的对比)
前言
- 最近这半年，skills这个名词非常火------无论是Claude Code Skills的爆火，还是skills.sh平台的快速迭代，都在说明这个东西貌似在agent领域是一个比较好用的东西
- 我打算用两篇博客讲清楚什么是skills，以及实际开发中我们如何开发一个基于skills范式的智能体
- 这篇博客主要讲明白什么是skills，让大家对skills有一个深刻的了解，下一篇博客我们上实战
一、skills背景
在构建基于大模型（LLM）的Agent应用时，我们常常面临一个核心矛盾：如何让一个通用的Agent，具备处理众多高度专业化、甚至相互独立的任务的能力？
传统的做法是，将所有的知识、规则和工具一股脑地塞进Agent的系统提示词中。但这会带来几个致命问题：
- 上下文过载：当你有几十个甚至上百个专业技能（如财务分析、库存管理、法律审查）时，单个模型的上下文窗口根本装不下。
- 能力冲突：不同专业领域的指令（如"SQL语法"与"法律条文格式"）混在一起，可能相互干扰，降低Agent在单一任务上的表现。
- 协作困难：在大型组织中，不同团队（如销售部、法务部）无法独立、高效地维护和更新属于自己领域的Agent知识。
为了解决这个问题，一种名为 Agent Skill 的架构模式应运而生。它借鉴了人类"在需要时学习"的理念，成为构建可扩展、专业化Agent的关键技术。
二、什么是skills
Agent Skill 是一种将专业能力封装为可被Agent按需"调用"的模块化单元 。它本质上是一套基于提示词的专业化指令和上下文知识，Agent在需要处理特定领域的任务时，才动态地将其加载到自己的上下文窗口中。
你可以把Agent Skill理解为：
- 对于Agent：它是一个可以随时"翻看"的专业手册。当接到一个销售数据分析的任务时，Agent会先去"书架"上取下《销售分析手册》，翻开阅读里面的表结构、业务逻辑和示例查询，然后再动手写SQL。
- 对于开发者：它是一个可以独立开发、测试和部署的能力插件。销售团队可以维护《销售分析Skill》，库存团队维护《库存管理Skill》，彼此解耦，互不干扰。
三、Skill的核心特征
Skill的核心特征概括为以下几点：
| 特征 | 描述 | 带来的价值 |
|---|---|---|
| 提示词驱动 | Skill的核心是专门编写的提示词，包含特定领域的知识、规则、业务逻辑和示例。 | 相比于用代码实现的复杂工具，提示词驱动的Skill更轻量、更易编写和维护。 |
| 渐进式披露 | Agent在初始时只知道Skill的名称和一句话描述，其详细内容只有在被调用时才加载到上下文中。 | 这是解决上下文过载的关键，让Agent可以拥有无限的知识储备。 |
| 团队自治 | 不同的团队可以独立地为自己的业务领域开发和维护Skill。 | 消除了跨团队协作的瓶颈，实现了企业级Agent能力的规模化构建。 |
| 轻量组合 | Skill相比于一个完整的、拥有自己对话历史的子Agent更为简单。 | Agent通过组合调用不同的Skill，可以快速适应复杂多变的任务。 |
| 资源感知 | Skill的提示词可以指向外部文件（如脚本、模板、数据字典），Agent在需要时会进一步读取这些资源。 | 实现了更深层次的渐进式披露，确保Agent只在必要时加载最详细的信息。 |
四、Skill如何工作？------ 渐进式披露的三层架构
Skill的精髓在于其加载方式，这种模式被称为"渐进式披露"（Progressive Disclosure）。它通常遵循一个三层架构
-
第一层：元数据（轻量级）
- 内容：每个Skill的名称和一句话描述（例如："sales_analytics: 用于销售数据分析，包含客户、订单和收入的表结构及业务逻辑"）。
- 时机：这些信息被常驻在Agent的系统提示词中，占用极少的上下文。
- 作用：让Agent知道它拥有哪些能力，但暂不加载细节。
-
第二层：核心内容（按需加载）
- 内容：Skill的详细提示词，包括具体的业务规则、表结构、操作流程等。
- 时机：当用户的问题明确指向某个领域时（例如，用户问"帮我写个SQL查一下上个月的销售冠军"），Agent会识别出需要"销售分析"技能，并通过调用一个特定的工具（如load_skill）来获取这个Skill的详细内容。
- 作用：此时，Agent的上下文中才真正充满了处理当前任务所需的具体专业知识。
-
第三层：详细资源（深度按需加载）
- 内容：Skill中引用的更庞大的资源，例如完整的数据库Schema文件、代码模板、或上百页的PDF文档。
- 时机：Agent在阅读了Skill的核心内容后，如果发现还需要更底层的细节（比如需要查看某个表的全部字段），它可以再次通过工具调用来读取指定的文件或资源。
- 作用：确保Agent永远只加载"刚刚好"那么多的信息，实现极致的上下文效率。
五、何时使用Agent Skill？
Skill模式并非万能，它最适合以下场景：
- 单一Agent，多领域专家：你希望用一个对话式Agent，处理来自财务、销售、人力等不同部门的问题，且各部门的知识体系相对独立。
- 企业级知识库：你需要为Agent接入大量文档（如产品手册、合规政策），这些文档可以按主题拆分为不同的Skill。
- 需要团队协作：不同的业务团队需要独立维护Agent在自己领域的知识。
当你开始思考"如何添加下一个能力而不撑爆上下文"时：这是采用Skill模式最明显的信号。
六、Skill 与其他模式的对比
为了更精准地理解Skill，我们可以将其与另外两种常见模式进行对比
- Skill vs. 普通工具
- 普通工具：通常是一个函数，用于执行一个动作（如send_email， calculate）。
- Skill：主要是一段提示词，用于提供知识和上下文。它也可以关联工具，但核心是"告诉Agent如何思考和理解"。例如，sales_analytics Skill本身不执行SQL，但它教会了Agent如何正确地写SQL。
- Skill vs. 子Agent
- 子Agent：拥有独立的模型调用、对话历史和工具集，是一个完整的"下属"。
- Skill：是依附于主Agent的"记忆卡"，没有独立的推理循环，更轻量、响应更快。