LLM、Agent和Skill的关系

在搞清楚 skill是什么之前先搞清楚LLM、Agent和Skill的关系。

大模型（LLM，Large Language Model）

代表：GPT、文心一言、通义千问、DeepSeek 等

能干什么：

• 理解自然语言、写文案、翻译、推理、写代码、回答问题
• 输入 prompt → 直接输出文本

局限：

• 本身没有 “行动能力”，不能自己调用工具、联网、操作文件、循环执行任务
• 没有长期目标、不会自己拆步骤、不会自动纠错
• 它只做单次的文本生成，做完一轮就结束
• 知识是静态的（训练截止时间之后的内容不知道，除非外接搜索）

简单比喻： 大模型 = 一个很会动脑、但是坐在原地不动、不能自己动手的聪明人，你问一句，他想一句说一句，不会主动做事。

Agent（智能体）

Agent 是以大模型为核心，额外加上一套运行框架，一般包含这几个模块：

1. LLM（大脑，负责思考、规划、判断）
2. 规划器：把大目标拆成一步步小任务
3. 工具调用能力：联网搜索、代码执行、读写文件、调用 API、控制其他程序
4. 记忆模块：短期上下文记忆 / 长期记忆，记住之前做了什么
5. 反思模块：做完一步检查结果，错了就重新调整方案

一句话总结： 大模型 = 大脑（会思考、理解、生成文字）；Agent = 装上工具、有目标、会规划执行的智能体，大脑一般就是大模型。

大模型是组件，Agent 是一套完整智能系统。

Skill 是什么

Skill 是封装好、可被外部调用的原子能力 / 函数，一般是固定功能：

• 输入参数 → 执行逻辑 → 返回结果 例子：
• search_skill：联网搜索
• file_write_skill：写入文件
• calculator_skill：数学计算
• api_query_skill：查业务后台数据

Skill 本身不会思考，它只会死板地执行一件固定任务，没有自主目标。它就是 “能力实现”，不是智能。 Skill 也不是大模型，很多 Skill 甚至就是一段普通 Python 函数。

比喻：

• Skill：原子可调用能力（手）
• LLM：负责推理、决策的大脑
• Agent：把大脑 + 记忆 + 规划 + Skill 调度 打包起来，能自主完成复杂任务的智能体

再通俗比喻：

• LLM：大脑，会理解需求、做判断
• Skill：工具包里面一个个现成工具：查天气、查数据库、写文件、发邮件、调用接口、运行代码
• Agent：会动脑的工人，拿到目标后，让大脑（LLM）思考：我该用哪个 Skill、先做哪个、做完看结果要不要继续

举一个完整例子

需求：帮我查深圳 AI 产品专员近 3 个月薪资，整理成 markdown 报告保存到本地

1. Agent 拿到目标，LLM 思考：第一步需要搜索薪资数据 → 调用 search_skill
2. search_skill 返回网页内容
3. LLM 看完，判断信息不全，再次调用 search_skill 补充数据源
4. 信息齐了，LLM 整理成 markdown 文本
5. Agent 调度 file_write_skill，把报告写入本地文件
6. LLM 判断目标全部完成，Agent 结束任务

所以skill相当于是给Agent装上能干活的手脚。也可以简单理解为Skill是解决方案的封装（解决方案的流程和步骤）

Skill 的官方定义（Anthropic 标准）

1. 一种开放的技术协议 通过结构化的文件夹（包含指令逻辑、执行脚本、所需资源）来扩展 Agent 的原生能力，是连接 Agent 通用智能与特定领域专业知识的桥梁。
2. 高度模块化 每个 Skill 专注解决一个独立、具体的问题，边界清晰，解耦设计。
3. 代码可复用 一次编写完成，可被不同的 Agent 实例多次调用，避免重复造轮子。
4. 功能可组合 支持多个原子 Skill 自由组合编排，共同协作完成复杂的业务任务。
5. 动态加载 Agent 可根据当前任务需求，灵活地实时加载或卸载对应的 Skill。

Skill 的本质：SOP 的数字化资产化 将人类在特定领域积累的 SOP（标准操作程序）等流程性知识，通过结构化的方式进行封装，转化为 AI Agent 可以“消化”并自动执行的标准化数字资产。

