Agent Skills实战指南：与Prompt、Tool、Workflow的区别及手写方法

Agent Skills这个概念在2025年下半年突然刷屏先是Anthropic放出Skills紧接着OpenAI正式发布Agent SkillsLangChain也跟进做了开源实现。但说实话大部分解读还是停留在又一个大模型新功能的层面很少有人讲清楚它和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是模型的操作手册。我建议用FrontmatterYAML头 正文步骤的结构组织下面直接给大家我的模板--- 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都能跑自动回归测试有兴趣的朋友可以顺着这个方向继续深入。