中 #LLM Agent#Reasoning

Regression Tax（回归税）：给 LLM Agent 加 Skill 为什么既能帮忙又能拆台

笔记日期： 2026-07-27 笔记作者： Zhongzhu Zhou 阅读论文： The Regression Tax: Decomposing Why Skills Help — and Hurt — LLM Agents 论文作者： Darshan Tank, Baran Nama（Sentient Labs） arXiv： 2607.22520v1，2026-07-24 发表状态： arXiv 预印本（cs.AI）

0. 为什么值得认真读这篇

过去一年里我看到的所有”Agent Skill”体系——Anthropic 的 skill-creator、OpenAI 的 Codex skill 指南，以及一堆研究系统比如 Trace2Skill、EvoSkill、SkillOpt——几乎都在汇报同一种数字：加了某个 skill 之后平均任务成功率提升了 X 个点。这就是它们全部的评测叙事。这篇论文认为，这个叙事严重不完整，而一旦你看清楚为什么，你会很难再对今年读到的其它”加了个脚手架，准确率就上去了”的论文视而不见。

问题一句话讲清楚：一个聚合的通过率差值，根本没法告诉你这个 skill 到底是修好了本来就失败的任务，还是拆坏了本来能通过的任务——而这篇论文发现，这两件事其实是同时、大规模地在发生。论文让同一个 agent、同一批任务、除了 skill 库开/关之外别的完全不变，跑了 5832 次配对运行。结果是：skill 库总共”救活”了 553 个任务-条件组合，同时又”打死”了 324 个组合（相对于另一批本来能通过的任务而言的回归）——也就是说，每个 skill 库的毛收益里，超过一半会被新引入的失败悄悄抵消。一个在榜单上看起来干净利落地 +5 分的 skill 库，真实情况可能是”新解决了 15 个，新破坏了 10 个”，而这个分解在你只盯着边际通过率的时候是完全不可见的——你必须去看配对的、逐任务的状态迁移。

真正让这篇论文超越”又一篇关于提示工程的负面结果”的地方，是作者没有停在”skill 有时候会帮倒忙”这句话上。他们建立了一套标注体系——真正去读配对的执行轨迹，而不只是盯着数字——把每一次回归的原因归到三种机制之一：（1）skill 描述渗透（osmosis），仅仅因为一个 skill 的名字和描述常驻在系统提示里，即便它的正文从未被读取，也能改变行为；（2）grounding 位移（grounding displacement），被调用的 skill 的流程覆盖了对输入的正确解读；（3）verification 位移（verification displacement），被调用的 skill 压制了裸 agent 本来会做的自我核查。这三种机制中每一种都是可证伪的、可以在对话记录里追溯的，这在”agent 行为”相关的论断里非常罕见。论文对自己统计结论的脆弱性也很坦诚——经过 18 次比较的 Bonferroni 校正后，原本 5 个”显著”的 skill 库效应里只剩 3 个存活——这种自我怀疑反而让存活下来的结论更可信，而不是更可疑。

如果你在构建、评测或上线”agent skill”、“工具使用指南”、“系统提示当作操作手册”，或者这一大类正在快速膨胀的、以上下文形式存在的程序性脚手架，这篇论文给了你一套词汇和一套测量方法，用来发现一种你几乎肯定已经在制造、却完全没有测量的失败模式。

1. 前置知识

1.1 “Agent Skill” 到底是什么

在当前这一波 agent 工具（Claude Code、Codex/OpenCode，以及类似的命令行驱动的编程/办公 agent）里，一个skill 是一个小巧、结构化的自然语言包，被加载进 agent 的上下文里，用来引导它完成某一类任务。具体来说它包含：

  • 一个名字和简短的描述（通常一两句话：“当任务涉及 X 的时候使用这个 skill”），它直接放在系统提示或工具列表里，这样 agent 才能判断要不要调用它；
  • 一个正文（body）：更长的自然语言文档，包含一步步的操作指引，有时候还捆绑了辅助代码或命令行片段，只有当 agent 决定调用/读取这个 skill 的时候，正文才会被拉进上下文。

这种”描述常驻、正文按需加载”的两层结构，是这篇论文全部论证的关键设计细节。现有大多数评测和防御方法（屏蔽某个 skill、对 skill 做检索门控、给 skill 算一个”回归预算”）只对正文做推理：它们问的是”如果这个 skill 的正文不存在，结果会不会变？“它们完全看不到一种纯粹来自”描述始终在上下文里可见”的效应，因为它们从来不跑那种描述在场但正文从未被调用的对照实验。这个盲区，正是论文第一种机制（osmosis）栖身的地方。

1.2 用到的两个办公自动化基准

论文特意选了两个既不是玩具任务、也不是对抗性设计的基准——它们是任何一个办公室职员都能认出来的实用任务，更重要的是，这两个基准可能出现的错误类型不同，这让论文能干净地把机制拆开：

  • OfficeQA-Pro：针对真实美国财政部财务 PDF 的问答——抽取某个数字或定义、对比不同年份/报告的数值、解读表格、计算比率或百分比变化、综合多篇文档的信息。答案是一个单一数字，按大约 1% 的容差与标准答案比对。因为答案是单一带容差的标量，这里的”回归”是无歧义的：数字对不对一目了然，而且轨迹几乎总能显示出 agent 到底读错了哪个输入，或者哪一步算术出了问题。
  • SpreadsheetBench：真实的 Excel 论坛表格编辑任务——定位/筛选数据、写公式、填充或更新单元格、排序、去重、跨表操作。单元格级任务只涉及指定区域；表级任务涉及更大的区域。评分方式是比较目标单元格的数值，对 agent 留下的任何公式，都会用一个已知有盲区的评分引擎重新计算——它无法重新计算像 AGGREGATE 这样的现代 Excel 函数，或者结构化/表格引用。这个评分细节后面会造成巨大影响（见第 5 节）。

1.3 配对比较与 McNemar 检验

方法论的骨架很简单但很严谨：对同一个任务、使用同一个模型和同一套工具，跑两种条件——无 skill（“none”）和带 skill 库（“treatment”）——并记录两种条件下的通过/失败。因为两次运行共享任务、模型和工具，任何结果上的差异（除去后面会讨论的运行间随机性）都可以归因于 skill 库的存在。这是一种匹配配对设计，而配对二元结果正确的显著性检验是McNemar 检验：它忽略两次运行结果一致的任务（都通过或都失败），只检验那些不一致的配对——从通过变失败，或从失败变通过的任务。设 bb 为通过→失败的翻转数（回归），cc 为失败→通过的翻转数（收益），零假设是 b=cb=c（skill 库没有净方向性效应），精确双侧 McNemar 检验从这 b+cb+c 个不一致配对在 p=0.5p=0.5 下的二项分布计算 p 值。这在这里正是正确的工具，因为论文的核心论点正是：即使净效应 c−bc-b（也就是聚合通过率差值汇报的那个数）看起来平平，甚至美化了一个实际上正在用大量正确答案换少数新答案的 skill 库，bb 和 cc 也可能都很大。

