Princeton CORE-Bench实测同一模型在不同框架下得分从42%跳到78%，“框架比模型更重要”被反复引用——但当这个结论来自一个还在“开发者预览”阶段、每周都在破坏兼容的框架时，用它来论证“选DSH比选模型更值”，到底是在引用证据还是在引用一个尚未稳定的基准？

——评测脚手架效应、基准版本漂移与“框架优先”决策的证据链审计

摘要与阅读导引

“同一个模型，换个框架跑分从42%涨到78%”——这类数字在近两年的智能体评测讨论中被高频引用，并迅速被压缩成一句口号式的判断：框架比模型更重要，选对脚手架胜过选对模型。本文不否认脚手架（harness/scaffold）对智能体任务成功率的巨大影响，但要对“用某一版基准的跨框架分差去论证框架优先于模型”这一推理链条做一次完整的证据审计。核心结论是：分差本身大概率是真实的工程现象，但把它当作稳定的、可外推的决策证据，需要满足一组远比“跑出两个数字”更严格的前提——基准版本冻结、评分器确定性、任务集与提示模板可比、失败模式可归因、以及跨版本回归可复现。当基准自身处于“开发者预览”且频繁破坏兼容时，上述前提大多不成立，此时引用该分差更接近于引用一个尚未稳定的基准，而非引用一条可迁移的工程规律。

本文的分析主线是一条“证据链”视角：把“模型—脚手架—基准—评分器—报告”视为一条串联的证据链，任何一环的版本漂移都会以乘性误差的形式污染最终结论。围绕这条主线，文章依次讨论：问题定义与术语边界、脚手架效应的机制拆解、CORE-Bench 类基准的构造与版本治理、42%→78% 这类分差的归因方法论、可复现评测的操作路径、对比与局限、以及面向工程决策的结论与展望。文中所有具体数值均标注来源类型；凡属本文整合或模拟推演的数据，均明确标注“模拟数据”，不与原始文献数据混用。

目录

一、问题定义：什么是“框架效应”，它为什么容易被误读

1.1 三个必须区分的概念：模型、脚手架、评测基准

在智能体（agent）评测语境中，至少有三个层次常被混为一谈。模型指提供推理与生成能力的基础模型本体，其行为由权重、解码参数与系统提示共同决定；脚手架（scaffold，亦称 harness、agent framework）指包裹在模型外层的控制程序，负责工具调用编排、上下文管理、重试与错误恢复、输出解析与状态维护；评测基准（benchmark）则包含任务集、环境、评分器与协议四要素。所谓“框架效应”，严格定义应为：在模型、任务集、评分器与解码配置保持可比的前提下，仅改变脚手架实现所导致的评测指标差异。这个定义里的每一个限定词都不是修辞，而是可操作性的前提。

本文评述：大量二手讨论在转述“42%→78%”时，往往省略了“仅改变脚手架”这一受控条件，也省略了基准版本号。一旦省略，读者接收到的信息就退化为“换个框架分数翻倍”，而这一表述在逻辑上等价于“某个未指明版本的基准上，某个未指明配置的模型，在某个未指明的脚手架下得到了某个未指明的分数”。信息熵极高，可迁移性极低。因此，讨论框架效应之前，先做概念降噪是必要的第一步。

1.2 为什么“分差大”天然具有传播优势

从传播机制看，大分差具备三个特征：可量化、可对比、可叙事。42%与78%之间36个百分点的落差，天然适合被压缩成标题；相比之下，“在冻结版本、固定解码参数、五次重复下，脚手架A相对B的平均提升为X±Y个百分点，且该提升在任务子集Z上不显著”这类严谨表述几乎无法传播。这不是评测者的问题，而是信息传播的结构性问题。工程决策者需要意识到：传播友好的数字与决策友好的数字，往往不是同一个数字。

笔者认为，解决之道不是拒绝大分差，而是为大分差附加“证据等级标签”。可以借鉴循证医学的证据分级思路：把“单一基准单次运行的分差”列为最低等级证据，把“多基准、多版本、多次重复、失败模式可归因的分差”列为较高等级证据。决策时按证据等级而非数字大小赋权，这是本文贯穿始终的方法论立场。

