Agent 评测方法学三重奏：Next-Turn 指标为何失灵 —— 精读
论文 A：When Better Turns Do Not Make Better Agents: Diagnosing the Gap Between Next-Turn Metrics and Workflow Success 论文 B：What Stops a Small Language Model From Driving a Database Agent ｜ 代码仓库 论文 C（背景参照）：τ²-bench（Sierra + 普林斯顿，真实客户交付模拟基准；来源 x.com/rohanpaul_ai/status/2101760224713687437）
发表时间：A 与 B 均为 2026 年 9 月（arXiv v1，2026-09-18 提交）；C 为 2025 年产业基准。
机构：A —— Dialpad Inc.（纯企业团队，13 位作者）；B —— 独立研究者 / LibreDB Studio 贡献者（Cevheri Bozoğlan 等 4 人）；C —— Sierra 联合普林斯顿大学。
领域标签：cs.CL（A，计算语言学）/ cs.SE（B，软件工程）/ Agent 评测、Benchmark、工具调用。
写在前面：为什么要把三篇论文放在一起读
这三篇论文表面上各说各话：A 是企业的客服工作流评测诊断，B 是独立研究者对开源数据库 Agent 的"田野记录"，C 是产业界推出的超真实交付基准。但它们共享同一个结论——我们用来看模型"好不好"的指标，和它"能不能干活"之间，存在一条被长期忽略的裂缝。
A 从"协议"角度切：当评测协议从开卷变成闭卷，结论彻底翻转。B 从"归因"角度切：当失败被拆到接口层的机械形态，修的是服务器而非模型。C 从"真实性"角度补刀：在足够真实的端到端交付里，最强模型也几乎全线崩盘。三者合起来构成一条完整的评测方法论批判：必须闭环（A）、必须真实（C）、必须归因到接口层（B）。
下面用九部分标准精读结构，把 A 与 B 各自完整展开，C 仅作为定位背景贯穿。
一、论文背景（共用）：Agent 评测的"三层失真"问题
要理解这三篇论文在反对什么，得先理解当前 Agent 评测的两大默认习惯，以及它们如何制造失真。
1.1 什么是 Agent，为什么要"评测"它
Agent（智能体） 指一类会"多步决策 + 调用工具"的大模型程序：它不像普通聊天机器人只吐一句话，而是在一个任务里连续行动——问用户要信息、调用数据库/API、读返回结果、再决定下一步，直到把事办完。一个客服 Agent 的典型轨迹是：识别意图 → 调用订单查询 → 据结果解释政策 → 调用退款工具 → 给出最终答复。
评测 Agent 之所以难，是因为它的质量本质是一条轨迹的质量，而非每一步的平均质量——早期错误会改变后续每个决策的上下文。
1.2 失真层一：Next-Turn（下一步）评测的"开卷"错觉
实践中最主流、最便宜的评测协议叫 next-turn evaluation（下一步评测）：给模型"正确历史 + 政策 + 工具定义"，让它预测"下一步该做什么"，再用 ROUGE、BERTScore 或 LLM 裁判去比对参考答案。它便宜、可复现、可验证——所以统治了工业界。
但它有两个致命缺陷（论文 A 明确指出）：
- 它替模型恢复了正确状态。每一步预测都基于"黄金历史（gold history）"，也就是正确答案拼出来的对话前情。模型早期犯的错误无法影响后面的决策。于是它测的是"给定正确状态，模型能不能给出对的下一步"，而不是"模型自己能不能一步步构建并维持这个状态"。
- 参考式指标会奖励"长得像答案"的错误响应。CONFETTI（Alkhouli et al., 2025）也注意到：黄金轨迹会通过上下文学习"人为抬高"后段表现。
类比（给初学者）：金历史评测就像开卷抄答案——老师把前面每一步的标准答案摊在你面前，只问你"这一步写什么"。你能抄得很好，不代表你真能从头独立做完这道题。闭环重放（closed-loop replay）才是闭卷真考——你用自己的前一步输出当下一步的输入，错了就错着往下走，最后看题到底做没做成。
1.3 失真层二：把"模型能力"当成失败的唯一归因
论文 B 批判的是另一种默认假设：小模型跑不动 Agent，是因为它"推理能力不够"（capability threshold，能力阈值）。这个假设预测——失败应该长成"模型根本不行动"。但 B 在 8,199 次真机运行里看到的几乎相反：大多数失败是模型"行动了、做对了一部分、却在模型和服务器之间的边界上把成果弄丢了"。
这就引出第二层失真：把失败笼统归因到"模型不行"，等于把评测 harness（运行框架、工具契约、解析器、拒绝消息）当成不可见常量；而 B 证明，harness 的缺陷本身就是失败主因之一。
1.4 失真层三：基准"不够真实"导致分数与能力脱钩
C（τ²-bench）提供第三层失真的极端样本：它模拟真实客户交付（公司记录、客户需求、生产 API、现有代码、预算），要求产出可部署的客服智能体。在这种"端到端真实"里，即便当时最强的编码智能体也只过了 23.9%。这说明很多在简化基准上刷出高分的模型，放进真实交付就露馅——即评测学界常说的 agentic disconnect（Agent 失联）：基准测的东西和企业真正需要的多步工具使用、不确定性下的决策、真实任务完成，根本不是一回事。
三层失真合起来就是本合读的核心命题：评测协议、归因框架、真实性，任何一个环节偷懒，都会让"分数好看"与"真能干活"彻底脱钩。
二、论文定位与关联工作（评测协议谱系 + τ²-bench 参照）
2.1 评测协议的谱系
把 A、B、C 放进 Agent 评测的研究谱系，可以按"评测协议离真实执行有多近"排一条轴：
| 协议形态 | 代表工作 | 是否用黄金历史 | 是否端到端真跑 | 本文定位 |
|---|---|---|---|---|
| 参考式单轮指标（ROUGE/BERTScore/LLM裁判） | 经典 NLG 评测；CONFETTI（Alkhouli et al., 2025） | 是 | 否 | A 的 L1–L2，被证明会高估 |
| 严格工具正确性（确定性解析） | ToolLLM、BFCL、API-Bank 的工具项 | 是 | 否 | A 的 L3，仍开卷 |
| 闭环重放 / 端到端执行 | A 的 L4–L5；τ-bench / τ²-bench | 否 | 是 | A 的"闭卷真考" |
| 生产级真机 ledger + 接口层归因 | B（LibreDB） | 否 | 是（真数据库） | 把"失败归因"做成可观测 |
| 超真实交付模拟 | C（τ²-bench，Sierra+普林斯顿） | 否 | 是（生产 API） | 真实性天花板旁证 |
关键区别在于：A 的巧思是"固定工作流与模型、只变评测协议"，把协议本身变成唯一变量，从而干净地隔离出"开卷 vs 闭卷"带来的结论差异。B 的巧思则是把 harness 也变成变量——它不固定拒绝消息和解析器，而是直接在发布中的产品里修它们，并测量修复后 40 个模型整体如何变化。
2.2 τ²-bench 作为背景参照（C）
τ²-bench（Barres et al., 2025，arXiv:2506.07982）是 τ-bench 的"双控（dual-control）“升级版，同样来自 Sierra 与普林斯顿。它要求智能体在真实客户交付情境中工作：面对公司记录、客户需求、生产 API、现有代码与预算约束，产出可部署的客服智能体。来源推文（rohanpaul_ai，2026-09）报告：当时最强的编码智能体也只过了 23.9%。
C 不直接占章节，但它是"真实性锚点”：用最硬的端到端真实任务证明，一旦评测足够真实，分数会断崖式下跌——与 A 的"闭环重放最高 10.4%"、“B 的多数损失来自接口层而非模型"形成互文。真实，是评测有效性的底线。
2.3 本文相对于谱系的位置
- 相对 CONFETTI：它指出黄金轨迹会人为抬高后段表现，但没有把单轮评测和端到端自主执行直接对比；A 补足了这个对比。
- 相对 τ/τ²-bench：它们提供端到端基准，但 A 进一步说明"同一份输出在不同协议下结论相反”，B 进一步说明"同一份失败要归因到接口而非模型"。
- 相对 AgentBench（Liu et al., 2024）：它把开源与商用模型的差距归因于长期推理与指令遵循；B 质疑这种归因"只和其测量所用 harness 一样好"——固定拒绝消息的基准测的是"模型+harness 组合"，而非纯模型。
三、问题定义
3.1 论文 A 的问题：指标与目标的"代理有效性"
具体问题：SFT（监督微调）让模型在 next-turn 评测下变好了，这是否意味着它在自主工作流里也变好了？
抽象问题：一个便宜的代理指标（proxy），在什么条件下能可靠地预测它本应代理的那个真实目标？
形式化：给定模型集合 M、工作流集合 W、同一组输出 O，定义
- 代理指标
P(O)= 金历史协议下的 next-turn 成功率（开卷）； - 真实目标
T(O)= 闭环端到端工作流成功率（闭卷）。
要回答的是：P 的提升是否蕴含 T 的提升，即 ΔP > 0 ⟹ ΔT > 0 是否成立。A 的实验设计就是直接测量这个蕴含关系，并且把"文本生成"与"工具执行"从聚合分里拆开，看 P 的提升究竟藏在哪个子能力里。
这个抽象的精妙处在于：它把"评测协议"本身当成实验变量，而非默认背景——多数论文默认"分数涨了就是能力涨了"，A 拒绝这个默认。
3.2 论文 B 的问题：失败的因果归因
具体问题：小开源模型驱动不了数据库 Agent，根因是"模型能力不够"吗？
抽象问题：当一个 Agent 运行失败时，失败应归因于哪个因果层——模型推理、工具语义、还是模型与服务器之间的"接口机械形态"？
形式化：把一次失败 run 分类到四类互斥（按优先级）的因果层：
clock：超时/截止（运行层面的资源）；capability：模型从头到尾没调用任何工具（真正的"不行动"）；verification：报告已生成但被验证器拒（交付物不合规）；transport：调用了工具、没超时、却始终没把成果送达（接口边界丢失）。
B 的核心断言是：如果"能力阈值"假设成立，capability 应占主导；而真实分布里 transport 最大、capability 最小，说明失败的主要因果层在接口，不在模型。
3.3 两篇论文问题定义的对应关系
| 维度 | 论文 A | 论文 B |
|---|---|---|
| 核心变量 | 评测协议（开卷 vs 闭卷） | 失败归因层（模型 vs 接口） |
| 要证伪的默认假设 | “next-turn 分数涨 = 工作流能力涨” | “小模型不行 = 推理能力不够” |
| 实验刀法 | 固定模型与工作流，只变协议 | 固定硬件/提示/任务，只变服务器 |
| 共同结构 | 把"默认不可见的背景"变成可控变量 | 同上 |
四、问题解法
4.1 论文 A 的解法：五级评测协议链
A 设计了一条从"能说一句像样的话"到"能独立跑完工作流"的五级协议链，每一步针对路径上不同能力（见图 1，论文原文）。关键点：协议是唯一的变量，工作流和模型固定。
| 层级 | 协议 | 评分方式 | 测什么能力 |
|---|---|---|---|
| L1 | 文本相似度 | 确定性 ROUGE-1 | 给定黄金历史，文本像不像参考答案 |
| L2 | 金历史轮次成功 | LLM 裁判（Gemini-2.5-Pro, temp=0）对 542 轮二分类 | 给定黄金历史，动作对不对（含文本与工具） |
| L3 | 严格工具正确性 | 确定性解析脚本，函数名+归一化参数精确匹配 | 工具调用是否逐字正确（无部分分） |
| L4 | 闭环重放（closed-loop replay） | 用模型自己的历史重跑 84 段对话，确定性用户模拟器；工具错最多重试 2 次 | 模型能否靠自己维持状态走到终点 |
| L5 | 整体工作流裁判 | LLM 裁判对每次重放判"用户目标是否完成、无政策违规、无工具错误" | 端到端是否真成功 |
A 的洞察是——只看 L1–L3 会系统性高估，因为黄金历史在每个决策前都把状态"复位"成正确的；L4–L5 才暴露早期错误如何向后传播。
4.2 论文 B 的解法：四类失败 taxonomy + 干预闭环
B 的解法分两步：先建一个可在结构化运行账本（ledger）上计算的失败分类法，再做"定位→修复→重测"的闭环。
（一）四类失败 taxonomy（按优先级应用，顺序本身有负载）
clock（25.8%）：运行因模型超时、轮次上限或截止而终止。capability（17.3%）：运行一次工具都没调用。verification（20.7%）：报告已写、却被验证器判为"未答复"（交付物不合规/引用无法解析）。transport（36.2%，最大类）：调用了工具、没超时、却始终没把可交付成果送达。
为什么顺序负载重？有 231 个损失同时"超时且没调用工具"，满足前两个定义。B 采用 clock-first，经验理由是其中 225 个连一个字符都没输出——更像内存混淆导致的"根本没启动"，而非"模型拒绝行动"。这一选择直接决定 headline：clock-first 下 capability 最小（17.3%），capability-first 下它升到 24.3%。B 诚实报告：transport 无论哪种顺序都是最大类，这是不依赖选择的发现；类排序只是"本语料的性质"，非普适结论。
（二）transport 的机械形态拆解（关键机制）
B 捕获被拒调用的参数后发现，transport 失败能拆成少数几种"机械形状"，且模型在实质上是对的：
- 写错通道：抽查 69 个终止轮，27 个把完整工具调用写进了文本通道而非作为结构化调用发出（其中 18 个正是"缺失报告"对应的报告工具）。一个真实案例：模型写出了完全正确的
compose_reportJSON，含真实 correlationId，却写在对话文本里，运行因此"做了所有活、唯独没送达"。这 27 个无一能被 JSON 解析，24 个因数组末元素被多关一次括号而失败。 - 字段错位（displaced fields）：捕获的拒绝里，模型把
statement塞进名叫change的字段、rationale叫成reason、单个证据项没包成列表——值全对，只是"放错了抽屉"，却被服务器判三个字段缺失。 - 自相矛盾的契约：某 3B 模型 data-analysis 单元 0/5，捕获显示模型把答案两半分别发给两个工具，服务器却在一个工具上要求 presentation 字段、在兄弟工具上禁止它，并以"缺失"判失败——结构性矛盾，与模型下一步做什么无关。
（三）五项服务器侧干预（不碰模型/提示/采样）
| # | 缺陷 | 修复 |
|---|---|---|
| 1 | 文本通道里的调用除非是可解析 JSON 否则不可见 | 按"命名"而非按"解析文档"识别调用 |
| 2 | SQL 被塞进枚举字段 change | 从语句内容读 kind，散文仍拒 |
| 3 | rationale 叫成 reason；证据是单对象或 JSON 字符串 | 精确一对一缺失/盈余即重命名；单对象视为单元素列表 |
| 4 | 一个近似键名被拒数月却从未生效 | 对扁平两字段调用应用重命名 |
| 5 | remove <字段> 让模型丢弃兄弟工具的字段 | remove 只留给"无处安放"的键；兄弟工具的字段用"它该去哪"回答 |
这五项有个反直觉的性质：都是服务器（接口）侧修改、零模型相关。修一次，全体模型受益。
五、评估指标与实验证据
5.1 论文 A 的实验设计与关键数字
数据集与模型：Dialpad 专有客服工作流，130 个工作流；用 GPT-5 双实例（用户/Agent）生成 1,800 段对话，经 Claude-4.5-Opus 与 Gemini-2.5-Pro 双裁判过滤后留存 1,027 段已验证对话；评估切分 84 段对话 → 542 个 next-action 样例（376 文本 + 166 工具）。模型为 Qwen3-4B/14B 与 Gemma3-4B/12B 的预 SFT（ZS）与 SFT 两版，训练配方完全相同（五轮）。
主指标（证明力分析）：A 的论点是"开卷涨 ≠ 闭卷涨"，所以证明力来自同一组输出在 L1–L5 下的结论反差：
| 指标（跨 4 模型平均） | ZS | SFT | Δ |
|---|---|---|---|
| ROUGE-1（L1） | 24.8 | 49.2 | +24.4 |
| LLM 裁判文本轮成功（L2） | 33.2% | 58.4% | +25.2pp |
| LLM 裁判工具轮成功（L2） | 17.8% | 23.7% | +5.9pp |
| 严格调用精确准确率（L3） | 3.5% | 8.5% | +5.0pp |
| 闭环重放工具工作流完成（L4） | 0/77 | 最高 8/77（Qwen3-14B） | 最高 10.4% |
| 整体裁判工具工作流成功（L5） | 0/77 | 0/77 | 0 |
实验设计为什么能证明论点：因为协议是唯一变量，L1–L3（开卷）与 L4–L5（闭卷）面对的是完全相同的模型输出。开卷下 SFT 让文本轮大涨 25.2pp、所有模型 ROUGE 与全轮成功都涨；闭卷下工具工作流完成最高仅 10.4%，整体裁判全军覆没 0/77。同一批 SFT 模型在开卷里"看起来有效"、闭卷里"被发现无效"——这直接证伪了 ΔP ⟹ ΔT。
注意 Gemma 的反例：两个 Gemma3 模型工具项几乎不涨甚至倒退（4B 精确准确率 3.0%→0.0%），说明聚合的"全轮成功"被频繁文本轮拉高，掩盖了工具执行的持续薄弱——这正是 A 主张"必须分项报告"的实证。
5.2 论文 B 的实验设计与关键数字
规模：11 天，39 个本地开源模型 + 1 个托管控制（gemini-3.5-flash-lite），6 个任务面（surface），8,199 次运行、110,711 条 ledger 事件、14,008 次被拒工具调用。可归因到具名模型的运行 4,951 次。
计分单元：一个 cell = 一个模型在一个 surface 上连续 5 次达标即"锁定"；一个模型在 6 个 surface 全锁即 30/30。B 强调用 row 模式（同一 sitting 内六 cell 全锁）而非 pooled（跨配置拼 streak），因为前者才是部署能据此行动的结论——pooled 会让两个模型虚高到 30/30，row 下实为 23/30、24/30。
主指标（taxonomy 分布，2,100 个 agent 模式损失）：
| 类 | 占比（clock-first） |
|---|---|
| transport | 36.2% |
| clock | 25.8% |
| verification | 20.7% |
| capability | 17.3% |
最关键的归因证据：2,100 个损失中 1,590 个（75.7%）来自至少调用过一次工具的 run。这个"参与度结论"对重采样稳健——在 99.7% 的按模型聚类重采样中成立，在 22 个有 ≥20 损失的模型中 15 个成立。它直接反驳"能力阈值"框架：多数损失是"参与了工具的 run"，而非"不行动的 run"。
干预闭环的因果证据：五项服务器修复后，6 个重测单元（同硬件、同提示、同任务）全部提升，sign test 给出 p = 0.031：
| 模型 | 修复前 | 修复后 |
|---|---|---|
| granite4.2:3b | 21/30 | 28/30 |
| mistral-nemo:12b | 18/30 | 26/30 |
| llama3.1:8b | 10/30 | 24/30 |
| cogito:8b | 0/30 | 21/30 |
| glm4:latest | 0/30 | 16/30 |
| deepseek-r1:8b | 18/28 | 24/28 |
B 诚实标注两个削弱项：干预 1 单独测仅 +1/0/0/−1，在方差内，真正拉动数字的是参数形状读取器；且部分提升来自此前"跨多天多配置拼凑的读数"本就非有效 row。所以这是带已知混淆的田野观测，不是消融，但仍强有力说明：距离是"单元"级而非"参数"级。
两个测量混淆（B 的方法论贡献）：
- 无界服务上下文 = 内存混淆：Ollama 未设上下文上限时，一个 7.1GB 的 12B 模型以 262,144 token 窗口常驻 51GB（64GB 机器），free 内存跌到 6%。某 3B 模型 planning 单元因此 0/5（全超时、零工具），封顶 32,768 后同一单元 5/5。这种状态在任何普通日志里都和"模型不会规划"长得一模一样。
- swap 压力：一个 24B 模型分析单元 0/5，单次运行 244–355 秒（此前 41–48 秒），swap 写了 19GB/20GB、145 万次 pageout——看 free 内存（53%）发现不了，得看 swap 是否在增长。
六、效果优势的根源解释
6.1 论文 A 的根源：金历史消除误差传播 → 测错了构念
因果链（论文实验已支持）：金历史协议在每个决策前把状态复位为正确 → 早期错误无法传播 → 模型只需"从正确状态预测下一步" → 这测的是*response prediction（响应预测）*而非 state construction（状态构建）。闭卷执行则允许早期错误向后滚雪球，暴露模型维持状态能力的真实上限。
反事实推理也支持：如果去掉金历史（即改用 L4 闭环），同样的 SFT 模型立刻从"全轮成功涨 19.3pp"跌到"工具工作流完成最高 10.4%、整体 0/77"。这说明开卷下的高分不是闭卷能力的证据，而是协议人为复位状态造成的假象。机制不是"文本生成比工具调用更容易被 SFT 提升"，而是"开卷协议根本没考工具调用所需的跨轮状态构建"。
6.2 论文 B 的根源：harness 的机械形态 → 接口修复全体受益
因果链（论文实验已支持 + 捕获证据）：服务器契约对"调用放在哪、字段叫什么、兄弟工具字段互斥"有刚性要求 → 模型在语义上做对了（正确的 correlationId、正确的 SQL、正确的证据）却在语法/通道/契约层被拒 → 这些拒绝发生在"模型与服务器的边界"而非"模型推理内部" → 所以修服务器（接口）而非修模型能同时抬升所有模型。
B 在 Discussion 里还反驳了"纯信息性"解释：如果失败只是因为拒绝消息没说清该修什么，那补一句说明就够了；但捕获数据显示，拒绝消息已经明确点名了缺失字段，模型仍四次发出同样的错位形状——这与 Gumaan（arXiv:2608.23651）的反事实结论一致：损害的很大一部分来自"失败调用的表层形式仍留在上下文里"，而非"标它失败"的语义。B 真正拉动数字的干预 2–5 改的是"服务器接受什么"，第五条还替换了一条本身就错的指令。
6.3 交叉验证：相关工作检索与对照
本次检索覆盖任务指定的三处参照：
| 研究（可核验链接） | 相似尝试 / 相关结论 | 与本文差异 / 适用边界 | 对根源解释的影响 |
|---|---|---|---|
| Braggaar et al., Evaluating Task-oriented Dialogue Systems: A Systematic Review（arXiv:2312.13871，2023/2024） | 系统综述 122 篇任务导向对话评测，指出构念（construct）与其操作化（operationalisation）常不清晰对应，呼吁更批判地看待"测的是什么" | 它是综述、非 Agent 闭环实验；但它在概念层支持 A 的核心主张——指标的操作化可能根本没测到它声称测的构念（即 construct validity 问题） | 支持 A：“金历史协议测的是响应预测而非状态构建"正是构念误设（construct mismatch）的一个具体实例 |
| τ²-bench / τ-bench（Barres et al. arXiv:2506.07982；Yao et al. arXiv:2406.12045） | 端到端、政策约束、工具–Agent–用户交互基准；C 报告最强编码智能体仅过 23.9% | 提供"真实性"极端样本；不分解失败归因 | 支持“必须真实/必须闭环”——端到端真实任务分数断崖，与 A 的 L4–L5 暴跌互文 |
| Agent 评测的 construct validity 与数据污染讨论（arXiv:2511.08042 “agentic disconnect”；数据污染综述 arXiv:2502.17521） | 指出很多基准存在弱构念效度——测的是"应试能力"而非真实能力；并提出 benchmark contamination 使公开基准分数失真 | 污染是训练期/检索期问题，与 A/B 的协议/接口机制不同层；但同属"分数为何不可信"的大议题 | 补充 A/B：分数失灵至少有三条独立路径——协议开卷（A）、接口归因错位（B）、基准失真/污染（C 与污染文献）。三者并行不悖 |
| Sigdel & Baral, ToolMisuseBench（arXiv:2604.01508）与 Schema-first 工具 API（arXiv:2603.13404） | 直接把"工具接口/拒绝消息"设为声明式变量，证明改变错误反馈文本能改善修正 | 用确定性基线策略与模拟器；B 是在已发布产品 + 40 真实模型上测同一轴 | 强支持 B：把 harness 当实验变量不是 B 首创，但 B 提供了生产级、跨多模型的因果证据 |
| Gumaan, Feedback that Backfires（arXiv:2608.23651） | 失败调用表层形式留在上下文会抬升重复失败概率；用运行时生成的描述替换原调用可消除 76% 重复 | 用 log-prob 代理；B 用端到端验证器 | 支持 B 对"纯信息性解释"的反驳 |
综合判断：
- 多研究共同支持的机制：①评测协议/构念误设会高估真实能力（A + Braggaar 综述 + agentic disconnect 文献）；②工具接口/反馈是失败的可归因层、且修接口能普惠模型（B + Sigdel&Baral + Gumaan）。这两条最稳。
- 仍属推测/受限的机制：B 的"类排序"被作者自己限定为"本语料性质、非普适”；且干预前后读数含已知混淆（跨配置拼凑、干预 1 单独无效），所以"修 harness 提升 6/6 模型"应读作田野观测而非干净消融。A 受限于"两个模型家族 + 单一客服域"，泛化需更多域验证。
七、必要知识反推
假设一个毫无基础的人要独立完成这两篇工作，他最少必须掌握什么？
7.1 领域知识层
- Agent 轨迹与 next-turn 评测的定义：不懂"轨迹质量 ≠ 轮次平均质量"就无从提出 A 的研究问题。
- 工具调用协议（function calling）与解析：B 的 taxonomy 全部建立在"调用是否被解析、字段是否对齐、证据是否可解析"之上，不懂 JSON Schema/工具契约就看不懂失败分类。
- 生产级 Agent 的运行框架（harness/verifier）：B 的整套发现依赖"服务器如何验证报告、如何拒绝调用、如何记录 ledger"。
7.2 方法论知识层
- 代理指标与构念效度（construct validity）：A 的核心是把"协议"当变量，这要求作者懂"指标测的是哪个构念"。
- 分类法的优先级负载与敏感性分析：B 展示分类顺序如何改变 headline，这是严谨 taxonomy 工作的基本功。
- 重采样/聚类不确定度：B 用按模型聚类重采样而非按 run，因为失败模式显然与模型相关——不懂 Wilson 区间与聚类会让结论被 naive 区间误导。
- 对照实验的"唯一变量"设计：A 固定模型与工作流只变协议；B 固定硬件/提示/任务只变服务器，把 harness 当变量。
7.3 工程知识层
- ledger/事件流作为证据源：B 强调"从 ledger 分析、而非从 sweep 日志"——日志记"请求了什么"，ledger 记"发生了什么"，二者曾实质分歧（某链报 48 次完成实则 0 次）。
- 本地推理引擎的上下文/内存陷阱：无界上下文导致 51GB 驻留、swap 压力——这是真实工程而非理论。
7.4 知识融合的关键节点
两篇论文的创造性都来自同一个融合点：把"默认不可见的背景"（评测协议 / 运行 harness）从常量提升为实验变量。A 在方法论层做这一步，B 在工程层做这一步，C 在真实性层做这一步——这个"变量化背景"的视角，是三篇能合流的根本原因。
八、论文中可以提取的通用性灵感
灵感 1：协议即变量（来自 A）
- 核心思想：当你怀疑一个指标不可信，最干净的做法不是换指标，而是固定对象、只变协议，让协议本身成为自变量。
- 论文证据：同一组 SFT 输出，开卷结论"全面变好"、闭卷结论"几乎全失败"。
- 推广场景：① 任何"单步 vs 端到端"评测对比（代码生成、RAG、规划）；② 训练中用验证指标代理上线指标时；③ A/B 实验把"评测口径"纳入设计。
灵感 2：生产 ledger 是最诚实的证据（来自 B）
- 核心思想：把运行中的每一次事件结构化记录（拒绝码、字段路径、是否解析），让"看不见的失败"可见。B 金句：“看不见形状的失败，无法被修复。”
- 论文证据：拒绝码不记录参数达十天，导致"字段放哪了"完全黑箱；加临时 dump 后才暴露 27/69 把调用写进文本通道。
- 推广场景：① LLM 应用的 observability 设计；② 分布式故障归因；③ 评测平台默认记录"被拒调用的真实参数"。
灵感 3：修 harness 不修模型（来自 B）
- 核心思想：多模型集体失败时，先怀疑接口/契约/反馈而非逐个重训——接口问题修一次、全体受益，距离是"单元"级而非"参数"级。
- 论文证据：5 项服务器侧修复（零模型改动）让 cogito:8b 从 0/30→21/30、glm4 从 0/30→16/30。
- 推广场景：① 多模型统一接入的 API 网关；② 把"错误反馈文案"和"解析器容差"作为基准工件公开（B 对排行榜的建议）；③ “系统 + 多异构组件"的协同优化。
灵感 4：开卷/闭卷二分法（来自 A + C）
- 核心思想：任何"给参考/正确前情"的评测都是开卷，任何"用自己的输出喂自己"的才是闭卷；分数要分项报，不能聚合掩盖。
- 论文证据：A 的 Gemma3 文本轮大涨却工具轮归零，聚合"全轮成功"掩盖工具薄弱；C 的 23.9% 天花板证明真实闭卷会暴跌。
- 推广场景：① 教育评测（过程性 vs 结果性）；② 智能体上线前的"影子模式"自跑；③ 报告 AI 能力时强制披露评测协议。
灵感 5：把混淆当一等公民报告（来自 B）
- 核心思想：无界上下文、swap、跨配置拼凑读数——这些测量混淆会伪装成模型失败。B 把它们写进论文而非抹平，反而成了方法论贡献。
- 推广场景：① 本地/边缘部署的评测；② benchmark 的"运行环境声明"应成为发表要件；③ 复现实验明确记录内存/上下文约束。
结语：三重奏合流
三篇论文在三个不同尺度上敲打了同一个假设——“分数好看了，Agent 就能干活了”：
- A（协议尺度）：开卷 next-turn 指标系统性高估闭卷工作流能力，因为金历史复位了状态、测错了构念。→ 必须闭环。
- C（真实性尺度）：在足够真实的端到端交付里，最强模型也只过 23.9%。→ 必须真实。
- B（归因尺度）：多数失败发生在模型与服务器的接口边界，修 harness 而非修模型即可普惠全体。→ 必须归因到接口层。
对 practitioner 的一句话建议：评测 Agent 时，把协议、真实性、接口归因同时当成变量来设计，而不是把其中任何一个当成不可见的背景。 否则你优化的是分数，交付的是幻觉。
注：C（τ²-bench）仅作定位背景，未占独立章节，符合任务约定。