从重复 Prompt 到程序性知识，理解 Agent Skill 为什么出现、为什么采用文件夹形式，以及它在 Agent 系统中真正解决什么问题。

我们已经有 Prompt，有 AGENTS.md，有 MCP，也有各种 Agent Framework。

那么，为什么近一年来，Agent 生态又开始认真讨论一种看起来过于简单的东西：一个目录，一份 SKILL.md，再加上一些可选的脚本和参考文件？

初看之下，Agent Skill 甚至不像一项“技术”。它没有新的推理算法，没有新的模型接口，也没有替代 MCP 的连接协议。任何人都可以在本地新建一个文件夹，写几段 Markdown，然后把它交给 Agent 使用。

但恰恰是这种简单，让我开始在意一个问题：Skill 为什么偏偏长成了一个文件夹？

如果它只是复用 Prompt，为什么不把内容直接放进系统提示词？如果它只是连接外部能力，为什么不使用 MCP？如果它真的能扩展 Agent 的能力，为什么不把它设计成一个新的 Agent 或一个专门的框架？

这篇文章不准备把 Skill 解释成“又一个要安装的概念”。我更想从这个问题出发，理解它在 Agent 系统中出现的原因：当模型已经足够通用后，我们究竟还缺少什么；为什么这种缺口更接近“做事经验”，而不是更多事实；又为什么文件夹成为当前最自然的封装形式。

先给出本文的核心判断：

Agent Skill 不是 Prompt 的高级皮肤，也不是 MCP 的替代品。它是一种把任务级程序性知识打包、发现、按需取用和持续维护的工程载体。

后文会进一步展开这句话。这里先澄清一个边界：不同 Agent Harness 对 Skill 的发现、加载和执行方式并不完全一致。开放规范定义的是目录与文件的最小格式；“metadata 常驻、正文触发后读取、资源按需访问”则是 Anthropic 等具体运行环境采用的一种重要实现，而不是所有系统的必然行为。Agent Skills Specification Anthropic Agent Skills Overview

本文每一节结尾都会留下一组“本节自检”。它们不是为了考察读者是否记住术语，而是为了检验：离开原文后，能否用这一节的概念判断一个具体设计问题。如果只能复述定义，却无法回答自检问题，说明理解可能还停留在表面。

1. Skill 出现前，Agent 真正缺少什么？

理解 Skill，不能从“它由哪些文件组成”开始，而应从一个更实际的场景开始。

假设你让 Agent 完成一项工作：根据客户反馈、产品文档和历史工单，生成一条研发可以直接处理的需求。第一次做时，你通常会在对话中补充大量信息：问题应该如何分类，哪些字段必须填写，怎样判断反馈是否重复，什么时候需要向人工升级，最终输出应该长什么样。

这一次任务也许完成得不错。可下一周，另一个客户提出类似问题，新的会话又开始了。你不得不重新输入规则，重新解释产品背景，重新提醒它不要承诺交付时间，也不要把未经验证的客户猜测写进需求结论。

这时，缺少的并不是模型的通用知识。

模型大概已经知道什么是客户反馈、Issue 和产品需求。真正稀缺的是这家公司的做事方式：怎样从原始反馈中提取证据，怎样定义“可执行需求”，什么情况必须人工判断，以及怎样算完成得足够好。

这类知识在认知科学中常被称为程序性知识。它不是“知道什么”，而是“知道在特定条件下怎样做，以及怎样才算做对”。

事实性知识：客户工单通常包含标题、描述和优先级。

程序性知识：处理客户反馈时，先确认客户、产品版本和复现条件；
证据不足时不要下根因结论；涉及数据丢失或合同承诺时，必须转人工审核。

两者都重要，但它们解决的问题不同。

事实性知识更接近“我要知道什么”，适合放在文档、数据库、知识库或 RAG 系统里，按问题语义检索。程序性知识更接近“这类任务应该怎样推进”，它的触发信号往往是任务类型：生成需求、审查变更、发布服务、处理告警、制作报告。

这也是 Skill 出现的第一个原因：Agent 需要的并不总是更多资料，而是可跨会话复用的做事协议。

---

本节自检

1. “客户反馈分诊流程”和“产品套餐权限表”分别更接近程序性知识还是事实性知识？为什么？
2. 为什么模型知道什么是 Issue，却仍可能不知道怎样为某个团队写出可执行的 Issue？
3. 如果一条经验只适用于某位客户的一次特殊事件，它适合直接写成通用 Skill 吗？还缺少什么判断？

2. 为什么一段长 Prompt 不够？

长 Prompt 并不是无效。事实上，一个好的 Skill 往往就来自一段在真实任务中反复验证过的 Prompt。

而且，完全可以为每一类任务准备一份任务级 Prompt。面对“客户反馈分诊”任务时，把完整流程作为 Prompt 传入当前对话，在技术上没有任何问题；任务量不大、规则仍在快速变化，或者你只是验证一个想法时，这通常还是最合适的做法。

因此，Prompt 与 Skill 的区别，不是“前者一次性、后者任务级”。两者都可以是任务级的。真正的区别在于：这套任务知识是否需要脱离某一次对话，成为一个可发现、可组合、可维护的工程对象。

一次性任务 Prompt：
在当前对话中临时说明目标、限制和输出格式。

可复用 Prompt 模板：
保存一段任务说明，由人每次复制、填写参数并显式发送。

Skill：
将任务说明、触发条件、参考资料、模板和可选脚本一起打包；
由 Harness 或 Agent 在合适的任务中发现并加载。

这不是一条严格的边界，而是一条连续谱。一个被版本化、反复复制使用、附带参考文件和脚本的 Prompt 模板，在工程意义上已经非常接近一个简单的 Skill。反过来，一个只含十行 SKILL.md 的 Skill，也可以被视为拥有标准化包装与发现机制的 Prompt 模板。

Skill 的价值出现在后两个条件同时满足时：一是这类任务会稳定地反复出现；二是仅靠人手复制 Prompt，开始出现遗漏、版本漂移、上下文过载或团队难以共享的问题。

把所有反复出现的经验都塞进项目级 AGENTS.md 也不是答案。项目规则和任务规则的生命周期不同。

项目级规则：
任何改动都必须运行测试；不得提交密钥；服务启动命令是什么。

任务级规则：
当任务是数据库迁移时，先备份、再生成迁移、执行验证查询、
准备回滚方案；只有在迁移任务发生时才需要这套流程。

如果把后一类规则永久塞进每次对话，Agent 会在不相关任务中反复携带它们。上下文不仅有容量成本，也有注意力成本：越多无关规则同时竞争，真正重要的约束越容易被忽略。