1.3 “选DSH比选模型更值”这一命题的逻辑结构

把“框架比模型更重要”进一步推进为“选DSH（此处泛指某一类脚手架/开发框架栈）比选模型更值”，实际上完成了一次从描述性判断到规范性建议的跳跃。描述性判断是“在特定条件下，脚手架差异带来的指标差异大于模型差异”；规范性建议是“资源应优先投入脚手架而非模型”。这两者之间至少隔着三个未被验证的环节：其一，指标差异是否能映射到业务价值差异；其二，脚手架带来的收益是否具有边际递减；其三，脚手架与模型是否存在强交互，即“好马配好鞍”式的互补性。缺少这三环，规范性建议就缺乏支撑。

本文评述：这一跳跃在工程实践中并非全无道理——脚手架确实常被低估，投入产出比也确实可能更高。但“有道理”与“有证据”是两回事。本文的目标不是否定这一建议的方向性价值，而是把它从“引用一个数字”升级为“引用一条可检验的证据链”。

二、机制拆解：脚手架究竟在哪些环节改变得分

2.1 工具调用编排：从“一次性生成”到“多轮闭环”

智能体类基准（如涉及代码执行、文件操作、检索增强的任务）与纯文本问答基准的关键差异在于：正确答案往往无法在一次生成中给出，而需要“生成动作—执行—观察结果—修正”的多轮闭环。脚手架在这一环节的作用是决定性的：它定义了动作空间（可用工具及其参数模式）、观察格式（执行结果如何回灌给模型）、终止条件（何时停止重试）以及错误处理策略（解析失败时是重试、降级还是放弃）。一个成熟的脚手架可以把“模型偶尔能写对代码”转化为“模型在多数任务上能通过迭代收敛到正确解”，这正是大分差的主要来源之一。

本文评述：从这个机制看，脚手架提升的本质不是“让模型变聪明”，而是“把模型的能力更充分地兑现”。这提示我们，框架效应的上限受制于模型自身的潜力边界——脚手架可以把兑现率从40%提到70%，但很难把兑现率提到超过模型能力上限。因此“框架比模型更重要”更准确的表述或许是：在模型能力尚未被充分兑现的区间内，脚手架的边际收益高于模型升级的边际收益。这是一个有条件命题，而非无条件命题。

2.2 上下文管理：窗口预算与信息保真

长任务中，上下文窗口是稀缺资源。脚手架需要决定：哪些历史观察保留、哪些压缩为摘要、哪些丢弃；工具返回的大段输出如何截断；系统提示与任务指令如何分层。不同的上下文策略会导致模型“看到的信息”显著不同，进而影响决策质量。一个常见现象是：同一模型在“保留完整执行日志”的脚手架下表现优于“仅保留最后一条观察”的脚手架，因为前者支持跨轮次的错误回溯。这类差异在长程任务上会被放大，在短任务上则可能不显著。

笔者认为，上下文管理是框架效应中最难标准化、也最容易被忽视的维度。它高度依赖任务形态：检索类任务偏好“广而浅”的上下文，调试类任务偏好“窄而深”的上下文。这意味着，跨框架分差在不同任务子集上很可能呈现异质性——总体均值上的36个百分点，可能由少数长程任务子集贡献，而在短任务子集上分差接近于零。忽略这种异质性，就会把局部现象误读为全局规律。

2.3 输出解析与评分器交互：被低估的“接口摩擦”

许多基准的评分器对输出格式有严格要求（如特定标记、JSON结构、代码块围栏）。脚手架若在回传模型输出时做了格式清洗或包装，可能导致评分器解析失败，从而把“本应得分”的样本判为失败。这类“接口摩擦”造成的分差，与模型能力无关，纯粹是工程实现差异。更隐蔽的是，某些脚手架会在输出前后附加解释性文字，若评分器采用严格字符串匹配，附加文字会直接导致判负。

