10 · Skill：怎样让Agent复用一套做事方法？

Skill把适用条件、处理步骤和所需资源组织成按需加载的方法，让Agent知道怎样采用已有能力，而不因此扩大权限。

本课的位置：Skill位于左侧方法复用层，将说明与配套资源按需提供给当前任务，影响输入组织和工具使用。

下面用一个教学设例：团队持续收到项目说明、发布约定和历史决策，希望Agent整理成文档导航。每次都要先确认资料范围、提取标题、保留来源、核对遗漏，随后才能交付。把这些反复采用的方法组织成“文档索引”技能，比每次从头解释更容易维护。

交付目标是一份能追到原文的导航。Skill位于任务与执行工具之间：宿主发现可用方法，判断当前任务是否适合，加载必要说明和资源，再通过已有工具处理资料。

Skill与提示词、工具、MCP怎样配合？

用户说“把本周新增资料整理成导航”，这是当前Prompt表达的目标与约束。文档索引Skill提供处理方法：先固定范围，再提取标题、核对来源与数量，最后交付。

Tool负责一次具体操作，例如读取文档、生成索引或保存产物；MCP负责宿主与外部能力之间的发现和通信。Skill可以指导Agent使用MCP工具，也可以采用已有文件工具，不要求每种技能都依赖同一种接入协议。

传统后端可以把索引生成固化为业务流程。如果输入稳定、步骤固定，直接使用批处理服务可能更省事。Skill更适合Agent面对多种文档任务时，按适用范围选用方法，并结合当前资料选择具体步骤。

灵活性也带来约束：方法写在说明里，不保证模型每次完全照做。数量核对、访问范围和动作权限等关键条件，仍应由程序检查。

一套可采用的方法，需要组织哪些内容？

说明文件SKILL.md保存名称、用途和处理步骤。名称标识技能，描述说明何时使用，例如“为Markdown资料生成保留来源的导航”，比“擅长处理各种资料”更能帮助判断适用性。

方法正文要把输入、输出与边界说清楚。这个场景中的输入是获准资料范围，输出包含文档标题、来源身份和导航条目；不能把未读到的文件当成不存在，也不能根据模糊文件名猜完标题就宣布完成。

较长的规则可以放在参考资料中，比如标题优先级、同名文档如何区分、无标题资料怎样处理；模板保存导航的组织方式；确定性计算可以附带脚本或指向已有处理工具。方法与资源相互引用，采用时必须保证资源完整。

这里不需要把所有业务知识挤进说明正文。步骤解释“下一步做什么”，参考资料解释“这一步采用什么口径”，工具负责真正处理。层次清楚，后续修改也更容易定位。

比如“确保索引准确”无法落地；“每个导航条目保留来源，处理数量与资料目录核对，缺标题的文档单独列出”就能指导执行，也能支持交付检查。

Agent怎样发现并采用它？

渐进加载是先让宿主或模型知道技能名称与描述，确定当前任务适合以后再加载完整说明，需要某项资源时才继续读取。

在这个场景里，用户要整理导航，“文档索引”符合用途；如果用户要比较两份合同条款，仅仅都属于文档工作，还不足以说明该技能适用。描述过宽，会让错误方法频繁介入；描述过窄，则可能错过本应覆盖的任务。

采用前要确认来源可信、引用资料齐全、环境与工具满足要求。某份引用规则缺失时，不能自动跳过；模板被更新但说明仍使用旧规则，也要先解决版本不一致。

技能描述、完整说明和引用资源不必全部占据每次对话。采用以后，当前步骤依赖的约束又要被保留，不能在上下文裁剪时只剩“生成导航”，却丢掉“必须保留来源与缺失说明”。

多个技能同时匹配时，可以按任务拆分或确定优先级，不宜把互相矛盾的整段说明一起送给模型。采用链路也要可追踪：本次用了哪个技能、哪个版本、哪些资源，方便解释结果与后续修订。

用同一套方法，走完一次文档整理

先根据用户范围形成资料目录，固定这次处理的输入版本。标题探查发现：项目说明和发布约定有明确一级标题，另有一份旧资料只有正文。

接着读取索引规则。若规则要求标题必须来自原文，Agent就应把旧资料标为“缺少标题”，保留来源并请求补充，而不是自行编一个标题掩盖差异。其余已确认条目可以按交付约定形成部分结果，并明确缺口。

如果业务允许回退到文件名，也可以采用另一种规则，但要标明标题来源是文件名而非原文。两种方案的取舍不同：严格规则减少猜测，适合正式知识目录；回退规则能覆盖更多历史资料，适合先做整理，但需要让读者识别生成内容。

处理工具生成导航后，程序核对条目数、来源对应关系和缺失记录；模型再解释分类、命名与不确定部分。生成成功不等于交付完整，工具退出也不能代替来源核对。

导航属于这次Run的产物，不写回通用技能模板；用户原文也不应被塞进共享技能资源。否则下一次采用时，可能混入上一次输入或结果。方法版本变化与执行产物变化是两件事。

资料来自远端时，MCP工具负责取得获准内容，工作空间保存输入快照与产物，Skill指导如何整理。它们组合起来完成任务，而不是由Skill自行承担所有存储与权限职责。

规则升级时，正在执行的任务怎么办？

假设旧版规定“无标题就列为缺失”，新版改成“允许回退到文件名”。即使输出字段完全一样，业务含义也发生了变化，不能只看版本号认为兼容。

运行中的Run应固定采用的版本与资源摘要，新任务再选择升级。需要切换时，明确记录变化，判断已有中间结果是否还能继续使用；不能让任务做到一半突然读取另一套规则。

版本记录不仅包含名称，还应关联来源、实际资源与内容摘要。资源被改了却没有更新版本，单看“1.0”无法识别差异。摘要能确认资源一致性，来源信任则需要另行建立；自带清单与摘要不会自动证明一个包可信。

升级评估要覆盖有标题、无标题、同名和资料缺失等代表情况，比较数量、来源、错误处理与输出含义。兼容升级不是“仍然能生成文字”，而是原来依赖这套方法的下游仍能正确理解结果。

跨宿主采用也需要看实际条件：发现位置、工具映射、审批方式、脚本依赖可能不同。通用格式提供了复用机会，不保证换一个产品就拥有相同能力。第三方技能还应保留作者、来源、固定版本与许可，确认所需资源完整。

方法写了“发送报告”，就自动获得发送权限吗？

技能可以声明需要某项能力，不能自行批准它。用户只授权整理当前资料，方法却要求把整个工作目录上传或发送到外部，宿主应拒绝超出范围的动作。

工具白名单等声明也不能绕过用户授权。读取资料、执行代码与产生外部副作用分别有权限边界，技能来源可靠，也不代表它适合当前数据和任务。

执行预算同样由宿主控制。方法可以建议先探查再处理，但模型若反复执行失败步骤，宿主要限制次数、时间并保留反馈。技能中的“遇到问题停止”需要现有工具和运行控制配合，不能只靠一句提示词保证。

到这里，一套方法已经有了适用条件、处理口径、资源、版本与权限边界。下一篇进入RAG：资料多到不能全部读取时，怎样找到相关内容并保留证据，再交给这些方法使用。