因此，Skill 解决的并不是“怎样把 Prompt 写得更长”，而是另一层工程问题：

这份经验属于哪一类任务？
它应该在什么时候出现？
它如何被团队共享和演进？
哪些细节应当立即提供，哪些只在需要时再读取？

从这个角度看，Skill 的价值不是替模型增加记忆，而是给团队的程序性知识增加一个稳定的生命周期：它可以被发现、修改、审查、版本化、评估，也可以在模型能力提升后被淘汰。

下一节将回答更具体的问题：既然要管理这类知识，为什么文件夹比一段配置、更长的系统提示词，甚至一个新的 Agent Framework 更合适？

---

本节自检

1. 为什么“每类任务一份 Prompt”仍然不能自动等同于 Skill？
2. 什么情况下，一份可复用 Prompt 模板比 Skill 更合适？
3. “数据库迁移流程”为什么通常不应被长期塞进每一次项目对话的全局规则中？

3. 为什么偏偏是一个文件夹？

到这里，仍有一个很自然的追问。

既然 Skill 的核心是任务级程序性知识，为什么不定义一份 YAML 或 JSON 配置？为什么不把它做成一个数据库表、一段注册到平台的 Prompt，或者一个新的 Agent Framework？

答案不是“文件夹比其他形式更先进”。恰恰相反，文件夹的价值在于它足够朴素：它是人、Git、操作系统、容器和大多数 Coding Agent 都已经理解的共同语言。

一个真实任务的经验，通常不会只是一段文字。它可能同时包含流程说明、产品术语、输入输出模板、样例数据、确定性脚本和领域参考资料。

customer-feedback-triage/
├── SKILL.md                 # 主流程与触发说明
├── references/
│   ├── issue-template.md    # 工单结构与验收字段
│   ├── severity-rubric.md   # 风险分级标准
│   └── product-glossary.md  # 产品术语与模块边界
├── scripts/
│   └── validate_issue.py    # 校验必填字段与格式
└── assets/
    └── issue-example.json   # 示例或固定资源

如果把这些内容塞进一段 Prompt，内容会迅速失去结构：流程、规范、代码和示例混在一起；每次修改时，也很难判断改动影响的是哪一部分。若把它们拆成一组没有共同根目录的文件，Agent 又缺少一个明确入口，不知道哪些文件属于同一项能力、应按什么顺序读取。

文件夹恰好提供了一个很自然的能力边界：这组文件共同定义了一项任务能力，内部可以继续分层，外部则可以被安装、版本化、审查、分发和删除。开放的 Agent Skills 规范也因此只要求一个目录与其中的 SKILL.md，其余脚本、参考文件和资源均是可选内容。Agent Skills Specification

3.1 文件夹解决的不是存储，而是组合

可以把一个复杂 Skill 看成四种东西的组合：

说明：模型需要遵循什么流程与判断原则。
知识：模型需要查阅哪些术语、规则、模板与案例。
工具：哪些确定性动作应交给代码而非语言生成。
资源：任务运行时要复用的固定文件或样例。

这四类内容的生命周期往往不同。

产品术语可能每月更新，Issue 模板可能随团队规范调整，校验脚本需要单独测试和发布，而主流程只在任务边界变化时修改。文件夹使它们能够独立演进，却仍然作为同一个能力单元被交付。

这比“把所有内容写进 SKILL.md”更重要。Skill 的核心不是一份越来越长的说明书，而是让不同性质的工件在同一个任务边界内协作。

3.2 文件夹天然适合 Agent 的工作方式

对人来说，文件夹容易理解；对当前主流 Coding Agent 来说，它也很自然。

Agent 不需要学习一种新的专用 DSL。它只需使用已有的文件系统能力：列目录、读取文件、搜索文本、运行脚本、修改内容、查看版本差异。Anthropic 的实现正是利用虚拟机中的文件系统和 Bash，让模型在 Skill 被触发后逐步读取 SKILL.md 与它引用的资源。Anthropic Agent Skills Overview

这里有一个容易被忽略的好处：Skill 的定义本身也是可检查对象。

传统工具的说明常常只是一段注册在服务端的 docstring。模型能看到它，却不一定能知道工具内部做了什么。脚本型 Skill 则不同：当 Agent 需要确认一个校验脚本会不会修改数据、依赖哪些环境变量时，它可以直接阅读脚本源码；当团队发现规则过时，也可以像修改普通代码一样提交 Pull Request、运行测试并审查 diff。

这并不意味着 Skill 中的脚本天然安全。恰好相反，脚本使 Skill 更接近一项软件依赖：它需要可信来源、版本控制、最小权限和隔离执行环境。文件夹让这些风险更可见，但不会自动消除它们。

3.3 文件夹为渐进式披露留出了结构

文件夹的另一个价值，是让“知道得更多”和“当前加载得更多”分离。

一个成熟 Skill 可能包含很多细节，但 Agent 不应该在每次任务开始时读取全部内容。较好的结构通常是：

metadata：这项能力何时相关？
    ↓
SKILL.md：任务的主路径是什么？
    ↓
references/：遇到特定分支时，应查哪份细节？
    ↓
scripts/：哪些动作不需要模型逐步推理，而应直接执行？

这不是把信息藏起来，而是把信息组织成可导航的层级。模型先获得足以判断“要不要进入这项能力”的最小信号；进入后再读取主流程；只有遇到某个产品模块、风险等级或输出格式时，才继续打开对应的参考文件。

在 Anthropic 当前的 Agent Skills 机制中，名称和描述用于启动时的发现，完整 SKILL.md 在 Skill 被触发后才载入，引用文件与脚本则按需访问。这是一种渐进式披露实现；其他 Harness 即使采用不同加载方式，也可以沿用相同的结构原则。Anthropic Agent Skills Overview

3.4 文件夹不是魔法，也不是唯一答案

文件夹并不会自动让任务变得可靠。

如果一个流程只有十行稳定说明，没有引用资料，也没有脚本和复杂分支，那么一份 Prompt 模板可能更直接。如果能力需要跨组织授权、连接实时业务系统或管理长时间运行状态，单个文件夹也不够，还需要 MCP、权限系统、数据库和 Agent Harness 的支持。

因此，“Skill 是文件夹”不应被理解为一种对所有 Agent 问题的回答。更准确的说法是：

文件夹为任务级程序性知识提供了一个低成本、可组合、可检查的边界；当任务复杂度增加时，它可以自然地接入工具、运行时和治理机制，而不必先引入一个庞大的框架。

下一节将继续回答一个更关键的问题：文件夹中的 SKILL.md、references/ 和 scripts/ 分别应该承担什么职责？它们又如何和模型、Harness、MCP 共同完成一次任务？