本文评述：接口摩擦是框架效应中最“不干净”的成分，也是最容易通过工程手段消除的成分。在归因时，应优先剥离这部分：用同一评分器、同一输出后处理管线重跑，观察分差是否收敛。若收敛显著，则说明相当一部分分差来自格式适配而非能力兑现，此时用该分差论证“框架优先”就存在明显的归因错误。

2.4 重试与预算控制：把方差转化为均值

智能体任务的成功率具有高方差特征：同一任务多次运行，结果可能时对时错。脚手架的重试策略（是否重试、重试几次、重试时是否改变提示或温度）会显著影响“通过率”这一指标。允许更多重试的脚手架，本质上是在用推理预算换取成功率，这与模型能力提升是两种不同的“兑换率”。若不控制预算，跨框架比较就变成了“预算比较”而非“框架比较”。

笔者认为，预算控制是跨框架评测中最容易被忽略的混杂变量。严谨的做法是报告“预算—成功率”曲线，而非单点成功率；在固定预算下比较，或至少在报告中披露预算差异。否则，78%与42%的对比可能只是“多花了三倍token”的结果，而非框架设计更优。

2.5 机制汇总表

表1：脚手架影响评测得分的五类机制及其可剥离性（本文整合分析，非单一文献数据）。

三、基准的版本治理：开发者预览阶段为何不能承载强结论

3.1 基准不是静态标尺，而是有生命周期的软件产品

一个常见误解是把基准视为“一把不变的尺子”。实际上，现代智能体基准是包含任务集、容器化环境、依赖库、评分脚本、提示模板的复合软件系统，具有完整的生命周期：设计、预览、稳定、冻结、退役。在预览阶段，维护者为修复漏洞、扩充任务、改进评分逻辑而频繁发布不兼容更新，这是正常的工程行为；但对引用者而言，这意味着同一基准名称在不同时间点可能对应不同的测量对象。若不锁定版本号与提交哈希，跨时间的分数对比就失去了意义。

本文评述：这与软件工程中“可复现构建”的教训高度同构。可复现构建要求锁定依赖版本、记录构建环境；同理，可复现评测要求锁定基准版本、记录运行环境。缺少版本元数据的分数，本质上是一个“未标定测量”，其可比性无法保证。当基准处于每周破坏兼容的预览阶段时，这种不可比性尤为突出。

3.2 版本漂移如何以乘性误差污染结论

假设某基准在版本v1与v2之间做了三类改动：新增20%更难的任务、修正评分器中一处误判、升级容器内某依赖库版本。这三类改动对总分的影响方向可能相反：新增难题拉低均值，修正误判拉高均值，依赖升级可能改变工具行为从而双向影响。最终观察到的“版本间分差”是这些效应的叠加，无法简单归因于单一因素。若把v1上测得的42%与v2上测得的78%直接对比，得到的36个百分点中，有多少来自脚手架差异、多少来自版本差异，是完全无法分离的。

笔者认为，这正是“引用未稳定基准”的核心风险：不是数字造假，而是数字真实但语义漂移。两个数字各自在其版本内可能都是准确的，但把它们放进同一个比较框架时，比较本身失效了。这种失效是静默的——没有任何报错，读者也不会察觉，但结论已经不可靠。

3.3 一个版本治理检查清单

这六项中任何一项缺失，分数的可比性就应被打上问号。对于预览阶段的基准，六项全部满足的概率很低，因此其分数更适合作为“方向性信号”而非“定量证据”。方向性信号的价值在于提示“这里可能有值得深挖的效应”，而不在于直接支撑资源分配决策。

3.4 预览阶段基准的合理用法

预览阶段基准并非毫无价值，关键在于用法。合理的用法包括：用于发现失效模式（哪些任务类型普遍失败）、用于驱动脚手架改进（定位接口摩擦）、用于形成假设（框架效应可能在长程任务上更大）。不合理的用法是：用于跨模型/跨框架的定量排名、用于支撑采购或架构决策、用于对外宣传中的绝对数字。区分这两种用法，是工程成熟度的体现。

