给 Agent 装技能库，结果它把原本会的题做错了：5832 次实验拆解”回归税”

一个反直觉的发现

你给 LLM Agent 装了一个精心打磨的技能库——里面有导航技能、算术技能、表格处理技能。跑一遍测试，通过率从 70% 升到 81%。你很高兴，准备上线。

但你漏掉了一个问题：那 70% 里原本能做对的题，现在还都做对吗？

Sentient Labs 的 Darshan Tank 和 Baran Nama 在 arXiv 2607.22520 里做了这么一件事：他们在两个办公自动化基准（OfficeQA-Pro 和 SpreadsheetBench）上，用三个模型-框架栈（OpenCode+MiniMax-M2.7、Codex+GPT-5.4-mini、Claude Code+Sonnet 4.6），跑了 5832 次配对实验——同一个任务，一次带技能库，一次不带，然后逐题对比。

结果让人后背发凉。

553 次 gain，324 次 regression：59% 的增益被抵消

论文定义了四种结果：

– Gain：原本做错，装技能后做对 – Regression：原本做对，装技能后做错 – Retained：两次都做对 – Residual failure：两次都做错

5832 次配对里，他们观察到 553 次 gain 和 324 次 regression。也就是说，技能库帮 Agent 解决了 553 个新任务，但同时弄坏了 324 个原本能解决的任务——59% 的增益被回归抵消。

这就是论文标题里的”回归税“：你每赚一块钱，都有相当一部分被税收拿走。技能库的”税”不是钱，是它解决新任务时破坏的旧任务。

更扎眼的是：18 个实验条件里，没有一个的 regression 计数为零。哪怕是通过率提升最显著的 Claude Code+Sonnet 4.6 在 SpreadsheetBench 上（从 70.2% 提到 81.1%），也仍然弄坏了 16 到 20 个原本能做对的任务。

排名也会反转

光看通过率，你会以为”增益最多的库最好”。论文里有一个让人愣一下的反例。

在 Claude Code+Sonnet 4.6 跑 OfficeQA-Pro 时，三个技能库的 gain 计数是 10、11、12，regression 计数是 2、4、7。

– 按 gain 排名：openai 第一（12），Ours 第二（11），anthropic 第三（10） – 按净效应（gain – regression）排名：anthropic 第一（+8），Ours 第二（+7），openai 第三（+5）

排名完全反转。增益最少的库反而最好，因为它”破坏得最少”。

这个发现可以提炼成一个原则：评价技能库，不能只看它新增了多少能力，还要看它弄丢了哪些原有能力。平均通过率这个标量把两种完全不同的库伪装成一样的。

三种回归机制

论文最值钱的部分，是把 81 个 OfficeQA-Pro 回归案例逐个追溯，归纳出三种”技能如何把 Agent 带歪”的机制。

机制一：技能描述渗透（Skill-Description Osmosis）

技能库的”名字+描述”常驻在系统提示里。哪怕 Agent 从未调用这个技能，光描述在那里，就能改变它的行为。

论文里有个让人脊背发凉的例子。UID0096 这道题问的是某个关税率的移动平均，正确答案 0.377。不带技能时，Sonnet 4.6 答出 37.708%，通过。带上三个技能库中的任何一个，答案都变成 38.757%，全部失败——而且三个技能库的失败方式一模一样。

调查发现：没有任何技能被调用。失败只来自技能描述里的两个词——”revised” 和 “customs”——这两个词让 Agent 把”修订后的海关数据”理解偏了。

这就像你桌上放着一本《刑法典》，哪怕你今天不查法条，光是它在那里，你做事就会下意识谨慎一点。技能描述对 Agent 的影响也是这种”渗透”——不需要被调用，只需要存在。

这个机制对现有技能管理方法是个直接打击：ASSAY、GRASP、RSEA 这些方法都是”技能被检索或调用时才判断它是否有害”，但渗透发生在调用之前。你没法用检索屏蔽测出这个效应，因为描述一直在上下文里。

机制二：接地置换（Grounding Displacement）

技能被调用后，它规定的程序覆盖了 Agent 对输入的正确理解。