---

本节自检

1. 文件夹相比“可复用 Prompt 模板”，新增的核心价值是什么？
2. 为什么将流程、参考资料和脚本分开，不只是为了目录好看？
3. 文件夹为什么不是一个完整的 Agent 系统？当它不够用时，还缺少什么？

4. 一项 Skill 在运行时到底发生了什么？

上一节把 Skill 描述成一个能力边界，但这还不够。

一个常见误解是：把 Skill 放进目录后，Agent 就“学会”了一项新能力。实际发生的事情没有这么神秘。模型的权重没有改变，Skill 本身也不会在模型内部执行代码。它只是让 Agent 在一次任务中，能够获得更合适的上下文、找到更明确的路径，并使用 Harness 提供的工具完成工作。

要看清这个过程，先区分四个角色：

模型：理解任务、选择下一步、调用工具、综合判断。

Skill：定义这类任务的流程、知识入口、资源与可选脚本。

Harness：发现和挂载 Skill，提供文件系统、工具、Sandbox、权限与执行环境。

外部系统：业务数据库、工单系统、日志平台、CRM 等由 MCP、API 或其他工具连接。

Skill 不是第四个角色的替代品。它不会凭空让 Agent 访问 CRM，也不会自动创建安全的执行环境。它更像一份面向 Agent 的任务说明书，加上一组与说明书共同交付的资源；真正让 Agent 能读取文件、运行命令和调用外部服务的，是 Harness。

4.1 从用户请求到结果：一条典型链路

以“整理客户反馈并生成需求草稿”为例，一次典型执行会经过下面的过程：

在 Anthropic 当前的实现中，Skill 的名称与描述会在启动时提供给模型，用于发现可用能力；当模型判断任务相关时，再读取完整的 SKILL.md；参考文件和脚本则在后续需要时通过文件系统访问。Anthropic Agent Skills Overview

这条链路中最重要的不是固定顺序，而是职责分离：模型不需要在一开始背下所有产品规则；Skill 不需要自己执行代码；Harness 也不需要理解业务语义。每一层只负责自己擅长的部分。

4.2 Skill 是 Context 吗？是，但这句话不够完整

说“Skill 是 Context”有助于理解它如何影响模型，但如果把它当作完整定义，就会遗漏执行环境。

更准确地说，Skill 中不同内容处在不同位置：

metadata 与 SKILL.md 指令
    -> 被模型读取后，成为上下文的一部分。

reference 文件、模板、脚本源码
    -> 只有在被读取时才成为上下文的一部分。

脚本的实际执行
    -> 发生在模型之外，由 Harness / Sandbox 完成。

脚本、MCP 或 API 的执行结果
    -> 再返回模型，成为新的上下文和后续判断的依据。

模型本身只会生成“读取文件”“运行脚本”“调用工具”的动作请求。它不会真的在自己的参数中执行 Python，也不会直接访问数据库。Harness 才是连接语言模型与真实环境的执行者。

因此，我更愿意把 Skill 描述为：

Skill 通过上下文组织任务知识，并借助 Harness 编排工具与资源，从而让模型能够在特定任务中稳定地行动。

这也解释了同一份 Skill 在不同环境中的效果为什么会不同。把它放进只支持文本输入的聊天界面，它可能退化成一份参考说明；放进拥有文件系统、Shell、浏览器、MCP 与隔离执行环境的 Harness，它才可能成为真正可执行的任务能力。

4.3 scripts/：把确定性动作从语言中拿出来

Skill 里的脚本并不是必需项。很多 Skill 只有 SKILL.md 和少量参考资料，已经足够有效。

脚本适合承担的是那些不需要语言理解、却要求稳定复现的动作。例如：

校验生成的 Issue 是否包含必填字段；
将一批工单按确定规则清洗成统一格式；
计算 SLA、错误率或优先级分数；
生成固定样式的报告文件；
检查输出是否符合 JSON Schema。

让模型在自然语言中反复解释这些步骤，既浪费上下文，也容易在边界条件上漂移。把它们固化成脚本后，模型只需要决定“何时运行、传入什么参数、怎样解释结果”；脚本负责以确定方式完成计算或校验。

这不是“用代码替代模型”。更准确的分工是：

模型负责：理解意图、处理歧义、综合证据、作出需要语境的判断。

脚本负责：计算、转换、格式化、校验等确定性动作。

一个健康的 Skill 会不断审视这条边界。某个步骤如果已经被反复验证、输入输出稳定、错误可以机械判断，它就应该逐渐从自然语言指令下沉为代码；反过来，涉及业务权衡、模糊信息和例外处理的部分，仍应保留给模型或人。

4.4 scripts/ 与 MCP：一个负责流程内确定性，一个负责连接

scripts/ 和 MCP 经常同时出现，但解决的问题不同。

MCP / API：
让 Agent 能够连接和操作外部系统。
例如读取 CRM、查询历史工单、创建 Issue、获取订单状态。

scripts/：
让 Agent 在本地或 Sandbox 中可靠完成流程里的确定性步骤。
例如清洗字段、计算分数、校验输出、生成文件。

在客户反馈分诊场景中，一种自然组合是：

MCP 获取客户反馈与历史工单
    -> 脚本提取、去重并校验结构化字段
    -> 模型依据 Skill 的分诊规则形成结论
    -> MCP 将人工确认后的结果写入 Issue 系统

前者解决“能不能拿到或写入数据”，后者解决“固定步骤能不能稳定完成”，模型则负责“这些数据在当前业务语境下意味着什么”。三者互补，不能互相替代。

4.5 执行能力越强，越要讨论权限

一旦 Skill 包含脚本和外部工具，它就不再只是文档，而是一项软件依赖。

这带来一个必须提前回答的问题：Agent 能做什么，谁来限制它？

对于业务 Agent，一个合理的最小权限分层可以是：

只读：检索客户反馈、产品文档、历史工单和运行数据。

建议：生成需求草稿、风险说明与待确认的问题。

需审批写入：创建正式 Issue、修改优先级、通知客户或更新 CRM。

禁止自动化：承诺交付时间、修改合同、删除业务数据、执行资金操作。

Skill 可以声明流程中需要哪些工具，但真正的权限控制必须由 Harness、身份系统或外部服务完成。把“未经人工批准不得修改客户优先级”只写进 Markdown 不足以形成安全边界；正确做法是让写入工具本身要求审批或受策略引擎限制。

下一节将回到一个更细的设计问题：既然 Skill 能同时包含流程、资料和脚本，怎样决定哪些内容该放进 Skill，哪些应放在项目规则、RAG、MCP 或 Subagent 中？