1.4 多重比较校正（Bonferroni）

一共有 18 组独立的”skill 库 vs. 无 skill”比较（3 套工具栈 × 2 个基准 × 3 个 skill 库），如果每次都用名义上的 α=0.05\alpha=0.05 去检验，整个比较家族的假阳性率会远高于 5%。Bonferroni 校正是最简单的修正方式：要把整体误报率控制在 α\alpha 以内，每个单独检验需要达到 α/m\alpha/m，mm 是比较次数——这里是 0.05/18≈0.00280.05/18\approx0.0028。这个方法偏保守（当各检验之间相关时可能低估真实效应），但当你不想在重叠数据上跑的一组检验里挑好看的结果时，这正是应该先做的事，而这篇论文是拿这个工具来审视自己，而不是挑几个”显著”的格子来讲故事。

2. 架构 / 实验设计概览

整篇研究其实更像是一套实验设计，而不是一套系统架构，所以第一张要内化的图，是四种条件与三套模型-工具栈如何组合成这 5832 次运行。

flowchart TB
    subgraph Stacks["3 套模型-工具栈"]
        S1["OpenCode<br/>+ MiniMax-M2.7"]
        S2["Codex<br/>+ GPT-5.4-mini"]
        S3["Claude Code<br/>+ Claude Sonnet 4.6"]
    end
    subgraph Benchmarks["2 个基准"]
        B1["OfficeQA-Pro<br/>N=94 任务"]
        B2["SpreadsheetBench<br/>N=392 任务"]
    end
    subgraph Conditions["每个 (工具栈, 基准) 下 4 种条件"]
        C0["none<br/>（无 skill）"]
        C1["anthropic 库"]
        C2["openai 库"]
        C3["Ours 库"]
    end
    Stacks --> Benchmarks
    Benchmarks --> Conditions
    Conditions --> Runs["486 任务 x 4 条件 x 3 工具栈<br/>= 5832 次配对任务-条件运行"]

图 1（对应论文 Fig.1 的架构配图）：完整的全因子设计。这个笛卡尔积里的每一格都只跑一次，而每个 treatment 条件都在自己的 (工具栈, 基准) 格子里与同一个 none 基线配对——正是这种配对关系让 McNemar 检验成立。

三套模型-工具栈是刻意异构的——每种 agent 框架（OpenCode/Codex/Claude Code）都绑定了一个不同的底层模型（MiniMax-M2.7/GPT-5.4-mini/Claude Sonnet 4.6）。这是论文自己坦承的一个局限（模型和工具栈是混杂的——你没法问”这是模型的问题还是工具栈的问题？”），但它换来了一定的普适性：任何能在全部三套工具栈上都成立的模式，就不太可能只是某一个特定 agent 脚手架或某一个特定模型怪癖的产物。

2.1 常驻的描述 vs. 按需加载的正文

这是让整套机制分类学成为可能的架构细节，值得单独画出来：

flowchart LR
    subgraph SystemPrompt["Agent 的系统提示 / 工具列表（每一轮都在）"]
        D1["Skill A：名字 + 描述"]
        D2["Skill B：名字 + 描述"]
        D3["Skill C：名字 + 描述"]
    end
    subgraph ConditionalLoad["只有 agent 调用了才会加载"]
        Body1["Skill A：完整正文<br/>（流程、代码、示例）"]
    end
    D1 -. "agent 决定调用" .-> Body1
    D2 -. "本任务从未被调用" .-> X["正文从未进入上下文"]

图 2（架构细节）：描述在每一轮对话中都无条件存在于上下文里；正文则被 agent 运行时的调用决策所门控。任何只测量”如果我移除/屏蔽一个 skill 的正文，结果会怎样变化”的方法，都对纯粹由描述常驻上下文所产生的效应视而不见——这正是第 4 节里的 osmosis 通道。

3. 方法：如何构建 skill 库、定义结果、对回归分类

3.1 四阶段 skill 库生产流水线

为了从同一份底层证据出发得到多个独立撰写的 skill 库（这样库与库之间的差异反映的是撰写风格，而不是观察到的失败信号不同），论文对每套工具栈只跑一次受控的四阶段流水线：

flowchart LR
    A["阶段 1：基线运行<br/>agent 在无 skill 下执行，<br/>记录轨迹"] --> B["阶段 2：分析员<br/>阅读轨迹，<br/>提取反复出现的失败信号"]
    B --> C["阶段 3：元 skill 创建者<br/>（anthropic / openai / Ours）<br/>把信号变成 skill"]
    C --> D["阶段 4：评测运行<br/>skill 加入上下文后<br/>重跑基准"]

图 3（流水线）：分析员每套工具栈只运行一次，所以三个元 skill 创建者都从同一批失败信号出发——三个最终库之间唯一的差异，是每个创建者如何把共享信号变成 skill 文本。

流水线的编号伪代码：

1.  baseline_trajectories = []
2.  for task in benchmark.tasks:
3.      trace = agent.run(task, skills=None)
4.      baseline_trajectories.append(trace)
5.  failure_signals = analyst.extract_recurring_causes(baseline_trajectories)
6.  for creator in [anthropic_creator, openai_creator, ours_creator]:
7.      library = []
8.      for signal in failure_signals:
9.          skill = creator.author_skill(signal)     # 各创建者做法不同，见 3.2
10.         library.append(skill)
11.     evaluation_traces = []
12.     for task in benchmark.tasks:
13.         trace = agent.run(task, skills=library)
14.         evaluation_traces.append(trace)
15.     store(creator, library, evaluation_traces)

这套设计强制执行的关键不变量是**“只有 skill 库在变”**：在每个 (工具栈, 基准) 格子内，任务集合、模型和工具在四种条件下都保持不变，所以任何通过/失败的差异都可以归因于当前上下文中是哪一个 skill 库（或者没有）。

3.2 为什么同样的信号，三个创建者做出三种不同的库

