给 Agent 加了技能，它反而不会干活了？这篇论文拆透了「倒退税」

给 LLM Agent 加技能、加工具、加 procedural prompt，几乎是现在做 Agent 的标配动作。加完看一眼平均成功率，涨了，舒一口气，接着堆下一个。但盯过单个 case 的 diff 的人，多半见过这种鬼事：一个本来能跑通的流程，加了新技能之后反而断了。不是偶发，稳定复现。

这篇 7 月 24 日挂在 arXiv 上的论文，名字叫「The Regression Tax」，作者 Darshan Tank 和 Baran Nama，把这种现象从「偶尔遇到」拆成「系统分析」。他们跑了近 6000 次实验，横跨两个办公自动化 benchmark 和三种模型栈，对比了带技能和不带技能的 Agent 表现。

更值得看的是两种失败的区别。一种叫 regression：加了技能之后搞砸了以前能做的事。一种叫 residual failure：有技能没技能都搞砸。论文的核心发现是，regression 的规模大到，表现最好的技能之所以最好，主要不是因为它们带来了更多提升，而是因为它们造成的倒退更少。

这个结论和直觉相反。挑技能、写 prompt、加 tool use，默认思路都是「怎么让 Agent 多学会一些本事」。这篇论文的结论是，先别看它能多干多少，先看它别丢多少。

三个让 Agent「变笨」的路径

论文归纳了三种倒退模式，全部来自实际 trace 分析。

第一个叫 skill description osmosis。哪怕一个技能从来没被真正调用过，仅仅是它的描述存在于上下文中，就会改变 Agent 的行为方式。相当于给一个人看了一本操作规程，他没照着做，但他做事的方式已经被那本规程影响了。加技能等于加上下文噪音，这层影响不可控。

第二个叫 grounding displacement。技能规定了具体执行步骤，但这些步骤覆盖了 Agent 原本对输入的解读方式。本来 Agent 会自己判断当前屏幕状态、邮件内容、表单字段，现在它先套技能模板，模板对不上就整段垮掉。

第三个叫 verification displacement，最隐蔽。技能给出的流程让 Agent 跳过了它本来会做的输出检查。本来它会看一眼结果合不合理，现在按步骤走完就交卷了。

当前主流 Agent 技能设计过度集中在「procedural guidance」——教它怎么做，但 grounding（理解当前环境）和 verification（检查结果对不对）上的支撑远远不够。论文分析发现，大部分 persistent failure 的真正根源就在 grounding 和 verification，不是步骤不够细。

怎么接住这个结论

这篇论文给出了可以直接用的评估方法：不要把技能的效果只看成平均提升，拆成 gains 和 regressions 两部分再算账。一个技能 gain 很高但 regression 也很高，净效果可能不如一个 gain 更低但 regression 几乎为零的技能。

每次加技能前和后，跑一遍同样的回归测试集——不是测新能力，是测旧能力有没有被破坏。设计技能时把 grounding 和 verification 写进去，而不只是执行步骤。比如一个发邮件的技能，除了「填写收件人、主题、正文、发送」，还要加上「检查收件人地址是否完整」「核对附件是否已上传」「发送后确认发件箱有这条记录」。

论文最后落在一个不太让人舒服的判断上：Agent 的可靠性，更大程度上取决于 grounding 和 verification 的能力，而不是选了哪个 procedural skill。花大力气精调的那套步骤模板，可能不如多花点时间让 Agent 看清环境、确认好结果来得实在。

这不是一篇劝人别加技能的论文。它只是用 6000 次跑的结果提醒了一件事：加进去的每一段指令，都在改变 Agent 的行为方式——不只是希望它变的那部分。而这部分代价，平均分看不出来。