---

本节自检

1. 一项脚本型 Skill 为什么不能被简单说成“模型会执行 Python”？
2. 在客户反馈分诊任务中，为什么 MCP 和脚本不能互相替代？
3. 哪些业务操作即使 Skill 写得再好，也不应只靠自然语言规则约束？

5. 不要问“该不该用 Skill”，先问这项能力缺什么

到这里，最常见的问题通常是：这个需求到底该写成 Skill、Prompt、AGENTS.md、RAG，还是 MCP？

这个问题本身容易把设计带偏，因为这些机制并不处在同一个层次上。

MCP 解决连接，Subagent 解决任务拓扑，RAG 解决知识检索，权限系统解决授权；Skill 主要解决的是任务级程序性知识的封装与取用。它们不是五种互斥方案，而是同一个 Agent 系统里的不同部件。

更有用的问题是：为了完成这项任务，Agent 究竟缺少什么？

我会先从四个维度判断。

作用域：这条知识只属于当前对话、整个项目，还是某一类重复任务？

时效性：它是稳定流程，还是必须从外部系统实时获取的事实？

执行形态：它需要模型在主上下文中完成，还是需要隔离、并行或长时间运行？

风险等级：它只是提供建议，还是会写入业务系统、影响客户或造成不可逆后果？

这四个问题比“哪个概念更流行”更能决定架构。

5.1 先按知识的作用域分层

最容易混淆的，是 Prompt、项目规则、Memory 和 Skill。它们都可能以文字形式出现，但服务的作用域不同。

机制	最适合放什么	不适合放什么
Prompt	当前任务的临时目标、补充限制、输入数据	会反复出现的完整流程
AGENTS.md / 项目规则	始终成立的项目约定、测试命令、安全底线	只在少数任务中需要的长流程
Memory	项目事实、用户偏好、近期决策、会变化的背景	需要严格版本化和审核的流程规范
Skill	某类任务可复用的流程、判断原则、模板与脚本	单次任务的临时上下文

一个简单判断是：如果它在每次进入项目时都成立，放项目规则；如果它只在某类任务中成立，放 Skill；如果它只对当前任务成立，放 Prompt。

Memory 比较特殊。它更像“系统从过去互动中知道了什么”，例如某位客户偏好的报告格式、某个项目最近决定不再使用的接口、用户希望回答更简洁。它可以帮助任务，但不应默默取代经过审查的业务流程。对于“客户投诉涉及数据丢失时必须转人工”这类规则，Skill、策略系统或权限控制比自动抽取的 Memory 更可靠。

5.2 RAG 与 Skill：一个回答“知道什么”，一个回答“怎样做”

RAG 最适合处理大量、不断更新且难以人工穷举的事实材料：产品文档、帮助中心、历史工单、合同条款、知识库文章。

它的输入通常是一个具体问题，目标是从语义上找到相关事实：

“客户使用的企业版是否支持 SSO？”
“历史上是否有人报告过相同错误码？”
“这个模块当前的退款政策是什么？”

Skill 解决的是另一类问题：当 Agent 开始处理“客户反馈分诊”这项任务后，应该先做什么、需要查哪些信息、怎样定义证据不足、何时转人工、输出必须满足哪些字段。

因此，一个更自然的关系是：

Skill 定义流程与检索策略
    -> RAG / 搜索系统提供当前相关事实
    -> 模型基于事实执行流程中的判断

不要把所有产品资料复制进 Skill，也不要期待 RAG 自己补出完整流程。前者会使 Skill 膨胀并快速过期，后者会让 Agent 每次都从一堆事实中临场猜测“下一步该做什么”。

5.3 MCP 与 Skill：一个提供能力，一个提供使用方法

MCP 或普通 API 让 Agent 能够读取、写入或操作外部世界。它回答的是：

能否查询 CRM？
能否读取工单系统？
能否创建 Issue？
能否获取订单、库存或日志？

Skill 回答的是：拿到这些信息之后，这一类业务任务应如何推进。

例如，“创建 Issue”的 MCP 工具本身不应决定什么叫高优先级、什么材料足以证明是缺陷、是否该把客户原话写入公开字段。这些属于业务流程与判断，应由 Skill、策略规则和人工审批共同决定。

反过来，Skill 也不应假装自己拥有实时事实。它可以写“查询客户等级和历史工单”，但真正的数据访问必须来自 MCP、API 或其他受权限控制的连接器。

5.4 Subagent：不是知识包，而是上下文与执行的隔离单元

Subagent 常被误认为是“更强的 Skill”。其实它解决的是另一件事：让一部分工作拥有独立的上下文、工具权限和执行生命周期。

适合使用 Subagent 的信号包括：

• 任务需要大量检索、分析或试验，不希望污染主上下文；
• 多个子问题可以并行，例如分别研究竞品、财务数据和客户反馈；
• 子任务需要更窄的工具权限；
• 任务会运行很久，主 Agent 只需要最终结论与关键证据。

Skill 与 Subagent 最自然的组合是：Subagent 提供隔离的执行空间，Skill 提供该空间中应遵循的专业流程。

例如，主 Agent 可以把“分析客户反馈是否属于重复需求”交给一个研究型 Subagent；该 Subagent 加载反馈分诊 Skill，检索历史工单和产品资料，最后只返回分类、证据链接与不确定项。主 Agent 无需承载全部检索过程，也不会因为大量原始工单而失去主线。

5.5 高风险决策不应被“放进 Skill”就算解决

还有一层不应被任何上下文机制替代：责任边界。

Skill 可以指导 Agent 识别“疑似 P0 客户问题”，却不应单独授权它向客户承诺赔偿、修改合同、调整正式优先级或删除数据。这里需要的不是更长的指令，而是审批、权限、审计和可回滚的业务流程。

可以把一次业务动作拆成两部分：

认知与建议：
Agent 收集证据、给出分类、说明风险、生成草稿。

权威与执行：
有权限的人或策略系统确认后，才写入业务系统或触发外部动作。

这条边界很重要。因为模型是否“看起来理解了规则”，不能替代系统是否真正阻止了越权行为。

5.6 一张实际可用的决策表

下面这张表不是绝对规则，但可以作为设计起点。

你遇到的问题	优先考虑	原因
这次任务临时多了一条限制	Prompt	生命周期只属于当前任务
每个任务都必须遵守的仓库约定	AGENTS.md / 项目规则	全局、稳定、应始终可见
一类重复任务的流程与验收标准	Skill	需要按任务发现、复用和迭代
大量随时变化的产品或业务事实	RAG / 搜索	需要按语义检索权威信息
访问 CRM、工单、数据库等外部系统	MCP / API	需要受控连接与身份权限
大规模检索、长时分析或并行子任务	Subagent	需要隔离上下文和执行生命周期
影响资金、合同、客户承诺或生产数据	人工审批 + 策略系统	需要责任、权限、审计和回滚