【拓展补充】

• Anthropic是Claude大模型的开发公司，Skill机制最早由Anthropic正式标准化，也是目前行业认可度最高的Skill规范。
• 原子Skill指最小粒度、只完成一件事的技能，比如“PDF提取文本”是原子Skill；“生成月度财务报告”则是组合Skill，需要拆分数据提取、图表生成、文案撰写、排版导出等多个原子Skill协作完成。
• SOP（Standard Operating Procedure）即标准作业流程，是企业里沉淀的标准化做事步骤，比如“报销审批三步流程”“测试报告生成规范”，Skill本质就是把人类的流程经验，变成AI可以自动执行的数字资产。

Skill 的物理结构：一个文件夹就是一项能力

以 pdf-editor-lite/（核心能力目录）为例，完整包含4个组成部分：

1. SKILL.md 核心指令文件（必选）：定义了Skill的核心逻辑与功能
2. scripts/ 可执行脚本目录：包含 merge_pdf.py 等自动化工具脚本
3. references/ 参考文档目录：存放 api_doc.md 接口文档与技术说明
4. assets/ 静态资源目录：存放templates/模板、图片素材等

【拓展补充】 这种文件夹式的结构和日常的项目文件夹逻辑完全一致，好处是易读、易迁移、易管理，不需要特殊的平台格式，普通开发者就能快速上手。其中SKILL.md是唯一必选文件，其他目录根据技能复杂度可选，简单的纯指令型Skill甚至可以只包含一个SKILL.md文件。

SKILL.md 解剖：YAML 元数据 + Markdown 正文

1. YAML 元数据 (Metadata)

代码示例：

---

name: pdf-processing

description: 提取 PDF 文本、合并拆分文档，用户处理 PDF 时调用。

license: MIT

---

定位：模型的「索引卡片」 定义技能的核心身份信息，帮助模型快速判断当前对话场景是否需要激活并调用该 Skill。

注意：License许可不是必须的，看情况。但是必须有name和description，遵循YAML格式，类似之前学的Json格式的键值对：”key: value”，注意，冒号后面必须要有空格。

2. Markdown 正文 (Body)

标准结构：

# 技能核心说明文档

## 适用的具体业务场景 (When to Use)

## 详细的任务执行步骤 (How to Do)

## 关键的边界注意事项 (Attention)

定位：模型的「工作指南」 提供详尽的任务执行逻辑、上下文约束与操作细节，指导模型在调用后如何高质量地完成具体任务。

正文部分就像提示词工程，但是它比提示词工程要更全面一点，因为提示词工程基本就是纯文字，没有涉及到脚本之类的。

Markdown 是一种轻量标记语言，用简单符号排版文字，写出来干净，能直接转成网页、文档、笔记。后缀一般是 .md。是用简单符号代替 Word 的各种菜单加粗、标题、列表，易写易读，GitHub、语雀、Notion、掘金、很多文档都在用。

和 YAML 区别：

YAML：配置文件，给程序读

Markdown：写文档、笔记，给人看

【拓展补充】

• YAML是一种轻量级配置文件格式，语法简单、人类易读，这里用来存放元数据，就像商品的标签，让大模型一眼就能看懂这个技能的用途和边界。
• 正文的三段式结构（什么时候用、怎么做、注意什么）完全贴合人类工作手册的逻辑，大模型能精准理解执行边界，避免乱调用、瞎操作。
• MIT是最宽松的开源许可证，允许商业使用、修改和分发，是开源Skill最常用的协议。

渐进式披露：Skill 的省 Token 秘诀

三层按需加载机制

1. Level 1 · 元数据 约100 Tokens，Agent 启动时，仅加载核心 name 与 description
2. Level 2 · 指令层 小于5000 Tokens，任务匹配成功后，才完整加载 SKILL.md 指令集
3. Level 3 · 资源层 按需动态加载，模型推理判定需要时，才读取 References 或执行脚本

效果对比

传统“一次性投喂” VS Skill 渐进式披露 拒绝一次性塞入海量冗余信息，大幅提升 Token 利用率 Context 占用下降80%以上，显著降低上下文窗口压力

【拓展补充】