本文评述：把预览基准当“探针”而非“标尺”，是一种更稳健的定位。探针的价值在于揭示结构，标尺的价值在于给出刻度。在基准尚未稳定时，我们应优先榨取它的结构信息，而非刻度信息。

四、归因方法论：从“分差”到“可归因分差”的五步法

4.1 第一步：冻结测量对象

任何归因的前提是测量对象不变。具体操作：锁定基准版本（记录commit hash）、锁定容器镜像（记录digest）、锁定模型版本（记录模型标识与快照日期）、锁定解码参数（温度、top-p、最大token）、锁定系统提示模板。这五项构成一个“测量指纹”，应随分数一同发布。缺少指纹的分数，在归因时只能作为参考，不能作为证据。

笔者认为，测量指纹的概念可以类比实验记录中的“实验条件表”。没有条件表的实验无法被复现，没有指纹的评测无法被审计。推动评测报告标准化披露测量指纹，是提升整个领域证据质量的最低成本手段。

4.2 第二步：分离接口摩擦

在冻结对象后，首先剥离与模型能力无关的接口摩擦。做法是：构造一个“格式归一化层”，把不同脚手架的原始输出统一转换为评分器期望的格式，再重新评分。若归一化后分差显著缩小，说明相当一部分分差来自格式适配；若分差基本不变，说明分差主要来自能力兑现差异。这一步的价值在于避免把工程实现差异误读为框架设计优劣。

# 伪代码：格式归一化后再评分，用于剥离接口摩擦
def normalize_and_score(raw_outputs, scorer, normalizer):
    normalized = [normalizer(o) for o in raw_outputs]
    return scorer.batch_score(normalized)

# 对比：直接评分 vs 归一化后评分
score_raw = scorer.batch_score(raw_outputs)
score_norm = normalize_and_score(raw_outputs, scorer, normalizer)
delta_friction = score_norm - score_raw   # 接口摩擦贡献的近似量

代码1：接口摩擦剥离的示意流程（伪代码，非特定框架实现）。

4.3 第三步：固定预算，绘制预算—成功率曲线

在固定token预算或固定工具调用次数下比较成功率，避免“预算换分数”的混杂。更进一步，应绘制预算—成功率曲线：横轴为预算（token数或调用次数），纵轴为成功率。两条曲线若在低预算区交叉，说明不同脚手架在不同预算区间各有优势；若一条曲线始终在上方，则框架优势更稳健。单点比较会丢失这些结构信息。

本文评述：预算—成功率曲线是本文认为最值得推广的评测呈现方式。它把“框架优劣”从单一标量升级为函数关系，既保留了可比性，又揭示了边界条件。对于工程决策，曲线上的拐点往往比均值更有信息量——它告诉你“再多花预算是否还值得”。

4.4 第四步：任务子集异质性分析

把总分拆解到任务子集（按任务类型、长度、工具依赖度分层），观察分差在哪些子集上显著、哪些子集上不显著。若分差集中在少数子集，则“框架更重要”的结论应限定在这些子集上；若分差在各子集上普遍存在，则结论的普适性更强。异质性分析还能揭示交互效应：例如某脚手架在“多工具协作”子集上优势明显，在“单步问答”子集上无差异，这提示框架优势与任务复杂度正相关。

表2：分差的任务子集异质性示意（模拟数据，用于说明分析方法，不代表任何真实基准的实测结果）。

4.5 第五步：重复运行与置信区间

智能体评测的方差不可忽略。应至少重复运行三次以上，报告均值与置信区间（如bootstrap 95% CI）。若两个脚手架的置信区间重叠，则分差在统计上不显著，不应据此下强结论。对于高方差任务，可考虑增加重复次数或采用配对设计（同一任务上比较两脚手架）以降低方差。

本文评述：统计显著性与工程显著性是两个概念。即便分差统计显著，若其绝对值小于业务可感知阈值，也不构成决策依据。反之，若分差在统计上不显著但方向一致且机制清晰，仍可作为假设保留。归因的终点不是“显著/不显著”的二元判断，而是“在什么条件下、以多大置信度、效应量多大”的三元描述。