真正成熟的 Agent 不会只选择其中一个。它会在同一条任务链路中组合它们：项目规则提供底线，Skill 组织流程，RAG 提供事实，MCP 连接系统，Subagent 隔离复杂分析，审批机制守住风险边界。

下一节将从“选择合适机制”推进一步：即使已经决定写 Skill，怎样判断它写得好，怎样避免把经验变成冗余、冲突或过时的上下文？

---

本节自检

1. 为什么“客户反馈分诊”通常既需要 Skill，又需要 RAG 和 MCP？
2. 一份每天都会变化的产品定价表，为什么不适合直接写进 Skill？
3. 当一个 Agent 要分析上千条工单时，Subagent 带来的关键价值是什么？
4. 为什么高风险业务操作不能只通过 Skill 中的一句禁止指令来约束？

6. 写好一个 Skill：不要保存所有经验，只保存真正有用的差异

理解了边界之后，下一步才是写作。

很多人第一次写 Skill 时，会自然地做一件事：把自己知道的所有流程、背景、异常、踩坑和示例都写进去。结果往往得到一份几百上千行的说明书。它看起来很完整，却未必能让 Agent 做得更好。

原因很简单：模型不是空白新人。它已经知道大量通用知识，也能完成很多常规步骤。一个好的 Skill 不应重复教模型它本来就会的内容，而应补上它在这个任务、这个团队、这个环境里稳定缺少的部分。

我会把这个原则写成一句检验问题：

这一段内容，是否足以抵消它占用的上下文、增加的冲突风险和维护成本？

如果答案是否定的，它不应该被写入 Skill。

6.1 Skill 应从一条成功轨迹中提炼，而不是从空白处设计

最可靠的 Skill 往往不是先写出来，再期待 Agent 按它成功；而是先让 Agent 在一个具体任务上成功，再回头提炼成功轨迹中可复用的部分。

以客户反馈分诊为例，第一次可以先用普通 Prompt 完成任务。任务结束后再回看：

哪些信息是完成任务必不可少的？
哪些步骤每次都要重复？
哪些错误反复发生？
哪些判断依赖团队约定，而非通用知识？
哪些动作已经足够确定，可以交给脚本？

将答案沉淀下来，才会得到更接近真实工作流的 Skill。

这比凭想象写一份“完美流程”更重要。抽象得太早，Skill 容易变成错题本：它记录了某次任务的偶发失败和临时补丁，却没有抽出可迁移的原则。下一次情况稍有变化，模型就会被旧规则牵着走。

因此，第一版 Skill 应当小。它的目标不是覆盖所有例外，而是稳定地重现一条已经验证过的主路径。

6.2 先决定约束强度：窄桥写步骤，开阔地写原则

不同任务需要的自由度并不一样。

有些任务像窄桥：两侧是悬崖，步骤遗漏或顺序错误就会造成严重后果。数据库迁移、生产发布、权限变更、合同发送都属于这一类。对于它们，Skill 应写得精确，必要时提供脚本、检查清单和回滚路径。

另一些任务更像开阔地：目标明确，但达到目标有多种合理路径。代码审查、需求分析、竞品研究、界面设计通常属于这一类。对于它们，过度规定每一步反而会限制模型利用具体语境作出判断。Skill 更适合提供目标、质量标准、优先级与反例，而不是伪装成不可变更的流水线。

窄桥任务：
把关键步骤、前置条件、验证与回滚写清楚。

开阔地任务：
把目标、判断原则、质量标准和禁止事项写清楚。

决定约束强度的，不应是“我是否信任模型”，而应是错误的可逆性、容错空间和验证成本。

这也是为什么同一个业务系统里会同时存在两类 Skill：

“创建正式客户 Issue” Skill：
字段、权限、审批和写入步骤较严格。

“分析客户反馈趋势” Skill：
强调证据、分析框架和不确定性表达，保留较大判断空间。

6.3 description 不是摘要，而是触发契约

在支持自动发现的 Harness 中，Skill 的名称和描述承担了一个特殊职责：让模型或路由器判断这项能力何时相关。

因此，description 不应写成营销文案，也不应只说“这是一个客户反馈 Skill”。它应该回答两件事：

这个 Skill 能做什么？
在什么类型的任务中应该使用它？

例如：

description: >
  Classify customer feedback into support questions, bugs, feature requests,
  or duplicate reports. Use when turning raw customer messages into an
  evidence-backed issue draft. Do not use for direct customer replies or
  for changing issue priority without human approval.

这里同时包含能力、触发条件和负向边界。

如果描述太宽泛，Skill 会在无关任务中误触发，挤占上下文并干扰决策；如果描述过窄，它又会在真正需要时被遗漏。触发准确率本身就是可以被测试和迭代的质量指标，而不是写完后无法改变的元数据。

6.4 SKILL.md 负责主路径，也负责导航

SKILL.md 的工作不是成为知识库全文。它应当同时承担两件事：

主路径：这项任务通常怎样开始、推进、验证和结束。

导航：遇到特定分支时，应到哪里获取更详细的规则、模板或工具。

一个可读的主路径可以是：

1. 读取客户反馈原文，不先下结论。
2. 查询客户、产品版本与相似历史工单。
3. 按支持咨询、缺陷、需求或重复反馈分类。
4. 证据不足时列出待确认项，不编造根因。
5. 使用模板生成草稿，并运行字段校验。
6. 命中高风险条件时转人工审批，不直接写入正式系统。

如果正文开始出现大量产品模块、几十条业务规则或多层条件分支，应该优先拆出引用文件。正文保留高频主路径，并明确指向细节的位置，例如“严重等级判断见 references/severity-rubric.md”。

这里需要克制。引用链越深，模型越容易只读取其中一部分；同一条规则也不应散落在多个文件里。保持单一事实来源，比不断增加说明更重要。

6.5 references/ 保存细节，scripts/ 固化确定性

两者都不是为了让目录看起来专业。

references/ 适合保存模型偶尔需要、但不应每次预加载的资料：产品术语、分级规则、字段字典、模板、典型案例。它们应按领域拆分、标题明确，并尽量从 SKILL.md 一跳可达。

scripts/ 适合保存输入输出稳定、可机械验证的动作：字段校验、格式转换、固定计算、报告渲染、Schema 检查。每多一个脚本，就多了一项依赖、权限和维护责任，因此不要把“模型能做但不够快”的所有事情都立刻脚本化。