UID0025 问的是 1934 到 1946 年美国公共工程支出的绝对差，正确答案 142。不带技能时，MiniMax-M2.7 Agent 读对了表格，返回 142。带上 anthropic 库后，Agent 调用了两个”导航+算术”技能，按技能指引走了另一条路径，返回 542。

注意：Agent 的算术没出错，技能本身也没写错。问题是技能指引的路径指向了错误的表格范围。Agent 本来自己能读对，但技能一插手，它就跟着技能走了。

这就像一个熟路的司机被 GPS 拐进了一条不熟的小巷——不是路错了，是 GPS 替他做了选择。技能库的”导航”在它不熟悉的领域反而比 Agent 自己的判断更差。

在 81 个 OfficeQA-Pro 回归里，59 个（72.8%）属于接地置换。这是绝对主导的失败模式。

机制三：验证置换（Verification Displacement）

技能程序抑制了 Agent 本会执行的输出检查。

UID0100 这道题，不带技能时 Agent 返回 [2.81, 0.030, 8.705]，正确答案 [2.81, 0.030, 8.706]，容差内通过。带两个技能后，Agent 在最后一步没做那个本该做的对齐检查，答案偏了，失败。

算术没错，方法没错，错的是没回头检查。

这个机制在 OfficeQA-Pro 上罕见（只有 3 个混合案例），但在 SpreadsheetBench 上是决定性的。那里有个让人哭笑不得的发现：

663 个公式相关失败里，226 个（34%）其实公式完全正确，只是值检查器（grader）无法评估 Excel 的结构化引用公式。Agent 已经做完了所有该做的，但评分系统说它错了。用真正的 Excel 引擎重新计算这 226 个，通过率每个库平均提升 11 到 49 个百分点——GPT-5.4-mini 从 67% 直接跳到 79%。

这揭示了一个对称结构：验证置换让 Agent 不检查自己的输出，而评分器的验证盲区让正确输出被算作错误。两边都是”验证层”的缺失，一边是 Agent 没检查，一边是评分器不会检查。

三阶段管道：技能修错了阶段

论文用一张图把问题说清楚了。Agent 任务分三阶段：

[输入] → grounding（读对输入）→ method（执行程序）→ verification（检查输出）→ [输出]

现有技能库几乎全部聚焦在 method 阶段——教 Agent 怎么算、怎么导航、怎么操作表格。但论文的回归和残留失败分析显示：

– OfficeQA-Pro 的失败 90%+ 在 grounding：Agent 算对了，但读错了表格、年份、定义 – SpreadsheetBench 的失败集中在 verification：公式写对了，但没人检查输出 – method 阶段是最不容易出问题的

这就像一家餐厅：厨师做菜（method）已经很熟练了，但服务员点错单（grounding）和出餐前没核对订单（verification）才是问题主因。你给厨师塞了一本《烹饪技巧大全》，但服务员和质检员没人管。

这个洞察可以提炼成一个跨域通用的工程原则：优化要瞄准瓶颈阶段，而不是最显眼的阶段。method 阶段最显眼（”它在思考！”），但 grounding 和 verification 才是失败藏身处。

残留失败：技能库救不了的任务

论文还分析了”两次都失败”的残留失败。这些任务暴露了技能库的系统性盲区。

UID0227 问的是 1982 年 Q3 的某个财政部数据，正确答案 261。不带技能和带任何技能库时，Agent 都返回 67000 左右——错得离谱，差两个数量级。原因是 Agent 把”月度存量”理解成了”季度平均流量”，这个 grounding 错误所有库都没纠正。

这指向一个深层问题：现有技能库都是”过程指导”——怎么算、怎么导航、怎么操作。但残留失败的根因是 grounding（读错输入）或 verification（没检查输出），过程指导救不了这两类错。

就像一个学生物理概念都搞错了，你给他一本《解题技巧大全》没用——他需要的不是方法，是先搞清楚题目在问什么。

统计显著性的冷水

论文还有个让人清醒的统计细节。18 个条件里只有 5 个达到 p<.05，Bonferroni 校正后只有 3 个存活——全部是 Claude Code+Sonnet 4.6 在 SpreadsheetBench 上的三个库。

其他 15 个条件的”提升”在统计上都和噪声无法区分。