这是论文里明确测量”撰写流程本身、而不只是 skill 内容”如何影响结果的地方，值得展开讲清楚——为什么这样做、显而易见的替代方案是什么、各自在哪里会失效：

  • anthropic 创建者遵循 Claude Code 的 skill 撰写指南，是测量驱动的：起草一个 skill → 在测试提示上有/无该 skill 各跑一次 agent → 给两次运行打分 → 根据测得的差异重写 → 重复直到该 skill 在自己的基准循环上确实有帮助。为什么它有效：它直接优化你最终关心的东西（这个 skill 到底有没有帮助），所以一个在自己的内部基线上都过不了关的 skill，在进入评测运行之前就会被淘汰。显而易见的替代方案是完全相信 skill 作者的直觉，跳过测量循环——更便宜，但对这篇论文研究的这类回归完全是盲的。它会在哪里失效：内部基准循环只在少量精心挑选的提示上测试每个 skill，样本规模比完整的下游评测小得多，也可能不具代表性；一个 skill 可以通过自己的内部检查，却在没被内部循环测过的下游任务上以不同方式发生回归。
  • openai 创建者遵循 Codex 的 skill 指南，是单次通过的：搭建 skill 文件框架，用校验器检查结构，直接产出——没有评测循环，没有对效果的测量。为什么它有吸引力：速度快，不需要基准测试基础设施，这也更贴近大多数实践者实际撰写 skill 的方式（写一次就发布）。显而易见的替代方案是 anthropic 式的测量循环；权衡在于撰写成本与盲区风险之间。它会在哪里失效：因为没有测得的反馈，一个 skill 的文本只会被检查内部结构是否合法，从不检查行为效果，而这正是论文所展示的、在某些工具栈上导致回归数不成比例地更多的原因（表 2：openai 在 SpreadsheetBench 上的净效应始终是三者中最弱或并列最弱的）。
  • “Ours” 创建者（论文自己的贡献）加入了先查重后创建（在库里搜索类似的已有 skill 并更新它，而不是新建重复项）和一个自我批判环节，会依据一份清单重写草稿，并且只使用标准库辅助工具，因此可以跨工具栈使用。为什么它有效：先查重后创建直接针对一种失效模式——skill 数量泛滥、彼此近似重复甚至可能冲突——这是另外两个创建者没有明确防范的问题；自我批判环节是一种廉价的内部一致性检查，不需要完整的基准评测循环。显而易见的替代方案是上述两种极端之一；Ours 位于两者之间（比完整测量循环便宜，比单次通过更受审查）。它会在哪里失效：自我批判依据清单，终究还是模型在检查自己的作业——它无法访问真实结果，所以抓不住那种读起来内部自洽、但在真实任务上行为错误的 skill（这一点在第 5.3 节 UID0025 案例中可见：Ours 库重新定位的公式仍然把单元格区域锚定错了，没能恢复 anthropic 库能恢复的答案）。

论文明确说明它不对这三个创建者排名，也没有任何结论依赖于某个 skill 是谁写的——它们的存在纯粹是为了从同一份证据里生成多个库，让这项研究不至于只是在报告某一位作者写作风格的伪影。

3.3 结果分类学：每个任务四个桶

每个任务，在其 none 运行和 treatment 运行之间比较，恰好落入以下四个桶之一：

结果none → treatment含义
Gain（收益）失败 → 通过该库修好了裸 agent 做错的事情
Regression（回归）通过 → 失败该库破坏了裸 agent 本来做对的事情
Residual failure（残留失败）失败 → 失败无论有没有 skill，agent 都没解决
Retained（保留）通过 → 通过该库没有影响裸 agent 已经解决的任务
flowchart TB
    subgraph WithoutSkills["无 skill"]
        P0["通过"]
        F0["失败"]
    end
    subgraph WithSkills["带 skill 库"]
        P1a["通过"]
        F1a["失败"]
        P1b["通过"]
        F1b["失败"]
    end
    P0 -->|"依然正确"| P1a["Retained"]
    P0 -->|"被破坏"| F1a["Regression"]
    F0 -->|"被修好"| P1b["Gain"]
    F0 -->|"依然错误"| F1b["Residual failure"]

图 4（数学/分类学可视化）：这张四向通过/失败迁移表是论文里每一个数字的底层支撑。普通评测报告的聚合通过率差值，把整个 2×2 结构压缩成一个标量 c−bc-b（收益减回归），这正是为什么两个净效应完全相同的 skill 库，其 Gain/Regression 分解可能天差地别（见第 6 节）。

3.4 回归的机制分类流程

对每一次回归（none 下通过、treatment 下失败），作者阅读配对的执行轨迹，用以下判定流程赋予一个标签：

1.  阅读该任务的 `none` 轨迹和 treatment 轨迹
2.  treatment 运行中是否有任何 skill 的正文被调用或读取？
3.  如果没有被调用：
4.      检查是否存在"影响证据"：
5.          (a) 同一个任务在 >=2 个独立撰写的库下是否以相同方式翻转？
6.          (b) 行为变化是否与某个 skill **描述**（而非正文，因为正文从未被读取）中出现的词汇相符？
7.      如果 (a) 或 (b) 成立：标签 = OSMOSIS（渗透）
8.      否则：标签 = OTHER（仅存在性翻转，无影响证据——视为噪声）
9.  如果被调用或读取过：
10.     定位 treatment 轨迹与（正确的）`none` 轨迹发生分歧的第一个阶段
             （读取输入 vs. 核查输出）
11.     如果分歧发生在**输入阶段**（读错了表格/范围/实体/定义/年份）：
12.         标签 = GROUNDING DISPLACEMENT（Grounding 位移）
13.     如果分歧发生在**输出阶段**（基线本会做的核查被压制或替换）：
14.         标签 = VERIFICATION DISPLACEMENT（Verification 位移）
15.     如果分歧横跨两个阶段：标签 = GROUNDING + VERIFICATION

这套流程里有两处设计选择值得专门讨论：

  • 要求跨库复现或描述词汇匹配才能标记 osmosis（第 5–8 步）是一个刻意设置的高门槛。为什么：单个库在单次运行中翻转单个任务，完全可能只是普通的 LLM 采样方差，因为论文并没有跨随机种子做重复实验（第 6.2 节明确指出了这个局限）。要求同一个任务在多个独立撰写的库下以相同方式翻转——或者要求模型自己的推理轨迹呼应某个 skill 描述中的词汇——是一个廉价但真实的证伪测试：如果描述本身不是真正的因果原因，那么三个独立撰写的描述恰好把同一个错误答案推向同一个方向，这是一个低概率的巧合。替代方案——把每一个仅存在性翻转都标为 osmosis——会用纯噪声夸大这种机制的表观频率；论文明确保留了一个”Other”桶来装这些未经证实的翻转（OfficeQA-Pro 的 81 个回归里有 4 个）。
  • 全部标签由一位作者赋予（第 5 节直接说明）。这是整套分类学中最诚实、也最真实存在的弱点：没有标注者间一致性统计数据，而单个标注者对”这个证据算不算影响”的判断阈值，恰恰是最需要第二个盲标注者来验证的那类主观判断。论文在自己的局限性部分对此很坦诚，我在下面第 9 节会再次提出，因为这是在信任机制比例（相对于每种机制客观存在这件事本身，附录 B–C 的案例已经让后者很难被质疑）之前，我最希望看到被修复的一件事。

