1. 从“臃肿”到“精悍”一次Skill瘦身的完整复盘先说说我为什么要折腾这件事。大概三个月前我手头同时跑着好几个Agent项目有基于Claude Code做代码审查的有接DeepSeek API做文档摘要的还有一个用Codex做自动化测试的。每个项目里都塞了一堆Skill——就是那种告诉Agent“你该怎么干活”的提示词模块。一开始觉得挺爽功能越加越多Skill文件从几百行膨胀到两三千行结果呢Agent开始犯迷糊了。最典型的表现是你让它改个函数名它给你把整个文件重写了你让它查个日志它反手给你生成一段Python脚本。明明Skill里写了“只做最小改动”它就跟没看见一样。后来我拿几个标准测试用例跑了一遍——就是圈子里常说的“鹈鹕骑自行车”那类提示词测试——发现准确率从最初的85%掉到了60%出头。这时候我才意识到Skill不是越多越好臃肿的Skill正在拖垮Agent的表现。这篇文章就是把我这几个月踩过的坑、试过的方案、最终跑通的那套瘦身方法论完整拆开讲。不管你是刚接触Agent开发的新手还是已经在调提示词的老手只要你的Skill也遇到了“越加越笨”的问题这篇内容应该能帮你省下不少试错时间。核心关键词就几个Skill瘦身、Agent表现优化、提示词工程、Claude Code、DeepSeek。我会从设计思路讲到实操步骤再把我遇到的那些奇葩问题和排查方法一并奉上。2. 为什么Skill会越用越“胖”先搞懂Agent的认知负荷2.1 Skill的本质是什么它和Agent、Harness到底什么关系很多人刚入门的时候容易把几个概念搅在一起。我用一个生活化的类比来解释Agent就像是一个刚入职的实习生Harness是公司给他配的工位、电脑和办公软件而Skill就是你写给这个实习生的岗位操作手册。手册写得越厚实习生越容易翻到后面忘了前面。Harness和Agent的区别在于Harness是运行环境层面的东西——比如Claude Code这个工具本身、DeepSeek的API调用框架、Codex的执行沙盒——它决定了Agent能做什么动作。而Skill是认知层面的东西它决定了Agent在某个具体场景下应该怎么思考、怎么决策。我见过不少项目把本该放在Harness层面的逻辑硬塞进Skill里。比如“调用某个API时先检查网络状态”这种明明是Harness该处理的结果写进了Skill导致每次Agent做决策都要多读几百个token的无关信息。这就是典型的职责错位。2.2 臃肿Skill的三大典型症状第一个症状是指令淹没。当你的Skill文件超过1500行Agent在推理时真正需要的那条指令很可能被淹没在大量“以防万一”的补充说明里。我做过一个粗略统计在一个2000行的Skill中核心指令大概只占15%剩下的85%都是边界情况处理、示例、注意事项、格式说明。Agent每次调用都要把这2000行全部读一遍注意力被严重稀释。第二个症状是规则冲突。这个特别隐蔽。比如你在Skill开头写了“保持简洁只输出必要内容”结果在中间某个章节又写了“为了确保用户理解每个步骤都要详细解释”。这两条规则在不同场景下都合理但Agent同时读到就会犯迷糊。我遇到过最离谱的一次Agent在同一个回复里先给我一段极简的代码然后又附了三百字的解释完全自相矛盾。第三个症状是示例过载。很多人喜欢在Skill里塞大量few-shot示例觉得例子越多Agent学得越好。但实际上当示例超过5-6个Agent会开始“模仿示例的表面形式”而不是“理解示例背后的逻辑”。比如你给了10个“用户问A你答B”的示例Agent遇到A的变体A时会硬套B的格式哪怕内容完全不匹配。2.3 瘦身不是删减而是重构信息层级这里要澄清一个误区Skill瘦身不等于简单地把内容删掉。我一开始也犯过这个错误直接把Skill从2000行砍到500行结果Agent连基本任务都完不成了。后来才明白瘦身的核心是重构信息层级——把“每次都需要的信息”和“按需查阅的信息”分开把“规则”和“示例”分开把“核心逻辑”和“边界处理”分开。打个比方原来的Skill像一本没有目录的厚书Agent每次都要从头翻到尾。瘦身后的Skill应该像一张思维导图主干清晰分支按需展开。具体怎么做下一章我会详细拆解。3. 瘦身方案设计三层分离架构3.1 核心层、规则层、参考层的职责划分我最终跑通的方案是把Skill拆成三层。核心层只保留最关键的3-5条指令控制在200字以内这部分是Agent每次都必须读的。规则层包含具体的操作规范和约束条件大概500-800字Agent在需要做决策时查阅。参考层放示例、边界情况、格式模板这部分不直接进入Agent的推理上下文而是通过工具调用按需检索。这个设计的逻辑依据来自Agent的上下文窗口特性。不管是Claude Code还是DeepSeek上下文窗口都是有限资源。你把2000行全部塞进去核心指令的“注意力权重”就被稀释了。而三层分离之后核心层始终占据最优先的注意力位置规则层在需要时加载参考层几乎不占用常驻上下文。我实测下来同样的任务集三层架构的Skill比原始臃肿版本准确率提升了23个百分点从62%回到了85%以上。而且响应速度也有明显改善因为Agent不需要每次处理那么多token了。3.2 什么内容该放哪一层判断标准与实操方法判断一条内容该放哪层我总结了一个简单的测试如果这条内容缺失Agent会不会完全无法完成任务如果会放核心层。如果只是可能导致结果不够完美放规则层。如果只是影响边缘情况的处理放参考层。举个例子。“你是一个代码审查助手”这句话缺失了Agent就不知道自己的角色必须放核心层。“审查时优先关注安全漏洞其次是性能问题”这条缺失了Agent还是会审查只是优先级可能不对放规则层。“如果遇到SQL注入风险按以下格式输出警告”这种放参考层。实操的时候我建议先把现有Skill的所有内容列出来逐条打标签。我自己的Skill从2000行拆完后核心层只有180字规则层720字参考层拆成了5个独立的检索文档。Agent的表现不降反升。3.3 为什么这种架构能提升Agent表现注意力机制视角从注意力机制的角度看Agent在处理上下文时每个token获得的注意力权重是不一样的。靠近开头和结尾的内容通常获得更高权重中间部分容易被忽略。臃肿Skill的问题在于核心指令往往不在开头也不在结尾而是散落在中间自然就被“淹没”了。三层架构把核心指令固定在开头规则层紧随其后参考层移出常驻上下文。这样Agent的注意力资源集中在了最该关注的地方。另外参考层通过工具调用按需加载相当于把“记忆”变成了“检索”这更符合Agent的工作方式——它不需要记住所有细节只需要知道“遇到什么情况该去哪里查”。4. 实操一步步给Skill做减法4.1 第一步给现有Skill做“体检”别急着动手删。先拿一个标准测试集跑一遍现有Skill记录Agent在哪些任务上表现好、哪些表现差。我用的测试集包括10个代码审查任务、10个文档摘要任务、5个多轮对话任务。每个任务都有明确的预期输出方便量化对比。跑完之后你会得到一张“问题分布图”。比如我的数据显示代码审查任务中“遗漏安全漏洞”占比最高文档摘要任务中“输出格式不一致”最严重。这些问题就是你瘦身的重点方向。同时用工具统计一下Skill文件的token分布。我用的方法很简单把Skill按章节切分分别计算每个章节的token数。结果发现“示例”章节占了42%“注意事项”占了28%真正核心的“任务指令”只有12%。这个数据直接告诉我该砍哪里。4.2 第二步核心层提炼——把2000字压到200字核心层提炼是最考验功力的环节。我的方法是“三问法”第一问Agent如果不读这条能不能知道自己是干什么的第二问Agent如果不读这条能不能知道最终输出什么第三问Agent如果不读这条会不会做出完全错误的行为只有三个问题都回答“会”的内容才留在核心层。按这个标准我原来的Skill里只有4条内容合格角色定义、任务目标、输出格式要求、绝对禁止事项。其他全部下移。写核心层的时候有个技巧用短句不用长句。比如“你是一个代码审查助手负责找出代码中的安全漏洞和性能问题”就比“你的职责是对用户提交的代码进行全面的审查重点关注安全性和性能方面的潜在问题”要好。前者28个字后者42个字信息量一样但前者Agent处理起来更快更准。4.3 第三步规则层重组——按决策场景而非功能模块组织规则层的组织方式很关键。很多人习惯按功能模块分比如“代码审查规则”“文档处理规则”“对话规则”。但Agent在实际工作中不是按模块切换的而是按场景决策的。所以我改成按决策场景组织当Agent需要判断“要不要修改代码”时加载一组规则当Agent需要判断“输出什么格式”时加载另一组规则。这样改的好处是Agent在某个决策点上只需要关注相关的几条规则而不是把整个规则库都读一遍。我实测下来按场景组织的规则层Agent的规则遵循率从71%提升到了89%。4.4 第四步参考层外置——用检索代替记忆参考层的外置我用了两种方式。对于结构化的内容比如输出格式模板、错误码对照表我做成JSON文件Agent通过读取文件的方式获取。对于非结构化的内容比如边界情况处理示例我做成向量检索Agent根据当前上下文检索最相关的2-3个示例。这里有个坑要注意检索的粒度不能太细也不能太粗。太细了检索结果碎片化Agent拼不起来太粗了检索结果太长又回到了臃肿的老路。我的经验是每个检索单元控制在200-400字正好是一个完整的示例或一条完整的规则说明。4.5 第五步验证与迭代——用数据说话瘦身完成后必须用同一套测试集重新跑一遍。我的对比数据是这样的瘦身前准确率62%瘦身后第一版准确率78%调整检索粒度后第二版83%优化核心层措辞后第三版87%。整个过程迭代了四轮每轮都有明确的改进方向。这里要提醒一点不要一次改太多。我第一轮同时改了核心层、规则层和参考层结果准确率反而掉了。后来改成每轮只改一层才能准确判断哪个改动有效、哪个改动无效。5. 避坑指南我踩过的五个坑5.1 坑一把“瘦身”做成了“阉割”我第一版瘦身直接把Skill从2000行砍到300行结果Agent连基本的任务边界都搞不清了。用户问一个超出范围的问题它居然硬答。后来才明白瘦身是重构信息层级不是删除信息。该有的约束一条都不能少只是换了个存放位置。5.2 坑二核心层写成了“口号”一开始我的核心层写的是“你是一个专业的、高效的、严谨的代码审查助手”。这种形容词堆砌对Agent来说几乎是噪音。后来改成“你负责审查代码中的安全漏洞和性能问题输出格式为问题类型、严重程度、修复建议”Agent的表现立刻稳定了。核心层要写“做什么”和“输出什么”不要写“你有多专业”。5.3 坑三规则层规则之间互相打架这个坑特别隐蔽。比如一条规则说“优先保证准确性”另一条说“响应速度要快”。单独看都没问题但Agent同时读到就会纠结。我的解决方法是给规则加优先级标签明确告诉Agent“当规则冲突时以哪条为准”。5.4 坑四参考层检索结果不相关检索粒度没调好的时候Agent经常检索到不相关的示例然后硬套。比如用户问的是Python代码审查检索出来的却是JavaScript的示例。后来我在检索前加了一层“场景过滤”先判断当前场景再在对应场景的示例库里检索准确率大幅提升。5.5 坑五忘了测试多轮对话场景单轮任务的测试很容易通过但多轮对话才是真正的考验。Agent在第三轮、第四轮的时候很容易忘记核心层的指令因为上下文里已经堆了很多对话历史。我的解决方法是每轮对话开始时把核心层重新注入一次。虽然增加了少量token消耗但换来了多轮场景下准确率从54%到82%的提升非常值得。6. 常见问题速查与排查技巧6.1 Agent突然不遵循核心指令了怎么办先检查上下文长度。如果对话历史超过了一定阈值核心指令的注意力权重会被稀释。解决方法是在每轮对话开始时重新注入核心层或者用系统消息的方式把核心层固定在最高优先级位置。6.2 瘦身后Agent变得“不敢做事”了怎么办这通常是因为规则层约束过严。检查一下规则层里有没有“必须”“绝对”“严禁”这类词用得太密。Agent对强约束词很敏感太多强约束会让它变得保守。适当把一些“必须”改成“建议”把“严禁”改成“避免”给Agent留出合理的判断空间。6.3 参考层检索总是慢半拍怎么办检索延迟主要来自两个方面检索库太大或者检索逻辑太复杂。我的优化方法是给检索库建索引按场景、任务类型、关键词三个维度预分类。检索时先走索引定位再做语义匹配。优化后检索延迟从平均800ms降到了200ms以内。6.4 怎么判断瘦身是否“过度”了一个简单的判断标准拿10个典型任务跑一遍如果Agent在超过3个任务上出现了“完全无法完成”的情况说明瘦身过度了。如果只是“完成得不够好”那属于正常波动可以通过微调规则层来优化。问题现象可能原因排查方法解决方向Agent忽略核心指令上下文过长导致注意力稀释检查对话轮数和token数每轮重新注入核心层Agent行为保守规则层强约束词过多统计“必须/严禁”出现频率替换为建议性表述检索结果不相关检索粒度或场景过滤有问题抽查检索日志调整粒度或加场景过滤多轮对话表现下降核心指令被对话历史淹没对比单轮和多轮准确率固定核心层位置输出格式不稳定格式规则放在了参考层检查格式规则的存放位置格式要求上移到核心层6.5 一个容易被忽略的细节Skill文件的编码格式这个坑我踩了整整两天。Skill文件里如果有特殊字符或者不统一的换行符某些Agent框架解析时会出问题导致部分指令“丢失”。表现就是Agent有时候遵循指令有时候不遵循看起来像随机行为。后来统一用UTF-8编码、LF换行符之后问题消失了。如果你也遇到Agent行为“时好时坏”先检查一下文件编码。7. 瘦身之后Agent表现提升的量化对比与长期维护7.1 实测数据瘦身前后的关键指标对比我把瘦身前后的数据整理了一下方便你直观感受差异。测试集包含25个任务覆盖代码审查、文档摘要、多轮对话三个场景。指标瘦身前瘦身后变化任务准确率62%87%25%平均响应时间4.2s2.8s-33%规则遵循率71%89%18%多轮对话准确率54%82%28%单次调用token消耗32001400-56%token消耗的下降特别值得关注。瘦身后每次调用少消耗1800个token按每天1000次调用算一个月能省下5400万token。如果用DeepSeek API这部分的成本节省相当可观。7.2 长期维护怎么防止Skill再次“发胖”瘦身不是一劳永逸的。项目迭代过程中新需求会不断冒出来Skill很容易再次膨胀。我给自己定了几条规矩第一任何新增内容必须先判断属于哪一层不能直接往核心层塞。第二每月做一次Skill“体检”统计各层token占比核心层超过300字就预警。第三新规则上线前必须跑回归测试确认不会影响已有任务的表现。另外我建议把Skill文件纳入版本管理。每次修改都记录改了什么、为什么改、测试结果如何。这样当Agent表现出现波动时可以快速定位到是哪次修改引入的问题。7.3 什么情况下该考虑重新设计而不是继续瘦身如果你的Skill已经瘦身过两轮但准确率还是上不去可能问题不在Skill本身而在Agent的Harness配置或者任务设计。比如Harness的工具调用接口设计不合理Agent需要花大量精力在“怎么调工具”上自然就没精力关注Skill里的指令了。这时候应该回头检查Harness层面而不是继续在Skill上折腾。我在实际项目中的体会是Skill瘦身的收益在第一个月最明显之后边际效益递减。当你把准确率从60%拉到85%之后再想往上提升靠的就不是瘦身了而是更精细的规则设计和更高质量的参考示例。所以瘦身要趁早做但也不要指望它能解决所有问题。