跳转至

Regression Tax: 技能包导致 Agent 性能退化的系统性分析

📊 Level ⭐⭐ | 9.5KB

核心概念

Regression Tax（回归税） 是指为 LLM Agent 添加技能包（Skills）后，其在部分任务上获得增益的同时，在另一些原本能独立完成的任务上出现性能退化的现象。该概念由 Sentient Labs 在 arXiv:2607.22520 中系统提出，基于 5,832 次配对对照实验。

关键数据：553 次增益（Gain）伴随 324 次回归（Regression），回归抵消 59% 的毛增益。表现最优的技能库拉开差距的核心不是解锁更多新任务，而是搞砸的旧任务更少。

三种回归机制

1. Skill-Description Osmosis（技能描述渗透）

技能的描述文本常驻在系统提示词中，即使技能本身从未被调用，其描述内容持续参与模型的上下文推理，影响模型行为。

案例 (UID0096)：计算"关税率的中心移动平均值"。无 Skill 输出正确 37.708%。引入任意技能库后（技能全程未被调用），仅因描述中含"修订后数据"（revised figure）等词汇，模型输出 38.757% 被判错误。

Osmosis 具有双向性：在低调用率的栈上，未调用的技能带来更多增益而非损害。评估方法仅在技能被检索/调用时起作用，会完全漏掉这一通道。

2. Grounding Displacement（输入锚定偏移）

技能被调用时最主要的退化原因，占 OfficeQA-Pro 所有退化的 72.8%。技能自带的标准化流程强制覆盖模型原生的信息读取逻辑——模型不再根据题目匹配对应文档/表格/年份数据，而是机械套用技能步骤，读错原始素材。

3. Verification Displacement（输出校验失效）

技能抑制或取代 Agent 原本会执行的自我验证与输出检查环节。案例：计算绝对百分比变化，无 Skill 输出 +4.815（正确），加载 Skill 后输出 -4.816（符号错误），因技能流程中未包含符号验证步骤。

结构性问题

现有技能体系过度聚焦于 Method（执行过程），对 Grounding（输入理解） 与 Verification（输出校验） 投入严重不足。

  • OfficeQA-Pro：持续失败的任务根源集中于输入环节（读了错误数据源）
  • SpreadsheetBench：34% 失败任务的公式逻辑正确，失败原因在于验证环节存在问题

深度分析

三种机制的因果层次并不在同一平面上

这三种机制常被并列阅读，但它们其实是两类性质不同的失效。Skill-Description Osmosis 属于上下文污染：技能本体从未进入执行路径，仅凭描述文本常驻 system prompt 就改变了模型的推理倾向（UID0096 从 37.708% 漂移到 38.757%）。这意味着「检索」与「选择」类防御——按需加载、相关性过滤、掩码——在原理上就无法奏效，因为它们保护的是「技能被选中」那一刻，而污染发生在技能被选中之前，且完全不依赖是否被选中。Grounding Displacement 与 Verification Displacement 则属于流程覆盖：技能确实被调用，其预设步骤挤掉了模型原生的读输入与查输出习惯。两者的修复路径同样不同——污染只能靠削减描述本身的信息载荷来消除，覆盖则可以通过重写流程来引导。

这一区分还揭示出一类被普遍忽略的成本：描述常驻成本。技能库的扩张不只消耗 token 预算，还会把一批未必相关的领域词汇（"revised"、"customs"）永久注入每一次推理。传统成本核算只统计「技能被执行时」的开销，属于系统性低估——被忽略的正是第三类成本。

净增益应取代召回率成为技能库的排序目标

59% 的回归抵消率意味着，一个技能库的净收益高度依赖「少搞砸旧任务」而非「多解锁新任务」。论文中最有说服力的证据是排序反转：在 Claude Code·OfficeQA 配置下，anthropic 技能库的增益数最少（10），却因回归最少（2）而取得最高净分（+8）。若按传统指标——覆盖率、可解决问题数、召回率——排序，得到的名次与真实效用并不一致，甚至会奖励那些激进堆技能、把旧任务推向退化的库。

这重塑了技能库的竞争逻辑：领先者不是知道更多，而是遗忘更少。对任何以「技能数量」「支持场景数」为卖点的评测排行榜，这都是一个直接质疑——指标衡量的是覆盖广度，而用户真正感知的是净通过率。

规模化张力：检索缓解 Displacement，却治不了 Osmosis

技能生态的默认演进方向是规模——更多技能、更细覆盖、更强检索。但 Osmosis 的存在使「技能越多越好」不成立：无论检索多么精准，未被检索到的技能描述依然躺在 system prompt 里，污染面随技能库规模持续扩大，而收益增长却受限于任务分布的相关性。退化因此可能先于增益达到饱和。

这与 SkillCorpus 技能生态提纯 所代表的「提纯 + 检索」路线形成清晰对照：提纯提升的是被调用技能的命中质量，直接针对 Displacement；但只要描述文本仍在 prompt 中常驻，Osmosis 那一半退化就不会被消除。二者是互补而非替代——提纯负责流程覆盖，描述精简负责上下文污染，而覆盖率对两者都不是解。

评测设计：三条件对照是唯一能拆出隐藏成本的结构

无 Skill / 仅 Skill 描述 / 完整 Skill 包这三条件，不是方法学上的仪式，而是唯一能把三条退化通道分开的结构性设计。缺少「仅描述」这一条件，评测会把 Osmosis 与「技能未生效」混为一谈：退化被观察到，却归因不到描述上，修复方向自然落到错的地方。

更值得警惕的是测量时点的选择。只在技能被调用（invoked）时才记录的评测，会把 Osmosis 通道整条漏掉——那部分退化恰恰发生在技能从未被调用、因而不会被任何「调用埋点」捕获的路径上。这意味着以调用日志作为唯一数据源的自动化评测管线，会系统性低估回归，且低估幅度与描述文本的信息密度正相关。换言之，这类评测漏掉的不是零头，而是约等于一半的退化面。

「好技能」判据落在流程结构，而非更强的指导

对设计的含义具体且反直觉：技能的价值不在于 Method 写得多详尽，而在于是否把 Grounding（从哪张表、哪一列、什么格式起手）与 Verification（结果条件、符号判断）内建为流程的必经环节。OfficeQA-Pro 的残留错误集中在输入环节，SpreadsheetBench 有 34% 的失败任务逻辑本身正确——两者都不是「指导不够强」，而是流程缺少约束读取、约束核验的骨架。

一个可落地的自检：翻开一份技能文档，如果它对「执行步骤」的描述远比「确认做对了没有」更详细，它就已经落在回归税的高风险区间。这同样解释了 Hermes Agent Skill 互优化实验 一类的自动化技能优化为何必须把验证信号纳入反馈回路——只优化 Method 的迭代会在同一方向上不断加码，从而放大而非缩小回归。

实践建议

评估层面： - 报告效果须从净通过率升级为增益 vs 回归的综合评估 - 分别测试三种条件：无 Skill、仅保留 Skill 描述（隔离渗透效应）、完整 Skill 包

设计层面： - 技能重心从 Method 转向 Grounding + Verification - 好的技能应包含：从哪里开始的定位信息（哪个表、哪一列、什么格式）+ 确认正确性的检查机制（结果条件、符号判断）

与现有工作的关系

不同于 ASSAY/GRASP/RSEA 等通过选择性丢弃/掩码来规避有害技能的方法，Regression Tax 研究聚焦于理解技能为何会导致退化——包括那些即使不被调用也会产生影响的描述渗透效应，这是基于选择/检索的方法无法覆盖的。

关联

→ 原文存档