Agent Skills这个概念在2025年下半年突然刷屏，先是Anthropic放出Skills，紧接着OpenAI正式发布Agent Skills，LangChain也跟进做了开源实现。但说实话，大部分解读还是停留在"又一个大模型新功能"的层面，很少有人讲清楚它和Prompt、Tool、Workflow到底有什么区别，更没人讲一个Skill从零到落地到底该怎么写。这篇文章我就以自己这段时间的实操经验，把这层窗户纸捅破。
1. Agent Skills 的本质：把"老师傅的经验"做成了可安装的软件包
1.1 Skill 要解决的不是单次调用问题，而是能力沉淀问题
过去两年做Agent应用，最头疼的一件事就是：每次换项目、换Agent，都要把一套业务规则、操作流程、提示词从头再写一遍。哪怕只是做个周报生成器，也要重新告诉模型"上周期做了什么、下周期计划什么、风险怎么归类、格式用几级标题"。这些经验明明是可以沉淀下来的，但现有机制里它们只能散落在各种Prompt、代码、文档里，根本无法组织化管理。
Agent Skills要解决的正是这件事。它把"某种专业任务应该怎么做"这一整套方法论——包括操作步骤、使用规范、参考资源、预期产物、质量校验方法——打包成一个可安装、可复用、可共享的文件包。模型只要加载这个包，就能在特定任务场景下表现得像受过训练的工作人员，而不是每次都在现场即兴发挥。
1.2 Skill 的物理结构：核心入口是 SKILL.md，配套文件负责干活
一个最小的Agent Skill通常包含下面几类内容。我以自己给团队写的"技术方案评审纪要生成器"Skill为例，它的目录结构长这样：
review-notes-skill/ ├── SKILL.md # 技能说明书，模型会优先读取这个文件 ├── scripts/ │ ├── extract_topics.py # 从会议记录中抽取评审主题 │ └── format_output.py # 将结果按模板格式化 ├── resources/ │ ├── meeting_template.md # 会议纪要模板 │ └── examples/ │ ├── example_1.md # 一份合格输出样例 │ └── example_2.md # 一份有缺陷但可修正的样例 └── validation/ └── check_output.py # 验证生成结果是否合格关键在于SKILL.md，它是模型理解这个Skill的入口。模型在需要时会把它的内容整个读进上下文，前端有元数据（名称、描述、适用场景），正文部分是分步骤的操作指南，末尾可以挂上验证方式。而scripts/、resources/这些是辅助资产，需要时由模型按需读取或执行。
提示：SKILL.md不是给人看的传统README，它的阅读对象是模型，所以语言要采用命令式、步骤化，避免散文式描述。
1.3 Skill 的"运行原理"：模型在上下文里执行方法论
很多人第一次接触Skill时，会觉得它不过就是换了个壳的Prompt。我一开始也这么想，直到自己写完一个Skill并在Claude里加载试跑之后，才意识到区别在运行机制上：Prompt只是静态的文本输入，而Skill是一个可以动态加载、自我验证的工作包。
当Agent接到一个任务时，它会先判断当前任务和环境中有哪些可用的Skills。如果某个Skill的描述匹配这个任务，Agent就会读取对应的SKILL.md，把操作方法装进上下文，然后按步骤执行。执行过程中如果需要调用脚本处理数据、读取资源文件做参考，它也会自行完成。执行结束后，还可以按照验证脚本检查输出是否达标。整个链路把"教模型怎么做"和"检查模型做得好不好"闭环起来，这才是Skill和普通文字提示真正拉开差距的地方。
2. 别再把 Skill 和 Tool、Prompt 混为一谈，边界划清楚了才不会踩坑
2.1 Tool 是一只机械手，Skill 是一套包含手法和判断的完整打法
如果让我用一句话区分：Tool是Agent用来操作世界的原子能力，而Skill是告诉Agent"面对什么情况、按什么顺序、用哪些Tool、按什么标准交付"的完整方法论。
举例来说，web_search是一个Tool，它知道怎么联网查资料，但不知道查什么、查到之后怎么整理；而"竞品调研Skill"则明确规定了：先搜哪几类关键词、用哪些数据源、信息按什么维度归类、最后输出什么格式的报告。Tool是Skill任其调用的零部件，Skill才是那个懂得安排零部件的操盘手。实际项目中你完全可以在一个Skill里串起搜索、爬取、解析、总结等多个Tool。
2.2 Prompt 只是一段话，Skill 是一个带验证机制的执行闭环
再拿Prompt对标。两者最本质的区别是：Prompt没有反馈回路，模型读完就按自己的理解执行，对不对全凭天意；而Skill自带验证机制。我在设计Skill时会在末尾写明"输出必须经过validation/check_output.py检查，不合格需重新生成"，这样Agent能在交付前先自查一遍结构是否完整、字段是否齐全、长度是否达标。
另一个差别是复用粒度。Prompt往往跟具体任务强绑定，换个场景就要改。Skill则带了触发条件（Description和适用场景），模型可以自动判断"这个任务该不该用这个Skill"，跨项目复用时不需要把那一大段话重新粘一遍，只需要把Skill目录放过去即可。
2.3 Workflow 是一次性的流水线，Skill 是可无限复用的资产
Workflow和Skill的差别，在我看来像"一次性搭建的流水线"和"可复用的工艺包"。Workflow规定了从A到B到C的必经路径，适合稳定、重复、结果可预期的流程；但换个输入源、换个业务场景，Workflow往往要大改。
Skill则把经验从具体流程中解放出来，更强调"面对这类问题应该考虑哪些因素"。比如收到需求时，Skill可以引导Agent按：需求背景、约束条件、方案对比、风险评估、落地步骤的结构去分析，至于每一步具体怎么执行，由Agent结合上下文灵活处理。这也是Skill更接近"智能"的原因——它给的不是死步骤，而是可应变的思考框架。
3. 从零手写一个 Skill：我以"技术方案评审纪要生成器"为例
3.1 第一步先想清楚：这个Skill负责什么，不负责什么
很多Skill项目半路翻车，问题都出在边界没划清。在动手写文件之前，建议先用三五句话回答下面几个问题：
- 这个Skill的核心输入是什么？谁来提供？
- 它能做什么？产出物的形态是什么？
- 它明确不做什么？比如不负责技术评审本身的结论判断，只负责记录。
以我的评审纪要Skill为例，边界是这样的：它接收一份会议速记文本，职责是抽取其中与技术方案相关的决策、待办、风险，并按照团队模板生成纪要。它不去评判方案好坏，也不去替代人工做技术判断，这些留给评审人自己。
边界确定之后，Skill的编写范围也就清晰了，后续所有文件都围绕这个边界展开，不会越写越臃肿。
3.2 SKILL.md 的六个关键字段，我的写法是这种结构
SKILL.md是模型的"操作手册"。我建议用Frontmatter+YAML头 + 正文步骤的结构组织，下面直接给大家我的模板：
--- name: review-notes-generator description: 从技术方案评审会议的速记文本中提取决策、待办、风险，并按团队模板生成结构化纪要。适用于评审会、方案评审、架构决策等场景。 license: MIT --- # 技术方案评审纪要生成器 ## 适用场景 - 输入：一场技术评审会议的原始速记或录音转写文字。 - 输出：一份Markdown格式的评审纪要。 ## 环境要求 - 需要可执行 Python 脚本（系统自带python3即可）。 ## 执行步骤 1. 读取输入文本。 2. 调用 `scripts/extract_topics.py` 提取候选主题和关键句。 3. 结合会议语境，将讨论内容归类到：决策事项、待办行动、风险问题、遗留讨论。 4. 调用 `scripts/format_output.py` 按模板生成纪要。 5. 运行 `validation/check_output.py` 校验纪要字段，如不达标则回到第3步修订。 ## 输出模板 严格按照 `resources/meeting_template.md` 的章节组织内容。 ## 参考样例 - `resources/examples/example_1.md`：合规输出示例 - `resources/examples/example_2.md`：含缺陷输出示例，用于对比学习 ## 重要原则 - 只记录评审中出现的事实和结论，不新增个人观点。 - 待办必须包含负责人（若原文本没有，注明"待确认"）和截止时间（若无，注明"未设定"）。要注意几个细节。第一，description字段要包含任务类型、输入格式、输出格式、适用场景，因为Agent是根据它来匹配Skill的。第二，执行步骤要足够明确，不能出现"根据常识整理"这种模糊表达。第三，样例是必须的，少量few-shot示例对模型输出的稳定性提升非常明显。
3.3 配套脚本和验证脚本：把"好"变成可测量的指标
Skill的配套脚本不追求复杂，能干活就行。我的评审纪要Skill里，extract_topics.py负责从文本里抽候选句子，它本身不依赖大模型，只是做规则式提取——按标点切句、统计关键词权重、挑出和"决策/风险/待办"相关的高分句子。这样做的理由是：让脚本处理确定性高的部分，把判断空间留给模型，执行效率和可控性都能兼顾。
验证脚本的价值则在于给"生成得好不好"一个量化标准。我写的check_output.py会检查：
# 检查输出中是否包含必须的章节 - 必需section是否齐全（决策事项、待办行动、风险问题） - 是否有未解析的超长段落（意味着模型可能没做归纳） - 是否引用了输入文本中不存在的内容（防止幻觉）如果校验不通过，Agent会被要求回到上一步重新生成，这样最终交付质量就从一个随机事件变成了一个经过多层把关的稳定输出。我认为这是Skill区别于普通Prompt最有工程价值的设计。
4. 主流平台上的落地差异：OpenAI、Anthropic 与开源方案各走各路
4.1 OpenAI Agent Skills：和 ChatGPT、Realtime API 的配合更紧密
OpenAI在2025年10月发布了Agent Skills，定位是让用户在ChatGPT和Agent API里安装可复用的技能包。它的Web界面里提供了"Skills"管理入口，用户可以上传技能包，也可以从类似应用商店的渠道安装第三方技能。这个体验非常接近"给ChatGPT装插件"——只不过插件是代码级集成，而Skill更侧重工作流和方法的复用。
在API层面，OpenAI把Skills作为第一等公民来设计，Agent可以自动从配置的技能库中选择匹配的技能响应任务。它还提供了AgentKit等配套工具，方便开发者把技能包集成到自主运行的Agent里。我在实测中发现，它在对话场景下偶尔会跳过加载技能直接回答，因此在提示词里明确标注"如果有匹配的Skill必须使用"会更稳定。
4.2 Anthropic Claude Skills：源文件可见、社区共享文化浓厚
Anthropic走的是另一条路。它的Skills体系围绕"可视化编辑器"和"技能库/社区分享"来展开，核心成员还可以把自制的技能上传并填上标题、描述、行业标签。Claude在桌面App和API里都能无缝加载这些技能。
最打动我的是它的"source transparency"：用户可以直接打开Skill的源文件，看到里面到底写了什么，而不是一个不可审计的黑盒。对于团队来说，这非常重要，因为每个Skill都会直接影响模型行为，不可审计就等同于失控风险。如果你是开发者，想在Claude生态里做团队内部共享，Anthropic的Skills机制是最省事的。
4.3 开源和框架层方案：LangChain 里的 Minion 与"Skill-Registry"
如果你不想绑死在某个厂商生态里，LangChain在自家博客里提出的拆法也很有参考价值。它把Agent配套的能力拆成了"Skills（用于特定任务的指令和工具）"、"Memory（长期记忆）"、"Orchestration（动态编排）"三层。虽然LangChain没有原生的"SKILL.md规范"，但你可以用它的自定义工具 + 提示词模板的组合模拟出Skill的效果。
另外，OpenAI开源的Skill registry也支持本地自托管，意味着团队可以搭建一个内部技能市场。我更推荐这种做法：把技能包放在Git仓库里管理，配合CI/CD做版本验证，再通过内部工具推送到所有Agent环境。对我们这种对数据安全要求高的团队，这是唯一可行的方案。
5. 实战之后，我想告诉你这几件后悔没早知道的事
5.1 一个Skill只教一件事，别做瑞士军刀
我最开始写Skill时犯过一个典型错误：想把"会议纪要生成"和"项目周报生成"合并成一个"文档自动生成Skill"。结果执行时，模型总是纠结于该按哪套规则走，输出风格在不同任务之间反复横跳。拆成两个独立Skill之后，触发准确率大幅提升。
这个教训的本质是：Skill描述越聚焦，模型匹配越准确。一个Skill的适用场景写得太宽泛，会导致两个问题——既抢了其他Skill的触发机会，又让模型在面对不同子任务时方针混乱。如果你的Skill描述里出现了"等"字，或者有好几个"或者"，大概率是把多个能力塞进了一个包，拆开是更好的选择。
5.2 验证脚本不是用来惩罚模型的，而是用来对齐预期的
第一次设计验证机制时，我写得很苛刻：每个字段都要求通过正则匹配、格式稍有不对就判定失败。结果Agent在反复重试中浪费了大量token，产出却更僵硬了。后来我调整了思路：验证脚本只检查"影响下游使用"的结构性问题，至于用词、句式这种主观部分，绝不过度约束。
具体来说，必查项只有三个：必需章节是否存在、关键字段是否为空、是否存在与输入无关的补充说明。其他方面只要结构合理就放行。验证的本质是"兜底"，不是"精雕"，这个定位想清楚了，Agent的执行效率和输出质量反而都好很多。
5.3 Skill也要做版本管理，改坏了一行描述等于改坏一个流程
这是我在团队协作里踩过最深的一个坑。同事更新了一个Skill的步骤描述，觉得自己只是改了几个字，结果模型执行出来的结果从"参会人+决策"变成了"包含完整讨论摘要"，整个纪要风格都变了。如果那个Skill没有版本管理，这个改动是想回滚都无从下手的。
现在我们的团队规定所有Skill都用Git管理，并且约定了一套简单的规则：
- 每次修改必须更新README里的变更日志，写明改动点和触发原因
- 描述字段和行为逻辑有改动时，必须升中版本号；只改错别字、补充样例升小版本号
- 所有Skill修改必须经过"Golden Test"——用一组标准输入跑一遍，确认输出没有出现预期外的改变
这套规则看起来很基础，但真的能拦住大部分"改一个词引发连锁反应"的坑。
5.4 上下文中塞太多Skill，模型反而变迟钝
最后提醒一个大家容易忽略的问题：Skill文件本身是要占用上下文窗口的。哪怕每个Skill只有2000到3000个token，加载三个五个也会积累成一笔不小的开销。而且过多的Skill还会造成"噪音"，让模型对当前任务的注意力被稀释。
我建议在项目里维护一个"按需加载"机制，类似插件系统，Agent只检索与当前任务匹配度最高的2到3个Skill，而不是把所有技能包全量塞进上下文。Skill数量超过15个的项目，我强烈建议做一个索引文件，先由它做一次粗筛，再决定真正加载哪些技能。
我在多个项目里跑通Agent Skills这套思路之后，最直观的感受是：它真正把"调教模型"这件事从一门玄学变成了工程实践。你不再需要靠一遍遍改进提示词来碰运气，而是可以把经验固化成可安装、可验证、可版本化的资产。下一步我准备把团队的Skill注册表接入CI，让每个新版本的Skill都能跑自动回归测试，有兴趣的朋友可以顺着这个方向继续深入。