4. 核心统计分解，推导过程

4.1 净效应恰好等于收益减回归

设 NN 为某个基准的任务数，cc 为 Gain 迁移数（失败→通过），bb 为 Regression 迁移数（通过→失败），rr 为残留失败数，tt 为保留数。根据构造：

N=c+b+r+t(2)N = c + b + r + t \tag{2}

无 skill 时的通过率是 p0=t+bNp_0 = \dfrac{t+b}{N}（none 下所有通过的任务：保留的加上之后会回归的）。带 skill 时的通过率是 p1=t+cNp_1 = \dfrac{t+c}{N}（treatment 下所有通过的任务：保留的加上新收益）。配对差值是：

Δ=p1−p0=(t+c)−(t+b)N=c−bN(3)\Delta = p_1 - p_0 = \frac{(t+c)-(t+b)}{N} = \frac{c-b}{N} \tag{3}

这个推导正是论文核心方法论观点的支撑：聚合的通过率差值本身就已经是一个归一化后的净效应——它在数学上恒等于 (c−b)/N(c-b)/N，所以每当它单独被汇报、而不带上配对的原始计数时，就必然丢弃了 cc 和 bb 各自的量级信息。两个库可以有完全相同的 Δ\Delta，却对应截然不同的 (c,b)(c,b) 组合——比如 (c,b)=(10,2)(c,b)=(10,2) 和 (c,b)=(50,42)(c,b)=(50,42) 都给出 +8+8 的净效应，但后者是在动用五倍于前者的任务总体来达到这个数字的，如果你在乎的是可靠性而不是平均改进，这个差异非常重要。这正是第 5 节里 Claude Code · sonnet-4.6 / OfficeQA-Pro 上 anthropic 与 openai 之间的对比：收益分别是 10 和 12，但回归分别是 2 和 7，仅按收益排名（openai 第一）在按净效应排名时会反转（anthropic 第一）。

4.2 McNemar 精确检验，完整推演

对每一个 treatment-vs-none 配对，我们只需要不一致计数 bb（通过→失败）和 cc（失败→通过）；一致的任务（两次都通过或都失败）不携带方向性效应的信息，会被排除出检验。在”该库没有系统性方向效应”的零假设下，每个不一致的任务在”是收益”和”是回归”之间等价于一次公平掷硬币，即 b∼Binomial(b+c,0.5)b\sim\text{Binomial}(b+c,0.5)（在 H0H_0 下）。精确双侧 p 值为：

p=2×min⁡(∑k=0b(b+ck)0.5b+c,  ∑k=bb+c(b+ck)0.5b+c)(4)p = 2\times\min\left(\sum_{k=0}^{b}\binom{b+c}{k}0.5^{b+c},\;\sum_{k=b}^{b+c}\binom{b+c}{k}0.5^{b+c}\right) \tag{4}

上限截断为 1。直觉理解：如果 bb 和 cc 接近相等（不一致任务两个方向都不少），那观测到的分布看起来就像公平硬币，pp 值就会保持很大——该库对很多任务有影响，但没有可靠的方向性偏好朝着改进的方向。只有当分布明显不对称时（比如 Claude Code·sonnet-4.6/SpreadsheetBench 上 anthropic 库的 b=16,c=59b=16,c=59），精确二项分布的尾部才会收缩到显著水平附近。这就是为什么一个库可以大量改变任务的结果（涨的跌的都有），却仍然过不了显著性检验——被检验的是方向，不是变化的体量。

4.3 配对差值的 95% Newcombe 置信区间

除了 p 值之外，论文还给出了 Δ=(c−b)/N\Delta=(c-b)/N 的 Newcombe 型置信区间，它考虑了 p0p_0 和 p1p_1 这两个比例的配对（非独立）结构，而不是把它们当成两个不相关的二项样本处理（那样会低估配对设计本来能提供的精度）。实践上的解读是：当这个区间跨过零时（表 2 中 18 个条件里有 13 个如此），观测到的净效应在统计上无法与纯粹的配对抽样噪声区分——论文很小心地把这个提醒放在主结果表的每一行里，而不是只汇报点估计。

4.4 对 18 次比较的 Bonferroni 校正

在 m=18m=18 次同时进行的 McNemar 检验下，校正后的显著性阈值是 α/m=0.05/18≈0.0028\alpha/m=0.05/18\approx0.0028。在 5 个未校正下 p<0.05p<0.05 的条件里，只有 3 个能通过校正后的门槛——全部是 Claude Code·sonnet-4.6/SpreadsheetBench 这一组（三个库全部 p<.001p<.001，即便校正后依然成立）。另外两个名义上显著的格子（Claude Code·sonnet-4.6/OfficeQA-Pro 的 anthropic 库，p=.039p=.039；OpenCode·minimax-m2.7/SpreadsheetBench 的 anthropic 库，p=.008p=.008）在校正后不再显著（校正后 p=0.69p=0.69 和 0.140.14）。这是论文拿自己的统计工具，反过来审视自己最好看的几个数字，也是整个结果部分最重要的一个数字：在尝试证明”加一个 skill 库能可靠地带来帮助”的 18 次尝试中，只有 3 次——而且局限于一个工具栈和一个基准——站得住脚。

4.5 为什么不能直接用卡方检验代替 McNemar 检验

一个自然而然会问的问题是：既然这里本质上是在比较两个比例 p0p_0 和 p1p_1，为什么不直接用普通的两样本卡方检验（即把 p0p_0 和 p1p_1 当成来自两个独立人群的估计）？答案在于这里的两个比例不是独立的——它们来自同一批任务在两种条件下的重复测量，因此两者之间存在强相关性（一个本来就容易通过的任务，在两种条件下都更容易通过）。如果忽略这种相关性、把两个比例当成独立样本去做卡方检验或普通的两比例 zz 检验，会严重高估方差，从而让置信区间变得比实际更宽、把本来存在的真实效应掩盖掉。相比之下，配对设计下的 McNemar 检验只看不一致的那一部分任务，直接丢弃了一致部分（都通过或都失败）不携带方向信息这个事实，从而充分利用了配对设计本躯带来的统计效力。这也是为什么论文会强调：“因为处理组与无 skill 基线是配对的，我们用精确的 McNemar 检验来检验净效应”——这不仅仅是一个术语选择，而是直接影响到哪些效应能被判定为统计上可靠的关键选择。