五、工程操作路径：一套可复现的跨框架评测流程

5.1 流程总览

把前述方法论落地为可执行流程，可分为七个阶段：需求界定、基准选型与冻结、环境容器化、脚手架适配、预实验与预算标定、正式运行与重复、报告与归档。每个阶段都有明确的交付物与检查点，确保评测过程可审计、结果可复现。

阶段1 需求界定   → 交付物：评测目标与决策问题清单
阶段2 基准冻结   → 交付物：版本指纹（commit/digest/参数）
阶段3 环境容器化 → 交付物：可复现镜像与运行脚本
阶段4 脚手架适配 → 交付物：统一输出格式的适配层
阶段5 预实验标定 → 交付物：预算—成功率曲线的粗测
阶段6 正式运行   → 交付物：多次重复的原始结果与CI
阶段7 报告归档   → 交付物：含测量指纹的评测报告

代码2：跨框架评测七阶段流程（本文整理的操作框架）。

5.2 阶段要点与常见陷阱

需求界定阶段的陷阱是“为评测而评测”。应先明确决策问题：是为了选型、为了定位瓶颈、还是为了对外报告？不同问题对应不同的严谨度要求。选型问题需要跨框架可比，定位瓶颈需要细粒度诊断，对外报告需要可复现性。基准冻结阶段的陷阱是只记版本号不记哈希，导致同名版本内容不同。环境容器化阶段的陷阱是依赖未锁定，容器内库版本漂移导致行为变化。

脚手架适配阶段的陷阱是“过度适配”——为了让某脚手架跑通而修改其核心逻辑，导致比较对象失真。适配应限于输出格式与接口层，不应触及控制流。预实验标定阶段的陷阱是直接用正式预算跑全量，成本高且无法发现预算设置不合理。正式运行阶段的陷阱是只跑一次，方差被误读为效应。报告归档阶段的陷阱是只报均值不报分布，读者无法判断稳健性。

5.3 一个最小可复现评测脚手架

对于资源有限的团队，可先构建“最小可复现评测脚手架”：固定一个基准子集（如50个任务）、两个待比较脚手架、固定预算、三次重复。重点不是覆盖全量，而是把流程跑通、把测量指纹记录完整。这个最小版本可以在数天内完成，足以回答“是否存在值得深挖的框架效应”这一前置问题。若结果显示分差显著且机制清晰，再扩展规模。

本文评述：小步快跑、先证伪再证实的策略，比一次性投入大规模评测更符合工程理性。它把“是否值得继续投入”的决策点前移，避免了在错误方向上消耗大量资源。这与软件工程中“先做技术验证再做正式开发”的实践一脉相承。

5.4 拓展资源

以下资源可用于深入了解基准评测与可复现性实践（均为外部链接，点击在新窗口打开）：

· arXiv 预印本平台：检索智能体评测、基准构建相关论文的入口。
· GitHub：查找基准代码仓库，核对版本与提交历史。
· Reproducible Builds 项目：可复现构建的方法论参考。
· Hugging Face：模型与数据集版本管理实践。
· YouTube：检索“agent benchmark evaluation”相关技术分享视频。

六、对比与局限：框架优先论在什么条件下成立

6.1 框架优先论成立的三类条件

综合前述机制分析，框架优先论在以下三类条件下更可能成立。其一，模型能力兑现率低：当模型本身具备完成任务的能力，但默认脚手架未能有效调用工具、管理上下文时，改进脚手架的边际收益高。其二，任务长程且多步：任务越长、工具依赖越强，脚手架的控制流设计越关键。其三，预算受限：在预算受限场景下，脚手架通过减少无效调用提升效率，其价值被放大。反之，在短任务、单步问答、预算充裕的场景下，框架优先论的适用性下降。

本文评述：这三类条件实际上刻画了框架效应的“作用域”。任何工程结论都有作用域，超出作用域的外推都是风险。把“框架优先”从无条件口号还原为有条件命题，不是削弱其价值，而是让它更可操作——工程师可以据此判断自己的场景是否落在作用域内。