• Token是大模型处理文本的基本单位，1000Token大约对应700-800个汉字。大模型的上下文窗口（能同时“记住”的文本长度）有限，且Token越多，推理速度越慢、调用成本越高。
• 渐进式披露就像查字典：先看目录（元数据）找到对应词条，再看详细解释（指令），需要例句再翻附录（资源），而不是把整本字典全塞进脑子里。Skill数量越多，这种机制节省的Token比例越明显。

工作流示例：Agent 如何使用 Skill

以“PDF转Word”任务为例，完整执行流程分为5步：

1. 用户提问：“帮我把这个 PDF 转成 Word”
2. 检索元数据：发现 pdf-processing Skill 符合当前需求
3. 读取 SKILL.md：查阅文档，明确需要调用 pdf_to_docx.py 脚本
4. Agent 执行脚本：运行命令 python scripts/pdf_to_docx.py input.pdf
5. 获取执行结果：任务完成，将转换后的文件路径返回给用户

💡 核心洞察：Agent 并不需要自己编写复杂的转换代码，它的核心价值在于根据用户需求进行“决策”和“调度”，将任务分发给最合适的 Skill 去执行。

【拓展补充】 这个流程清晰划分了大模型和脚本的分工边界：大模型做“选择题”和“调度题”（判断用什么工具、按什么顺序用），脚本做“执行题”（确定性的代码运行）。既发挥了大模型的自然语言理解和任务规划能力，又保证了执行的稳定性，避免了大模型手写代码容易出错的问题。

小结

1. Skill 的核心构成

• 元数据 (Metadata)：核心目标是让用户“找得到”需要的服务
• 指令 (Instruction)：核心目标是让系统“懂得做”具体的任务
• 脚本 (Script)：核心目标是让服务真正“做得动”并执行

2. 渐进式披露的核心优势

• 像“翻字典”一样高效：按需查找，聚焦当前任务。用户只获取当下需要的信息，精准且无负担。
• 拒绝“背词典”式记忆：避免一次性灌输海量信息，极大地降低了认知门槛，提升了用户的使用体验。

【拓展补充】 这里的“用户”同时也指代大模型本身。对大模型来说，一次性加载所有技能说明就是“背词典”，认知负荷极高，很容易出现遗忘、混淆、错用；渐进式加载让模型只处理当前任务相关的信息，调用准确率和执行效率都会显著提升。

使用篇：如何让 Agent 拥有“超能力”？

STEP 01 寻找 Skills 核心市场

• 官方仓库：直接访问 Anthropic 官方 GitHub 技能库

• 社区生态：OpenClaw、Cursor 插件市场等活跃社区

STEP 02 下载 Skill 一键启用

• 放置目录：将下载文件夹拖入项目的 .claude/skills/ 目录

• 自动加载：Agent 启动时会自动扫描并加载新技能

【拓展补充】 .claude是Claude桌面客户端的本地配置目录，类似VS Code的.vscode目录，用于存放自定义配置和扩展能力。目前主流的Agent客户端（如Claude Desktop、Cursor编辑器）都支持这种目录式Skill加载，无需复杂的部署和配置，拖拽即可完成安装。

两种调用模式：显式 vs 隐式

1. 显式调用 (Explicit)

核心逻辑：用户主导，指令明确 用户通过特定的指令前缀（如 @符号）直接告诉 Agent 需要调用哪个 Skill，系统接收到明确的信号后立即执行。

典型指令示例：@pdf 帮我把这份合同文档转为高清图片格式

2. 隐式调用 (Implicit)

核心逻辑：Agent 主导，智能匹配 Agent 自动解析用户的自然语言需求，结合 Skill 的元数据描述（功能、参数等）进行意图匹配，自动激活最合适的 Skill 来解决问题。

自然语言交互示例：用户说“这份合同对方没法编辑，帮我处理一下” → 自动激活pdfSkill

【拓展补充】

• 显式调用适合精准场景：你明确知道要调用的技能名称，不会出现误匹配，执行效率最高；
• 隐式调用适合日常自然交互：用户不需要记忆技能名称，使用体验更好，但对元数据的描述质量要求很高，描述越精准具体，匹配准确率越高；
• 企业内部落地一般推荐“隐式为主、显式为辅”，兼顾使用体验和可控性。

