给 Agent 装技能库，为什么它反而把原本会的题做错了？
一个反直觉的发现
想象你雇了一个能干的助手，他擅长处理各种办公任务。你觉得他还能更厉害，于是给他配了一本"标准操作手册"——各种任务的最佳实践技能库。结果呢？他的平均成功率确实提高了。但如果你逐个任务检查，会发现一个诡异的现象：有些他原本能做对的题，装了技能库之后反而做错了。
这不是假设。Sentient Labs 的 Darshan Tank 和 Baran Nama 在 2026 年 7 月发布的论文《The Regression Tax》中，用 5832 次实验揭示了这个被平均数掩盖的暗面。
5832 次实验拆解：59% 的增益被"回归税"吃掉
研究者做了件此前没人系统做过的事：不只看"装了技能库后平均成功率提升多少"，而是逐个任务对比"装了技能库前能解决、装了之后反而失败"的案例。他们把这个现象叫做回归（Regression）——技能让 Agent 变差了。
实验跨越两个办公自动化基准（SpreadsheetBench和某办公任务基准）和三个模型工具链，共 5832 次任务-条件运行。结果触目惊心：
- 553 次"增益"：原本失败、装了技能后解决
- 324 次"回归"：原本解决、装了技能后失败
- 回归抵消了 59% 的增益
三种"隐形杀手"：技能如何在你没注意时让 Agent 变差
研究者深入分析执行轨迹后，识别出三种回归机制。这三种机制的阴险之处在于：它们大多发生在技能"没被调用"的时候。
杀手一：技能描述渗透（Skill-Description Osmosis）
技能库放在系统提示词里，Agent 每一步都能看到所有技能的描述。问题是，仅仅看到技能描述，就足以改变 Agent 的行为——哪怕这个技能从未被调用。
类比：你给新员工一本厚厚的操作手册放在他桌上。他从头到尾没翻开过，但手册的存在让他下意识地觉得自己应该按"手册风格"做事。结果他原本灵活的处理方式变得僵化了。技能描述像一种气味，弥漫在上下文里，悄悄改变 Agent 的决策倾向。
杀手二：接地置换（Grounding Displacement）
技能规定的操作流程，覆盖了 Agent 原本解读输入的方式。Agent 不再仔细"读题"，而是按技能流程预设的方式去理解输入——哪怕这种理解是错的。
论文附录里有个精彩案例：Agent 面对一张包含图表的电子表格，技能流程预设了"先读图表标题"的步骤。但这张表的标题位置有歧义，Agent 原本能正确识别，却因为技能流程的暗示，把错误的单元格当成了标题，导致后续全盘皆错。技能不是在方法层出错，而是在更早的"读题"层就偏了。
杀手三：验证置换（Verification Displacement）
技能流程抑制了 Agent 本应对输出执行的检查。Agent 原本会回头验证"这个结果合理吗？"，但技能流程给了它一种"流程走完了就是对的"的错觉。
这三种机制的共同特征是：它们都不是技能"做了什么"导致的，而是技能"存在"本身导致的。 传统的"检测有害技能然后删除"的方法对此无能为力，因为技能根本没被调用——你没法删除一个没被调用的技能。
真正的瓶颈不在"方法"，而在"接地"和"验证"
论文最深刻的发现来自对持续失败（有技能和无技能都失败的任务）的分析。研究者把 Agent 任务分为三个阶段：
1. 接地（Grounding）：正确读取和解读输入 2. 方法（Method）：执行操作流程 3. 验证（Verification）：检查输出是否合理
现有技能库几乎全部聚焦于"方法"阶段——教 Agent 怎么做。但执行轨迹分析显示，持续失败的主要来源是接地和验证，而不是方法。技能库在错误的层面使劲。
这就像一个学生考试不及格，老师以为是他"解题方法"不对，给他塞了一堆方法手册。但实际上他丢分的原因是"读题读错了"和"算完没检查"。方法手册不仅没帮他，还可能让他更不重视读题和检查。
研究者做了件漂亮的事：他们重新评分了 226 个被原始评分器误判的任务（原评分器自己也有接地问题），发现许多"回归"和"持续失败"其实可以通过更好的接地和验证来恢复。
这对 Agent 系统设计意味着什么
1. 评估技能不能只看平均分，必须拆解净效应
一个技能让 Agent 在 10 个任务上提升 5 个、在 5 个任务上回归 5 个，平均分是"提升 0"——但这个"0"掩盖了完全不同的两种失败模式。论文呼吁：技能评估必须把净效应分解为增益和回归，而不是只看总体改进。
2. 技能描述本身就是行为干预
"技能描述渗透"的发现意味着，技能库的设计不只是"写好技能内容"，技能的描述文本本身就是一种行为干预。一个从未被调用的技能，仅凭描述就能改变 Agent 行为——这要求技能描述的设计要像设计 prompt 一样谨慎。
3. Agent 可靠性的瓶颈在接地和验证，不在方法
这是论文最反直觉的结论：可靠性更多取决于接地和验证，而非程序性技能选择。 现有技能库过度投资于"教 Agent 怎么做"，却低估了"帮 Agent 读对题"和"帮 Agent 查出错"。
跨域类比：为什么"加东西"反而让系统变差
Regression Tax 不是 Agent 领域独有的现象。这是一个更普遍的原理：给复杂系统添加优化组件，可能因为干扰原有流程而产生负效应。
- 软件工程：给代码库加抽象层，有时让简单逻辑变慢——抽象的"存在本身"就有成本
- 组织管理：给团队加流程规范，有时让原本灵活的处理变僵化——规范的存在改变了行为，哪怕没被严格执行
- 教育：给学生加解题模板，有时让原本能做对的题做错——模板暗示了错误的解题路径
结语
论文标题里的"Tax"（税）是个精准的比喻。技能库不是免费的——它有税。这个税不是调用技能时付的，而是技能"存在"本身就在收的。5832 次实验告诉我们：最好的技能库不是增益最多的，而是交税最少的。
更深一层的启示是：Agent 系统的可靠性瓶颈不在"会不会做"，而在"读得对不对"和"查得严不严"。这和人类执行复杂任务的瓶颈是同构的——大多数错误不是不会做，而是没看清题目、没检查结果。技能库应该像好老师一样，帮 Agent 在它真正薄弱的环节（接地和验证）下功夫，而不是在它已经做得不错的环节（方法）继续加码。
论文链接：https://arxiv.org/abs/2607.22520 （论文未开源代码，分析基于论文原文）