4.6 代入具体数字：一个完整的 McNemar 计算例子

为了让公式 (4) 不只停留在抽象符号层面，值得实际代入一组论文中的真实数字。取 Claude Code·sonnet-4.6 在 OfficeQA-Pro 上的 anthropic 库：c=10c=10（收益），b=2b=2（回归），不一致总数 b+c=12b+c=12。在零假设 H0:b=cH_0: b=c 下，这 12 个不一致任务中每一个都是公平掉硬币，我们想知道“12 次掉硬币里最多只有 2 次正面（即回归）”这件事有多不寻常。将 b=2,b+c=12b=2, b+c=12 代入公式 (4)：

p=2×∑k=02(12k)0.512=2×((120)+(121)+(122))×0.512(5)p = 2 \times \sum_{k=0}^{2} \binom{12}{k} 0.5^{12} = 2 \times \left(\binom{12}{0}+\binom{12}{1}+\binom{12}{2}\right) \times 0.5^{12} \tag{5}

展开组合数：(120)=1\binom{12}{0}=1，(121)=12\binom{12}{1}=12，(122)=66\binom{12}{2}=66，三项相加得 79，乘以 0.512=1/40960.5^{12}=1/4096，再乘以 2，得到 p≈2×79/4096≈0.0386p\approx 2\times79/4096\approx0.0386，与表 2 中汇报的 p=0.039p=0.039 对齐（小小的舍入误差来自四舍五入）。这个 pp 小于 0.050.05，因此在未校正下被列为“显著”；但在 α/18≈0.0028\alpha/18\approx0.0028 的 Bonferroni 门槛下，0.039>0.00280.039 > 0.0028，这个效应就无法幸存下来。把这个手工计算走一遍的价值在于：它让人直观地看到，当不一致总数只有 12 时，即使收益/回归比例看起来很态意（5 倍），绝对样本量也太小，不足以在严格的多重比较校正下站稳脚跟。

5. 实验与结果

5.1 总表：18 个条件下的收益、回归与净效应

完整结果（重建自论文表 2）横跨 3 套工具栈 × 2 个基准 × 3 个库：

工具栈 / 基准库通过率（无 skill → 带 skill）收益回归净效应95% 置信区间p 值
OpenCode·minimax / OfficeQA-Proanthropic51.1→52.11413+1(−9.8,+11.9)1.000
OpenCode·minimax / OfficeQA-Proopenai51.1→55.31612+4(−6.7,+15.3)0.572
OpenCode·minimax / OfficeQA-ProOurs51.1→60.6156+9(+0.2,+18.9)0.078
Codex·gpt-5.4-mini / OfficeQA-Proanthropic54.3→56.41715+2(−9.7,+13.9)0.860
Claude Code·sonnet-4.6 / OfficeQA-Proanthropic72.3→80.9102+8(+1.5,+15.5)0.039
Claude Code·sonnet-4.6 / OfficeQA-Proopenai72.3→77.7127+5(−3.7,+14.3)0.359
OpenCode·minimax / SpreadsheetBenchanthropic63.3→70.26235+27(+2.0,+11.8)0.008
OpenCode·minimax / SpreadsheetBenchopenai63.3→64.34541+4(−3.6,+5.7)0.747
Claude Code·sonnet-4.6 / SpreadsheetBenchanthropic70.2→81.15916+43(+6.8,+15.2)<.001
Claude Code·sonnet-4.6 / SpreadsheetBenchopenai70.2→81.16320+43(+6.5,+15.4)<.001
Claude Code·sonnet-4.6 / SpreadsheetBenchOurs70.2→82.16619+47(+7.5,+16.4)<.001

（加粗行为通过 Bonferroni 校正的行；为节省篇幅省略的行遵循相同模式，完整 18 行见论文表 2。）

汇总全部 18 个条件：553 个收益迁移，324 个回归迁移。回归抵消了59%的毛收益，剩下净留存 229 个。按基准拆分：OfficeQA-Pro 获得 122 个、破坏 81 个（66% 的收益被抵消）；SpreadsheetBench 获得 431 个、破坏 243 个（56% 被抵消）。这就是论文标题里”回归税”的由来——需要注意的是，这不是只集中在表现较差的格子里：即便是一个净效应看起来很正的库，比如 OpenCode·minimax 的 openai 库在 SpreadsheetBench 上（破坏 41 个，获得 45 个），也几乎是在用和收益差不多规模的回归来换取那个净效应。

5.2 机制拆解：OfficeQA-Pro（81 个回归，完整编码）

机制minimax-m2.7gpt-5.4-minisonnet-4.6合计占比
Grounding 位移233425972.8%
Osmosis5091417.3%
Grounding + Verification12033.7%
Other21256.2%
pie title OfficeQA-Pro 回归机制分布 (N=81)
    "Grounding 位移" : 59
    "Osmosis" : 14
    "Grounding + Verification" : 3
    "Other" : 5

图 5（复现的实验结果，对应论文表 3）：当 skill 正文确实被调用时，grounding 位移占主导（minimax-m2.7 上 23/31，gpt-5.4-mini 上 34/37）；osmosis 集中在那个”相对于回归数而言，skill 工具被调用得最少”的工具栈上（sonnet-4.6，13 个里有 9 个）。这种按工具栈拆分出来的分布本身很有信息量——它说明一个回归归属于哪种机制，很大程度上取决于该工具栈的操作台到底有多频繁地选择调用 skill，而不是 skill 内容本身。

5.3 机制拆解：SpreadsheetBench（243 个回归，粗粒度编码）

机制minimax-m2.7gpt-5.4-minisonnet-4.6合计占比
Osmosis452507028.8%
正文被调用60404618.9%
评分器缺陷101753213.2%
Other5431109539.1%
pie title SpreadsheetBench 回归机制分布 (N=243)
    "Osmosis" : 70
    "正文被调用" : 46
    "评分器缺陷" : 32
    "Other" : 95

图 6（复现的实验结果，对应论文表 4）：SpreadsheetBench 的回归没法像 OfficeQA-Pro 那样干净地拆成 grounding vs. verification（单元格数值答案不像单一带容差的数字那样清楚地暴露出第一个出错的阶段），所以论文报告了一个更粗的分类。**评分器缺陷（grader artifact）**这一类（13.2%）揭示了一个非常重要的混淆因素：一部分”回归”根本不是行为层面的——它们只是纯数值比对的评分器无法重新计算像 AGGREGATE 这样的现代 Excel 函数，把一个正确的公式判成了错误。

5.4 修复评分器缺陷，最多找回 49 个百分点的通过率