下面开始实操：

可以去腾讯维护的一个skill库找找现成的skill：SkillHub - 专为中国用户优化的 AI Skills 社区

安装一个skill流程：

随便在主页找到一个，点进去，下载一个放在.claude/skills文件夹下

给它解压

前面说的三个文件都有。

_meta.json`程序 / 平台包的身份、依赖、资源索引，用来加载、安装、校验这个技能包SKILL.md`AI + 人技能的业务规则、提示词、执行逻辑（真正干活的指令）

CHANGELOG.md`人版本更新记录，每次改了啥`scripts/`程序要跑的脚本

references/`AI参考资料、知识库素材

由于现在一个skill也相当于是一个软件，所以需要一个_meta.json（元信息清单文件），

它是给平台 / 加载器程序读的配置清单，不是给人看的说明书，相当于这个 skill 包的身份证 + 打包清单。

里面一般存这些信息：

技能名字、版本号（和你文件夹 `tupiangaizi-1.0.2` 对应）；

作者、标签、简介、许可证；

依赖：这个 skill 依赖哪些别的技能、工具；

目录声明：告诉系统去哪里找 `scripts`、`references` 里面的资源；

兼容要求：最低支持哪个版本的运行环境；

校验信息、唯一 ID；

平台先读 `_meta.json`，才知道怎么加载这个 skill 包，再去读取 SKILL.md 和脚本资源。

有些skill下面还会昂一个readme文件来描述项目（说明该项目是用来干嘛的），example文件是使用示例。

反正除了references、scripts和SKILL这三个，其他都是可有可无的文件。

加载skill是在客户端，决定用哪个skill是由大模型决定的，所以skill的描述一定要尽可能写得详细一点。脚本是Agent执行的，不是大模型执行的，执行的结果会交给大模型。

现在用VS code打开这些文件看看

先看SKILL

红框内的就是元数据，然后下面全是正文内容。

现在可以在Claude上确认一下我们这个skill是否安装好了

可以看到我刚刚放在.claude/skill文件夹下的skill，说明成功安装好了

它告诉我们可以用/加名字的方式使用对应的skill

它会一步一步告诉我们应该怎么使用

让它把图片上红框的文字改掉试试

改好了变成这样

开发篇：从零写一个“测试报告分析”Skill

核心需求：自动化测试报告分析 每日自动解析 JUnit XML 报告，自动计算并输出通过率、失败用例详情及 Top3 崩溃堆栈信息。

四步开发流程

1. Step 01 · 创建项目目录 初始化项目根目录：test-report-analyzer/，作为所有代码和配置的容器。

2. Step 02 · 定义技能规范 (SKILL.md) 明确输入源（XML路径）、输出数据结构（JSON）及边界错误处理逻辑。

3. Step 03 · 编写解析脚本 开发scripts/parse_junit.py，实现XML解析、通过率计算与堆栈提取。

4. Step 04 · 技能集成测试 将 Skill 完整目录交付 Agent，使用真实的历史测试报告进行调用验证。

【拓展补充】

• JUnit是Java生态最主流的单元测试框架，它输出的XML格式测试报告是测试团队日常高频处理的文件类型；

• 这个开发流程和普通软件开发完全一致：建项目→写需求文档→写功能代码→测试验收，只是多了一份给大模型看的“说明书”（SKILL.md），普通后端/脚本开发者几乎没有学习成本。

编写高质量 SKILL.md 的三条铁律

1. 触发条件要精准 写清楚“当用户提到 JUnit XML 且需要计算通过率时调用”，明确模型的触发时机。

2. 边界要写死 明确网络超时重试3次、文件不存在报错、SQL只允许SELECT语句等规则，规避异常风险。

3. 输出要结构化 要求返回固定的 JSON Schema，规范数据格式，方便 Agent 进行下一步的自动化处理。

【拓展补充】 这三条是行业大量踩坑后总结的最佳实践：

• 触发条件模糊会导致误调用：比如描述只写“处理文件”，用户说“处理一下数据”也会被匹配到，造成不必要的干扰；

