第 7 章：Skills 的含义、作用与运行机制
本章解释 Skill 怎样保存工作方法、怎样被发现和读取，以及它与提示词、项目约定、工具和 MCP 的区别。故障处理单案例用于说明固定规则与每次输入的关系。
7.1 什么是 Skill
把工作方法整理成可复用的技能
Skill 可以理解为：供 Agent 使用的一套任务说明，以及完成任务时可能需要的资料、模板和脚本。 一个 Skill 对应一项相对明确的工作，例如整理故障处理单、核查订单数据或检查 Python 项目的交付材料。
OpenAI 将技能描述为包含说明与资源的文件夹，用于组织可以重复使用的工作流程，核心文件是 SKILL.md。官方 Skills 概念说明
以将故障记录整理为Word的任务为例，每次都可能需要交代：
- 先读取故障原文，再提取已经确定的事项。
- 行动清单要包含任务、负责人和完成日期。
- 没有说明的负责人或日期写“待确认”。
- 输出真正的 Word 文档，并检查表格与排版。
如果这些要求经常重复，就可以整理成“故障处理单制作”技能。下一次仍然需要提供新的故障记录，但不用重新写一遍完整方法。
Skill 不等于重新训练模型
使用技能时，Agent 读取说明和资源，结合当前输入执行任务。保存一个技能文件，不意味着模型参数已经改变，也不意味着所有客户端都会自动获得它。
可以把关系理解为：模型理解和判断，Agent 组织执行，工具完成具体操作，Skill 提供可复用的方法和资源。
什么值得做成技能
优先选择经常重复、规则比较稳定、结果能够检查的任务。例如，订单统计口径和 Word 故障处理单结构都比较明确。
只发生一次的简短改写，直接提出要求通常就够了。如果工作方法还没有跑通，先完成一次真实任务，再提炼技能，往往更容易发现遗漏。
7.2 Skill 与其他概念有什么区别
这些概念可以配合使用，下面按本课程中的主要用途区分：
| 概念 | 主要解决什么问题 | 本课程例子 |
|---|---|---|
| Prompt，提示词 | 这一次要做什么 | 把这份故障记录整理成 Word 文档 |
| 项目规则 | 在这个项目里遵守什么约定 | Python 项目只使用标准库、输出中文 |
| 记忆 | 保存后续可能用到的偏好或背景 | 用户偏好简洁的中文说明；是否保存取决于产品设置 |
| 知识库或参考资料 | 有哪些事实和资料可查 | 故障排查流程说明、订单状态定义 |
| Skill | 这类工作按什么方法完成 | 读取记录、提取行动项、生成文档、检查结果 |
| 工具 | 实际执行什么操作 | 读文件、运行 Python、写入文档 |
| MCP | 怎样按协议连接外部工具或资源 | 接入一个提供资料查询能力的服务 |
| 插件 | 怎样打包、安装和分发一组能力 | 把相关技能和工具集成一起提供 |
例如，参考资料说明“只有已支付才算有效”；技能要求先读取该口径，再进行统计；Python 脚本负责计算；当前提示词指定这次处理哪个文件。
插件的具体组成因平台而异。在 OpenAI 的插件体系中，技能可以与 MCP 服务配合：服务提供工具，技能组织如何使用工具完成任务。技能与 MCP 的关系
因此，不必为了制作第一个技能就先开发 MCP 服务，也不必每个技能都包含程序代码。
7.3 一个 Skill 通常包含什么
一个包含可选资源的 Skill 可以采用以下结构：
incident-notes/
├── SKILL.md 技能用途和工作步骤
├── references/ 可选：故障整理规则与示例
├── assets/ 可选：Word 模板等资源
└── scripts/ 可选：生成或检查文件的程序以上为目录结构示意。最小技能可以只有 SKILL.md，其他目录按实际需求增加。Codex 官方说明列出了名称、描述、正文及可选资源的组织方式。技能文件结构
名称与描述：让 Agent 知道什么时候考虑它
名称用于标识技能，描述应说明用途和适用场景。
例如，“帮助处理文件”很难区分应该用于哪类任务；“根据故障记录整理结论、行动项和待确认问题，用于编写故障处理单”就明确得多。
描述不是营销语。写清楚什么时候使用，比声称“功能强大、适用所有场景”更有用。
正文：说明怎么完成任务
正文应让 Agent 知道输入是什么、先做什么、缺资料怎么处理、输出什么、怎样检查。
本章故障处理单的方法可以概括为：
读取原文 → 区分已确定与待确认事项 → 提取行动清单
→ 生成 Word 文档 → 对照原文检查事实与排版资料、模板与脚本：分别放合适的内容
长篇业务规则可以放进参考资料；固定版式可以放进模板；需要稳定重复的计算可以交给脚本。技能正文说明何时读取或使用它们。
例如，第三章 Excel 的已支付订单统计规则属于业务口径；第四、五章 Python 中经过验证的统计代码，后续可以作为数据处理技能的脚本资源。包含脚本后，还要说明运行环境、参数和失败时的处理方法。
7.4 Agent 怎样使用 Skill
从发现技能到执行任务
可以用下面的过程理解：
- 客户端发现当前环境中可用的技能。
- Agent 根据名称、描述和用户要求判断是否需要使用。
- 使用时读取技能正文，再按需要读取配套资源。
- 结合本次输入调用工具，生成并检查结果。
Codex 使用按需加载的方式：先获得技能的基本信息，选中后再读取完整说明。这通常称为“渐进式加载”。它不意味着所有资源会一次性进入上下文，也不意味着安装越多就一定越好。Codex 技能加载机制
显式指定与自动匹配
显式指定，是用户明确要求使用某个已可用的技能。自动匹配，是 Agent 根据任务与技能描述选择技能。自动匹配是否发生，还受客户端支持和技能配置影响。
例如，可以先在技能列表确认某个故障处理单技能已经可用，再选择它并提出本次任务。具体入口和调用方式在下一章分别演示，不把一个客户端的操作直接套到另一个客户端。
WorkBuddy 官方技能页面提供技能市场与已安装技能入口，并介绍本地包导入、查找与创建方式。WorkBuddy 技能说明
怎样判断它真的起了作用
区分三件事：技能是否可用、执行时是否读取、最终结果是否符合要求。只看到技能名称出现在列表里，不能证明这次任务已经使用它。
操作时结合客户端显示的技能调用或文件读取记录，检查执行过程；再打开结果文件核对内容。即使界面显示调用成功，也要继续检查事实和格式。
7.5 简单案例：把 Word 故障处理单的方法固定下来
先展示原来重复输入的要求
打开第十章的独立故障记录B，展示下面这段要求：
请读取故障记录B.txt，生成故障处理单.docx。
包含已确定事项、行动清单和待确认问题。
行动清单使用可编辑表格，列出任务、负责人、完成日期。
缺少负责人或日期时写“待确认”，不补造损失金额和根因。
对照原文检查事实，并检查 Word 文档的表格与分页。这是一段本次任务的提示词。如果每次都要重复，就可以把其中稳定的规则提炼进技能。
分清固定方法和每次变化的输入
| 固定到技能里的内容 | 每次任务提供的内容 |
|---|---|
| 提取确定事项、行动项和待确认问题 | 本次故障记录 |
| 缺失信息不猜测 | 本次明确补充的信息 |
| 使用 Word 表格表达行动清单 | 本次输出文件名与位置 |
| 检查事实、表格与排版 | 本次特殊格式要求 |
技能不应该把“小陈负责整理两份JSON样例”写成每次都使用的规则。这是某次故障的事实，应从本次资料读取。
再展示使用技能后的任务表达
当相应技能已经制作、安装并可用后，本次要求可以更简洁：
请使用已安装的故障处理单技能，处理故障记录B.txt。
输出到当前工作空间的“订单故障处理单.docx”。以上是技能已安装时的请求示例。请求本身不会创建或安装技能；安装与实际调用将在下一章介绍。
最后打开结果，检查关键事实
本次材料应得到以下行动项：
| 任务 | 负责人 | 完成日期 |
|---|---|---|
| 整理两份JSON样例 | 小陈 | 2026-10-16前 |
| 检查中文CSV导出 | 待确认 | 待确认 |
| 整理排查说明 | 待确认 | 2026-10-17与2026-10-18存在冲突 |
记录日期为2026-10-15，生产修复日期未确定。排查说明日期有冲突；自动重发支付回调明确本次不做。还要用 Word 或 WPS 打开文档，检查表格能否编辑、内容是否被裁切。
技能的价值在于复用明确的方法，是否可靠仍需换一份输入再次检查。
当技能需要使用 MCP
故障处理单可以只读取本地文件；文档查询技能则可以要求 Agent 先调用文档 MCP 检索，再读取原文并整理引用。两者都可以使用 Skill，差别在于执行时依赖的工具。
技能正文应写明需要什么能力、如何使用返回结果、服务不可用时怎样处理。MCP 服务连接和访问授权由运行环境与服务端配置；写一段技能说明不会自动建立连接。Skills 与 MCP 的分工
7.6 Skills 的能力边界
有说明，还需要执行条件
如果技能要求生成 Word 文档，环境中必须有相应生成能力；如果要求运行 Python，必须有可用解释器；如果要求从外部服务取数据，还需要服务连接与授权。
技能可以附带脚本和资源，帮助完成工作，但在说明里写“读取某系统数据”并不会自动获得系统访问权限。也不能把缺少工具时生成的普通文本改名为 .docx，就算完成文档任务。
同一个技能，换环境后要重新检查
WorkBuddy 与 Codex 的安装位置、可用工具和执行环境可能不同。一个技能在其中一款软件运行成功，并不能直接证明另一款软件无需调整。
Codex 从 OpenAI 模型切换到 DeepSeek 后，也要区分：技能是否被发现、说明是否被读取、模型是否正确执行、工具是否正常工作。不要把所有失败都归因于模型。
方法写得清楚，仍然要检查成果
技能可能有过时规则、缺失步骤或不适合当前输入的假设。学习制作技能时，不只是写好一份说明，还要准备样例、观察失败并持续修改。
下一章先学习查找、安装与使用已有技能；随后再从一个小任务出发，逐步制作自己的技能，并加入模板、资料和 Python 脚本。