Skills 不是一段更长的 Prompt而是一种把“领域知识 工作流程 工具 资源”封装成可发现、可加载、可复用能力的方法。在学习 Deep Agents 的过程中Skills 是一个非常值得深入理解的概念。如果说Tools让 Agent “能做什么”Memory让 Agent “记得什么”Subagents让 Agent “把事情交给谁”Filesystem让 Agent “把上下文放在哪里”那么Skills 解决的是 Agent“应该如何完成某一类事情”。LangChain 官方将 Skills 定义为一种可复用的领域能力包可以把工作流、最佳实践、脚本、参考文档和模板资源组织在一个目录中并通过渐进式披露Progressive Disclosure只在任务真正需要时加载详细内容从而避免 Context Bloat。Datawhale 的《Deep Agents 实战》则进一步把 Skills 与 Tools、Memory 等机制放在一起进行比较强调 Skills 更适合承载多步骤工作流 领域知识 资源。本文就来系统拆解 Skills。一、为什么 Agent 需要 Skills先看一个最简单的 Agent用户 ↓ LLM ↓ Tool ↓ 结果例如用户帮我查一下 LangGraph 的 interrupt 怎么使用 Agent ↓ 搜索工具 ↓ 搜索文档 ↓ 回答看起来没有问题。但如果要求 Agent查阅 LangGraph 官方最新文档按照官方推荐方式分析 interrupt 的使用场景给出代码示例并检查 API 是否已经发生变化。事情就复杂了。这已经不是一个简单的 Tool 调用而是一套完整流程1. 找到官方文档入口 2. 判断哪些文档相关 3. 优先阅读概念文档 4. 再阅读具体 How-to 5. 确认 API 6. 综合多个来源 7. 给出代码 8. 避免引用过时信息如果每次都通过 Prompt 告诉 Agent你应该先这样做…… 然后这样做…… 最后这样做……很快就会出现一个问题Prompt 越来越长。而且这些经验无法很好地复用。于是我们可以把这套经验封装成langgraph-docs/ └── SKILL.md这就是 Skill。二、Skills 到底是什么一个 Skill 最基本的结构是skills/ └── langgraph-docs/ └── SKILL.md更完整的结构可以是skills/ └── langgraph-docs/ ├── SKILL.md ├── scripts/ │ └── fetch_docs.py ├── references/ │ ├── api-patterns.md │ └── style-guide.md └── assets/ ├── report-template.md └── schema.jsonLangChain 官方明确采用这种目录式结构SKILL.md是核心文件还可以包含scripts/、references/和assets/等辅助资源。因此可以把 Skill 理解成Skill Instructions Knowledge Workflow Resources Optional Tools它不是单纯的 Prompt。三、Skills 和 Prompt 最大的区别这是理解 Skills 的第一关键点。传统 PromptSystem Prompt ↓ 告诉模型应该怎么做SkillsSkill ├── 什么时候使用 ├── 应该怎么做 ├── 使用哪些参考资料 ├── 是否运行脚本 ├── 输出什么格式 └── 如何处理异常因此Prompt 是一次性的上下文输入而 Skill 更像一个可以被 Agent 发现、调用和复用的能力模块。可以类比软件工程Prompt ≈ 一段配置 Skill ≈ 一个可复用的软件包甚至可以进一步类比npm package ↓ 代码能力复用 Skill ↓ Agent 工作能力复用Datawhale 也采用了类似的类比将 Skills 理解为一种标准化的 Agent 能力分发和复用机制。四、SKILL.mdSkill 的核心一个 Skill 最核心的文件SKILL.md它由两部分组成YAML Frontmatter Markdown Instructions例如---name:langgraph-docsdescription:Use this skill for requests related to LangGraph in order to fetch relevant documentation and provide accurate,up-to-date guidance.---下面# langgraph-docs ## Overview This skill explains how to access LangGraph documentation. ## Instructions ### 1. Fetch documentation index ... ### 2. Select relevant documentation ... ### 3. Fetch and synthesize ...官方文档明确要求name和description位于 frontmatter 中并作为 Skill 被发现和匹配的重要信息。五、description 为什么如此重要这是 Skills 一个非常容易被低估的设计。Agent 启动的时候并不会把所有 Skill 的完整内容全部读进 Context。首先看到的是name description例如langgraph-docs Use this skill for requests related to LangGraph documentation...于是 Agent 根据用户问题 ↓ Skill description ↓ 是否匹配决定是否进一步读取 Skill。因此description 实际上承担了 Skill 的“路由标签”角色。例如不好的 descriptiondescription:Helps with PDFs.问题是什么时候使用 做什么 覆盖哪些任务都不明确。更好的 descriptiondescription:Extract text and tables from PDF files,fill PDF forms,and merge multiple PDFs. Use when working with PDF documents,forms,or document extraction.这样 Agent 更容易匹配。LangChain 官方特别强调Skill 的 description 是 Agent 在发现阶段用于判断是否激活该 Skill 的关键信息因此应该明确说明做什么 什么时候使用。六、Skills 最核心的设计Progressive Disclosure如果让我只记住 Skills 一个概念我会选择Progressive Disclosure渐进式披露。为什么因为 Agent 的能力越来越多Agent ├── PDF Skill ├── Excel Skill ├── LangGraph Skill ├── SQL Skill ├── Code Review Skill ├── Research Skill ├── Report Skill └── ...假设每个 Skill 都有 5000 tokens20 Skills × 5000 100000 tokens如果启动时全部加载Context 爆炸所以 Skills 采用Level 1 Metadata ↓ Level 2 Instructions ↓ Level 3 Resources官方文档将其明确划分为三级加载机制。七、Level 1MetadataAgent 启动Skill A name description Skill B name description Skill C name description而不是Skill A 全文 Skill B 全文 Skill C 全文例如PDF Skill → 处理 PDF LangGraph Skill → 查询 LangGraph 官方文档 SQL Skill → SQL 数据分析这一层的目标只有一个让 Agent 知道“我有哪些能力”。八、Level 2Instructions当用户提出帮我分析 LangGraph interrupt。Agent 发现langgraph-docs可能匹配。于是read_file( /skills/langgraph-docs/SKILL.md )把完整 Skill 加入当前 Context。这时候 Agent 才看到应该访问什么网站 应该先查什么 如何筛选文档 如何验证 如何组织答案也就是说启动 ↓ 知道 Skill 存在 任务发生 ↓ 才读取 Skill 内容九、Level 3Resources如果SKILL.md中进一步引用references/api-patterns.md或者scripts/fetch_docs.pyAgent 才进一步读取或执行。于是Metadata ↓ Instructions ↓ Resources形成三级上下文加载。这个设计非常漂亮因为信息越详细进入 Context 的时间越晚。十、为什么 Progressive Disclosure 很重要可以把它理解成 Agent 的上下文懒加载。传统方式启动 ↓ 加载全部知识 ↓ 执行任务Skills启动 ↓ 加载能力目录 ↓ 用户任务 ↓ 匹配 Skill ↓ 加载具体指令 ↓ 需要什么再加载什么这和软件工程中的Lazy Loading非常相似。所以 Skills 的价值并不仅仅是“方便管理 Prompt”。它实际上是一种Context Management 机制。十一、Skills 的四类组成部分一个完整 Skill 通常包含四类内容Skill │ ┌──────────┼──────────┐ ▼ ▼ ▼ Instructions References Scripts │ │ │ └──────────┼──────────┘ ▼ Assets分别来看。1. SKILL.md负责核心规则 执行流程 决策逻辑 边界条件 输入输出2. references/负责详细知识 API 文档 规范 案例 错误码 领域知识例如references/ ├── api-patterns.md ├── error-codes.md └── style-guide.md它们不需要一开始全部进入 Context。3. scripts/负责可执行逻辑例如scripts/ └── extract_pdf.pyAgent 不需要重新生成一遍 PDF 解析代码而是直接调用经过测试的脚本。于是LLM ↓ Skill ↓ Script ↓ Deterministic Logic这比LLM ↓ 每次重新生成代码更加稳定。4. assets/负责模板 Schema 图片 配置 数据文件例如assets/ ├── report-template.md └── schema.json当任务需要的时候再读取。十二、Skill 不只是“知识”还可以包含 Workflow这是我认为 Skills 和普通知识库最大的区别。例如法律研究 Skill不应该只有什么是合同法 什么是违约责任而应该告诉 Agent1. 明确法律问题 2. 查询现行法律 3. 查询司法解释 4. 检查法规有效性 5. 查找相关案例 6. 区分事实与法律结论 7. 给出引用 8. 标记不确定性也就是说Skill 更接近“怎么做事”而不仅仅是“知道什么”。因此可以形成一个很重要的区别Knowledge 知道什么 Skill 知道如何完成任务十三、Skills、Tools、Memory 到底有什么区别这是最容易混淆的地方。可以用一个简单的表格理解能力核心问题典型内容ToolsAgent 能做什么操作搜索、API、数据库、发邮件MemoryAgent 应该长期记住什么用户偏好、项目背景、持久上下文SkillsAgent 应该如何完成某类任务流程、规范、领域知识、脚本Filesystem中间信息放在哪里文档、结果、分析过程Subagent谁负责完成任务Researcher、Coder、AnalystDatawhale 对 Skills、Memory、Tools 的对比也采用了这一思路Tools 偏向原子操作Memory 偏向持久上下文而 Skills 更适合按需加载的专业能力。十四、一个非常好用的判断方法以后不知道该把东西放在哪里可以问三个问题。问题 1Agent 需要“执行一个动作”吗例如搜索网页 调用 API 查询数据库那么Tool问题 2Agent 需要“长期记住”吗例如用户喜欢中文回答 项目使用 PostgreSQL 公司代码规范那么Memory问题 3Agent 需要“按照一套专业流程完成任务”吗例如做 Code Review 分析 PDF 研究法律问题 生成技术报告 查询 LangGraph 官方文档那么Skill十五、Skills 与 RAG 有什么关系这和前面那篇《Deep Agents RAG》可以直接串起来。传统 RAGQuery ↓ Retriever ↓ Knowledge ↓ LLMSkillsTask ↓ Skill ↓ Workflow ↓ Knowledge / Tools / Scripts ↓ Result所以RAG 主要解决“找到什么”Skill 可以解决“应该怎么找、怎么用”。例如LangGraph Skill里面可以规定优先官方文档 ↓ 先查 llms.txt ↓ 选择 2~4 个相关页面 ↓ 阅读具体文档 ↓ 综合回答这实际上就是Retrieval Strategy 被封装成 Skill。因此可以把二者组合Agent │ Skill │ ┌───────┼────────┐ ▼ ▼ ▼ RAG Tools Scripts │ │ │ └───────┼────────┘ ▼ Result十六、Skills SubagentDeep Agents 的另一个重要设计是Skill 可以和 Subagent 结合。例如Main Agent │ ├── Researcher │ └── research Skill │ ├── Analyst │ └──>Subagent Skill就可以形成专业化 Agent。例如Research Agent Agent Web Search Tool Research SkillReport Agent Agent Filesystem Report Skill这样主 Agent 不需要掌握所有细节。十七、一个重要设计不要让所有 Agent 都拥有所有 Skills假设有20 个 Skills如果所有 Agent 都加载Main Agent → 20 Researcher → 20 Coder → 20 Writer → 20会产生上下文膨胀 能力重叠 Skill 匹配冲突更好的方式Main Agent ↓ 通用 Skills Researcher ↓ Research Skills Coder ↓ Coding Skills Writer ↓ Writing SkillsDatawhale 的实践中也特别强调了主 Agent 与自定义 Subagent 的 Skill 边界通用子 Agent 可以继承主 Agent 的 Skills而自定义子 Agent 则需要显式配置自己的 Skills。十八、Skills 可以形成“能力分层”实际项目可以建立skills/ ├── org/ │ ├── security/ │ └── compliance/ │ ├── team/ │ ├── coding/ │ └── testing/ │ └── project/ ├── deployment/ └── architecture/形成组织级 ↓ 团队级 ↓ 项目级如果出现同名 Skillshared ↓ team ↓ project后面的 Skill 可以覆盖前面的版本。LangChain 官方将这种机制定义为多个 Skill source 的组合并采用last wins的优先级策略。十九、这其实很像软件工程的配置继承例如Base ↓ Team Override ↓ Project Override对应通用能力 ↓ 团队规范 ↓ 项目规范因此 Skills 不仅可以作为能力包还可以成为Agent 的可组合配置层。这对于企业级 Agent 特别有价值。例如 SaaSOrganization Skill Tenant Skill User Skill Request Skill最终构成当前 Agent 能力集合官方文档也支持根据用户、角色、租户、工作区等运行时上下文选择或隔离 Skill library。二十、Skills 甚至可以动态加载例如SKILLS_BY_ROLE{engineering:[/skills/code-review/,/skills/testing/,],data:[/skills/sql-analysis/,/skills/visualization/,],support:[/skills/ticket-triage/,],}那么工程师 ↓ Engineering Skills 数据分析师 ↓ Data Skills 客服 ↓ Support Skills这意味着Agent 的能力可以根据运行时上下文动态变化。而不是所有用户共享同一个固定 Agent。二十一、Skill 还可以携带 Tool这是 Deep Agents Skills 更进一步的地方。一个 Skill 不一定只有Instructions还可以关联专属 Tools。例如Linear Skill可以包含list_issues create_issue但这些工具不是 Agent 启动时全部暴露出来。只有当 Skill 被读取以后相关工具才可以变得可用。官方文档称这种机制为skill tools并说明其目标之一就是让工具 Schema 延迟到真正需要时才进入上下文。于是Skill ↓ Read SKILL.md ↓ Unlock Tools ↓ Execute这进一步体现了Skills 本质上也是 Context Engineering 的一种机制。二十二、为什么“工具延迟加载”很重要假设 Agent 有100 个 Tools每个 Tool 都有name description parameters schema如果全部放进 Prompt100 Tools ↓ 大量 tokens ↓ 模型选择压力 ↓ Tool confusion而 Skills 可以变成启动 ↓ Skill description ↓ 任务匹配 ↓ 读取 Skill ↓ 加载相关 Tool于是100 个潜在工具变成当前任务 ↓ 5 个相关工具这就是典型的Progressive Tool Disclosure二十三、Skills 可以执行代码一个 Skill 还可以携带scripts/例如arxiv-search/ ├── SKILL.md └── scripts/ └── search.pySkill 中规定1. 执行 scripts/search.py 2. 解析搜索结果 3. 提取标题、作者、摘要 4. 返回结果于是 Agent 不需要每次自己生成requests.get(...)而是调用经过验证的脚本。这带来一个很重要的工程价值把不应该交给 LLM 临时生成的确定性逻辑沉淀成代码。形成LLM ↓ Skill ↓ Tested Script ↓ Deterministic Result官方文档也明确支持在scripts/中放置可执行代码并建议脚本具备清晰依赖、错误信息和边界处理。二十四、Skill 是“软逻辑”Script 是“硬逻辑”这个组合非常值得理解。例如Skill 告诉 Agent 什么时候调用 PDF 提取 需要提取哪些内容 遇到扫描 PDF 怎么办 输出格式是什么而Script 负责 真正执行 PDF 提取于是Skill 决策与流程 Script 确定性执行这其实是 Agent 工程中非常理想的组合把不确定性留给 LLM把确定性沉淀成代码。二十五、如何编写一个好的 Skill我认为可以总结成四个原则。原则一description 要“可匹配”不要description:Helps with coding.应该description:Review Python code for security,performance,and maintainability issues. Use when the user asks for code review or requests a Python quality assessment.让 Agent 能回答什么时候应该启用二十六、原则二SKILL.md 不要写成百科全书官方建议 Skill 的主体保持精简文档指出正文应控制在约 5000 tokens 以内同时 Agent Skills 规范建议避免过长的 Skill 文件详细材料应该拆到references/。推荐SKILL.md ↓ 核心流程 references/ ↓ 详细知识而不是SKILL.md ↓ 50000 tokens否则就失去了 Progressive Disclosure 的意义。二十七、原则三为 Agent 写不是为人写人类喜欢背景介绍 理论说明 长篇解释Agent 更需要Step 1 Step 2 Step 3 If A: Do B If C: Do D因此 Skill 应该尽可能包含执行步骤 决策条件 输入示例 输出示例 异常情况 边界条件例如## Workflow 1. Identify the users framework version. 2. Fetch the official documentation. 3. Prefer API reference over blog posts. 4. If multiple versions exist, verify the version. 5. Cite the source.这比LangGraph 是一个非常强大的框架……更适合 Agent。二十八、原则四少而精而不是 Skill 越多越好很多人第一次使用 Skills容易走向Skill 1 Skill 2 Skill 3 ... Skill 50 Skill 51但 Skill 越多并不意味着 Agent 越强。如果出现Skill A “处理代码” Skill B “帮助编程” Skill C “解决开发问题” Skill D “代码分析”Agent 很可能不知道到底应该选择谁因此官方建议减少职责重叠的 Skills必要时合并相关能力。一个好的 Skill 应该边界清晰、职责单一、触发条件明确。二十九、Skill 的最佳抽象能力模块最终可以把 Skill 抽象成Skill │ ┌───────┼────────┐ ▼ ▼ ▼ Knowledge Workflow Resources │ │ │ └───────┼────────┘ ▼ Agent而不是Skill 一份 Prompt这是两个完全不同的理解层次。三十、Skills 与 Context Engineering结合前面《Deep Agents RAG》的讨论可以发现Skills RAG Filesystem Memory Subagents其实都在解决同一个大问题如何管理 Agent 的 Context例如RAG解决需要什么外部知识Filesystem解决大量信息放在哪里Skills解决应该如何使用这些知识和工具Memory解决哪些信息应该长期保留Subagent解决哪些信息应该交给另一个 Agent所以Skills 是 Context Engineering 的重要组成部分。三十一、从 Prompt Engineering 到 Skill Engineering这可能是 Skills 最值得关注的意义。早期 AI 应用Prompt Engineering核心工作怎么把 Prompt 写好后来RAG开始关注怎么给模型提供知识再往后Agent开始关注怎么让模型使用工具完成任务而 Skills 进一步关注如何把专业工作方法沉淀下来于是形成Prompt Engineering ↓ RAG ↓ Tool Use ↓ Agent ↓ Skills ↓ Agent Capability Engineering三十二、Skills 的真正价值把经验资产化假设一个公司的资深工程师知道怎么做 Code Review 怎么排查线上问题 怎么写技术方案 怎么发布服务 怎么进行安全检查过去这些知识主要存在于人的经验 Wiki Prompt现在可以逐步沉淀成skills/ ├── code-review/ ├── incident-response/ ├── architecture-review/ ├── deployment/ └── security-check/于是个人经验 ↓ Skill ↓ Agent ↓ 团队复用这就是 Skills 最有价值的地方把人的工作方法逐步转化为 Agent 可以执行的能力资产。三十三、从个人 Skill 到企业 Skill Library进一步可以形成Skill Library │ ┌────────────────┼────────────────┐ ▼ ▼ ▼ Engineering Marketing Operations │ │ │ ┌────┼────┐ ┌────┼────┐ ┌────┼────┐ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ Code Test Dev SEO GEO Content CRM SOP Support最终企业不只是拥有一个 Agent而是拥有一个 Agent 能力库。Agent 可以根据任务动态组合任务 ↓ Skill Selection ↓ Skill Composition ↓ Tools ↓ Subagents ↓ Result这比单纯做一个“大而全”的 Agent 更容易扩展。三十四、Skills 与 Spec 编程也有联系如果把我们熟悉的软件工程方法放进 Agent 开发可以看到一个有趣的关系。传统开发需求 ↓ Spec ↓ CodeAgent Skills任务 ↓ Skill ↓ Agent Execution一个成熟 Skill 实际上很像Agent 世界中的“操作规范 / 执行 Spec”。例如Code Review Skill可以定义输入 ↓ 检查项 ↓ 判断规则 ↓ 执行工具 ↓ 输出格式 ↓ 验收标准因此未来的 Agent 工程很可能会越来越强调Spec Skill Tool Evaluation而不只是Prompt LLM三十五、一个实际的 Skill 示例例如我们要创建skills/ └── csdn-blog/ ├── SKILL.md ├── references/ │ └── style-guide.md └── assets/ └── article-template.mdSKILL.md---name:csdn-blogdescription:Write technical CSDN articles about AI,Agent,LangChain,and related engineering topics. Use when the user asks to create or polish a CSDN technical blog post.---正文# CSDN Blog Skill ## Workflow 1. Identify the technical topic. 2. Explain the problem before introducing the solution. 3. Prefer architecture diagrams and code examples. 4. Separate concepts from engineering practice. 5. Include common mistakes. 6. End with a concise summary. ## Structure - Title - Introduction - Core concepts - Architecture - Code example - Engineering practice - Common pitfalls - Summary ## Style - Chinese - Technical but readable - Avoid excessive marketing language - Use Markdown headings - Prefer concrete examples这样以后用户 写一篇 Deep Agents 的 CSDN 博文Agent 就可以发现 csdn-blog ↓ 读取 SKILL.md ↓ 读取 style-guide ↓ 使用模板 ↓ 生成文章这就是一个真正可复用的 Skill。三十六、Skill 设计的一个完整心智模型到这里可以形成一个非常完整的模型Agent │ ┌────────┴────────┐ ▼ ▼ Skills Tools │ │ ┌──────┼──────┐ │ ▼ ▼ ▼ ▼ Workflow Knowledge Resources Execution │ │ │ │ └──────┼──────┘ │ ▼ │ Context │ └────────┬────────┘ ▼ Agent Loop │ ┌────────┴────────┐ ▼ ▼ Subagents Filesystem │ │ └────────┬────────┘ ▼ Result这已经不是简单的LLM Prompt而是Agent Harness Capability Modules Tools Context Management三十七、Skills 的边界在哪里Skills 很强但并不是所有东西都应该做成 Skill。例如不适合 Skill查询天气 查询数据库 发送邮件 调用支付 API这些更适合Tools适合 Skill按照公司规范做 Code Review 进行一次完整的法律资料研究 按照固定流程生成技术报告 按照团队规范进行数据库迁移 查阅官方文档并完成 API 分析因为这些都具有多步骤 专业知识 决策逻辑 资源三十八、生产环境还需要考虑权限如果 Skill 可以修改文件 执行脚本 调用工具那么它就不只是“文本”。它已经具备一定执行能力。因此生产环境必须考虑Skill Visibility Skill Read Skill Write Tool Permission Script Execution Human Approval例如企业官方 Skill ↓ Read Only而个人实验 Skill ↓ WritableLangChain 官方文档已经提供了针对 Skill 文件读写的权限控制机制也支持通过权限规则禁止 Agent 修改受控 Skill 库。三十九、Skills 的真正进化方向如果把整个 Agent 发展过程串起来Prompt ↓ RAG ↓ Tools ↓ Agent ↓ Memory ↓ Subagent ↓ Skills ↓ Agent Harness我们会发现早期重点是让模型回答得更好。现在重点逐渐变成让 Agent 完成事情。而 Skills 解决的是让 Agent 学会一类事情并且这种能力可以被复用、组合和持续维护。四十、最终总结如果只记住本文的几个结论我建议记住下面这张图Skills │ ┌───────────┼───────────┐ ▼ ▼ ▼ Workflow Knowledge Resources │ │ │ └───────────┼───────────┘ ▼ Agent │ Progressive Disclosure │ ┌───────────┼───────────┐ ▼ ▼ ▼ Tools Subagents Filesystem │ │ │ └───────────┼───────────┘ ▼ Agent Loop │ ▼ ResultSkills 不是 Prompt 模板。它更像一个可发现、可加载、可组合、可复用的 Agent 能力包。其中最重要的设计不是SKILL.md本身而是背后的Progressive Disclosure启动 ↓ 只知道有哪些 Skill ↓ 任务匹配 ↓ 加载相关 Skill ↓ 按需读取 References / Assets ↓ 必要时加载 Tools ↓ 执行任务这套机制解决了 Agent 越来越强之后必然遇到的一个问题能力越来越多但 Context 不能无限膨胀。因此从 Context Engineering 的角度看RAG 动态获取知识 Filesystem 管理外部上下文 Memory 保存长期上下文 Subagent 隔离上下文 Skills 按需加载工作方法而这几种机制组合起来才逐渐构成真正意义上的Agent Harness。我认为 Skills 最值得关注的长期价值是把人的经验 团队规范 领域知识 工作流程 确定性代码逐步沉淀成可复用的 Agent 能力资产这可能也是从“Prompt Engineering”走向“Agent Capability Engineering”的一个重要信号。参考资料LangChain 官方Skills — Deep AgentsDatawhale《Deep Agents 实战》第 7 章Skills — 可复用的 Agent 能力包DatawhaleDeep Agents 实战项目主页