一个实用的判断是：

若错误需要人理解语境才能判断，优先交给模型或人工。

若错误可以由确定规则判断，优先交给脚本、测试或策略系统。

6.6 Skill 也会腐烂

最后一个容易被忽略的问题是：Skill 不是写完就结束。

产品术语会变化，接口会废弃，模型会变强，旧的补丁式指令也会累积。一个曾经有用的 Skill，可能逐渐变成误导、冗余甚至干扰。

因此，维护 Skill 至少需要三件事：

版本：每次修改可追踪、可审查、可回滚。

证据：修改应来自失败案例、测试结果或明确的业务变化，
      而不是“感觉再加一句可能更好”。

淘汰：定期测试没有该 Skill 时的表现；若模型已稳定具备这项能力，
      应删掉过时规则，而不是让它永久占用上下文。

到这里，Skill 已经不再是一份静态提示词，而更像一项小型的软件资产：有输入、有行为、有依赖、有版本，也会退化。

下一节将处理最后一个关键问题：怎样证明一项 Skill 真正有用？如果不只是看输出“像不像专家”，又该评估什么？

---

本节自检

1. 为什么第一版 Skill 应从一条成功轨迹中提炼，而不是试图覆盖所有例外？
2. “窄桥”和“开阔地”的区别，为什么比“模型是否足够聪明”更适合决定指令粒度？
3. description 为什么不是一个简介，而是 Skill 的一部分行为设计？
4. 什么情况下应该删除一个 Skill，而不是继续往里面添加规则？

7. 不要问“输出像不像专家”，要问 Skill 是否带来了增益

写完一份 Skill 后，最容易出现的错觉是：让 Agent 跑一个例子，看到输出结构更完整、措辞更专业，于是宣布它“有效”。

这远远不够。

一次好输出可能来自模型原本就会做这件事，也可能来自输入恰好简单；一份写得很长的 Skill 甚至可能让某几个样例变好，却让其他任务误触发、成本上升或遗漏关键信息。

真正需要回答的问题不是“Agent 表现怎么样”，而是：

在相同任务、相同模型、相同工具条件下，这份 Skill 是否带来了可验证的净增益？

这句话包含三个关键词：对照、验证、净增益。

7.1 先区分三个层级：模型表现、Skill 增益与业务结果

它们经常被混成一个指标，但实际回答的是不同问题。

层级	要回答的问题	示例指标
模型表现	Agent 能否完成任务？	分类正确率、字段完整率、证据引用率
Skill 增益	Skill 是否比不使用它更好？	有无 Skill 的成功率差异、误触发率、人工修改率变化
业务结果	系统是否改善了真实流程？	工单处理时长、重复反馈率、人工分诊负担、客户问题闭环速度

这三层必须分开。

一个 Agent 即使能把客户反馈分类得很好，也不代表 Skill 有价值，可能裸模型就能做到。一个 Skill 即使提升了分类准确率，也不代表业务已经受益，可能人工审核、工具故障或组织流程仍然是瓶颈。

因此，第一轮 Eval 不必直接追求宏大的业务指标。先证明 Skill 在可控任务上带来增益，再逐步观察它是否改善真实工作流。

7.2 最小 Eval：同一批任务，做有无 Skill 的对照

一个实用的起点，是准备一组脱敏、人工标注过的历史任务，并让 Agent 在两种条件下完成它们：

实验组：模型 + 相同工具 + Skill
对照组：模型 + 相同工具 - Skill

除了是否加载 Skill 外，模型版本、工具权限、输入材料、时间预算和输出格式都应尽量保持一致。否则你无法知道表现变化来自 Skill，还是来自模型、工具或提示词的其他差异。

客户反馈分诊可以准备类似的任务集：

输入：客户原始反馈、必要的产品资料、历史工单摘要。

人工标注：正确分类、必须引用的证据、必填字段、
          是否应升级人工、哪些结论不允许自动下达。

输出：结构化需求草稿、证据链接、待确认项和建议动作。

不要只用写 Skill 时见过的案例做测试。至少留出一部分未参与设计的任务，作为 held-out 集。否则，Skill 可能只是记住了几个示例的表面模式，而没有学会可迁移的流程。

7.3 先测“有没有被正确使用”，再测“结果好不好”

对于自动发现的 Skill，任务成功之前还有一道门：它是否在该出现时出现、在不该出现时保持安静。

因此，Eval 应至少覆盖两类任务：

正例：确实应触发客户反馈分诊 Skill 的请求。

负例：看起来相关，但不应触发的请求，
      例如直接回复客户、修改正式优先级、处理合同争议。

可以用熟悉的信息检索术语衡量：

触发召回率：该触发的任务中，Skill 被成功加载的比例。

触发精确率：被加载的任务中，真正需要该 Skill 的比例。

只看任务输出，容易漏掉一种危险情况：Skill 在不相关任务里误触发，带来了错误流程或无关约束。对于业务 Agent，这类误触发往往比“没有触发”更难被发现。

7.4 把“正确”拆成可检查的维度

“这份需求草稿好不好”太模糊，无法稳定评估。

更好的做法是把它拆成可观察、可评分的维度：

维度	可检查的问题
分类正确性	支持咨询、缺陷、需求、重复反馈是否判断正确？
证据完整性	每个关键结论是否能追溯到客户反馈、产品资料或历史工单？
信息完整性	客户、产品版本、复现条件、影响范围、待确认项是否齐全？
流程合规性	高风险情形是否转人工，而非直接写入正式系统？
行动可执行性	研发或产品人员是否能基于输出继续处理，而不必重新追问全部背景？
成本与时延	是否在可接受的 token、工具调用和处理时间内完成？

其中一部分可以由脚本或 Schema 自动检查，例如字段是否缺失、链接是否存在、是否调用了不允许的写入工具；另一部分需要人工盲评，或由独立的评审 Agent 按固定 rubric 评分。

这里要避免把“另一个模型说它很好”当作唯一证据。模型评审可以扩大覆盖面，但高风险维度和少量关键样例仍应有人审。否则，生成模型与评审模型可能共享同样的盲点。

7.5 从失败案例中更新 Skill，而不是不断添加一句提醒

Eval 最有价值的产物不是一个分数，而是一组能够解释失败的案例。

当任务失败时，先分类问题发生在哪一层：

没有触发：description 或路由策略有问题。

读取不足：正文没有指向正确的 reference，或引用层级过深。

事实错误：RAG、MCP 数据、工具调用或证据规则有问题。

流程错误：主路径、例外条件或优先级定义不清楚。

确定性错误：应下沉为脚本、Schema、测试或策略规则。