论文第 5.3 节对所有在被评分区域内保留了公式的 treatment 失败样本（9 个 treatment 条件下共 663 个）重新评分，用一个真正会重新计算公式的完整电子表格引擎，而不是浅层的纯数值比对。找回的结果：

工具栈 / 库原始通过率修正后通过率找回的任务-条件数
minimax-m2.7 / anthropic70.274.7+18
minimax-m2.7 / openai64.368.4+16
minimax-m2.7 / Ours65.669.6+16
gpt-5.4-mini / anthropic67.678.6+43
gpt-5.4-mini / openai66.679.1+49
gpt-5.4-mini / Ours67.177.8+42
sonnet-4.6 / anthropic81.184.9+15
sonnet-4.6 / openai81.185.2+16
sonnet-4.6 / Ours82.184.9+11

单单这一个修复，就把 gpt-5.4-mini 工具栈的通过率从 60 出头拉到了 70 后段——这个跳跃完全归因于评分工具链的局限，与 agent 行为的任何变化无关。这有力地说明了”回归”不能自动等同于”agent 做错了”：663 个带公式的失败样本里，有 226 个（34%）本来就是正确答案，只是浅层评分器无法验证。这直接支撑了论文两条核心建议之一：skill 库应该携带可执行的输出核查，而不只是流程步骤，恰恰因为大量可挽回的失败都落在了验证阶段，而不是方法阶段。

6. 案例细读：为什么这套分类学是可证伪的，不是感觉派

我想详细走一遍论文里的两个案例，因为正是它们说服了我，这套机制标签不只是事后编的故事。

UID0025（Grounding 位移）。 任务：1934 年与 1946 年美国公共工程支出的绝对差值，标准答案 142。无 skill 时，agent 读到 1934 年是 549、1946 年是 407，计算 ∣549−407∣=142|549-407|=142，通过。带上 anthropic 库后，两个导航加算术的 skill 被调用；agent 按照它们规定的导航路径找到了另一对数字——1934 年变成了 949 而不是 549——并计算 ∣949−407∣=542|949-407|=542，一个完全错误的答案，却是在错误的输入上进行了完全正确的算术得出的。方法本身没有问题。回归 100% 发生在输入阶段。这正是 81 个 OfficeQA-Pro 回归里 59 个的模式：一个通用的导航流程会覆盖裸 agent 本来就能自己做对的正确读法，因为这个流程不知道自己正被应用在一个裸 agent 本来就已经做对了的案例上。

UID0096（Osmosis）。 任务：某关税税率的居中移动平均值，标准答案 0.377（37.7%）。无 skill 时，sonnet-4.6 回答 37.708%，通过。带上三个库任意一个——而且关键是，三次 treatment 运行里 skill 工具被调用的次数都是零——agent 都回答 38.757%，精确到小数点后三位完全一致。没有任何一个 skill 正文被读取过。在通过的那次运行和三次失败的运行之间，唯一变化的东西，是系统提示里存在哪些 skill 描述。论文用来证明这是真实影响、而非采样噪声的证据：（1）完全相同的错误值（38.757%）在三个独立撰写的库下都重现——这么精确的巧合，在纯粹的解码方差下是不太可能发生的；（2）这种偏移与三个库描述中反复出现的特定词汇（“revised”、“customs”）相符，即便携带详细流程的正文从未被加载过。这正是任何检索门控或调用门控的防御方法都看不到的机制，因为那些方法只在 skill 真正被调用时才介入——而这里它从未被调用。

这两个案例都固定住了”可见的推理过程”（算术、表格逻辑），把分歧精确定位到某一个阶段，这正是把它和纯粹定性的”感觉上 skill 有时候会帮倒忙”的观察区分开来的严谨之处。

还有第三个案例值得一提，因为它把 grounding 位移和 verification 位移这两种机制同时叠加在了一个任务上（附录 C.4 的 UID0100）：任务要求计算 2007–2013 财年司法部门支出的同比增长率，以及在这些同比数字上做 OLS 拟合得到的斜率和截距，标准答案是 [2.81,0.030,8.706][2.81, 0.030, 8.706]。无 skill 时 agent 返回 [2.81,0.030,8.705][2.81, 0.030, 8.705]，在容差范围内通过。带上 anthropic 库、调用了两个 skill 之后，agent 在某一年的同比数字来源上发生了分歧，而且从未对最终的三元组给出一个经过核查的答案——它同时在输入端读错了数据来源，又在输出端没有核查结果，因此被标记为 grounding + verification 复合型回归。带上 openai 库、同样调用了两个 skill，拟合的斜率和截距保持正确，但领头的同比项被错误取值（2.87 而不是 2.81），得到 [2.87,0.030,8.706][2.87, 0.030, 8.706]。基线的方法是健全的，输出也通过了；而在两个 treatment 库下，管道两端（输入读取和输出核查）都出了问题——这不是回归本身的问题，而是揭示了流水线两端同时脆弱的一个复合案例。

7. 设计选择讨论：作者还能怎么做，为什么没这么做？

  • 为什么用人工阅读配对轨迹，而不是自动化 diff？ 一套自动化流水线逐 token 比对轨迹，可以把规模扩展到更多回归样本，并去掉单一标注者的偏差（第 3.4 节）。显而易见的代价是：自动化 diff 无法在不引入另一个近似 LLM 判官的情况下，判断分歧发生在语义上的哪个阶段（“读输入”阶段还是”核查输出”阶段）——这恰恰会重新引入论文试图通过手工编码一个规模适中、可以被充分理解的样本（81+243 个回归，依然可观）来避免的那种未经验证的黑箱判断。
  • 为什么不跑多个种子来估计方差？ 论文明确指出（第 6.2 节）它没有跨随机种子做重复实验，所以运行间的随机方差没有和 skill 库诱导的方差分开。替代方案——每种条件跑 kk 次取平均——会把本已达到 5832 次的运行预算再乘以 kk，带来真实的成本增加，但这是我最希望在后续工作中看到的一项补充：没有它，“Other”桶里的一部分未解决回归（两个基准合计 5+95=100 个）可能只是解码噪声，而不是第四种尚未被发现的机制。
  • 为什么每套工具栈只绑定一个模型-工具组合，而不是把所有组合都交叉跑一遍？ 把 3 个工具 × 3 个模型交叉起来会得到 9 套工具栈而不是 3 套，再次把运行预算翻三倍——更重要的是，这些组合中的大多数（比如让 Claude Code 去配 MiniMax）并不是这些工具在实践中真实的使用方式，因为每个工具通常都是针对自己的原生模型调优的。论文接受的权衡是：模型和工具栈的效应是混杂的，所以”sonnet-4.6 在 OfficeQA-Pro 上表现出最强的 osmosis”可能是 Claude Code 的产物，可能是 Claude 模型的产物，也可能两者都是——论文没法把它们分开，并且明确说明了这一点。
  • 为什么用 McNemar 检验而不是对全部 18 个条件联合做一个混合效应逻辑回归？ 单个层级模型可以在各工具栈和基准之间借用统计效力，可能发现那些逐格 McNemar 检验（在 N≈94N\approx94 或 392392 的样本量下本来就统计效力不足）漏掉的、更弱但真实存在的效应。代价是：联合模型需要对效应如何跨工具栈泛化做出假设，而论文自身的混杂问题（见上文）让这类假设很难成立；逐格精确检验更透明，也更不容易被误用。考虑到这篇论文的可信度很大程度上建立在”不过度声称”之上，这种更保守的逐格选择，与论文自身的认识论立场是一致的。