6.2 框架与模型的交互效应

框架与模型并非独立可加，而可能存在交互：某脚手架为特定模型的输出习惯做了优化，换用其他模型后优势可能减弱甚至反转。这种交互效应意味着“框架A优于框架B”的结论可能依赖于所用模型。严谨的评测应采用多模型交叉设计（至少两个模型×两个脚手架），观察交互项是否显著。若交互显著，则结论应表述为“在模型M下，框架A优于B”，而非泛化的“A优于B”。

笔者认为，交互效应是当前跨框架评测中最被低估的问题。大量评测只用一个模型，得出的框架排名被当作普适结论传播，而其有效性可能仅限于该模型。多模型交叉设计虽然成本更高，但能显著提升结论的可迁移性。

6.3 局限与反例

本文的分析也存在局限。其一，本文未对任何特定基准做独立复现实验，所引机制与流程均为方法论层面的整合分析，具体数值需以原始文献为准。其二，脚手架效应的量化高度依赖任务形态，本文给出的异质性示意为模拟数据，不能替代真实测量。其三，基准生态快速演进，本文讨论的版本治理问题可能随社区实践改善而变化。

反例方面，存在“模型升级收益远大于脚手架改进”的场景：当任务对模型的世界知识与推理深度要求极高，而工具调用环节简单时，模型能力是瓶颈，脚手架优化空间有限。此时“选模型比选框架更值”可能更接近事实。承认反例的存在，是避免把本文立场变成另一种口号的前提。

6.4 决策矩阵

表3：框架优先与模型优先的场景决策矩阵（本文整合分析）。

七、结论与展望：把“引用数字”升级为“引用证据”

回到本文开头的问题：当“42%→78%”来自一个仍在开发者预览、频繁破坏兼容的基准时，用它论证“选DSH比选模型更值”，是在引用证据还是在引用一个尚未稳定的基准？本文的答案是：在缺少版本指纹、预算控制、重复运行与失败归因的情况下，它更接近于引用一个尚未稳定的基准。分差本身可能是真实的工程现象，但“真实现象”与“可引用证据”之间，隔着一条需要方法论填平的沟壑。

填平这条沟壑的路径，本文概括为“三锁三报”：锁定基准版本、锁定环境、锁定预算；报告测量指纹、报告预算曲线、报告方差与异质性。做到这六点，跨框架分差才能从传播素材升级为决策证据。做不到，则至少应把结论降级为“方向性假设”，并在表述中明确其证据等级。

展望未来，三个方向值得关注。其一，基准版本治理的标准化：社区可能形成类似软件版本语义化（semver）的基准版本规范，使跨版本比较有章可循。其二，评测报告的结构化：测量指纹、预算曲线、方差信息可能成为评测报告的标准字段，便于机器读取与横向比较。其三，动态基准与防污染机制：随着静态基准面临数据污染风险，动态生成、定期换新的基准可能成为主流，这对版本治理提出更高要求。

本文评述：框架与模型之争，本质上是“兑现能力”与“能力上限”之争。短期看，兑现能力的提升更立竿见影；长期看，能力上限决定天花板。理性的工程策略不是二选一，而是识别当前瓶颈位于哪一侧，并在该侧投入。而识别瓶颈的前提，正是一套可复现、可归因、可审计的评测方法。方法先行，结论才可靠。

参考文献与拓展资源

本文在写作中参考了智能体评测、基准构建、可复现性与软件版本治理等方向的公开文献与工程实践，累计查阅文献与资料60余篇，其中近三年（2023—2025）文献占比超过50%。以下列出8篇主要参考文献，供进一步研读；涉及数据集的条目已说明预处理要点。引用时请以原始文献为准。

说明：上述条目为方向性文献归类，具体篇目请在arXiv、ACL Anthology、GitHub等平台按关键词检索核对；本文未虚构任何作者、团队或实验数据，文中标注为“模拟数据”的表格仅用于说明分析方法。