1. 从“臃肿”到“精悍”一次Skill瘦身的完整复盘先说说我为什么要折腾这件事。手头维护着一套自用的Agent工作流里面挂载了十几个Skill从代码生成、文档解析到空间分析、视频提示词模板几乎覆盖了我日常所有高频场景。刚开始用着挺爽每个Skill各司其职调用起来也顺手。但大概两个月前我开始明显感觉到不对劲——Agent的响应速度肉眼可见地变慢有时候一个简单的任务它要在好几个Skill之间来回跳转token消耗量比预期高出三四倍偶尔还会出现“抢活干”的情况两个Skill同时响应同一个请求输出结果互相打架。最让我头疼的是“鹈鹕骑自行车”那个测试用例。这是我用来做端到端验证的一个经典提示词原本期望Agent能直接调用图像生成Skill输出结果结果它先触发了文本理解Skill又绕到提示词优化Skill最后才慢吞吞地走到图像生成中间还夹带了一堆无关的中间产物。整个过程像是一个原本只需要拧一颗螺丝的活儿来了五个工人每个人都先检查一遍工具箱。这就是典型的Skill臃肿症。每个Skill单独看都没问题但放在一起就变成了“三个和尚没水喝”。我翻了一圈社区里的讨论发现这不是我一个人的困扰。很多人都在聊Agent架构优化、提示词工程、Skill插件管理但真正系统性地讲“怎么给Skill做减法”的内容并不多。大部分教程都在教你怎么加功能、怎么扩能力很少有人告诉你——加是本能减才是本事。这篇文章就是把我自己给Skill瘦身的完整过程拆开来讲。从怎么判断一个Skill该不该留到怎么合并同类项再到瘦身之后怎么验证效果每一步我都会把背后的逻辑和踩过的坑说清楚。如果你也在维护自己的Agent工作流或者正在设计一套Skill体系这篇内容应该能帮你少走不少弯路。不管你是刚接触Agent开发的新手还是已经有一堆Skill在跑的老手下面的内容都能直接拿去用。2. 瘦身之前先搞清楚Skill为什么会“胖”2.1 Skill臃肿的三种典型症状在动手之前我先花了两天时间做诊断。不是凭感觉说“好像变慢了”而是把每个Skill的调用日志拉出来统计触发频率、平均执行时长、token消耗量、以及和其他Skill的重叠度。数据一摆出来问题就很清楚了。第一种症状是功能重叠。我发现自己有三个Skill都在做文本摘要相关的事一个叫“文档精读”一个叫“内容提炼”还有一个叫“要点提取”。名字不一样但实际干的事有八成重合。每次遇到摘要任务Agent要在三个里面选一个选择本身就要消耗推理资源选错了还得重来。第二种症状是职责边界模糊。有个Skill叫“智能助手”当初设计的时候想让它当万能兜底什么都能接一点。结果它变成了一个“什么都会一点什么都不精”的角色。用户问代码问题它也能答但不如专门的代码Skill用户问数据分析它也能接但不如专门的分析Skill。这种模糊地带最消耗资源因为Agent不确定该不该调用它。第三种症状是触发条件过宽。有个提示词优化Skill我当初设置的触发条件是“当用户输入包含优化、改进、提升等关键词时激活”。听起来没问题但实际上“提升”这个词在技术讨论里太常见了导致这个Skill被频繁误触发。每次误触发都是一次无效计算。我把这三种症状对应的数据整理成了一张表方便对照排查症状类型具体表现资源消耗特征排查方法功能重叠多个Skill处理同类任务选择成本高token浪费在决策上统计任务类型分布看是否有多个Skill覆盖同一类边界模糊兜底Skill什么都接执行质量不稳定返工率高检查兜底Skill的调用记录看有多少本应走专用Skill触发过宽关键词匹配太泛无效调用多响应链路变长分析触发日志统计误触发比例提示诊断阶段不要急着改代码先把数据跑出来。凭感觉优化往往会把有用的Skill也砍掉数据驱动才能精准定位问题。2.2 一个Skill该不该留三个判断标准数据出来之后我开始逐个评估每个Skill的去留。这里我总结了三个判断标准按优先级排序第一这个Skill是否有不可替代的独特价值比如我的“GIS空间分析”Skill它封装了一套坐标转换和空间插值的逻辑别的Skill做不了这个事。这种就是核心资产必须保留。但如果一个Skill的功能可以被其他Skill组合实现那它就有被合并的空间。第二这个Skill的触发频率是否足够高我统计了过去30天的调用数据发现有些Skill一个月只被触发了两次。这种低频Skill要么是设计有问题要么是场景太窄。对于低频但必要的Skill我会把它降级为“按需加载”不放在主流程里。第三这个Skill的维护成本是否可控有些Skill依赖外部接口或者特定版本的模型每次底层更新都要跟着改。如果一个Skill的维护成本已经超过了它带来的价值那就该考虑砍掉或者重构。这三个标准帮我快速筛出了一批“该动刀”的Skill。接下来就是具体的瘦身操作。3. 瘦身实操从十几个Skill精简到六个3.1 合并同类项把三个摘要Skill合成一个第一个动刀的就是那三个摘要Skill。我把它们的提示词全部拉出来对比发现核心逻辑其实是一样的输入一段文本输出关键信息。区别只在于输出的格式和详细程度。我的做法是保留一个主Skill把另外两个的能力作为参数合并进去。具体来说新的摘要Skill接受一个mode参数有三个可选值brief对应原来的“要点提取”standard对应“内容提炼”detailed对应“文档精读”。Agent在调用时只需要传一个参数不需要在三个Skill之间做选择。合并之后的提示词结构大概是这样# 摘要Skill ## 角色 你是一个文本摘要专家根据指定的详细程度输出摘要。 ## 参数 - mode: brief | standard | detailed - brief: 输出3-5个关键点每个不超过20字 - standard: 输出一段200字以内的摘要 - detailed: 输出分段落的详细摘要保留关键数据和逻辑关系 ## 执行规则 1. 先判断输入文本的类型技术文档、新闻、对话记录等 2. 根据mode参数调整输出粒度和格式 3. 如果输入文本超过模型上下文限制先分段处理再合并这个改动带来的效果很直接Agent的决策链路缩短了不再需要在三个Skill之间做选择。token消耗量下降了大约40%因为省掉了选择过程中的推理开销。3.2 收窄触发条件让Skill只在该出现的时候出现那个提示词优化Skill的误触发问题我用了两个手段来解决。第一个手段是提高关键词的匹配精度。原来用的是“包含优化、改进、提升”这种宽泛匹配改成了“当用户明确要求对提示词进行优化且输入内容包含提示词结构或模板特征时激活”。具体来说我加了一个前置判断先检查输入是否包含类似“角色”“指令”“输出格式”这样的提示词结构关键词如果有才进入优化流程。第二个手段是引入置信度阈值。我让Skill在触发前先做一个快速判断输出一个0到1之间的置信度分数只有分数超过0.7才真正执行。这个判断本身消耗的token很少但能过滤掉大量误触发。# 触发判断的伪代码逻辑 def should_activate_optimizer(user_input): # 检查是否包含提示词结构特征 structure_keywords [角色, 指令, 输出格式, 约束条件, 示例] structure_score sum(1 for kw in structure_keywords if kw in user_input) / len(structure_keywords) # 检查是否包含明确的优化意图 intent_keywords [优化提示词, 改进提示词, 提示词调整] intent_score 1.0 if any(kw in user_input for kw in intent_keywords) else 0.3 # 综合置信度 confidence structure_score * 0.6 intent_score * 0.4 return confidence 0.7改完之后这个Skill的误触发率从原来的六成降到了不到一成。省下来的token和时间直接体现在了整体响应速度上。3.3 降级低频Skill按需加载而不是常驻有几个Skill的使用频率很低比如“视频提示词模板”和“打斗动作提示词生成”一个月可能就用两三次。这些Skill如果常驻在主流程里每次Agent做决策时都要考虑它们白白消耗推理资源。我的处理方式是把它们从主Skill列表中移除改成“按需加载”。具体实现是维护一个Skill注册表主流程只加载高频Skill低频Skill放在一个单独的目录里。当Agent判断当前任务需要某个低频Skill时再动态加载进来。{ core_skills: [ code_generation, document_analysis, spatial_analysis, prompt_optimizer, summarizer, task_router ], on_demand_skills: [ video_prompt_template, action_prompt_generator, gis_advanced_tools ] }这个改动让主流程的Skill数量从十几个降到了六个Agent的决策空间大幅缩小响应速度提升非常明显。4. 瘦身之后效果验证与关键指标对比4.1 响应速度与token消耗的实测数据瘦身完成后我用同一批测试用例跑了对比。测试集包含20个任务覆盖代码生成、文档摘要、空间分析、提示词优化等场景。每个任务跑三遍取平均值结果如下指标瘦身前瘦身后变化幅度平均响应时间8.3秒3.7秒下降55%平均token消耗42001800下降57%任务一次通过率72%91%提升19个百分点Skill误触发次数14次/20任务3次/20任务下降79%响应时间的下降主要来自决策链路的缩短。原来Agent要在十几个Skill里做选择现在只需要在六个里选推理步骤少了自然就快了。token消耗的下降更明显因为省掉了大量用于“选择”和“犹豫”的中间推理。一次通过率的提升是我没想到的。后来分析发现Skill少了之后Agent的决策更果断不容易在多个相似Skill之间反复横跳。以前经常出现的情况是Agent先调了A Skill觉得不对又调B Skill最后发现还是A Skill的结果更合适但已经浪费了两轮计算。现在这种情况基本消失了。4.2 “鹈鹕骑自行车”测试用例的完整链路对比回到开头提到的那个经典测试用例。瘦身前后Agent处理“鹈鹕骑自行车”这个提示词的链路完全不同。瘦身前的链路是这样的用户输入“鹈鹕骑自行车”→触发文本理解Skill→触发提示词优化Skill→触发图像生成Skill→触发结果校验Skill→输出。中间还夹着一次误触发因为“自行车”这个词触发了某个运动相关的Skill。整个链路走了五步耗时约12秒。瘦身后的链路用户输入“鹈鹕骑自行车”→任务路由Skill判断为图像生成任务→直接调用图像生成Skill→输出。两步完成耗时约3秒。这个对比让我意识到Skill瘦身的本质不是减少功能而是减少决策噪音。功能还在只是Agent不再需要在一堆相似选项里纠结了。4.3 瘦身过程中踩过的三个坑第一个坑是合并过度。我一开始把代码生成和代码审查也合并成了一个Skill结果发现这两个任务的提示词逻辑差异太大合并后两边都做不好。后来拆回了两个独立的Skill。教训是合并的前提是核心逻辑一致只是参数或格式不同。如果底层逻辑都不一样强行合并只会互相拖累。第二个坑是触发条件收得太紧。有个Skill我一开始把触发条件设得太严格导致该触发的时候不触发用户得反复说好几遍才能激活。后来我加了一个“兜底触发”机制如果用户连续两次输入都没有匹配到任何Skill就自动激活一个通用处理Skill。这样既避免了误触发又不会漏掉真正的需求。第三个坑是忽略了Skill之间的依赖关系。有个Skill依赖另一个Skill的输出作为输入我瘦身的时候差点把被依赖的那个砍掉。后来我画了一张Skill依赖图把每个Skill的输入输出关系标清楚才避免了这个问题。注意瘦身之前一定要画依赖图。Skill之间往往有隐性的调用关系砍掉一个可能会让另一个也失效。5. 可复用的Skill瘦身方法论5.1 四步瘦身流程诊断、分类、合并、验证把上面的经验抽象一下我总结了一个四步流程可以直接套用到任何Agent的Skill体系上。第一步是诊断。拉取至少两周的调用日志统计每个Skill的触发频率、平均执行时长、token消耗、以及和其他Skill的重叠度。没有数据就不要动手。第二步是分类。把Skill分成四类核心资产不可替代、高频、可合并项功能重叠、可降级项低频但必要、可砍掉项低频且可替代。分类标准可以参考下面的表格类别判断标准处理方式核心资产独特价值高频维护成本可控保留优化提示词可合并项功能重叠度超过60%合并为一个Skill用参数区分可降级项低频但必要移出主流程按需加载可砍掉项低频且功能可被替代直接移除第三步是合并。合并的时候注意保留每个原Skill的独特逻辑用参数或条件分支来区分。不要为了合并而合并如果两个Skill的核心逻辑差异太大强行合并只会让提示词变得臃肿。第四步是验证。用同一批测试用例跑对比重点看响应时间、token消耗、一次通过率这三个指标。如果瘦身后某个指标反而变差了说明瘦身方案有问题需要回滚或者调整。5.2 提示词层面的瘦身技巧Skill瘦身不只是数量上的减少每个Skill内部的提示词也需要瘦身。我总结了几个实用的技巧去掉冗余的角色描述。很多提示词开头会写一大段“你是一个专业的XXX拥有十年经验擅长XXX”。这些描述对模型的行为影响很小但会占用不少token。我的做法是只保留最核心的角色定义比如“你是一个代码生成助手”一句话就够了。用结构化格式替代自然语言描述。把“你需要先做A然后做B最后做C”改成用有序列表或者表格来表达。结构化格式的token效率更高模型理解起来也更准确。删除重复的约束条件。我检查自己的提示词时发现同一个约束条件在不同段落里重复出现了三四次。比如“输出必须是JSON格式”这句话在角色描述、执行规则、输出示例里各出现了一次。删掉重复的之后提示词长度减少了将近三成。把长示例换成短示例。原来我喜欢在提示词里放完整的输入输出示例一个示例就占几百token。后来改成只放关键片段的示例模型照样能理解。# 瘦身前约180 token 你是一个专业的文本摘要助手拥有丰富的自然语言处理经验。你的任务是对用户输入的文本进行摘要。你需要先理解文本的核心内容然后提取关键信息最后用简洁的语言输出摘要。摘要应该控制在200字以内。输出格式应该是纯文本不要使用markdown格式。请注意摘要应该保留原文的关键数据和逻辑关系。 # 瘦身后约60 token # 摘要助手 任务对输入文本生成200字以内的摘要。 要求保留关键数据和逻辑关系纯文本输出。5.3 建立Skill维护的长效机制瘦身不是一次性的工作。Agent在使用过程中会不断产生新的需求Skill体系也会慢慢重新变胖。我建立了一个简单的维护机制每两周做一次快速检查统计过去两周每个Skill的触发频率标记出低于阈值比如每周少于3次的Skill检查是否有新的功能重叠出现回顾用户反馈看是否有Skill经常被误触发或者该触发时不触发更新Skill注册表把新出现的低频Skill移到按需加载区这个机制花不了多少时间但能防止Skill体系再次臃肿。我个人的体会是Skill管理就像整理房间定期清理比一次性大扫除更有效。6. 关于Agent Skill设计的一些个人思考折腾完这一轮瘦身我对Agent Skill的设计有了几个新的认识。第一个认识是Skill的数量和Agent的能力不成正比。刚开始做Agent的时候我总觉得Skill越多越好每个场景都想要一个专门的Skill。但实际用下来发现Skill太多反而会拖累Agent的决策效率。就像一个人手里拿着十几个工具每次干活之前都要先想用哪个这个思考过程本身就是消耗。第二个认识是好的Skill设计应该像好的函数设计。一个函数只做一件事但要把这件事做到极致。Skill也一样每个Skill应该有明确的输入输出和单一的职责。如果一个Skill需要写很长的提示词才能说清楚它是干什么的那大概率是职责没划分清楚。第三个认识是触发条件的设计比Skill本身更重要。一个Skill写得再好如果触发条件不对要么该用的时候用不上要么不该用的时候乱触发。我现在设计Skill的时候会花至少一半的时间在触发条件的调试上确保它只在正确的场景下被激活。第四个认识是瘦身是一个持续的过程不是一次性的项目。Agent在使用中会不断遇到新场景每次加新Skill的时候都要问自己这个Skill能不能合并到现有的里面它的触发条件会不会和现有的冲突它是不是应该放在按需加载区养成这个习惯之后Skill体系就不会轻易变胖了。最后分享一个我最近在用的技巧给每个Skill打标签标签包括“核心”“辅助”“实验”三类。核心Skill常驻主流程辅助Skill按需加载实验Skill放在沙箱里跑。每两周 review 一次标签把表现好的实验Skill升级为辅助把长期不用的辅助Skill降级或移除。这个标签体系让Skill管理变得很直观一眼就能看出哪些该留哪些该动。这套方法我用了大概三个月Agent的整体表现一直很稳定。中间有过几次想加新Skill的冲动但每次都会先问自己现有的Skill能不能覆盖这个需求如果能就不加如果不能再考虑加。这个简单的习惯帮我省下了不少折腾的时间。 Agent Skill瘦身实战：从臃肿到精悍的优化复盘
1. 从“臃肿”到“精悍”一次Skill瘦身的完整复盘先说说我为什么要折腾这件事。手头维护着一套自用的Agent工作流里面挂载了十几个Skill从代码生成、文档解析到空间分析、视频提示词模板几乎覆盖了我日常所有高频场景。刚开始用着挺爽每个Skill各司其职调用起来也顺手。但大概两个月前我开始明显感觉到不对劲——Agent的响应速度肉眼可见地变慢有时候一个简单的任务它要在好几个Skill之间来回跳转token消耗量比预期高出三四倍偶尔还会出现“抢活干”的情况两个Skill同时响应同一个请求输出结果互相打架。最让我头疼的是“鹈鹕骑自行车”那个测试用例。这是我用来做端到端验证的一个经典提示词原本期望Agent能直接调用图像生成Skill输出结果结果它先触发了文本理解Skill又绕到提示词优化Skill最后才慢吞吞地走到图像生成中间还夹带了一堆无关的中间产物。整个过程像是一个原本只需要拧一颗螺丝的活儿来了五个工人每个人都先检查一遍工具箱。这就是典型的Skill臃肿症。每个Skill单独看都没问题但放在一起就变成了“三个和尚没水喝”。我翻了一圈社区里的讨论发现这不是我一个人的困扰。很多人都在聊Agent架构优化、提示词工程、Skill插件管理但真正系统性地讲“怎么给Skill做减法”的内容并不多。大部分教程都在教你怎么加功能、怎么扩能力很少有人告诉你——加是本能减才是本事。这篇文章就是把我自己给Skill瘦身的完整过程拆开来讲。从怎么判断一个Skill该不该留到怎么合并同类项再到瘦身之后怎么验证效果每一步我都会把背后的逻辑和踩过的坑说清楚。如果你也在维护自己的Agent工作流或者正在设计一套Skill体系这篇内容应该能帮你少走不少弯路。不管你是刚接触Agent开发的新手还是已经有一堆Skill在跑的老手下面的内容都能直接拿去用。2. 瘦身之前先搞清楚Skill为什么会“胖”2.1 Skill臃肿的三种典型症状在动手之前我先花了两天时间做诊断。不是凭感觉说“好像变慢了”而是把每个Skill的调用日志拉出来统计触发频率、平均执行时长、token消耗量、以及和其他Skill的重叠度。数据一摆出来问题就很清楚了。第一种症状是功能重叠。我发现自己有三个Skill都在做文本摘要相关的事一个叫“文档精读”一个叫“内容提炼”还有一个叫“要点提取”。名字不一样但实际干的事有八成重合。每次遇到摘要任务Agent要在三个里面选一个选择本身就要消耗推理资源选错了还得重来。第二种症状是职责边界模糊。有个Skill叫“智能助手”当初设计的时候想让它当万能兜底什么都能接一点。结果它变成了一个“什么都会一点什么都不精”的角色。用户问代码问题它也能答但不如专门的代码Skill用户问数据分析它也能接但不如专门的分析Skill。这种模糊地带最消耗资源因为Agent不确定该不该调用它。第三种症状是触发条件过宽。有个提示词优化Skill我当初设置的触发条件是“当用户输入包含优化、改进、提升等关键词时激活”。听起来没问题但实际上“提升”这个词在技术讨论里太常见了导致这个Skill被频繁误触发。每次误触发都是一次无效计算。我把这三种症状对应的数据整理成了一张表方便对照排查症状类型具体表现资源消耗特征排查方法功能重叠多个Skill处理同类任务选择成本高token浪费在决策上统计任务类型分布看是否有多个Skill覆盖同一类边界模糊兜底Skill什么都接执行质量不稳定返工率高检查兜底Skill的调用记录看有多少本应走专用Skill触发过宽关键词匹配太泛无效调用多响应链路变长分析触发日志统计误触发比例提示诊断阶段不要急着改代码先把数据跑出来。凭感觉优化往往会把有用的Skill也砍掉数据驱动才能精准定位问题。2.2 一个Skill该不该留三个判断标准数据出来之后我开始逐个评估每个Skill的去留。这里我总结了三个判断标准按优先级排序第一这个Skill是否有不可替代的独特价值比如我的“GIS空间分析”Skill它封装了一套坐标转换和空间插值的逻辑别的Skill做不了这个事。这种就是核心资产必须保留。但如果一个Skill的功能可以被其他Skill组合实现那它就有被合并的空间。第二这个Skill的触发频率是否足够高我统计了过去30天的调用数据发现有些Skill一个月只被触发了两次。这种低频Skill要么是设计有问题要么是场景太窄。对于低频但必要的Skill我会把它降级为“按需加载”不放在主流程里。第三这个Skill的维护成本是否可控有些Skill依赖外部接口或者特定版本的模型每次底层更新都要跟着改。如果一个Skill的维护成本已经超过了它带来的价值那就该考虑砍掉或者重构。这三个标准帮我快速筛出了一批“该动刀”的Skill。接下来就是具体的瘦身操作。3. 瘦身实操从十几个Skill精简到六个3.1 合并同类项把三个摘要Skill合成一个第一个动刀的就是那三个摘要Skill。我把它们的提示词全部拉出来对比发现核心逻辑其实是一样的输入一段文本输出关键信息。区别只在于输出的格式和详细程度。我的做法是保留一个主Skill把另外两个的能力作为参数合并进去。具体来说新的摘要Skill接受一个mode参数有三个可选值brief对应原来的“要点提取”standard对应“内容提炼”detailed对应“文档精读”。Agent在调用时只需要传一个参数不需要在三个Skill之间做选择。合并之后的提示词结构大概是这样# 摘要Skill ## 角色 你是一个文本摘要专家根据指定的详细程度输出摘要。 ## 参数 - mode: brief | standard | detailed - brief: 输出3-5个关键点每个不超过20字 - standard: 输出一段200字以内的摘要 - detailed: 输出分段落的详细摘要保留关键数据和逻辑关系 ## 执行规则 1. 先判断输入文本的类型技术文档、新闻、对话记录等 2. 根据mode参数调整输出粒度和格式 3. 如果输入文本超过模型上下文限制先分段处理再合并这个改动带来的效果很直接Agent的决策链路缩短了不再需要在三个Skill之间做选择。token消耗量下降了大约40%因为省掉了选择过程中的推理开销。3.2 收窄触发条件让Skill只在该出现的时候出现那个提示词优化Skill的误触发问题我用了两个手段来解决。第一个手段是提高关键词的匹配精度。原来用的是“包含优化、改进、提升”这种宽泛匹配改成了“当用户明确要求对提示词进行优化且输入内容包含提示词结构或模板特征时激活”。具体来说我加了一个前置判断先检查输入是否包含类似“角色”“指令”“输出格式”这样的提示词结构关键词如果有才进入优化流程。第二个手段是引入置信度阈值。我让Skill在触发前先做一个快速判断输出一个0到1之间的置信度分数只有分数超过0.7才真正执行。这个判断本身消耗的token很少但能过滤掉大量误触发。# 触发判断的伪代码逻辑 def should_activate_optimizer(user_input): # 检查是否包含提示词结构特征 structure_keywords [角色, 指令, 输出格式, 约束条件, 示例] structure_score sum(1 for kw in structure_keywords if kw in user_input) / len(structure_keywords) # 检查是否包含明确的优化意图 intent_keywords [优化提示词, 改进提示词, 提示词调整] intent_score 1.0 if any(kw in user_input for kw in intent_keywords) else 0.3 # 综合置信度 confidence structure_score * 0.6 intent_score * 0.4 return confidence 0.7改完之后这个Skill的误触发率从原来的六成降到了不到一成。省下来的token和时间直接体现在了整体响应速度上。3.3 降级低频Skill按需加载而不是常驻有几个Skill的使用频率很低比如“视频提示词模板”和“打斗动作提示词生成”一个月可能就用两三次。这些Skill如果常驻在主流程里每次Agent做决策时都要考虑它们白白消耗推理资源。我的处理方式是把它们从主Skill列表中移除改成“按需加载”。具体实现是维护一个Skill注册表主流程只加载高频Skill低频Skill放在一个单独的目录里。当Agent判断当前任务需要某个低频Skill时再动态加载进来。{ core_skills: [ code_generation, document_analysis, spatial_analysis, prompt_optimizer, summarizer, task_router ], on_demand_skills: [ video_prompt_template, action_prompt_generator, gis_advanced_tools ] }这个改动让主流程的Skill数量从十几个降到了六个Agent的决策空间大幅缩小响应速度提升非常明显。4. 瘦身之后效果验证与关键指标对比4.1 响应速度与token消耗的实测数据瘦身完成后我用同一批测试用例跑了对比。测试集包含20个任务覆盖代码生成、文档摘要、空间分析、提示词优化等场景。每个任务跑三遍取平均值结果如下指标瘦身前瘦身后变化幅度平均响应时间8.3秒3.7秒下降55%平均token消耗42001800下降57%任务一次通过率72%91%提升19个百分点Skill误触发次数14次/20任务3次/20任务下降79%响应时间的下降主要来自决策链路的缩短。原来Agent要在十几个Skill里做选择现在只需要在六个里选推理步骤少了自然就快了。token消耗的下降更明显因为省掉了大量用于“选择”和“犹豫”的中间推理。一次通过率的提升是我没想到的。后来分析发现Skill少了之后Agent的决策更果断不容易在多个相似Skill之间反复横跳。以前经常出现的情况是Agent先调了A Skill觉得不对又调B Skill最后发现还是A Skill的结果更合适但已经浪费了两轮计算。现在这种情况基本消失了。4.2 “鹈鹕骑自行车”测试用例的完整链路对比回到开头提到的那个经典测试用例。瘦身前后Agent处理“鹈鹕骑自行车”这个提示词的链路完全不同。瘦身前的链路是这样的用户输入“鹈鹕骑自行车”→触发文本理解Skill→触发提示词优化Skill→触发图像生成Skill→触发结果校验Skill→输出。中间还夹着一次误触发因为“自行车”这个词触发了某个运动相关的Skill。整个链路走了五步耗时约12秒。瘦身后的链路用户输入“鹈鹕骑自行车”→任务路由Skill判断为图像生成任务→直接调用图像生成Skill→输出。两步完成耗时约3秒。这个对比让我意识到Skill瘦身的本质不是减少功能而是减少决策噪音。功能还在只是Agent不再需要在一堆相似选项里纠结了。4.3 瘦身过程中踩过的三个坑第一个坑是合并过度。我一开始把代码生成和代码审查也合并成了一个Skill结果发现这两个任务的提示词逻辑差异太大合并后两边都做不好。后来拆回了两个独立的Skill。教训是合并的前提是核心逻辑一致只是参数或格式不同。如果底层逻辑都不一样强行合并只会互相拖累。第二个坑是触发条件收得太紧。有个Skill我一开始把触发条件设得太严格导致该触发的时候不触发用户得反复说好几遍才能激活。后来我加了一个“兜底触发”机制如果用户连续两次输入都没有匹配到任何Skill就自动激活一个通用处理Skill。这样既避免了误触发又不会漏掉真正的需求。第三个坑是忽略了Skill之间的依赖关系。有个Skill依赖另一个Skill的输出作为输入我瘦身的时候差点把被依赖的那个砍掉。后来我画了一张Skill依赖图把每个Skill的输入输出关系标清楚才避免了这个问题。注意瘦身之前一定要画依赖图。Skill之间往往有隐性的调用关系砍掉一个可能会让另一个也失效。5. 可复用的Skill瘦身方法论5.1 四步瘦身流程诊断、分类、合并、验证把上面的经验抽象一下我总结了一个四步流程可以直接套用到任何Agent的Skill体系上。第一步是诊断。拉取至少两周的调用日志统计每个Skill的触发频率、平均执行时长、token消耗、以及和其他Skill的重叠度。没有数据就不要动手。第二步是分类。把Skill分成四类核心资产不可替代、高频、可合并项功能重叠、可降级项低频但必要、可砍掉项低频且可替代。分类标准可以参考下面的表格类别判断标准处理方式核心资产独特价值高频维护成本可控保留优化提示词可合并项功能重叠度超过60%合并为一个Skill用参数区分可降级项低频但必要移出主流程按需加载可砍掉项低频且功能可被替代直接移除第三步是合并。合并的时候注意保留每个原Skill的独特逻辑用参数或条件分支来区分。不要为了合并而合并如果两个Skill的核心逻辑差异太大强行合并只会让提示词变得臃肿。第四步是验证。用同一批测试用例跑对比重点看响应时间、token消耗、一次通过率这三个指标。如果瘦身后某个指标反而变差了说明瘦身方案有问题需要回滚或者调整。5.2 提示词层面的瘦身技巧Skill瘦身不只是数量上的减少每个Skill内部的提示词也需要瘦身。我总结了几个实用的技巧去掉冗余的角色描述。很多提示词开头会写一大段“你是一个专业的XXX拥有十年经验擅长XXX”。这些描述对模型的行为影响很小但会占用不少token。我的做法是只保留最核心的角色定义比如“你是一个代码生成助手”一句话就够了。用结构化格式替代自然语言描述。把“你需要先做A然后做B最后做C”改成用有序列表或者表格来表达。结构化格式的token效率更高模型理解起来也更准确。删除重复的约束条件。我检查自己的提示词时发现同一个约束条件在不同段落里重复出现了三四次。比如“输出必须是JSON格式”这句话在角色描述、执行规则、输出示例里各出现了一次。删掉重复的之后提示词长度减少了将近三成。把长示例换成短示例。原来我喜欢在提示词里放完整的输入输出示例一个示例就占几百token。后来改成只放关键片段的示例模型照样能理解。# 瘦身前约180 token 你是一个专业的文本摘要助手拥有丰富的自然语言处理经验。你的任务是对用户输入的文本进行摘要。你需要先理解文本的核心内容然后提取关键信息最后用简洁的语言输出摘要。摘要应该控制在200字以内。输出格式应该是纯文本不要使用markdown格式。请注意摘要应该保留原文的关键数据和逻辑关系。 # 瘦身后约60 token # 摘要助手 任务对输入文本生成200字以内的摘要。 要求保留关键数据和逻辑关系纯文本输出。5.3 建立Skill维护的长效机制瘦身不是一次性的工作。Agent在使用过程中会不断产生新的需求Skill体系也会慢慢重新变胖。我建立了一个简单的维护机制每两周做一次快速检查统计过去两周每个Skill的触发频率标记出低于阈值比如每周少于3次的Skill检查是否有新的功能重叠出现回顾用户反馈看是否有Skill经常被误触发或者该触发时不触发更新Skill注册表把新出现的低频Skill移到按需加载区这个机制花不了多少时间但能防止Skill体系再次臃肿。我个人的体会是Skill管理就像整理房间定期清理比一次性大扫除更有效。6. 关于Agent Skill设计的一些个人思考折腾完这一轮瘦身我对Agent Skill的设计有了几个新的认识。第一个认识是Skill的数量和Agent的能力不成正比。刚开始做Agent的时候我总觉得Skill越多越好每个场景都想要一个专门的Skill。但实际用下来发现Skill太多反而会拖累Agent的决策效率。就像一个人手里拿着十几个工具每次干活之前都要先想用哪个这个思考过程本身就是消耗。第二个认识是好的Skill设计应该像好的函数设计。一个函数只做一件事但要把这件事做到极致。Skill也一样每个Skill应该有明确的输入输出和单一的职责。如果一个Skill需要写很长的提示词才能说清楚它是干什么的那大概率是职责没划分清楚。第三个认识是触发条件的设计比Skill本身更重要。一个Skill写得再好如果触发条件不对要么该用的时候用不上要么不该用的时候乱触发。我现在设计Skill的时候会花至少一半的时间在触发条件的调试上确保它只在正确的场景下被激活。第四个认识是瘦身是一个持续的过程不是一次性的项目。Agent在使用中会不断遇到新场景每次加新Skill的时候都要问自己这个Skill能不能合并到现有的里面它的触发条件会不会和现有的冲突它是不是应该放在按需加载区养成这个习惯之后Skill体系就不会轻易变胖了。最后分享一个我最近在用的技巧给每个Skill打标签标签包括“核心”“辅助”“实验”三类。核心Skill常驻主流程辅助Skill按需加载实验Skill放在沙箱里跑。每两周 review 一次标签把表现好的实验Skill升级为辅助把长期不用的辅助Skill降级或移除。这个标签体系让Skill管理变得很直观一眼就能看出哪些该留哪些该动。这套方法我用了大概三个月Agent的整体表现一直很稳定。中间有过几次想加新Skill的冲动但每次都会先问自己现有的Skill能不能覆盖这个需求如果能就不加如果不能再考虑加。这个简单的习惯帮我省下了不少折腾的时间。