8. 局限性

论文对自身局限性的坦诚程度不同寻常（第 6.2 节），值得原原本本地复述，而不是一带而过：

  1. 领域范围：两个基准都是办公自动化任务，其中grounding（读对输入）和输出格式是突出的失败面。论文并不声称这些机制比例可以迁移到”方法本身才是主要瓶颈”的领域——例如多步数学证明搜索，或复杂代码重构，在这些领域里，agent 的过程性推理能力，而不是它能不能在表格里找对单元格，可能才是主要的失败模式。
  2. 模型-工具栈混杂：如前所述，每套工具栈都把一个工具绑定到它的原生模型上，所以归因于”某套工具栈”的效应，无法被干净地拆分成”由模型引起”和”由工具引起”。
  3. 统计脆弱性：18 组比较里只有 3 组通过 Bonferroni 校正，而且全部局限在单一工具栈（Claude Code·sonnet-4.6）和单一基准（SpreadsheetBench）内。论文自己的解读是，这种局限性强化了回归税这个核心论点（大多数看起来的改进，一旦对多重比较做了校正，在统计上就和噪声无法区分），而不是削弱了论文的核心主张——但这确实意味着那些具体的数值声明（比如”净效应 +43”）不应该被读成关于 skill 库普遍适用的、可以广泛推广的事实。
  4. 单一标注者标签：如第 3.4 节所述，全部 324 个回归的机制标签都由一位作者赋予，没有记录的标注者间一致性检查。
  5. 未跨种子重复：LLM 采样中运行间的随机方差没有被测量或剔除，所以一部分观测到的翻转（尤其是尚未归类的”Other”桶）可能只是解码噪声，而不是一种真正的机制。

8.5 小结：五个局限性背后的共同线索

把上面五条局限性并在一起看，会发现它们其实都指向同一个根本问题：这项研究在“验证一个现象确实存在”这件事上很确切（回归税肯定不为零，osmosis、grounding 位移、verification 位移这三种机制都能在具体轨迹里找到可信的个案），但在“精确量化这个现象有多大”这件事上还有不少未完成的工作——没有种子重复实验、没有长度匹配的对照、没有第二位盲标注者。这个区分对如何解读这篇论文很重要：它的定性结论（“回归税真实存在，且可以被归因到可命名的机制”）比它的定量结论（“72.8% 的 OfficeQA-Pro 回归是 grounding 位移”）要稳固得多。

9. 批判性分析

（a）这篇论文本身的具体缺陷。 方法论上后果最大的缺口，是缺失的种子重复实验（第 8 节第 5 条）。这篇论文整个回归机制的论证，都依赖于能把一次通过→失败的翻转归因于 skill 库，而不是普通的 LLM 采样方差——而针对这种替代解释，论文给出的唯一防护，是第 3.4 节用于 osmosis 标注的跨库复现检查——但这个检查只用在 osmosis 这一类，没有用在 grounding 或 verification 位移的回归上，而后两者占了绝大多数（OfficeQA-Pro 的 81 个里有 59+3 个，加上 SpreadsheetBench 243 个回归里未知的一部分）。完全有可能一部分被标为 grounding 位移的回归，实际情况是裸 agent 在 none 条件下的正确答案本身就是运气好的一次采样，如果不带 skill 重跑一次，也照样会失败。如果没有至少几次重复的 none 运行来估计这个基线噪声水平，机制比例（OfficeQA-Pro 上 72.8% grounding、17.3% osmosis）应该被理解为基于这套标注方案的上界估计，而不是关于底层因果过程的确凿事实。

（b）作者低估或遗漏的局限性。 论文在领域范围、混杂因素和统计脆弱性上都相当坦诚，但有一点讨论得不够充分：skill 库的大小是一个论文测量了、但没有控制的混杂变量。第 3.3 节顺带提到”库的规模从 3 个到 23 个 skill 不等”，且”没有做长度匹配”，并明确说明 treatment-vs-treatment 的对比”不是一个受控的 token 剂量”。但这也意味着主结果表（表 2，我的第 5.1 节）里每一个treatment-vs-none 的比较，同样不是一个受控的 token 剂量——一个 23 个 skill 的库带来的上下文远比一个 7 个 skill 的库多，而”更多与任务无关的上下文会损害推理”是一个论文自己也引用过的成熟效应（Shi 等人关于 GSM-IC 干扰句的研究，Liu 等人关于”Lost in the Middle”的研究）。完全有可能一部分被标为”grounding 位移”或”osmosis”的现象，实际上只是一种通用的干扰性上下文效应——换成任意 23 个 skill 的无关文本量都会发生，而不是因为这些具体的 skill 具体说了什么。论文从未跑过一个长度匹配的对照条件（比如 23 个近乎随机或打乱的”安慰剂” skill），来把”内容特异性的位移”和”通用的长上下文稀释”分开。这是论文自己引用的相关工作（第 2 节）几乎已经在暗示要做的一个自然且廉价的后续实验，它的缺失削弱了把 grounding 位移这一机制具体归因于 skill 内容（而非 skill 体量）的说服力。

（c）具体的、可操作的改进建议。 第一，至少在两个出现显著效应的工具栈/基准组合上，跑一个长度和 token 数匹配的安慰剂条件（用同等 token 数的随机无关文本替代真实 skill 库），以区分内容驱动的位移和通用的上下文稀释效应。第二，在至少 50–100 个分层抽样的任务上，对 none 条件做至少 3 个种子的重复实验，以估计纯粹来自采样噪声的基线翻转率，这样后续每一个机制归因的论断都能带上一个明确的噪声基线校正。第三，在 324 个回归中至少 20% 的样本上，引入第二位盲标注者扩展机制分类方案，并汇报 Cohen’s kappa——相对于论文核心数字对标注方案可靠性所依赖的分量，这个成本很低（第二作者几个小时的工作量）。第四，鉴于评分器缺陷这个混淆因素在 SpreadsheetBench 上被证明影响巨大（243 个回归里有 32 个，更广泛地说 663 个带公式的失败里有 226 个），论文应该反过来仔细审查：类似”评分工具链问题、而非 agent 行为问题”的伪影，是否也可能在 OfficeQA-Pro 的回归计数里被放大了——论文对 SpreadsheetBench 做了细致的核查，却没有对自己视为”干净”的基准做同等程度的反向审视。

