Agent技能层（Skill）：让大模型从“光说不练”到“会干活”的关键

这两年做Agent相关的东西我最大的感受是大模型早就不是“不会说话”的问题了而是“光说不练”的问题。让它聊天、写诗、做总结这些都没问题。但如果你指望它去处理一份合同、整理一仓库文档、按你的习惯把周报排好版它往往会给你整出一个看着像样、用起来想骂人的结果。2026年回头看真正把Agent从“演示品”推向“生产力工具”的那个东西不是模型参数更大而是Skill——技能层。如果你已经在用各种Agent产品一定见过类似的东西有人管它叫技能包有人叫能力插件有人叫Agent技能本质上就是把“你希望Agent在某个场景下怎么做事情”打包成一整套规则、步骤和示例让它在下次遇到同类任务时不再靠临场发挥。这篇文章我想把Skills这件事掰开揉碎讲清楚它是什么解决了什么问题怎么写怎么测怎么收藏积累成自己的技能库。适合AI产品经理、提示词玩家、以及想把Agent真正用进工作流的人参考。1. 先把概念说透Agent Skills到底在解决什么问题1.1 从“会聊天”到“会干活”Agent进化缺的那块拼图要理解Skills得先理解Agent自己的成长路径。早期的大模型应用就是聊天框模型知道很多知识但停留在“你说一句、我答一句”的层面这相当于一个刚毕业的实习生知识面很广但完全不懂你们公司的做事流程。后来大家发明了Function Calling让模型可以调用外部函数比如查天气、算数学题模型终于可以“动手”了但每次动手都需要开发者提前写代码、注册函数像极了实习生每干一件事都要问你要一张审批单。再往后出现了MCP这类工具协议把各种外部能力标准化模型可以动态发现工具、调用工具相当于给实习生发了一堆“部门联系方式”它知道有事找谁但依然不知道该按什么流程处理一份完整的任务。真正缺的是什么呢是一本“上岗手册”——上面写着遇到周报怎么处理、遇到合同要检查哪几点、遇到客户投诉先做什么后做什么、哪些情况必须停下来问你。Skills就是这本上岗手册。它不替代模型本身的推理能力也不替代工具的执行能力而是把“做某类任务的经验和流程”固化成一份可复用、可收藏、可随时调用的文档。模型拿到Skill之后相当于一个实习生读完了你写的SOP知道该按什么节奏干活了。1.2 Skills、插件、工具、工作流别再混为一谈我在和一些开发者聊的时候发现一个普遍的混乱插件、工具、Skill、工作流这些词常常被混用。这里我给出一个我自己用着很顺的区分方式。概念本质一个粗略的例子它的边界插件/扩展给Agent所在系统增加一项“功能模块”给浏览器助手加一个截图插件偏系统集成通常需要写不少代码和宿主环境强绑定工具/Function模型可调用的一次性动作单元查库存、翻译一段文本、计算运费单步操作只管“做一件事”不管整件事怎么做工作流/Flow预先编排好的固定执行路径先收集数据再清洗再生成报表流程是死的适合完全固定的任务一旦业务规则变了就要改流程Skill包含知识、规则、步骤、示例的“行为包”一份“如何验收前端页面”的技能文档偏行为方式模型读完后自己决定执行细节灵活性更高这个对比不是为了抠字眼而是为了让你在真正搭建Agent方案时选对工具。如果只是单步动作写一个Function就够了如果整套流程一百年不变用工作流也合理但如果你希望Agent能像人一样面对稍有变化的任务还能按经验行事那Skills就是更合适的那一层。Skill最大的特点在于它把“知识”和“执行”解耦了。知识写在Skill文件里执行交给模型。哪天你的业务规则变了改Skill文档就行不用重新发布一遍Agent程序。这听起来很简单但实际带来的维护成本下降非常明显。2. 它凭什么成为2026年的风向标2.1 模型能力上来了技能层才真正被激活有一个现象值得注意Skills这个概念其实不算全新两三年前就有人尝试过但一直不温不火。为什么偏偏到2026年被当成风向标我的看法是它是一门“水涨船高”的学问。模型本身能力不足的时候Skill文档写得再详细模型也执行不好因为它的指令理解、长文本遵循、多步推理能力跟不上。近两年模型在这几项能力上的突破正好让Skill这种“靠文字驱动行为”的方案真正跑得通了。你可以把模型理解成一位新员工Skill就是培训手册。手册再好员工领悟力太差也白搭现在员工的领悟力上来了手册的价值自然就凸显出来。还有一个容易被忽略的因素上下文窗口变大了很多。以前的模型一次只能消化一两页纸的提示词你塞一套完整的技能文档进去它可能前半段记得、后半段忘光。现在上下文窗口越来越宽一份完整的Skill文档可以在执行任务时整体加载模型读完再干活前后信息都能照顾到质量和早年那种“贴一段Prompt碰运气”完全不一样。2.2 标准化带来的复用红利一份技能文件多处复用风向标级的的东西背后一定要有标准化。2026年Skills能火起来很重要一个原因是技能文件的格式开始收敛了最常见的就是一种约定俗成的Markdown技能文档结构元信息、触发条件、执行步骤、注意事项、示例。你不用去记某个平台的私有格式一份写好的技能文档稍作调整就能在不同Agent产品、不同团队之间流转。我个人的习惯是技能文件尽量只依赖Markdown这种通用格式不掺平台私货。这样做的好处很实在跨团队分享方便用Git管理版本方便将来换Agent工具也方便。某一次我需要把团队里沉淀的七八个技能文档迁移到另一个内部系统里因为当初全部写成了纯Markdown整个迁移只花了一个下午几乎没有重写成本。如果当初用的是某个平台自己的Json格式估计要请五天假慢慢搬。标准化更大的意义在于社区生态。2026年已经出现不少“技能集市”有人把写好的技能文档整理成合集分享出来从“数据分析助手”到“公众号排版顾问”应有尽有。收藏这些技能就像程序员收藏代码片段、设计师收藏素材库一样是在积累自己的能力资产。2.3 “收藏”这个动作本质上是在积累经验资产标题里说“轻松收藏”这里面其实藏着一个认知转变。以前我们在AI时代收藏什么收藏文章、收藏提示词、收藏工具链接。这些东西有一个共同问题它们是“散装”的收藏了不代表会用用的时候还要重新读一遍、理解一遍、调试一遍。Skills改变了这种收藏的逻辑。你收藏的不再是一段知识点而是一整套已经跑通的行为方案。打个比方以前你收藏的是“如何做红烧肉的菜谱”下次做还要自己按菜谱一步步操作火候拿捏全靠临时发挥现在你收藏的是一个“会做红烧肉的厨师”直接把食材丢给他他自己按习惯操作你只需要最后尝一口味道。当然现在还没到直接雇厨师的程度但已经非常接近了。我自己现在维护着一个个人技能库里面大概有二三十个Skill覆盖了写周报、做会议纪要、整理读书笔记、分析表格数据这些高频场景。收藏它们的时候我不需要把每个技能的内容都背下来只需要知道库里有什么、哪个场景调用哪个用到的时候让Agent加载即可。值得一提的细节是你收藏Skill的时候也等于收藏了你自己反复沉淀下来的做事标准。比如我的会议纪要技能迭代过七版每一版都修正了上一版执行时的偏差。这些修改记录就是我最值钱的经验资产。3. 拆解一个高质量Skill的内部结构3.1 一份标准技能文件里到底该放什么很多初学者第一次写Skill容易犯一个错误把技能文件写成一篇“操作说明书”全是文字描述罗列了一堆“你应该怎么怎么做”然后丢给模型指望它自动开窍。结果模型执行得一塌糊涂。问题出在哪里缺结构。我整理过一套比较稳定的技能文件骨架基本分为五个区块顺序一般不要乱第一块是元信息写清楚技能名称、一句话描述、适用场景、作者、版本号。这段的作用主要是给“调用方”看的让人或系统快速判断这个技能适合什么任务。好的描述一定要带场景词比如“适用于每周五生成工作周报”而不能只写“生成周报”。第二块是触发条件明确告诉模型“遇到什么情况应该使用本技能”。这是很多人会忽略的重点。模型在解码时其实是在“匹配”你给它的场景描述越具体它越能判断“现在该调用这个技能了”。触发条件写得太宽它会乱用写得太窄该用的时候想不起来。第三块是执行步骤把完成任务的过程拆成有顺序的子步骤。注意步骤之间要给决策点告诉模型“在什么情况下跳到哪一步”而不是一串无脑顺序。这样技能才有适应性。第四块是注意事项也就是边界和禁止项。比如“不要修改原始文件”“超过200行数据时先分片处理”“如果缺少关键字段停下来向用户确认”。这一块是安全网很多翻车都出在模型自作主张上。第五块是示例最好给两到三个完整的、贴合的、有代表性的示例展示“输入什么、输出什么、过程中做了什么决策”。示例对模型行为的影响往往比抽象描述还大因为模型在模仿你给的范例。给一个坏示例它会学坏给一个好示例它执行质量会明显上一个台阶。3.2 以“周报整理助手”为例看技能文档如何设计假设你想让Agent帮你整理周报先别急着写“你帮我写周报”这几个字我们要拆一下这个任务。用户的原始需求往往是“把这一周的零散记录整理成一份周报。”这背后其实涉及至少五个子任务分类汇总、筛选重点、格式化输出、语气校准、不确定信息处理。如果不拆模型会自由发挥每次给的周报风格都不一样时而像流水账时而像小说。一个合理的技能设计应该是这样描述适用于每周五整理工作周报输入是杂散的工作记录输出是结构清晰、按项目分类的周报文本。触发条件当用户提供一周的工作记录、聊天记录、会议摘要并要求“整理周报”“汇总这周工作”“按项目写周报”时。执行步骤先通读全部记录识别出项目和任务两类维度再按项目分类同一项目下按时间或优先级排列任务然后合并重复项、过滤与工作无关的内容最后按“本周完成”“进行中”“问题与风险”三个区块输出且每条尽量用“动词结果”的句式。注意事项不编造没有的工作内容不确定是否属于本周的任务时先标记“待确认”不要直接删除如果记录少于三条先输出提示“记录过少建议补充”。示例给一份简短的原始记录展示它怎么把三句杂话变成一条规范周报条目。写好之后你可以看到模型不是“自由发挥”了而是按一套你认可的标准来执行。标准被固化下来才能被收藏、复用、迭代。这也是Skills区别于普通提示词的关键提示词主要靠临时引导技能则是把引导过程系统化。4. 手把手实操从零到一写出你的第一个Skill4.1 需求拆解与命名规范决定后面省不省心动手写Skill之前先花十分钟做需求拆解。我见过最快的翻车方式就是拿到需求直接写文档写完发现技能跟实际任务对不上。拆解时问自己三个问题第一这个任务是不是高频、有固定结构比如“整理周报”就比“帮我随便想想下周干点什么”更适合做成Skill。第二输入是什么、输出是什么输入可能是一段文本、一个文件路径、一整个文件夹输出是纯文本、Json还是表格第三你希望模型在执行中有多大的自由裁量权有些任务需要它严格按流程走有些任务希望它自己发挥。自由度设置错了技能就会要么死板、要么失控。命名规范也值得认真对待。我给技能命名的规则是“动词对象场景后缀”全小写用下划线连接。比如summarize_weekly_report、extract_meeting_action_items、review_product_launch_checklist。这样做有两点好处一是你收藏上百个技能后靠文件名就能快速检索二是很多Agent平台会对技能名称建立索引命名越符合直觉触发准确率越高。别用什么aaa_final_skill_v2这种名字三个月后你自己都找不到它。4.2 技能文件的标准写法一个可以直接抄的模板下面我给出一个我一直在用的基础模板你可以直接拿它做起点套到自己的场景里。注意模板里的“输入”和“输出”做了简化真实使用中请按你的任务改。--- 名称: review_code_quality 描述: 适用于审查一段代码的代码质量重点关注可读性、潜在缺陷和测试覆盖。 适用场景: 代码审查、提交前自检、代码教学反馈 作者: yourname 版本: 1.0.0 --- # 技能代码质量审查助手 ## 触发条件 当用户输入一段代码并要求“帮我看看代码”“审查这段代码”“有没有问题”时使用本技能。 ## 执行步骤 1. 先阅读完整代码识别语言与主要逻辑。 2. 从三个层面检查 - 可读性命名是否清晰、函数是否过长、逻辑是否有隐藏复杂度。 - 潜在缺陷是否有空指针风险、边界条件未处理、资源未释放。 - 测试覆盖关键分支是否有对应测试用例。 3. 按严重程度输出阻塞问题、建议改进、可忽略项。 4. 每类问题给出一句示例性修复建议但不需要直接重写全部代码。 ## 注意事项 - 如果代码长度超过500行先按函数拆分后再逐块审查。 - 不要臆测代码的业务需求缺少上下文时明确标注“需要人工确认”。 - 如果用户只要求指出问题不要求修改代码不要输出完整重写版本。 ## 示例 输入 一段包含明显空指针风险的Python代码 输出 【阻塞问题】 - 第X行变量在空值场景下直接访问属性建议增加空值判断。 【建议改进】 - 第Y行函数名含义模糊建议改为...这个模板的好处是模型拿到后会先看“触发条件”判断要不要用这个技能再看“执行步骤”按节奏走最后参照示例调整输出格式。每一部分都在引导模型行为而不是碰运气。4.3 让Skill“开窍”的测试闭环别写完就当完工技能文件写完只是第一步真正让它“开窍”要靠一轮一轮测试。我的流程非常简单粗暴准备一组测试样例包含三种类型——典型用例、边界用例、异常用例。典型用例看正常任务做得怎么样边界用例看输入太短、太长、格式不合规时能不能正确应对异常用例看它遇到完全不该使用该技能的场景时能不能正确拒绝。以刚才的代码审查技能为例典型用例是一段中等大小的Python脚本边界用例是一段几百行的大文件异常用例是用户只发了一句“晚饭吃什么”却让模型“按照代码审查技能处理”。一个好的技能应该能在异常用例面前明确拒绝或提示“这不是代码审查的适用范围”而不是硬着头皮瞎套。测试一次发现偏差就回去改对应的那一块。描述不准确就改描述示例不充分就补示例。不要指望一次成型我自己最常用的周报技能改了七个版本才稳定。每一次修改记录了原因和效果这就是技能库最宝贵的地方。测试中还要特别注意一个问题模型可能会“假装完成了任务”。具体表现是它输出了格式很漂亮的结果但内容其实没真正处理输入数据。比如给它三份会议记录它输出的会议纪要把每份都只复述了第一段后面的内容根本没读进去。这种时候不是模型蠢而是你的技能里缺少“强制完整处理”的约束。我通常在注意事项里加一句“必须覆盖所有输入记录任一记录未被引用时在结尾标注未覆盖清单。”加完这句翻车率立刻下降。4.4 收藏与管理把自己的技能库整理成“能吃老本”的资产技能多了之后收藏和管理就成了大学问。我的个人做法是三层结构底层是技能文件夹中层是索引文件上层是版本记录。在本地我建了一个skills/目录每个技能一个子文件夹里面放一份SKILL.md和若干辅助材料比如参考模板、测试样例。目录下维护一份INDEX.md用表格记录每个技能的名称、场景、版本、修改日期。别小看这个索引以后技能超过几十个的时候靠它可以快速定位而且在Agent加载技能时一份清晰的索引能帮助系统做检索匹配。版本管理我用Git每次修改技能文件就提交一次Commit消息写清楚“改了什么、为什么改”。比如fix: 周报技能增加未覆盖任务标注几个月后翻历史还能知道当初的决策过程。有很多次我把某个技能改坏了直接找回上一版比重新写一遍快多了。收藏别人的技能时要额外留心一点技能文件里可能带有原作者所在团队的业务习惯或私有信息。直接拖进自己技能库前先通读一遍把不适用的部分删掉把涉及内部数据的地方全部替换成通用描述。这一步不是洁癖是安全习惯。有些技能集市上的案例看起来干净但细看里面留着原作者的内部域名甚至客户名这种内容拷进来就是隐患。5. 常见问题与避坑实录5.1 技能“学过”了但执行起来还是不对这是我被问得最多的问题明明Skill文档写得清清楚楚模型也读取了但执行结果还是和预期差很远。排查顺序我建议固定下来先看触发条件是否匹配再看示例质量最后看步骤是否会误导。触发条件写得太宏观是常见原因。比如写“适用于所有文本处理任务”这等于没写模型在需要技能时根本无法判断当前任务是否属于这个技能。解决办法是把触发词写细最好列出用户可能说的原话片段“整理周报”“这周工作总结”“帮我汇总一下这周的进展”。示例问题也经常被低估。模型对技能的理解很大程度上来自示例中呈现的行为模式。你的示例如果输出很简短模型也会偏向简短示例如果不包含“信息不足时怎么办”模型遇到信息缺口就会编造。所以示例最好覆盖完整过程和一次异常处理。步骤误导的问题最隐蔽。比如你写“先总结再分类”模型可能先把所有内容压缩成一段再也没法分类了因为信息已经丢了。正确顺序是“先分类再总结”。这种问题很难通过调整措辞解决必须在测试中发现所以测试样例里一定要有能暴露顺序问题的用例。5.2 触发条件不灵该用的时候没用不该用的时候乱用触发条件不灵有两种表现。一种是该触发时不触发通常是描述里的场景词和用户真实表述不匹配。用户说“帮我写个会议纪要”你的触发条件里却写的“适用于会议总结”模型可能真的匹配不上。解决办法不是啰嗦而是列一个用户可能说法的清单把“写纪要”“做会议记录”“整理会上内容”都放进去。另一种是误触发用户聊着日常话题模型突然加载了技能。这通常是触发条件里的场景太宽泛比如“适用于任何文本写作任务”于是用户让Agent写个请假条它都套用了周报技能。解决方式是给触发条件加限定和排除项比如“仅当用户要求整理周期性工作总结时使用日常文字写作不属于本技能范围”。还有一个容易被忽略的因素技能名称和描述中出现的关键词可能会和模型内置的某些指令冲突。我遇到过一个小技能叫create_report结果只要用户说“报告一下”模型就触发它后来我把名字改成更具体的format_monthly_sales_report情况立刻好转。所以命名既要是“动词对象”也要尽量具体到任务特征。5.3 技能执行到一半和外部工具衔接不上很多Skill不只是写写文本还要调用外部工具比如发邮件、更新表格、读取数据库。这时候最容易翻车的点是工具参数描述不完整。模型可能正确判断了“需要发邮件”但不知道邮箱地址该从哪里取也不知道正文和主题用什么格式于是要么卡住要么乱传参。我在Skill文档里会专门加一节“外部工具说明”把每个会用到的工具体系写清楚工具名称、输入字段、字段格式、必填和选填、输出结果怎么使用。如果工具有权限限制还要明确提示“该工具只能操作授权范围内的数据”。不要嫌麻烦参数描述越精确模型执行越稳定。另一个实际遇到过的问题是外部工具返回了异常结果模型不会处理。比如查数据库返回“连接超时”有些Agent就直接把这句话当结果展示给用户。我后来在技能里加入了异常处理规则“工具返回错误时先记录错误信息尝试重试一次仍然失败则明确告知用户不掩盖错误不编造成功结果。”加上这条之后整个流程的可靠性提升了一个档次。5.4 安全边界不该Agent碰的事别写进Skill最后说一个必须重视的坑安全边界。Skills的本质是把行为方式固化成文档但如果一个技能里包含了一些不应自动执行的高风险操作又没有设置确认环节那它就是一个安全隐患。比如你写了一个“自动归档旧项目文件”的Skill里面包含“删除三个月未更新的临时文件”如果没有写“删除前必须生成清单并由用户确认”风险就很大。模型按技能执行可能把不该删的历史资料都清掉了。我个人的原则是涉及删除、发送、支付、审批这类不可逆或外部影响较大的动作技能里一定要写“执行前必须停下来向用户展示操作清单等待明确确认”。哪怕步骤多一步也值得。还有一个容易被忽略的边界数据隐私。技能文件里如果直接写了“将用户输入发送到翻译接口”“把记录同步到云端表格”你要确保这些行为是用户知情并且同意的。我在技能模板里习惯放一句通用约束“涉及跨系统数据传输前先向用户说明数据流向。”这句话不需要每次执行都机械地弹给用户但它提醒模型在边界操作上保持谨慎。针对安全这件事我给自己的技能库定了一条铁律凡是含敏感操作的技能版本号必须到两位小数每一次修改都要写明审查记录。因为这类技能一旦出问题代价比功能不好用大得多。宁可多写一步确认也不要图省事。写在最后我个人实际操作下来最深的体会是Skills真正的价值不在于单次执行效果多惊艳而在于它让你沉淀下来的工作方法变得可复用、可传播、可持续迭代。刚接触的时候我也觉得这不过是一种更复杂的提示词罢了但现在回头看它其实改变了我和Agent协作的方式——我不再每次重复交代任务细节而是在一遍遍打磨技能文件的过程中把自己脑子里的经验逐步“外置”成一个能力库。如果你现在刚开始接触我的建议很简单不要一上来就想做一个宏大又全能的技能从你自己每周都在做的事开始拆解它、写下来、测试它、收藏起来。等你攒到十个八个之后你会发现自己对“让Agent干活”这件事的理解已经完全不一样了。如果你也想开始收藏自己的Skill不妨先把第一个版本写丑一点也没关系。先跑通闭环再慢慢打磨这个领域里行动快比想得完美重要得多。