1. 为什么Agent项目需要技能而不是提示词1.1 从一次失败的对话说起上个月我负责的一个客服场景Agent项目进入联调阶段需求不复杂用户提问Agent先判断意图再调用对应接口最后生成回复。最初版本里每个意图对应一段精心调过的提示词还专门写了一个prompt路由模块按关键词和语义命中切到不同的处理分支。结果上线第一周就翻车了。业务方提了一个并不刁钻的需求同一个回复逻辑需要在不同渠道展示不同措辞同一个查单接口在售前和售后两个场景下调用参数和话术模板完全不同。我当时的做法是把这些分支全部塞回提示词里用如果你处于xxxx场景请xxxx这类句式不断叠加。提示词膨胀到三千多字后模型的输出风格开始漂移同一个问题有时候话痨有时候惜字如金线上反馈是客服时像人时像机器人。事后复盘问题不在提示词写得多差而在架构缺了一层东西可复用的、边界清晰的技能层。后来我把项目改造成基于agent-skills思路的技能化结构每个意图对应一个独立的技能包一个技能就封装一段完整的能力——触发条件、执行逻辑、输出规范、依赖资源打包在一起互相隔离按需挂载。改造完的效果立竿见影提示词总长度下降了60%风格漂移的问题基本消失新增一个业务场景不再需要动主流程只要加一个技能包再跑一遍回归测试就行。1.2 技能化到底解决了什么问题Agent技能这个概念在圈子里已经火了一阵但很多人把它理解成把提示词写规范一点。我觉得这个理解偏差很大。技能skill和提示词prompt最大的区别在于封装粒度提示词是给模型看的文字是对话时临时加载的上下文技能则是可独立维护、可测试、可版本化的能力单元它既包含模型指令也包含配套的脚本、参数校验、数据处理逻辑和退出条件。打个比方。提示词相当于你告诉实习生遇到这种情况就这么办技能则是你给实习生一套完整的工作手册加工具箱手册告诉他判断标准和步骤工具箱提供他执行时需要的螺丝刀和表格模板。两者都有用但复杂任务光靠口头交代是不够的。对Agent项目来说技能化的直接收益有三条我后面会展开细说这里先列个结论复用同一个技能可以在不同场景、不同Agent之间挂载不需要重复写逻辑隔离技能之间互不干扰一个技能的修改和回滚不会波及其他能力可测试技能有了明确输入输出边界后可以像单测函数一样做回归验证。这些收益对个人开发者做玩具项目可能体现不出来一旦Agent承载真实业务、面对真实用户几乎全是这类问题。这也是我写这篇文章的初衷把我从踩坑到梳理出一套可落地做法的过程记录下来给正在做Agent应用的同行一些参考。2. SKILL.md解剖一个标准技能文件里到底该写什么2.1 元信息与触发逻辑description比instructions更重要目前社区里比较流行的技能定义方式是一个技能对应一个目录目录里放一个SKILL.md说明文件外加可选的其他资源文件。这个格式最初由一些海外Agent项目带动后来国内很多团队也采用了类似约定。我自己实践下来这个约定最大的优点是人机共读——人能看懂结构模型也能解析元信息。一个SKILL.md的核心字段通常包括字段作用我的建议name技能唯一标识短横线命名如meeting-minutesdescription技能能力描述、适用场景、触发条件这是最重要的字段详见下文instructions模型执行该技能的详细步骤和要求写清楚流程、判断标准、输出格式dependencies运行需要的依赖资源脚本、配置文件、数据模板等metadata版本号、作者、更新日期等配合版本管理使用很多人写SKILL.md时把大量精力花在instructions上觉得越详细越好。我的实测结论恰恰相反description字段才是决定技能能否被正确触发的关键。为什么因为当前主流Agent的调用逻辑通常是先理解用户请求再在所有已挂载技能的description里做匹配选出最合适的技能然后把对应的instructions作为指令注入对话上下文。也就是说description是模型的目录索引而instructions是点进来之后看到的正文。如果索引写得含糊正文写得再精彩模型也找不到这个技能。我踩过的典型反面案例给一个代码审查技能写了description为Used for code review and code quality improvement and related tasks。看着没毛病实际运行时用户只是问了一句这段Python代码有什么可以优化的地方模型并没有触发这个技能。后来我把description改成审查代码质量、发现Bug和安全隐患、提出重构建议。当用户要求检查代码、看下这段代码、做code review时使用。不适用于单纯解释代码功能的请求。触发率立刻从40%左右提升到90%以上。description的写法我有一个基本模板先一句话说明技能能力再用列举最典型的触发场景最后用Do not use for...句式划定边界明确告诉模型什么时候不要用。边界约束看着多余实际能大幅减少误触发。2.2 指令正文的撰写原则给模型一套可执行的SOPinstructions是模型拿到这个技能后的操作指引写法上建议遵循几个原则。第一用步骤化描述代替散文式描述。模型对先做A再做B最后做C这种清晰流程的执行稳定性远高于对请妥善处理相关事宜这类模糊要求的执行稳定性。每一个步骤都要给出判断标准和产出物比如第1步阅读输入标记所有待处理的条目第2步对每个条目执行xx校验校验规则见下方校验规则小节第3步汇总校验结果按预设模板输出报告。第二必须给出输出格式的约束。我见过太多技能失败案例问题都是输出格式不稳定。在instructions里直接给出输出模板甚至给出一个填充示例模型照做的概率会高很多。如果你要求输出JSON那就在instructions里把字段名、字段类型、嵌套结构全部写死不要留任何让模型自由发挥的空间。第三写清楚异常处理路径。真实输入永远不会按你设想的剧本来。遇到异常情况怎么办是抛出错误、返回固定提示还是降级处理这个必须在instructions里明确。我的习惯是加一节错误处理逐条列出常见异常及对应行为。别小看这一节它能让技能从看起来能用变成真的扛得住线上。2.3 依赖与脚本技能不只是一堆文字纯粹的文本型技能比如改写润色摘要提取只需要SKILL.md就够了但很多真实业务技能需要配套脚本和资源。比如会议纪要技能可能需要一个语音转文字脚本报表生成技能可能需要一个图表渲染脚本客户分群技能可能依赖一个分类模型文件。这些依赖资源放在技能目录下的子文件夹里统一管理。我在实践中形成了这样的目录组织方式skills/ meeting-minutes/ SKILL.md scripts/ transcript_clean.py templates/ summary_template.md assets/ speaker_mapping.json脚本设计有两个原则。一是小而专每个脚本只做一件事输入输出边界清晰方便模型理解和调用。二是健壮性优先脚本要能容忍异常输入做好参数校验和默认值因为模型生成的调用参数经常不按常理出牌比如缺字段、类型错误、传了超长字符串。这里多说一句脚本的权限边界一定要收敛。技能脚本跑在Agent的执行环境里如果权限过大一旦指令被恶意注入代价会很高。我做技能时有个铁律脚本只允许处理传入的数据和指定目录内的资源不允许访问网络、不允许读写技能目录之外的文件、不允许执行非白名单命令。这个约束看起来保守但在真实环境中能帮你挡掉很多安全隐患。3. 从零手写一个会议纪要技能完整实操3.1 需求拆解与边界划定理论讲多了容易飘我用一个具体的例子把全过程走一遍。假设我们要做一个会议纪要技能输入是会议录音的转写文本输出是一份结构化的会议纪要。听起来很常见对吧但如果你直接开写SKILL.md很快就会发现一堆问题输入文本可能包含多人对话无法直接分辨谁说了什么有些内容属于闲聊不该进纪要决定事项和待办事项经常混在一起需要从陈述句里识别责任人和截止时间输出到底用中文还是英文、要不要Markdown格式、是否包含风险预警。我的做法是先做需求拆解把生成会议纪要这个大任务拆成四个子任务文本清洗、信息抽取、决策识别、格式渲染。每个子任务对应instructions里的一到两个步骤。这样既方便写提示词也方便后续测试定位问题——哪个环节输出不对直接对着改就行。同时要划定技能的边界。会议纪要技能只负责把转写文本整理成纪要不负责根据纪要生成周报后者是另一个技能的事。别试图做一个万能技能技能边界越清晰越容易被正确触发也越容易保证输出质量。边界划定我有几个自我拷问的问题这个技能的输入是什么输出是什么不属于这个技能处理的输入应该明确拒绝还是转交其他技能这三个问题想清楚技能设计就完成了一半。3.2 技能文件的最终形态按照上面的拆解我给出一个可参考的SKILL.md精简版本。需要说明的是真实项目的文件会比这长得多这里保留核心骨架。--- name: meeting-minutes description: 将会议录音转写文本整理为结构化会议纪要。当用户提供会议转写文本或语音转文字结果并要求生成纪要、总结会议、提炼待办时使用。不适用于普通文档总结。 version: 1.2.0 --- # Meeting Minutes Skill 将输入的会议转写文本转换为结构化会议纪要。遵循以下步骤 ## 步骤 1: 文本清洗 - 删除转写中的语气词、重复表达和无意义填充词如嗯那个。 - 对多说话人文本保留说话人标识无标识时按段落切分并编号说话人1、说话人2。 ## 步骤 2: 信息抽取 - 从清洗后的文本中抽取以下五类信息 1. 会议主题与背景 2. 关键讨论点每条不超过50字 3. 明确做出的决定 4. 待办事项责任人 内容 截止时间如缺失则标注待确认 5. 遗留问题 - 只抽取有明确依据的信息禁止臆测和补全。 ## 步骤 3: 输出格式 严格按照以下Markdown模板输出不要添加额外章节 # 会议纪要[主题] ## 基本信息 - 时间[若文本中有则填写否则写未记录] - 参会人[说话人列表] ## 讨论要点 - [每条一句话] ## 决定事项 - [每条一句话] ## 待办事项 | 责任人 | 内容 | 截止时间 | |--------|------|----------| | [姓名] | [事项] | [日期或待确认] | ## 遗留问题 - [问题列表] ## 错误处理 - 输入文本为空或过短少于50字输出转写文本过短无法生成有效纪要并停止。 - 文本语言为英文输出语言切换为英文模板结构不变。 - 识别不到明确决定或待办对应小节输出无不要强行编造。这个文件有几点值得注意。第一description里明确写了不适用于普通文档总结这是为了减少误触发。第二步骤和输出模板之间的对应关系是严格一致的模型只需要把抽取结果填进模板不需要自己发挥格式。第三错误处理只列了三条最常见的异常够用就好不要试图穷举所有异常——列太多反而会让模型混乱。3.3 验证与迭代怎么判断一个技能真的能用技能写完只是第一步关键是怎么验证。我的经验是分三级做测试。第一级是样例测试。准备3到5个典型的输入样例覆盖正常情况、边界情况和异常情况逐个运行技能查看输出。正常样例检验主流程边界样例检验模板健壮性异常样例检验错误处理逻辑。最初的几个测试样例可以自己造但一定要有一个是真实数据否则容易测试全过、上线即挂。第二级是回归测试。技能迭代过程中改一处逻辑很可能会影响其他流程所以我把所有历史测试样例保存下来每次修改后全部重跑一遍。这本质上就是传统软件工程里的回归测试思路。别嫌麻烦Agent项目的最大特点就是改起来容易、稳起来难没有回归测试技能很容易在几次迭代之后悄悄退化。第三级是线上评测。把技能挂到真实的Agent环境中让它在真实对话里被触发观察实际调用频率、任务完成率和用户反馈。这里有一个容易被忽略的指标技能的误触发率。如果技能频繁在不符合条件的情况下被调用说明description里的触发条件写得还不够精确需要回头去调description而不是改instructions。迭代时有一个心态要调整不要指望一次写对。我现在的习惯是第一版尽量简单只覆盖核心场景跑通之后再逐步加边界处理和复杂逻辑。第一版就追求完美往往会把技能写得又长又乱反而更难调试。4. 技能调试中的坑我踩过的失败模式与排查路径4.1 触发误判技能为什么该出手时不出手技能化改造落地之后我遇到的第一个高频问题是触发误差。技能明明存在description也写了但模型就是不调用它或者在不该调用的时候乱调用。这类问题排查起来很费时间因为模型内部匹配逻辑是不透明的你只能从description的反面去推测它为什么不匹配。我的排查路径一般是这样先看是不是描述语言和用户表达差异太大。比如技能description用词很技术化调用工单查询接口而用户根本不会这么说用户只会问我的快递到哪了。这时候需要在description里加入大量用户可能使用的口语化表达作为触发范例。再看是不是挂载了太多技能导致选择困难。Agent每次请求都要在所有已挂载技能的description里做匹配技能数量多了匹配精度必然下降。我实测过超过15个技能之后误触发率会明显上升。解决办法是把技能分组、分层或者让上层的路由技能先把请求分到子域再由子域内的技能做细粒度匹配。最后检查是不是技能描述之间有语义重叠。两个技能如果能力相近模型选谁全凭运气。比如订单查询和物流查询在很多场景下是重叠的要么合并要么在description里明确区分物流查询仅用于查询运输状态订单查询用于查商品、价格、支付信息。排查触发问题一定要改一句测一次不要一次改一大段。因为description的措辞变化对触发率的影响是非线性的可能多了一句范例触发率就上去了也可能少了一个限定词触发率就崩了。4.2 上下文污染技能和主对话的边界问题第二个让我头疼的问题是上下文污染。技能执行过程中会产生大量中间数据——抽取结果、临时变量、调试信息——这些数据如果不做处理就直接留在上下文里会让对话变得臃肿甚至干扰模型后续的判断。最典型的场景是Agent调用报表生成技能时在上下文中生成了大段中间计算结果技能执行完后这些内容还残留在对话里下一次用户提问时模型看到这些残留内容可能误以为它们是新的用户请求从而导致回答错乱。解决上下文污染有几个手段按优先级排序技能设计时就约束中间数据的生命周期所有中间计算结果只在技能内部使用最终输出必须是精简后的结构化结果不让中间数据流入主对话。在instructions里明确重要你只向用户输出最终纪要不要展示内部推理过程。这种显式约束对当前主流模型都有明显效果。在工程层面做上下文清理如果Agent框架支持上下文管理可以在技能执行结束后把指定范围内的消息标记为已处理或从上下文摘要中剔除。这里有一个需要权衡的地方上下文清理做得太狠会丢失必要的信息影响连贯性做得不够又会出现污染。我的实践标准是——主对话中只保留用户可见的最终结果和对后续对话有语义价值的信息其余一律不保留。这条标准看起来简单但落实下来能让Agent的长对话稳定性明显提升。4.3 脚本执行失败解析与降级技能如果带脚本脚本执行失败是绕不开的坑。模型在生成调用脚本的参数时经常出格我见过不少离奇场景字符串参数没加引号导致解析失败、参数类型传错、脚本收到空数组、文件路径里有空格导致找不到文件……这些问题在传统软件开发里早被编译器挡掉了但模型生成的调用没有编译器。应对思路有两个层面。一个是在脚本侧做入参兜底每个脚本开头都做严格的参数解析和类型校验不合法就返回统一的错误码和原因说明而不是直接抛异常终止。模型看到错误码后至少能据此调整参数重试。另一个层面是给技能设计降级路径。脚本执行失败不等于整个技能必须失败。比如会议纪要技能的文本清洗脚本挂了可以让技能退回纯模型处理模式依然能生成纪要只是质量略低。我在技能里通常写一条指令脚本执行失败时忽略脚本结果直接基于原始文本完成后续步骤。这条降级路径在实测中很有价值它把单点故障变成了可恢复的软错误。还有一个小提示脚本的输出要尽量干净。有些脚本会在处理过程中print一些调试日志如果这些日志被模型当作输出内容就会污染后续处理。脚本的最终输出应该是纯数据比如JSON调试日志写到stderr或者日志文件不要混进stdout。5. 个人技能库的组织与版本管理落地实践5.1 目录结构、命名规范与标签体系技能数量少的时候怎么放都无所谓一旦超过十个组织方式就变得重要了。我现在维护的个人技能库遵循一套简单的约定分享出来供参考。首先是目录结构。技能统一放在一个根目录下按领域分子目录子目录内每个技能一个独立目录。这样既支持按领域浏览也方便按目录做权限控制和打包分发。skills/ customer-service/ order-query/ after-sale-handler/ refund-calculator/ productivity/ meeting-minutes/ email-draft/ weekly-report/ >