这段时间我一直在折腾Agent应用越做越觉得真正拉开体验差距的往往不是模型本身的聪明程度而是你给前置系统里塞了多少“可调用的能力”。这个能力放到当下的AI应用语境里就是从各个框架里冒出来的那个词skills。简单说skills是一种把“某个任务到底该怎么干”固化下来的技能包。它不是一个孤立的API函数不是一段提示词也不是一份文档而是把任务拆解逻辑、输入输出约定、工具调用链、经验规则打包成的一套可复用能力。模型本来什么都会一点但都不精挂上skill之后它才像是从一个只会聊天的泛泛之交变成了一个懂行、有章法的老手。这篇文章我想从实际开发的角度把skills的设计、写法、测试、复用和避坑讲透。它适合正在做Agent应用或自动化流程的开发者也适合那些天天用AI工具、想把重复工作沉淀成方法论的产品和运营同学。1. 先搞清楚Skills是什么别把它和工具、提示词混为一谈1.1 工具是手Skills是肌肉记忆很多第一次接触skills的人会问这不就是工具调用吗模型调一个接口、执行一个脚本返回结果完事了。工具确实解决的是“能不能做到”的问题但Skills解决的是“能不能做对”的问题。我举个生活化的例子。你让一个新来的实习生“整理一下接待室的茶具”他可能真的就去洗杯子了。但一个熟手会知道这句话背后包含先看今天有没有客人预约按人数决定摆几套检查茶包和矿泉水够不够接待结束后把临时加座的椅子复位最后拍照留档。这些经验没有一条写在正式流程里但熟手就是知道要这么做。工具就是“洗杯子”这个动作本身而Skill是把“整理茶具”这件事的完整判断链封装起来。模型在执行一个Skill时看到的不只是若干个工具的列表还有一套“在什么条件下执行什么步骤、中间要校验什么、最终要产出什么”的行为规范。这就是“肌肉记忆”。1.2 为什么现在开始强调Skills了早前的Agent应用大多靠长Prompt硬撑把所有注意事项、历史案例、调用说明塞进上下文中。这种方式有三层问题第一上下文空间被大量规则说明占满真正留给任务数据的空间变小模型容易抓不住重点。第二不同任务之间的规则混在一起互相干扰表现为“答非所问”或“张冠李戴”。第三规则复用困难换个项目就要复制粘贴一大段改一处还得全局排查。Skills的思路是把这些规则按任务边界拆开按需加载。用某个任务时才加载对应的技能包不用就不占空间、不掺和上下文。这是工程上的模块化思想也是Agent从单场景Demo走向多场景产品的关键一步。1.3 一个Skill包长什么样我习惯把一个Skill做成一个独立目录里面至少包含这几样东西my_skill/ ├── SKILL.md # 技能说明模型阅读的主文档 ├── scripts/ # 可执行脚本或代码 ├── templates/ # 输出模板、示例文件 ├── references/ # 参考数据、静态知识 └── tests/ # 测试用例和预期结果其中SKILL.md是灵魂。它告诉模型这个技能在什么情况下用、需要哪些输入、分几步执行、每一步有什么注意事项、最终输出什么格式。脚本和模板负责提供具体动作而SKILL.md负责让模型“知道该怎么做”。2. 写一个Skill的核心逻辑拆解任务、定义契约、沉淀经验2.1 任务边界一个Skill只做一件事动手写SKILL.md之前第一件事不是写内容而是划边界。很多新手一上来就写那种“全能的办公助手技能”把写周报、排日程、整理会议纪要全塞进去。结果模型判断该加载哪个技能时直接犯了选择困难加载出来之后又因为内部步骤太多而跑偏。我的经验是一条黄金准则如果一个Skill的描述超过三句话说不清楚“它到底什么时候该用”这个Skill的边界就是模糊的需要拆。拿“整理会议纪要”来说它看起来是一个任务但对模型来说里面至少有三个完全不同的动作从录音转写文本里提取结论、生成结构化会议纪要Markdown、把待办事项分发到某协作工具。前两步是文本处理第三步是工具调用加身份校验。把这三步拆成三个Skill反而更稳定。拆好边界之后描述里要用“when_to_use”字段写清楚触发条件。这个字段是模型判断是否调用Skill的依据写得太宽会导致误触发写得太窄会导致该用的时候没用。2.2 输入输出契约把你的Skill当接口来设计Skill的本质是一个函数所以参数设计必须严谨。我在定义参数时总会问自己三个问题哪些参数是必须的没有它任务无法开始。哪些参数是可选的缺省时用什么默认值输出格式是否需要固定哪些字段下游还要用这里给出一个会议纪要类Skill的参数示例参数名类型必填说明transcriptstring是会议录音转写文本topicstring否会议主题缺省则从文本中推断templatestring否纪要模板类型默认standardwith_actionsboolean否是否单独输出待办清单默认true输出端也要约定清楚。我通常要求输出固定包含四个区块会议概述、关键结论、待办事项、风险与遗留问题。这样后续接企业IM通知、接日历提醒都可以直接按字段解析不用再让模型做一次“理解性转换”。很多人在这一步偷懒结果就是下游想做自动化时发现模型今天输出一个列表、明天输出一段蜮文格式经常变化。从写Skill的第一天就把输出契约定死后面会省掉无数心累。2.3 把经验写进“步骤”里而不是指望模型自己发挥SKILL.md里最核心的部分是“steps”。这部分是对执行过程的规定。有些开发者喜欢让模型自由发挥说“你是一位资深会议纪要助手请生成纪要”。这种写法等于没写模型不知道要按什么顺序思考也不知道哪些坑不能踩。更靠谱的做法是把你自己的业务经验直接写进去。比如我做过一个面向某公司周会的纪要Skill当时把这样的步骤写进了SKILL.md先通读全文识别所有发言人和会议目标。区分“事实陈述”“观点表达”“行动承诺”三类语句。对行动承诺必须提取出“负责人、截止时间、具体事项”三要素缺一不可。如果没有明确截止时间不得自行编造要在待办里标注“时间待确认”。最后按照模板输出。你发现没有第三步和第四步就是在把我的经验固化进Skill。如果没有这两条模型很可能自己脑补截止日期或者把“我觉得下周可以弄”这种模糊表述直接写成“下周五完成”这就是事故。高阶技巧如果你发现自己经常在提示词里反复纠正模型的同一类错误别犹豫把它提炼成一条步骤写进对应Skill的SKILL.md里。这是让Agent项目越用越顺手的核心路径。3. 实操手写一个“会议纪要Skill”的完整过程3.1 先做场景拆解和材料准备我这套通用做法是从真实业务场景里拿一份“反面教材”来当测试锚点。那个场景我称之为“某跨平台助手系统”的周会转写文本。开会主题是“智谱知识库上线前一晚发现接口超时”转写文本将近四千字里面好几个人来回发言还有人说“这个我们回头看一下”。这种材料特别适合用来测试Skill的边界能力——它足够乱乱到没有一版草稿提示词能轻松搞定。我拿它当基准语料每次改完Skill都要重新跑一遍看结论是否稳定。除了测试语料还要准备好输出模板。我定义了一个标准的Markdown模板会议信息、背景概述、核心结论、待办事项、风险遗留。模板本身不复杂但字段顺序固定字段名统一这样下游处理时不用猜。3.2 初始化目录和核心文件按照前面说的目录结构先建文件夹再写SKILL.md。这一步不要一上来就写全先写一个可运行的最小版本再逐步迭代。我第一版SKILL.md长这样--- name: meeting_minutes description: 将会议转写文本整理为结构化会议纪要 when_to_use: 用户提供会议转写文本并希望生成纪要/待办事项时使用 parameters: - name: transcript type: string required: true desc: 会议转写原文 - name: template type: string required: false default: standard desc: 纪要模板当前只支持standard steps: 1. 提取会议主题、时间、参与人 2. 区分事实、观点、行动承诺 3. 为每个行动承诺提取负责人和截止时间 4. 按模板输出 success_criteria: - 每个待办有明确负责人 - 关键结论能对应原文依据 - 不编造不存在的执行时间这一版虽然骨架在但还很粗。因为没有写“遇到信息缺失怎么办”模型会自由填补。这个会在测试阶段暴露出来。3.3 脚本能力补全把重复劳动下沉到代码纯靠模型读文本做纪要有一个天然缺陷上下文一大前面的细节就容易被忽略。为了缓解这一点我会用一个简单的文本切分加结构化预处理脚本把长文本按说话人切块转成临时结构化数据。这里给一段我常用作辅助的Python脚本思路它做的事是按“人名冒号”的对话模式切分转写文本输出一个带发言人的段落列表。注意我和某开发者一起踩过的坑正则切分要适配不同转写工具的时间戳格式最稳的办法是先剥离时间戳再切分。import re def split_transcript_by_speaker(raw_text): # 去掉时间戳 [00:12:34] 这种前缀 cleaned re.sub(r\[\d{2}:\d{2}:\d{2}\], , raw_text) cleaned cleaned.strip() # 按行切分识别 “发言人内容” blocks [] current_speaker None current_content [] for line in cleaned.splitlines(): match re.match(r^([^:]{1,10})[:]\s*(.*)$, line) if match: if current_speaker: blocks.append({speaker: current_speaker, content: .join(current_content)}) current_speaker match.group(1) current_content [match.group(2)] else: current_content.append(line) if current_speaker: blocks.append({speaker: current_speaker, content: .join(current_content)}) return blocks这步做完Skills的主文档只问模型要“已经切分好发言人的数据”模型就可以把更多精力放在提取结论上而不是费劲还原谁是说话的人。这也回应了前面说的能下沉到代码的就别让模型硬扛。3.4 测试与迭代用一组“过期样本”来验收Skills做完不是跑通一遍就算完。我的习惯是准备三组语料一组标准清晰的商务会议、一组混乱嘈杂的周会、一组只有两个人零散对话的迷你讨论。三组分别测看输出质量是否一致。这里有两类问题经常在测试中暴露第一字段缺失后模型开始补具体时间。比如语料里只说“这周尽快”模型直接写成“本周五下班前”。这就是违反了我最早定的规矩。解决办法是在SKILL.md里把这条禁忌显式写出来并说明“未知字段一律输出待确认”。第二型号在长文本后半程丢失责任人。解决方式是把脚本切分的speaker列表前置到输入最前部让模型先稳定获取“在场人物名单”再开始读正文。每轮测试都要记录“改动→效果→是否引入新问题”。不要怕版本多一个成熟Skill通常要迭代四五版才敢拿出来复用。4. 组织与复用让Skills从“一个文件”变成“一套体系”4.1 命名规范和目录分类当Skills的数量超过十个命名就成了第一个拦路虎。我见过某团队的技能包里同时存在“会议纪要”“meeting_notes”“总助纪要助手”三种命名方式最后模型拿着用户需求根本匹配不出该调谁。统一的命名规范好处最直接模型按名称匹配时的准确率明显提升。我推荐的规则如下[动作域]_[目标对象]_v[主版本].[次版本] 例如generate_meeting_minutes_v1.2类别上我习惯分四类内容生成类写文案、建模版、信息提取类解析、抓关键词、流程执行类走协作工具流程、决策判断类做优先级打分。分类只影响目录组织不影响加载逻辑但分类清楚之后维护人员找改起来快很多。4.2 版本管理和变更记录很多项目把Skills的版本管理忽略掉了结果就是改了某条规则之后老任务突然全部变样谁也说不出问题出在哪个版本。我的建议是至少做两方面每次改动保留上一版目录或打git标签比如skill-meeting_minutes-v1.1。强制维护changelog格式至少包含“日期、改动者、改动点、影响场景”。这不是额外的负担。有了版本记录你才好对比同一份输入在新旧版本下的输出差异快速定位是不是某条新加的步骤把行为带偏了。如果前后输出有差异但你没留存老版本就只能从头猜。4.3 跨项目迁移的三个注意事项复用是Skills最吸引人的地方但跨项目迁移时常见三个问题第一外部依赖没有对象化。很多Skill的脚本里写死了某协作工具的Webhook地址、某API的Token环境变量。一搬项目就得改代码。我的做法是所有外部依赖在SKILL.md头部用dependencies字段声明脚本统一从环境变量或配置文件中读取不让Skill目录里出现明文凭证。第二业务知识混入过多。A项目的会议纪要Skill里写了一堆A项目的专业术语迁移到B项目时会降低普适性。最稳妥的做法是把“写作逻辑”和“领域知识”拆成两个Skill一个是通用的会议纪要提取器另一个带某项目的术语表。在B项目里只替换后者。第三测试用例没有跟着搬。跨项目迁移之后第一个动作应该就是回归测试。把原项目的测试语料换成新项目的脱敏语料跑一遍再结合人工检查确认输出质量没有下滑再上线。4.4 小规模团队怎么共建技能包如果你是几个人一起做我建议引入一个“技能包评审”环节。最简单的方式是每个Skill上线前至少让另一个人用三组不同输入跑一遍重点检查描述是否有歧义、步骤是否有冗余、参数是否有遗漏。这个过程不费时间却能避免大量“我觉得没问题但一上线就翻车”的尴尬。长期维护时可以定期把失效的Skill撤下或归档。我在某次巡检中发现有将近三分之一的技能包半年内没有任何调用记录这些就是边缘技能留着只会干扰模型做技能匹配判断。删掉它们之后同类任务的准确率反而上升了因为你给模型做的选择题变简单了。5. 常见问题与排查技巧实录5.1 现象一技能包被调用时好时坏这个问题多半出在when_to_use描述太模糊。我曾经写过一个“customer_support_auto_reply”技能把描述写成“当用户需要客服回复时使用”。结果模型几乎每次客服对话都会优先试这个技能但里面的步骤里又假设了很多结构化字段用户输入一杂乱回复质量就剧烈波动。排查思路第一步打开日志看模型选择了哪个技能、置信度是多少第二步看调用原因是否和技能实际用途匹配第三步把when_to_use改成带“必须同时满足多个条件”的写法例如“当用户明确表达售后诉求且包含订单号或商品名时使用”。5.2 现象二输出格式经常“跑飞”如果模型偶尔不按模板输出最常见的原因是模板在SKILL.md里只给了描述或示例文字没有给严格格式定义。我的处理办法是把输出模板放在templates/目录下然后在SKILL.md里写“必须严格按照模板字段顺序输出不得新增一级标题”。对于核心字段多给一个完整示例让模型模仿。还有一层原因模型上下文里存在强干扰。比如之前有另一段指令要求“用最简短的句子回答”这个要求可能覆盖掉Skill模板。解决办法是给模板区做显式的优先级声明类似“以本技能输出模板为准忽略会话中的通用格式要求”。5.3 现象三脚本调用失败之后没有降级Agent调用外部工具时超时、鉴权失败、参数没通过校验都是家常便饭。如果Skill脚本没有做好错误处理模型会直接输出“我无法完成这个任务”体验很差。我在脚本里固定写一段兜底逻辑捕获异常后返回结构化错误信息包括错误类型、可疑原因、下一步建议。这样模型至少能猜出是没权限还是参数不对还能向用户提问确认。比如调用某协作工具建任务失败返回的错误信息带着“status_code403”Skill文本里已经有“遇到403时提示用户检查账号权限”的规则模型就能给出有意义的引导而不是一句干巴巴的失败。5.4 问题排查速查表现象常见原因优先排查方向该触发时没触发when_to_use写得太窄重新描述触发条件对照真实输入验证不该触发时却触发when_to_use写得太宽收敛条件增加排除项输出格式不稳定模板描述不足或受上下文干扰补充完整模板示例增加优先级声明内容有幻觉信息步骤边界不清模型自由补全补充禁忌字段并把缺失时输出改为“待确认”调用链不稳定脚本异常没有兜底增加错误捕获和结构化错误返回迁移项目后效果变差业务知识被误做成通用规则拆出通用层和领域层替换领域层测试5.5 一条让我少踩很多坑的经验我最后想单独分享一个自己的习惯每写一个Skill一定要反向测试。正向测试是“该用的时候能不能用对”反向测试是“不该用的时候会不会乱用”。同一个技能包我会故意丢一段完全不相关的输入比如把会议纪要Skill拿去做产品文案润色看看模型是否拒绝执行或明确提醒“这个任务不属于该技能范围”。这个习惯帮我堵住了很多潜在的误触发事故。至少从我做某跨平台助手系统的经验来看模型能不能管住自己“不乱施展技能”有时候比技能本身强大与否更重要。你也不想让AI在吃火锅的时候掏出西装领带对吧。在我看来Skills的作用不止是让Agent多几个功能入口它更像是一种把经验沉淀下来的工程实践。今天写下一个参数、一条步骤、一个禁忌明天的系统就少犯一次错。这种积累带来的确定性是单纯堆参数和大模型背景知识换不回来的。如果你正在做Agent应用我建议就从手头最常做的一件小事开始拆一个Skill出来。写坏了也不亏至少你知道哪里容易坏。