这两年做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，不妨先把第一个版本写丑一点也没关系。先跑通闭环，再慢慢打磨，这个领域里，行动快比想得完美重要得多。
这两年做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，不妨先把第一个版本写丑一点也没关系。先跑通闭环，再慢慢打磨，这个领域里，行动快比想得完美重要得多。