9.5 对中文读者的一点附加说明

国内团队在构建自己的 agent 框架或企业内部工具时，很容易把“给 agent 加一份 system prompt 里的操作手册”当成一件完全无副作用的事情——反正不行大不了不用，反正不会比不加更差。这篇论文最直接的实践意义，就是把这个直觉诐倒了：即便你的手册写得完全正确、从不被错误调用，它也可能单凭存在于上下文中就改变了模型的行为——而且这种改变完全不受你的控制。对于国内常见的“为 agent 配备一套业务 SOP / 知识库提示词”这类工程实践，这意味着一个反直觉但重要的检查项：在上线一份新知识库或 SOP 之前，不仅要测试它能不能修好现有的 bad case，还得回归测试一下它有没有悬而未决地改变了那些本来就处理得很好的任务的行为——即使那份知识库从未被显式检索命中。

10. 复现性说明

  • 模型-工具栈：OpenCode+MiniMax-M2.7、Codex+GPT-5.4-mini、Claude Code+Claude Sonnet 4.6——截至论文写作时，都是闭源或半闭源的模型/工具，意味着精确复现需要访问相同的模型检查点（受版本迭代/漂移影响）和相同版本的工具。
  • 基准：OfficeQA-Pro 被描述为作者基于美国财政部文档自行整理和验证的一个子集（而不是一个已有固定发布版本的公开基准），所以逐任务的精确复现依赖于作者是否发布这个整理过的子集；SpreadsheetBench 是一个公开的 NeurIPS 2024 基准（Ma 等人），有一个论文详细记录过的评分引擎局限（论文第 3.1 节，本文第 1.2 节）——任何重跑这个基准的人，都应该在信任原始通过率数字之前，先了解这个 AGGREGATE/结构化引用的盲区。
  • 统计方案：不一致配对上的精确双侧 McNemar 检验、配对差值的 Newcombe 95% 置信区间、α/18\alpha/18 的 Bonferroni 校正。这些都完整明确、标准合规——一个仔细的读者可以单凭表 2 里原始的 (b,c,N)(b,c,N) 三元组，重新推导出每一个汇报的 p 值和置信区间。
  • 未发布/未说明的部分：机制分类标签（论文第 5 节）由一位作者阅读配对轨迹后赋予；论文没有说明全部 324 份原始轨迹记录是否会被发布，供独立复核者重新标注——这本会是任何想独立验证机制比例论断的人最有价值的一份材料。

10.5 一个具体对照：同样的信号，三种不同的回归画像

为了让第 3.2 节里关于三位创建者的抽象讨论变得具体，值得走一遍在 OpenCode·minimax-m2.7 这套工具栈上，同一份失败信号发生了什么。分析员阶段（第 3.1 节）从基线轨迹里提取出一整批共享的反复失败原因。anthropic 创建者的测量驱动循环，把这些信号浓缩成一套相对保守的 skill 集合，每一个都在自己的基准测试提示上被单独验证过才会保留。openai 创建者没有评测循环的单次通过流水线，把同一批信号扩展成了这个工具栈上的 23 个 skill——几乎每一个反复出现的信号都变成了自己独立的 skill，没有合并或淘汰的步骤。Ours 创建者的先查重后创建步骤，把重叠的信号合并起来，针对同一份证据最终只落地成 7 个 skill。

这在这套工具栈的 SpreadsheetBench 上带来的下游效应（表 2，本文第 5.1 节）很有启发性：anthropic 净效应 +27（未校正下 p=.008p=.008，虽然没能通过 Bonferroni 校正），openai 只有 +4，Ours 是 +9。这个有 23 个 skill 的 openai 库，并不因为 skill 数量更多就明显更好——恰恰相反，它相对于收益的回归数偏高（41 个回归对 45 个收益，相比之下 anthropic 是 35 对 62），这与第 9 节 (b) 提出的上下文稀释担忧是一致的：更多的 skill 描述堆在上下文里、大多数从未被调用，就意味着更大的 osmosis 干扰面，而表 4（第 5.3 节）也确实显示，osmosis 正是这套工具栈上最大的单一回归机制（minimax-m2.7 在 SpreadsheetBench 上 115 个回归里有 45 个）。这并不能证明规模本身就是罪魁祸首——内容依然重要，因为 Ours 也合并了相关信号，最终落在两者之间——但这是一个很清晰的例证，说明为什么论文坚持认为，库的大小和撰写流程、而不只是 skill 内容本身，需要和任何一个净效应数字一起被汇报。

10.6 一个小型自检清单

如果你想在自己的 skill 库上复制这篇论文的方法论，下面这五项是最小可行的起点：（1）能否针对同一批任务、同样的模型和工具，只切换 skill 库开关，跑一轮配对对比；（2）能否把每个任务的结果归入 Gain/Regression/Residual/Retained 四个桶中的一个，而不只看平均通过率；（3）能否至少设计一个“描述在场但正文不可读取”的对照组，用来单独检验 osmosis 通道；（4）对每一个回归，能否在轨迹中定位到它究竟发生在输入阶段还是输出阶段；（5）能否对比一下自己的评分工具链是否存在类似 SpreadsheetBench 那种“看似行为回归、实则是评分工具链缺陷”的隐藏混淆。这五项中任何一项都不需要新的基础设施——只需要把现有评测流程跑两遍（有 skill 一遍，无 skill 一遍）并记录下两者的差异。

11. 结语

如果你在生产环境里部署 agent skill、工具使用指南，或任何以上下文形式存在的程序性脚手架：（1）汇报配对的收益/回归计数，而不只是聚合的通过率差值——两个净效应完全相同的库，可能正在以截然不同的规模拿走原有的可靠性；（2）明确测试仅存在性（osmosis）效应，跑一个”描述在场但正文不可访问”的条件，因为检索门控或调用门控的防御方法根本看不到这条通道；（3）把资源不成比例地投入到 grounding 和 verification 内容上，而不是过程性的”怎么做”内容——这篇论文的数据说明，现有 skill 已经在过度服务流水线中段的过程性部分，而在两端（grounding 和 verification，回归和残留失败集中的地方）投入不足。这些都不需要超出论文本身所用工具的新基础设施：一套配对运行的测试框架，以及愿意去读一读你的收益到底悄悄换来了哪些失败。