• 边界不清晰会导致风险操作：比如没限制SQL只能查询，大模型可能会执行删改操作，引发生产事故；

• 输出不结构化会导致无法串联：如果输出是自然语言，下游的其他Skill没法直接读取使用，就无法实现多技能的自动化编排。

下面开始实操：

知道怎么使用一个skill后

接下来自己写一个skill试试

写一个“自动化测试报告分析”：每日自动解析 JUnit XML （Java做单元测试的框架）报告，自动计算并输出通过率、失败用例详情及 Top3 崩溃堆栈信息。

第一步，创建项目目录

第二步，创建好目录之后进去创建一个SKILL.md文件

这一步可以用VS code打开创建好的文件夹

在元数据这里要把依赖的库也写上

因为我们要参考到这个文件，所以要创建一个这样的文件：

第三步，编写解析脚本

解析数据要用到脚本，所以要创建一个脚本文件夹

其实reference和scripts这两个不是必须的，有些skill的项目文件中就只有一个SKILL.md，主要还是看流程复不复杂，项目有没有要求。

第四步，技能集成测试

现在刚刚写好的skill已经有了，现在让它分析一份报告测试一下

解析完成，skill没有问题。

避坑指南：Skill 开发常见误区

误区1：代码组织混乱

• 典型错误：直接在 SKILL.md 中塞入数千行代码，导致文档臃肿、维护困难。

• 推荐做法：核心逻辑迁移至 scripts/ 目录；MD 文件仅保留功能说明与调用指令。

误区2：描述信息模糊

• 典型错误：description 字段仅写“处理文件”等模糊词汇，缺乏关键词，无法被索引。

• 推荐做法：包含具体业务关键词（如“提取 PDF 元数据”），精准描述功能，提升匹配度。

误区3：依赖环境缺失

• 典型错误：依赖库需用户手动安装，操作门槛高，且容易因环境差异导致运行失败。

• 推荐做法：脚本内置依赖自动检测与安装逻辑；或使用 Docker 沙箱封装完整运行环境。

【拓展补充】

• 代码混在文档里是新手最容易犯的错误，SKILL.md的定位是“说明书”不是“代码库”，就像手机说明书不会印电路板原理图一样；
• 描述模糊是影响Skill使用率的核心原因，元数据就是Skill的“搜索关键词”，写得越具体，被大模型匹配到的概率越高；
• 环境一致性是脚本类工具的老大难问题，“在我电脑上能跑，在你电脑上跑不起来”，Docker是目前解决这个问题最成熟的方案。

企业落地三件事（测试团队视角）

1. 盘点手工作业 打开终端历史记录，筛选做过5次以上的高频操作，将其统一封装成可复用的 Skill。
2. 规范设计 定义清晰的输入输出参数，完善异常错误处理逻辑，形成团队统一的开发与交付标准。
3. 单元测试 Skill本质是代码，代码必须具备可测试性。这也是Skill相比传统Prompt工程的核心优势之一。

【拓展补充】

• 优先封装高频重复操作，投入产出比最高。比如每天都要做的测试报告解析、日志查询、数据导出，做成Skill能节省大量人工时间；
• 传统Prompt工程是纯文本提示，没法做自动化测试，全靠人工试错；而Skill包含可执行代码，可以编写单元测试、集成测试，稳定性和可维护性远超纯Prompt方案，这也是企业级生产落地更青睐Skill的核心原因。

Skill 的版本管理策略

1. 遵循 Git 语义化版本 严格遵循语义化版本规范命名，例如：v1.0.0, v1.1.0, v2.0.0，让版本变动逻辑清晰、状态可追溯。

2. 重大变更升级 Major 版 当进行不兼容的核心功能迭代时，必须及时升级主版本号（Major），最大程度避免影响现有依赖旧版本的 Agent 稳定运行。

3. 搭建内部 Skill Registry 建议企业搭建私有 Skill 仓库（类似 npm），实现 Skill 资产的统一版本管理、安全高效分发与精细化的权限控制。

【拓展补充】

• 语义化版本（Semantic Versioning）格式为「主版本号.次版本号.修订号」：主版本号代表不兼容的重大修改，次版本号代表向下兼容的功能新增，修订号代表向下兼容的bug修复，是软件开发领域的通用标准；

