删掉Skill，Agent反而更听话？

本文来自微信公众号： 碳基智 ，作者：碳基智

之前也写过关于skill本质的文章，其实它就相当于一个给Agent用的system prompt，告诉模型“你是谁、该怎么做、什么不能做”这些事情，从Harness的角度看，边界围栏设立得清清楚楚，理论上Agent的输出效果会更好。

理论上……

但当我把自己的各类工作流抽象成skill以后，却发现：除了那些有着我鲜明个人特色需求的skill，不加载skill纯模型输出的效果也没想象中差。虽然从skill benchmark测试的结果看，skill输出的平均分往往要高于纯模型输出，但这背后的原因可能跟大家想的都不太一样。

1

大部分人迭代skill的流程通常是这样的：

先写完初版，上线试跑➡️发现问题，添加新约束➡️继续迭代，各种禁止词出现➡️最终skill行数从开始的400行，膨胀到近2000行。

但输出效果还是不够稳定。

越强调，文档越长；文档越长，注意力越分散；注意力越分散，违反越多；违反越多，再追加一遍。一个完美的恶性循环。

这里的技术原理，说白了其实就是模型的注意力机制问题。Stanford的经典论文《Lost in the Middle》里提到：

大模型对输入序列的注意力分布不是均匀的，开头和末尾的内容获得最多关注，中间区域容易被遗忘，呈U形曲线。

数据上看，开头指令的遵循率能达到73%，末尾会略低一些，到了中间区域遵循率就会骤降30%–50%。原因也很简单，Transformer的位置编码机制决定了，两个token距离越远，注意力越弱。

2

我最近正好读到了一篇新的论文《The Regression Tax:Decomposing Why Skills Help and Hurt LLM Agents》，它用相对还算严谨的实验给了我一些解答。我发现，传统的skill benchmark评测里面有一个大家都忽略了的地方。传统评测把一套skill加到Agent上，重新跑benchmark，然后比较平均成功率。比如无Skill通过100道题中的60道，加Skill后通过65道，结论通常写成提升5个百分点。

但那65道正确答题可能来自两条完全不同的路径：

• 新做对5道，原来会做的题一题没错；

  
  

• 新做对20道，同时弄错15道旧题。

  
  

两套系统的平均分都从60涨到65，可靠性却不在一个档次。第一套Skill扩大了能力边界，第二套Skill对能力做了大规模换血。作为用户，你很难分清楚，你的skill究竟是第一套还是第二套。

作者选了486个办公自动化任务，把每个配对任务分成四类：

净提升的公式：

通过率变化=（Gains−Regressions）÷任务总数

通过这样设置的对照实验，来看skill是否起到了应有作用。

486个办公自动化任务，其中94个来自OfficeQA-Pro，要求Agent阅读美国财政文件、表格与长PDF；392个来自SpreadsheetBench，要求Agent修改真实Excel工作簿。

每个任务放进三套model–harness组合：

• OpenCode×MiniMax-M2.7

  
  

• Codex×GPT-5.4-mini

  
  

• Claude Code×Claude Sonnet 4.6

  
  

每套组合再跑四种条件：不装Skill，以及Anthropic、OpenAI、作者自建的三套Skill库。486×3×4得到5,832次task-condition runs。

3

论文核心数据如下：

553次gain，对应324次regression。新增失败抵消了毛收益的59%，最后留下229次净增成功。Skill帮你新救回10道题的同时，大约又弄坏了原本会做的6道。

18个Skill条件全部出现regression，范围为2到41次。论文里没有一套Skill库做到“只加能力、不伤旧能力”。

OfficeQA-Pro的81次回归中，59次属于grounding displacement（输入锚定偏移），占72.8%。多数时候算法没算错，Agent读错了表、年份、定义或对象。

SpreadsheetBench的243次回归中，70次被归为osmosis，占28.8%。这些任务没有调用Skill正文，常驻description已经改变了行为。

接下来是一些印证我真实体验的结论。

Skill没调用也可能产生影响。

一个典型Skill可以拆成两层。description负责告诉Agent这项能力解决什么问题、什么时候应该触发；body放着详细步骤、脚本与参考资料。许多Agent框架采用渐进加载，body只在命中任务后读取，description却会常驻系统上下文，方便模型做路由。

问题就出在这张常驻目录上。

大模型生成答案时，会综合当前上下文中的词汇、指令与示例。description即使没有给出完整流程，也可能给模糊任务提供一个解释方向。论文把这种presence-only influence称为skill-description osmosis。osmosis原意是渗透，作者想表达的意思很直白：Skill正文虽然没打开，描述里的概念已经渗进了Agent的判断。

Grounding displacement（输入锚定偏移）

Grounding在大模型语境里常被译成“语义落地”“事实锚定”或“输入对齐”。它解决的问题是：用户说的这句话，究竟对应现实世界里的哪个对象、哪份数据和哪一种口径。

比如用户说“计算1934年和1946年公共工程支出的差额”，Agent需要完成几次锚定：找到正确文件、进入正确表格、确认两个年份、选中修订后的统计口径、识别单位。前面这些动作都属于grounding。

Grounding在这篇论文里指Agent能不能把任务落到正确输入上，说人话就是能不能读懂题，而不是像我们文科生一样即使不会做都能写个800字出来。

对应到用户体感上，你会发现Agent加了SOP后回答变得更完整、更“像”行家，但有时候却连问题本身都理解歪了。它进入了“按照手册完成任务”的模式，对用户输入中的具体限定反而不够敏感。

Verification displacement（验证环节被挤占）

Verification指的是模型交付前的结果检查。它需要拿最终产物重新对照用户要求，或者让真实工具执行比如：绝对值有没有保留正号，Excel公式能否重算，代码测试是否通过，文件格式是否符合交付标准。

Skill提供一套完整procedure后，Agent可能把“流程走完”当成“任务完成”，原本会做的结果检查被削弱。

作者把663个含公式的失败任务交给完整表格引擎重算，226个公式原本就是正确的，占34%。原评分器不会算部分函数，正确答案被判成错误。它提醒我们两件事：Agent需要可执行验证，评测Agent的系统也得先证明自己有检验能力。

4

最后，我们可以看到，Agent的能力管理正在重复软件工程走过的路。

这篇论文提醒大家的是，新增依赖一定要跑回归测试，不然你就会交回归税。Skill进入生产环境也需要回归预算、灰度和可撤销机制，一整个万变不离控制论了。

那么，工程上的解法大概有这几种：

分层架构：将Skill视为有层次结构的文档，位置决定优先级。

消除隐性冲突，规则要做到无歧义，让优先级显式化。

划重点：用正向指令替代否定指令，多项研究表明，模型对"不要做X"的遵循率显著低于"只做Y"。

结构化格式，降低模型的理解成本，推荐每个人都去学习下怎么用markdown写文档和表格。

试一下吧，朋友们！