越权风险：权限和审批机制没有在系统层阻止动作。

这份分类很重要，因为它阻止团队把所有失败都归结为“模型不够聪明”或“再加一句 Prompt”。有些问题该改 description，有些该更新知识库，有些根本不该写进 Skill，而应由权限系统或工具接口解决。

一次合理的迭代循环应该是：

收集失败案例
    -> 定位失败层级
    -> 提出最小修改
    -> 重新运行原有测试集与新增回归案例
    -> 比较有无 Skill 的变化
    -> 决定发布、回滚或继续观察

这样，Skill 的演进才更像软件工程，而不是不断给 Prompt 打补丁。

7.6 模型升级后，仍要重新评估

Skill 的收益不是永久的。

模型变强后，原来必须写进 Skill 的通用提示可能已经不再需要；反过来，新的模型行为和工具能力也可能使旧 Skill 误触发、约束过度，甚至妨碍更好的解决方案。

所以每次更换模型、调整工具权限、重构知识库或修改核心业务流程后，都应重新运行关键 Eval。一个成熟的 Skill 库不只会增加内容，也会删除已经失去边际价值的内容。

这也是我认为 Skill 与“保存一份 Prompt”最深层的区别：前者的生命周期包含评估、回归和淘汰；后者往往只是被复制、遗忘，然后在某个时刻悄悄失效。

下一节将把这些指标收束为一套更实用的诊断框架：当 Skill 失败时，究竟是误触发、事实幻觉、知识过期、越权，还是系统漂移？

---

本节自检

1. 为什么“分类准确率提高”本身不足以证明 Skill 有业务价值？
2. 为什么 Eval 必须同时包含应触发和不应触发的任务？
3. 发现一个失败案例后，怎样判断应该改 Skill、改 RAG、改脚本，还是改权限系统？
4. 为什么模型升级后，删除 Skill 也可能是正确的优化？

8. Skill 会怎样失败：五种不能靠“再加一句 Prompt”解决的问题

前面讨论了如何触发、编写和评估 Skill，但生产环境中的问题通常不会以“Skill 没有用”这样笼统的形式出现。

它们往往表现为五类更具体的失败：误触发、幻觉、知识过期、越权与漂移。

这五类问题看起来都像模型行为不稳定，根因却位于不同层。把它们混在一起处理，最常见的结果就是不断向 SKILL.md 添加补丁式提醒，最后得到一份更长、更冲突、也更难维护的说明书。

失败模式	表面现象	常见根因	优先修复位置
误触发	无关任务加载了 Skill，或相关任务没有加载	描述范围不清、路由重叠、缺少负例	metadata、路由策略、触发 Eval
幻觉	输出了没有证据支撑的事实、根因或承诺	事实来源不足、检索失败、未要求表达不确定性	RAG/MCP、证据规则、输出 Schema
知识过期	使用已废弃的产品规则、接口或流程	多个事实来源冲突、缺少所有者与更新时间	单一事实来源、文档治理、更新检查
越权	Agent 做了超出职责或权限范围的动作	只靠文字禁止，工具本身没有权限约束	工具权限、审批、策略引擎、审计
漂移	多轮迭代后，流程越来越长、规则互相矛盾	针对个例打补丁、缺少回归测试和淘汰机制	Eval 集、版本管理、重构与删除

8.1 误触发：错误可能在任务开始前就发生了

Skill 的错误不一定发生在执行过程中。

如果一个“客户反馈分诊” Skill 在“请帮我润色回复客户的邮件”这类任务中被加载，它可能会把原本只需要文案处理的任务，带入分类、建 Issue、风险分级的复杂流程。反过来，如果用户说“这个客户反复报告登录失败，帮我整理给产品团队”，而 Skill 没有触发，Agent 就可能漏掉证据收集和升级规则。

这类问题通常不是正文流程写得不好，而是触发边界没有设计好。

修复方式不是再往正文补充“必要时使用本 Skill”，而是为 description 和路由逻辑增加正例、负例与边界条件，并将它们纳入 Eval：

应触发：
将客户原始反馈整理为带证据的 Issue 或需求草稿。

不应触发：
直接给客户写回复；修改正式优先级；处理合同或退款争议。

误触发本质上是一个分类问题。只有先正确识别“这是不是这类任务”，后续流程才有意义。

8.2 幻觉：不是所有错误都该由 Skill 负责

业务 Agent 最危险的幻觉，往往不是写错一句产品介绍，而是把推测说成事实：未经验证便判断根因、编造历史工单、默认客户具备某项权限，或向客户暗示交付承诺。

Skill 可以降低这种风险，例如要求“每个关键结论都附证据链接”“证据不足时输出待确认项”“禁止在草稿中承诺时间”。但 Skill 不能凭自身制造事实。

当模型拿不到权威数据、检索返回了错误材料或工具调用失败时，问题的首要修复点不在措辞，而在事实链路：

权威数据是否可访问？
检索结果是否可追溯？
输出是否要求区分事实、推断与待确认项？
关键结论是否必须绑定来源？

因此，反幻觉的核心不是把“不要幻觉”写进 Prompt，而是让输出结构迫使模型暴露证据和不确定性。

8.3 知识过期：最安静，也最容易被忽略的失败

Skill 中的流程可能写得完全正确，却基于过时的事实。

例如，产品已经调整了套餐权限，但 references/plan-matrix.md 仍是三个月前的版本；团队已经修改了 P1 的定义，但旧的严重等级规则仍被另一份文档引用。模型不会知道这些冲突来自组织演进，它只会选择它当前读到的内容，然后稳定地执行错误流程。

这类失败很难通过一次任务的人工检查发现，因为输出往往格式正确、逻辑也通顺。

需要的不是更多参考文件，而是知识治理：

为权威文档指定所有者和更新时间；
让关键规则只有一个定义位置；
用链接代替复制；
在产品、接口或政策变更时触发相关 Skill 的检查；
定期扫描失效链接、冲突术语和长期未更新的规则。

Skill 的知识质量，最终取决于它所引用的事实来源是否保持健康。

8.4 越权：文字约束不是权限边界

“不要修改正式优先级”“不要向客户发送邮件”这类文字规则很重要，但它们不能独自承担安全责任。

只要 Agent 拥有相应写入工具和凭据，就存在误解、绕过或提示注入导致越权调用的可能。真正的权限边界必须存在于模型之外：工具本身应区分只读、草稿写入和正式写入；高风险动作需要审批令牌、策略检查或人工确认；所有写操作都应可审计、可回滚。

Skill：说明什么情况下应建议升级、应请求审批。

Harness / 工具策略：决定没有审批时，Agent 是否根本无法执行写入。