• Registry即软件仓库，类似前端的npm、Java的Maven，企业搭建私有仓库，可以统一管理所有内部Skill，控制访问权限，保障内部资产安全。

安全与沙箱：不让 Skill 变成“特洛伊木马”

⚠️ 核心风险隐患 Skill 脚本可能被植入恶意指令（如 rm -rf /）或非法窃取环境变量，若缺乏管控，AI 助手极易沦为攻击系统的“特洛伊木马”。

三层防护措施

1. 人工代码审计 强制要求所有 Skill 脚本代码可审计，由安全团队进行人工 Review，从源头拦截恶意逻辑与漏洞。
2. 容器沙箱隔离 基于 Docker 容器构建独立的隔离环境（如 MS-Agent 的 ms-enclave 方案），将脚本执行限制在受控空间内。
3. 权限最小化 遵循最小权限原则，仅授予 Skill 访问指定工作目录的权限，严禁跨目录读写或调用系统敏感接口。

【拓展补充】

• rm -rf / 是Linux系统的高危命令，会删除根目录下所有文件，直接损毁整个系统，是最典型的恶意脚本示例；环境变量中通常存储数据库密码、API密钥等敏感信息，窃取后会造成严重的数据泄露；
• 沙箱（Sandbox）是一种经典安全机制，让程序在封闭、受限的环境中运行，就算程序出现问题或带有恶意，也影响不到外部主系统，是执行不可信代码的标配方案；
• 最小权限原则是安全领域的黄金法则：只给程序完成任务必须的最少权限，多一点都不授予，就算被攻破，损失也能降到最低。

性能优化：Skill 太多会不会影响模型反应速度？

核心疑问

100 个 Skill 的元数据占据约 10k tokens，是否会导致模型推理速度显著下降？

解答

完全不会。采用渐进式披露机制，仅注入 Skill 核心元数据（单 Skill 仅几十字），整体 Token 开销极低，对响应速度影响微乎其微。

进阶优化

针对超大型项目，建议引入 RAG 动态检索机制，根据用户提问实时召回相关 Skill，替代全量注入，大幅提升系统运行效率。

【拓展补充】

• 10k tokens大约对应7000多汉字，对当前主流大模型（上下文窗口普遍达到几十万token）来说占比非常小，确实不会对推理速度造成明显影响；
• RAG（检索增强生成）就是用向量检索技术，从海量Skill库中快速找出和当前问题最相关的少数几个，只把这几个的元数据提供给大模型，适合企业内部有上百上千个Skill的超大规模场景，可以进一步降低token消耗，同时提升匹配准确率。

自动生成Skill实操

要是觉得自己写skill有点麻烦，也可以直接用coze生成skill：扣子编程，你的 AI 开发伙伴， Vibe Coding 基础设施，自然语言对话开发智能体、工作流、网页应用、移动应用，一键部署上线

注意，提示词要尽可能规范才能生成好的skill，可能需要很多提示词，不太可能就这一句话就能生成很好的skill。

Coze写好的skill可以下载下来放到claude中测试一下可不可用

目前测试skill的最好方式就是手工测试。

我们也可以在找找有没有能生成skill的skill。也可以直接叫workbuddy帮忙创建或者安装一个skill。

可以直接把skill的文件包复制到对话框，提示词让它安装，使用的话就直接在对话框打了/这个符号，然后把任务告诉它，它就自己调用这个skill工作了

或者如果有想法的话可以把自己的想法直接告诉workbuddy帮忙创建一个skill。

以下我们用的一个示例来演示一下做一个简单的skill完整的工作流：

做一个homework改作业的skill，如果有别的用户要安装这个skill，那就必须要有一个引导的流程：

然后将引导流程告诉workbuddy

之后再把标准工作流程（SOP）发给它，一个skill就做好了，如果觉得自己梳理标准工作流太难，不会梳理，可以直接叫它帮忙梳理。

这只是一个简单的skill的标准工作流程，后面会继续更新到复杂的skill的制作过程。

这么看来skill跟我们写代码的时候写的那些函数的作用有异曲同工之妙，就是把一些频繁的操作单独封装成可重复调用的工具。