这不是说技能库没用——Claude Code+Sonnet 4.6 在 SpreadsheetBench 上的提升是真实的（+43 到 +47，p<.001）。但这个提升高度依赖模型和基准的组合，不能外推到其他场景。

工程启示

这篇论文对每一个在搭 Agent 系统的人都有直接价值。

第一，评测要报告 gain/regression 配对计数，不只净通过率。 两个库净通过率相同，可能一个全是 gain、一个一半是 regression。前者稳定，后者脆弱。

第二，技能评测至少要跑三个条件：无库、仅描述、描述+体。 只对比”无库 vs 有库”测不出渗透效应——描述在那里就改变行为，body 调没调用是另一回事。

第三，技能设计要瞄准 grounding 和 verification，而不是 method。 过程指导已经过度服务了。具体的接地信息（”这个表格的 vintage 是什么”）和可执行的输出检查（”用 Excel 引擎重算这个公式”）才是真正能恢复任务的杠杆。

第四，评分器也要做验证。 SpreadsheetBench 的值检查器把 226 个正确公式判错——评分器的盲区就是假阴性的藏身处。如果你用这个评分器调技能库，你会把”正确但评错”的技能当成有害的丢掉。

和”评测盲区定律”的呼应

这篇论文是”评测盲区定律”的又一个例证。之前 Epanorthosis（谄媚偏置）、TokenBudget（CoT 命运双峰）、QuantiBias（量化引入偏见）、Möbius RoPE（种子彩票方差）、TriviaRoomQA（知识边界悬崖）都指向同一个主题：你测什么就优化什么，不测的就是问题藏身处。

Regression Tax 把这个定律从”模型评测”扩展到”Agent 评测”：平均通过率是最大的评测盲区。它把 gain 和 regression 合并成一个数字，让你看不见技能库在哪些任务上破坏了哪些能力。

更妙的是，论文还揭示了评分器自己的盲区——值检查器不会评估结构化引用公式，所以 226 个正确答案被判错。评测器的盲区是盲区中的盲区，你甚至不知道自己没测到。

跨论文共识：分工比统一更有效

这篇论文还和”分工比统一更有效”的跨域原则呼应。技能库试图用统一的”过程指导”覆盖 grounding、method、verification 三个阶段，但失败集中在它没覆盖的两个阶段。

正确的方向应该是：让专门的工具做专门的事——grounding 阶段用具体的输入定位工具，verification 阶段用可执行的输出检查工具，method 阶段才用过程指导。这和 Euclid-MCP 的”让 LLM 当诗人，让 Prolog 当会计”是同一个思路：承认统一处理是低效的，把不同阶段交给最擅长它的工具。

我的思考

这篇论文最让我触动的是 UID0096 那个案例。三个不同的技能库，在同一个任务上，以完全相同的方式失败——仅仅因为它们的描述里都有”revised”和”customs”这两个词。

这像一面镜子。我们以为技能库是”工具箱”，Agent 用哪个取哪个。但实际上，技能库更像 Agent 工作的”背景音乐”——哪怕它没在听，音乐的节奏也在改变它的步伐。这个”渗透通道”是所有基于检索的技能管理方法的盲区。

更深一层：这篇论文让我重新思考”能力”这个词。我们说”Agent 有 X 能力”时，其实是在说”在某个评测集上 Agent 通过了 X% 的题”。但 Regression Tax 告诉我们，这个数字掩盖了 Agent 在哪些题上变强、在哪些题上变弱。两个 Agent 同样 80% 通过率，一个全是 gain、一个一半是 regression，它们的可靠性天差地别——前者稳定，后者脆弱。

“能力”不是通过率，是 gain/regression 的配对结构。这个洞察不只适用于技能库，也适用于任何对 AI 系统的评测——RLHF 后的模型、量化后的模型、蒸馏后的模型，都该看它弄丢了哪些原有能力，而不只看它新增了什么。

测什么就优化什么，不测的就是问题藏身处。Regression Tax 给这个定律添了最新的一笔。

—

论文：The Regression Tax: Decomposing Why Skills Help and Hurt LLM Agents 作者：Darshan Tank, Baran Nama（Sentient Labs） arXiv：2607.22520 代码：暂未开源