把这两层分开，才不会让安全性依赖模型在每次任务中“恰好遵守规则”。

8.5 漂移：每次局部修复，可能都在损害整体

漂移不是某一次明显的错误，而是 Skill 在长期迭代中的缓慢失真。

一个用户反馈说格式缺字段，于是加一条规则；另一个任务误分类，于是再加一个例外；第三次模型漏读资料，又把同一段信息复制进正文。几个月后，Skill 可能拥有互相矛盾的步骤、重复的事实和无人敢删的历史补丁。

这种现象与代码库的技术债务很像。解决它不能只靠更谨慎地添加规则，而要把 Skill 当作软件维护：

每项修改绑定一个失败案例或业务变化；
每次修改运行回归 Eval；
定期合并重复规则，删除已失效的例外；
比较“有 Skill”与“无 Skill”的结果，确认它仍有边际价值；
模型升级后重新判断哪些规则已经过度约束。

因此，漂移的反面不是“永远不改”，而是有证据地修改，并有能力安全地删除。

这五种失败模式共同说明：Skill 不是静态知识库。它是一项处在模型、工具、事实来源和组织流程之间的工程资产，必须被观察、诊断和维护。

---

本节自检

1. 如果 Agent 把“润色客户邮件”误当作“客户反馈分诊”，你会优先检查 Skill 的哪个部分？为什么？
2. 一份输出带有自信结论但没有任何来源链接，这更可能是 Skill 的流程问题、RAG 问题，还是权限问题？应怎样继续定位？
3. 为什么“禁止 Agent 修改优先级”写在 SKILL.md 中，仍不足以防止越权？
4. Skill 中不断增加例外规则，为什么可能让它对未来任务更差而不是更好？

9. 从第一个 Skill 开始：建立一个小而完整的闭环

读到这里，很容易产生另一种焦虑：既然一项成熟 Skill 涉及触发、上下文、脚本、工具、评估、权限和维护，那是不是必须先搭一套完整 Agent 平台才能开始？

不需要。

大多数团队的第一个 Skill 都不应该是“万能业务 Agent”，而应该是一项满足三个条件的小任务：

重复出现：已经做过几次，并且预计还会继续出现。

边界清楚：输入、输出和完成标准能够说清。

风险可控：先以只读、生成草稿或提供建议为主，
          不直接执行不可逆业务动作。

例如，把客户反馈整理成需求草稿、把发布前检查变成清单、把周报数据汇总为固定结构，都是比“自动管理全部客户问题”更好的起点。

9.1 第一个 Skill 的最小闭环

一个足够小、但完整的工作流可以是：

1. 选择一个高频且边界明确的任务。

2. 用普通 Prompt 完成几次真实任务，保留成功与失败轨迹。

3. 提炼一条主路径：输入是什么、输出是什么、什么算成功。

4. 只写模型稳定缺少的本地知识和流程约束。

5. 为它准备少量未参与设计的测试任务。

6. 先以只读或草稿模式运行，记录人工修改与失败原因。

7. 将失败归因到触发、知识、流程、工具、权限或模型判断，
   再做最小修改并回归测试。

它看起来没有“自主 Agent”那么炫，但已经包含了最重要的能力：经验不再只留在一次对话里，而是能够通过测试和版本控制被后续任务复用。

对个人开发者而言，第一版甚至可以只有：

一个 SKILL.md
+ 一份输出模板
+ 五到十条历史任务作为 Eval 集

当你发现字段检查反复出错，再加入校验脚本；当你发现经常要查询外部系统，再接入 MCP；当任务上下文变长或可以并行时，再引入 Subagent。能力应该跟着真实瓶颈增长，而不是因为某个组件流行就提前堆进系统。

9.2 Skill 解决不了什么

Skill 很有用，但它不是“让 Agent 变可靠”的万能答案。

它不能替代以下东西：

权威事实来源：
过期或错误的产品资料，不会因为放进 Skill 就变正确。

工具与权限：
Skill 可以说“查询订单”，但不能自行获得数据库权限，
也不能保证外部 API 的结果可靠。

业务责任：
Skill 可以生成建议，却不能替组织承担合同、资金、安全或客户承诺的责任。

模型能力：
当任务需要模型尚不具备的推理、感知或长期规划能力时，
更长的 Skill 只会把缺陷包得更复杂。

评估与运营：
Skill 可以定义流程，却不能自动证明流程带来了业务价值。

这些边界并不会削弱 Skill 的价值，反而说明它应该放在正确的位置：不是整个 Agent 系统，而是连接模型、任务知识、工具和验证机制的一层。

9.3 回到最初的问题：为什么偏偏是一个文件夹？

现在可以回到文章开头的问题。

Skill 之所以常常表现为一个文件夹，不是因为文件夹本身拥有智能，也不是因为 Markdown 比数据库或 Prompt 更高级。

它之所以合适，是因为一项可复用的任务能力天然需要一个边界：把流程、局部知识、模板、脚本和测试放在一起；让人和 Agent 都能找到、读取、修改、审查和版本化；又让这些内容可以在需要时逐步进入 Agent 的工作过程。

文件夹恰好提供了当前最低成本的共同边界。

从这个角度看，Skill 的演进路径也变得清晰：

一次成功的 Prompt
    -> 可复用的任务流程
    -> 带引用和脚本的 Skill
    -> 带 Eval、权限与版本治理的能力资产

并非每一段 Prompt 都值得走完这条路。大多数临时任务不值得，模型已经做得很好的通用能力也不值得。值得被 Skill 化的，是那些反复出现、拥有稳定边界、能够验证，并且一旦沉淀就能持续节省团队注意力的经验。

这也是我对 Agent Skill 最终的理解：

它不是给模型添加一段更长的说明，而是把人类在特定任务中积累的“怎样做才算对”，转化为 Agent 可以发现、调用、验证和持续维护的工程接口。

当我们把 Skill 当作这种接口来设计时，讨论的重点就不再是“我写了多少个 Skill”，而是：哪些经验值得被沉淀，哪些规则应被代码强制，哪些判断必须保留给人，以及怎样证明这份经验确实让系统变得更好。

---

本节自检

1. 你手头是否有一项任务，同时满足“重复出现、边界清楚、风险可控”？它为什么适合作为第一个 Skill？
2. 如果第一个 Skill 没有任何脚本、MCP 或 Subagent，它是否仍然是一个有效起点？为什么？
3. 当一个 Skill 的规则越来越多时，你会如何判断应继续扩展、拆分重构，还是直接删除？

---

参考资料

• Agent Skills Specification
• Anthropic: Agent Skills Overview
• Anthropic: Skill authoring best practices