1. 项目概述与核心需求解析先说结论Agent Skills 这个概念最近在智能体圈子里被反复提起但真正会用的人其实不多。大多数人把它当成普通插件的平替或者以为就是写几个 prompt 模板存起来调一调这都属于低估了它的价值。Agent Skills 到底是什么我理解它是一类可以被智能体显式调用的小型专项能力——以精确的输入描述触发、以结构化步骤执行、以可校验的结果输出。它和 Prompt 模板最大的区别在于Skills 不只是告诉模型“怎么回答”而是给模型一套可执行的、分阶段的处理协议中间还能嵌入外部工具调用、代码解释器、文件读写这些交互性操作。换句话说Prompt 是教模型做人Skill 是让模型上手干活。这篇文章选的角度是“五个真正好用的 Skills”我把它定义成覆盖高频场景、接口简洁、稳定性好、能直接放进现有智能体流程使用的成熟能力同时补上一节自定义教程把设计一个 Skill 的完整思路和骨架代码走一遍。适合谁看正在做智能体应用但觉得默认能力不够用的开发者、想要在团队内部搭建轻量级 AI 工具的工程师以及刚刚接触 AI Agent 生态、想了解真实玩法的学习者。我看过太多人绕开这套机制不用宁可每次写一大段引导词去临时约束模型也不愿意花半小时做一个 Skill 来长期复用这个成本账怎么算都不划算。我们需要拆解的需求有两层第一层是“用”即理解这五个 Skills 各自解决什么问题、在什么场景下调用最合适、参数设计上要注意哪些细节第二层是“造”即掌握自定义 Skill 的标准流程——从需求定义、步骤设计、两条语义路径指令型与代码型、到测试与迭代闭环。这两层打通Agent 的能力边界就不只能靠大模型本身的提升来扩展而是可以由你自己来定制扩展。我不打算堆砌概念直接拿实际能跑的案例说事。下面的内容基于我自己的实测和调试记录案例中的智能体统一叫“某跨平台系统”的一个内部试验项目我拿它做了不少对照测试后面会逐步分享心得。2. 五个真正好用的 Skills 逐一拆解2.1 Skill 一六页 PPT 大纲规划器——让模型先搭结构而不是先想文案很多人让 AI 做 PPT 时第一反应是让它直接生成每一页的详细内容这个思路从一开始就错了——模型在没有结构约束的时候普遍会把所有内容堆在一起产出的东西密度不均逻辑链断裂严重。“六页 PPT 大纲规划器”这个 Skill 的核心在于它先强制模型在全局视角下做分页规划再逐页生成要点最后才进入文案层。我做的这个版本是给团队内部汇报用的核心针对性问题就是“汇报内容逻辑混乱”“不知道每页讲什么”。它的设计思路并不复杂核心是流程拆分。第一阶段模型需要先定义整份 PPT 的叙事主线明确六页分别承担什么角色——封面定调、痛点引入、方案解答、案例论证、数据佐证、行动呼吁。每一页的要求都不同封面页不能堆摘要应该放结论性的标题痛点页要说人话不要罗列术语方案页必须把“我做了什么”和“为什么有效”绑在一起讲。第二阶段只生成大纲每页只允许三到五个要点且层次关系必须清晰不允许出现“第一点之外还有第一个子点”这种混乱结构。第三阶段才是细化文案且这个阶段在我实际使用中很少触发——因为大多数情况下大纲一旦立住用户自己就能补齐文案了。为什么要限制成“六页”因为汇报类场景下六页是信息表达效率比较高的结构多于六页容易注水少于六页又往往压缩了必要的逻辑环节。当然如果你有不同需求这个数字完全可以调。但我觉得大家真正值得借鉴的不是六页这个具体数字而是“先结构、后内容”的处理协议。在实际测试中这个 Skill 的输出质量比直接提问高很多尤其是在“为什么选这个方案”这一类需要因果逻辑的内容上模型的表达会显著更聚焦。2.2 Skill 二代码差异走查员——不写测试只做变更安全评估智能体写代码已经不是什么新鲜事但我发现大多数人在让智能体处理代码变更时忽略了“变更影响评估”这个重要环节。模型默认只会看 diff很难主动去思考这些改动会影响哪些调用方、会不会造成兼容性问题、错误处理路径是否完整。“代码差异走查员”这个 Skill 就是解决这个问题的——它不替你做代码审查的全流程而是专注做差异影响分析。这个 Skill 的执行逻辑是输入一段 diff 或两份代码片段它按固定维度输出分析报告——变更点在哪个模块、影响面有哪些、涉及哪些依赖关系、需要重点验证的分支路径是什么。关键要求是模型给出的影响评估必须基于代码逻辑推导不能凭空推测不确定的影响点要显式标记为“待确认”不能为了完整性而编造信息。我实际用过一次 diffs 特别大的场景几百行的变更丢进去如果让人肉去逐行看真的要花不少时间但这个 Skill 能快速定位出核心变更模块、圈出相对有风险的点这样我再去看这些关键位置就好。它不会替代人来做最终判断但它能把人的注意力引导到正确的地方——人机协作的价值就在这里。如果你经常要 review 大量代码变更这个 Skill 的制作优先级我会放得很高。2.3 Skill 三结构化信息抽取器——把非结构化内容变成表格做智能体应用的人大概率都遇到过这个痛点大模型能理解一段文字但输出结果往往格式不稳今天给你 JSON明天给你 Markdown 表格后天直接在段落里夹带注释下游程序一解析就崩。我之前在某跨平台系统的数据清洗流程里就被这个问题卡过很久。后来想通了不要期望模型自己保持格式稳定你需要给它一个显式约束的 Skill。“结构化信息抽取器”就是在这一背景下设计的。它的功能是从一段非结构化的文本中按预设的字段定义抽取信息并严格输出为指定格式的表格或 JSON。关键细节在于字段映射表的设计——你需要预先定义每个字段的中文标签、字段名、允许取值类型、是否必填、无法抽取时的默认值策略。例如一段招聘需求文本字段可能包括岗位名称、薪资范围、技能要求、工作地点、经验年限如果原文没有给出薪资就填入“面议”。这种预设兜底策略很重要它避免了模型强行编造或留空导致下游失败。使用这个 Skill 有个经验输入时最好同时给一段示例文本和一个目标字段表模型在抽取时能更好地对齐你的语义预期。实测下来在字段定义明确的情况下抽取准确率能到九成以上剩下的基本属于原文本身含糊不清导致。它比较适合的场景包括简历筛选、合同条款抽取、评论情感标签化、任意表单的自动录入。它虽然不是那种一听就高深的能力但实用价值却非常高——稳定的输出结构比炫酷的回答更能解放生产力。2.4 Skill 四会议纪要动作提炼器——别全文转写只留行动项先问一个问题你让 AI 帮你总结会议纪要时最想要的东西是什么我的真实需求其实不是全文总结而是从冗长对话里找出后续要做什么、谁来做、什么时候完成顺带把决策点和风险信息摘出来。市面上不少会议纪要工具都能做全文摘录但真正能准确提炼行动项的却不太多。“会议纪要动作提炼器”这个 Skill核心就是把“行动项抽取”作为最高优先级目标。它的处理协议分三步。第一步筛选对话中的行动表达包括但不限于明确的任务指派、承诺的时间节点、条件的承诺关键在于不要让模型混淆“建议”和“行动”这一步尤其需要提示模型保持谨慎。第二步将行动项整理为独立的表格每行包含负责角色或人、行动描述、截止时间、优先级、来源上下文如果对话里没有出现明确负责人表格中要写“待指派”而不是让模型猜测。第三步自动从对话中提取潜在风险和决策信息另行输出。这里有一个技巧在 Skill 定义中要写明“宁可少提取不要编造”这能显著降低幻觉率。这个 Skill 还有一个价值——输出格式非常规整可以直接对接后续任务管理系统。理论上只要把生成的项目级表格通过接口推到任务看板里流程就能自动化贯通。实测中我在某次团队评审会上试过一次原对话近一个小时提炼出来的行动项刚好九条其中有几条的确是我当时没留意到的小任务细节能起到不小的提醒作用。2.5 Skill 五通用五步问题拆解法——让模型学会“先分解再回答”最后一个 Skills 和前面几个不同它不依赖具体业务场景而是一个通用型思维协议。它的作用是当模型遇到一个复杂、边界模糊的问题时强制它按五个步骤进行拆解——第一明确问题本身和约束条件第二列出可选的解决路径第三对比路径的优劣和适用条件第四选定一条路径并细化执行步骤第五总结验证方法和判断标准。为什么需要这个 Skill因为默认情况下模型面对复杂问题时容易“跳步”直接给结果而省略推理过程这种输出看起来漂亮但往往经不起推敲用户在真实世界里也难以落地。引入这个 Skill 后它把所有“隐性推理”显式化了用户能看到模型在每一步展开的内容从而判断中间环节是否合理——这其实有点像让 AI 给人展示草稿让信任感大幅提升。我自己的使用方法是把它挂到智能体的一个开关上。当遇到开放式问题、规划类问题、多选一决策类问题时我会手动触发这个 Skill但像直接查询、简单问答这类场景不启用它保持响应速度。这个设计思路也提示大家Skills 不是越多越好也不是每个对话都要启用而是要在合适的场景里精准调用。3. 自定义 Skill 的完整制作流程3.1 第一步明确 Skill 的输入输出契约想做一个能用的 Skill我建议先把“输入—处理—输出”的边界定清楚这比急着写代码重要得多。很多开发者上来就想写实现结果做出来的东西既不是通用能力也不是垂直工具两头都不靠。先想清楚三个问题。第一你这个 Skill 要服务的输入是什么比如“六页 PPT 大纲规划器”的输入是汇报主题、目标受众、核心数据而“代码差异走查员”的输入是一份 diff 或两个版本的代码片段。输入定义要具体不能写“任意文本”。第二中间处理逻辑有哪些步骤每个步骤做什么是否允许调用外部工具第三输出格式是什么是表格、JSON 还是 Markdown 文档不要忽略输出的校验规则。比如可以让模型在输出完成后自检一遍字段完整性这能减少下游解析的出错率。我习惯把这个过程做成一张“输入输出契约表”设计任何 Skill 之前先把这张表填满。一张比较标准的表类似这样项目内容定义设计要点输入描述触发该 Skill 的任务类型要详细到“什么场景下用户会发起这个任务”输入参数必填项、选填项及其格式每个参数都要有类型说明处理步骤阶段划分和每阶段目标步骤越多约束越强但别超过五步输出格式结构化字段和示例字段命名要可预测、可扩展兜底策略信息缺失时的默认处理方式防止模型为了对齐格式而编造3.2 第二步两类 Skill 写法选一个适合你的按执行方式划分我把 Skill 分成两类指令型Prompt-based和代码型Code-based。指令型 Skill 的本质是“在系统提示词里嵌入一段高度结构化的执行协议”。你写的不是一句提示词而是包含角色定义、执行步骤、约束规则、输出模板在内的完整指令块。它的优势是简单、调试快、不依赖运行环境劣势是模型仍有一定自由发挥空间稳定性依赖你的文本设计能力。适合做思维导图类、分析类、策略类这些不涉及复杂计算的技能。代码型 Skill 则是将处理逻辑用代码固化下来模型只负责提取关键参数并填充执行执行过程由代码完成再把结果返回给模型整理成最终答案。比如你想做一个批量格式转换的 Skill与其让模型逐条处理不如把转换逻辑写成脚本模型只需要按要求传入输入即可。代码型 Skill 的优势是精度高、可复现、适合固定流程劣势是需要考虑环境兼容、依赖管理试错成本高一些。我给你的建议是凡是涉及计算、格式转换、API 调用、文件处理的场景优先考虑代码型凡是涉及分析、策略、写作、规划的场景优先考虑指令型。两者无法完全替代。以下是一个实际跑过的代码型 Skills 骨架示例我用它做文本清洗与字段抽取核心部分如下import json import re def parse_extract(text: str, schema: dict) - dict: result {} for field, config in schema.items(): pattern config.get(pattern) if pattern: match re.search(pattern, text) result[field] match.group(1) if match else config.get(default) else: result[field] config.get(default) return result schema { 岗位名称: {pattern: r(?:岗位|职位)[:]\s*([\u4e00-\u9fa5\w]), default: 未提供}, 薪资范围: {pattern: r(\d[kK]?[-~至]\d[kK]?), default: 面议}, } print(json.dumps(parse_extract(text, schema), ensure_asciiFalse))这段代码的思路非常直白按 schema 里定义的字段正则去匹配输入文本匹配不到就用默认值兜底。在指令型 Skill 中极少有“稳定到可复现”的事换成代码型就能做到。页面后半段你仍然可以让模型把这份 JSON 转成用户友好的格式但核心准确率由代码保障。3.3 第三步把 Skill 封装进智能体运行时写好 Skill 逻辑后还要把它接入智能体的运行时。这里我不推荐直接在系统提示词里贴一整段长文本因为不同平台和框架对提示词长度有不同限制也影响维护效率。最佳实践是把 Skill 的定义单独写成一份配置文件通过框架的动态加载机制注册进运行时让智能体根据用户的描述判断是否触发对应的 Skill。配置结构中必须包含以下关键字段技能名称、描述用于智能体判断是否调用、输入参数 schema、执行类型指令型/代码型、执行代码或指令文本、版本号。用 YAML 描述可能长这样name: markdown_table_extractor description: 从非结构化文本中抽取字段并生成 markdown 表格 input_schema: text: type: string required: true fields: type: array items: string required: true execution: type: code_python entry: extract_table.py version: 1.0你还需要考虑调用时的输出兼容问题。比如某框架的运行时对工具返回结果做二次解析那你的代码脚本输出格式就要严格匹配框架预期——如果框架期望 JSON 对象那脚本执行后就不应该打额外日志。这一步看起来小但实际部署时很多运行时报错都由此引起。我在某跨平台系统里第一次集成时就是没注意标准输出中多了一行调试信息导致工具调用结果一直解析失败。3.4 第四步调试与迭代闭环Skill 的调试和普通代码调试不一样属于“半随机系统”的调试你得接受模型输出的不稳定性。我的建议是用一套固定的测试集反复跑同一输入观察输出一致性和质量变化。建立十个典型输入样本作为基线就够用了覆盖正常情况、边界情况和异常情况。跑测试时重点关注三类问题格式漂移、内容幻觉、过度拒绝。格式漂移最常见——有时模型会自己发挥输出不必要的开场白或结束语这会破坏下游解析。解决办法是在 Skill 中加强格式约束比如加入输出规范自检步骤。内容幻觉多发生在信息缺失时模型会倾向补全一个看似合理的答案应对策略是兜底字段策略和禁止编造提示。过度拒绝则是模型因为约束太严格或者对无关输入理解能力过弱直接判定自己不适用通常需要优化 Skill 的触发描述让它的识别范围更精准。我之前在调试一个“数据脱敏器” Skill 时就遇到过类似问题明明输入是一段身份证号脱敏需求模型却因为描述写得太窄而拒绝执行。后来把触发描述改宽泛了些加入了“任何疑似个人信息的处理任务”这一类泛化描述效果立竿见影。这个经验后来被我复用在好几个 Skill 的调优中现在想来触发描述的设计质量直接决定了 Skill 的可用率值得花时间打磨。4. 经验技巧与常见问题排查实录4.1 一个好的 Skill应该具备哪些特征做过的 Skill 多了之后我总结了一些共性特征也许能作为你后续设计时的参考标准。第一个特征是“专注单场景”。一个 Skill 只解决一个场景问题不贪多。如果你发现自己在设计时又开始加各种功能停下来把它拆成两个。某次我尝试做一个“代码评审 注释生成 架构分析”三合一的 Skill最终实测效果很一般。后来拆成三个独立 Skill每个准确率和稳定性都上升了一大截。原因很简单多任务叠加会让模型的注意力分散每一步的提示设计也会彼此干扰。第二个特征是“收敛表达”。好 Skill 的输出一定是一个固定结构的产物不是一大段自由文本。只要可能输出都以表格、JSON、列表、模板形式呈现。这带来的好处是下游可以做自动化对接也方便人对结果做 diff 比较。第三个特征是“允许人介入”。Skill 不应是一个黑盒它应该在关键节点给人留出校验和调整的余地。比如在“六页 PPT 大纲规划器”里模型在生成完大纲后应停下来等用户确认再继续深入内容——这种设计在实际体验中很有价值。也许一个更反直觉的特征是Skill 不能太“聪明”。如果你写的 Skill 经常让模型自由发挥、灵活调整那就退化成普通 prompt 了。Skill 的价值恰恰在于让模型在既定约束里做有限动作去掉不必要的自由性。4.2 常见问题速查表我整理了在设计和使用 Skills 过程中比较常见的几类问题以及对应的处理建议方便大家对照排查。常见问题可能原因处理建议输出格式不稳定指令中对格式约束不够强在 Skill 末尾增加输出自检步骤让模型确认格式符合再返回触发不够精准触发描述写得过窄或过宽重写描述涵盖典型场景并补充相关泛化描述模型拒绝执行约束过于严苛适当放宽约束区分“禁止”与“建议”两种表达结果重复冗余提示中输出模板与系统提示词有重叠排查重复定义理清职责边界执行结果不符合预期未定义有效边界条件和默认兜底补充缺失信息时的默认处理策略代码型 Skill 报错输出日志混入标准输出将日志写入文件或用专用通道保持结果纯净模型幻觉严重缺失的信息被补齐增加禁止推断规则和字段级兜底策略参数解析失败输入 schema 与运行时约定不一致校验字段名和类型对照框架文档逐项确认4.3 我踩过的几个坑讲几个我在实践中踩过的比较典型的坑希望你能少走一些弯路。第一个坑是急于做复杂的 Skill 而跳过了单场景验证。早期我最早那版代码型 Skill 是从“信息抽取 校验 去重 报告生成”一步到位的结果模型在中间环节出错时根本定位不了是哪个阶段的问题。后来把流程拆成逐步标记的阶段每次只验证一步再串联起来调试效率反而提高了。对于复杂的 Skill你要允许模型分阶段输出中间结果而不是只给终态。第二个坑是忽略了输出中的隐藏字段污染。有一次代码型 Skill 在生产环境跑着跑着输出解析偶发失败查了很久才发现是模型在填充 JSON 时加了一个不在 schema 里的额外字段下游解析器严格模式直接拒绝。从那之后我在所有 Skill 的输出契约里都加了一行“只能输出 schema 定义的字段不得添加额外内容”并且在下游做一层强校验过滤。第三个坑是触发描述只写了正面场景没写反例。比如一个负责“提取行动项”的 Skill如果没有在描述里说明它不适用于闲聊类对话那么智能体可能在一个随便聊天的场景里强行触发它产出内容乱七八糟。后来我给每个 Skill 都补充了“不适用场景”的约束触发精准度明显改善。4.4 一点使用心得在某种程度上Skills 的设计哲学和函数设计很像——函数要做单一职责要有清晰入参出参要能独立测试。你如果带着这个思维去设计 Skills很多模糊的问题都能变得清晰。还有不要试图把所有逻辑塞进一段提示词里必要时就用代码做支点。代码是确定性的模型是概率性的让确定性的部分承担关键计算反而能发挥两者合力。另外我建议你建立一个 Skills 的版本管理习惯。每次改动都记录版本号和测试结果方便回溯。我自己现在用一个简单的变更日志文件管理所有 Skills 的迭代记录这样哪怕三个月后回头看当初某版 Skill 为什么被推翻也能找到依据不至于靠回忆。5. 设计一套自己的 Skills 时的一些补充建议5.1 从需求的“高频痛点”出发而不是从技术可能出发做 Skills 时最忌“因为能做所以做”。我自己早期也经历过这个阶段——今天看到模型能总结就做个总结器明天看到能翻译又做个翻译器。结果做出来的东西确实能用但真实场景里根本不会主动想起来用。后来我调整了策略每两周记录一次自己实际使用智能体时感觉别扭的地方把它列为候选场景。比如有段时间我发现让模型输出表格后转成 Excel 总要多步操作于是做了一款“表格转 Excel 生成器”的代码型 Skill又比如很长一段时间我处理招聘 JD 时总要重复输入字段定义于是做了前面提过的“结构化信息抽取器”。这种从实际卡点出发选型的方式比较不容易做出自我感动型工具。5.2 模块化设计底层能力、业务能力、表达能力的图层划分如果你要建一套 Skills 体系我建议分层设计而不是平铺一堆独立技能。底层是通用能力比如“结构化输出”“格式转换”“信息校验”中间层是业务能力比如“代码走查”“会议纪要提炼”“信息抽取”最上层是表达能力决定最终面向用户的输出风格和质量。当业务层技能需要底层能力时可以直接复用不用在每个技能里重复写提示词。我这里再举一个真实做过的案例。我在做“简历自动筛选器”这个 Skill 时底层复用了“结构化信息抽取器”的抽取逻辑中间层加了行业字段映射上层则自定义了输出模板和推荐等级规则。最终开发时间只花了不到两天因为有相当一部分效率是靠底层复用来提升的。如果你一开始就把底层能力打磨好后续叠加新业务场景会非常快。5.3 不要忽视“运行成本”的评估Skills 的调用要消耗不少 token尤其是那些需要多步骤推理或长上下文输入的 Skill。一个完整的走查或抽取流程消耗量可能是普通对话的几倍以上。在效果满足的前提下尽量控制成本。几个我实测有效的技巧减少不必要的长输入、精简输出模板字段、代码型 Skill 用脚本替代模型推理环节、设置触发条件避免在低价值场景里启动重技能。我自己测算过“会议纪要动作提炼器”处理一小时对话约消耗中等规模 token 量相比人工整理一小时会议记录的时间成本仍然是很划算的。但你要真的去算这笔账而不是无脑让所有东西都开 Skills。5.4 测试集是 Skill 的生命线无论你的 Skill 设计看起来多完美没有一套固定的测试集你就不敢更新它。我强烈建议为每一个 Skill 配一个包含十到二十条样本的测试集覆盖正常、模糊、边界、异常四类情况。每次修改后都跑一遍对照输出差异。没有回归测试的 Skill 就像没有安全网的修补迟早出问题。我自己的操作流程是先建基线把当前版本的输出记录下来当我对 Skill 做了改动后重新输出与新基线对比并标注变化点。这套流程让 Skills 的更新有了相对清晰的质量链路。6. 后续还可以这样扩展讲完这五个 Skills 的制作与使用心得剩下一个话题想简单聊一下——如果你愿意继续深挖Skills 这套机制还存在不小的扩展空间。一是“Skill 组合编排”。单个 Skill 解决问题组合之后可以完成更完整的任务链。比如“结构化信息抽取器 代码差异走查员”组合起来可以做一个自动生成变更影响报告的系统效率会非常高。你还可以用一个编排器型 Skill 动态判断什么时候调用哪个子 Skill这种方式非常接近智能体工作流。二是“跨系统复用”。Skill 本质上是轻量级模块理论上只要运行时接口兼容就能迁移到不同智能体平台上。我在某跨平台系统上做过一次试验把一个代码型 Skill 从一个运行时迁移到另一个运行时只要调整配置文件的加载方式核心逻辑代码一行没动就成功跑起来了。这种可移植性很有价值——相当于沉淀下来的能力可以在多处复制利用。三是“反馈数据积累”。如果你把 Skill 的使用日志沉淀下来积累多了之后就能用这些真实行为数据来反向优化触发描述、步骤设计和约束参数让 Skill 的体验越用越顺。这也就是把一个静态技能变成动态演进能力的过程。我个人目前在使用 Skills 时最深的一个体会是它让智能体从一个“只会聊天的模型”慢慢变成了一个“能稳定产出结果的工作具”。对开发者来说这种转变的价值很难用几句话描述完整。上面这些经验和踩坑记录希望对正在折腾智能体的你有实际的参考价值。