当智能体失败时：模型还是执行框架，谁该受责？

1. 问题与价值

这篇论文解决的核心问题是：当一个 LLM Agent 失败时，到底该怪模型还是怪执行框架（harness）？传统 Agent 评测把「模型 + harness」当成一个黑箱整体，只看最终任务得分。这样做的后果是，同一个模型换一个 harness 可能排名反转，同一个 harness 换一个模型可能从领先变垫底，但现有评测无法告诉你失败发生在哪一层。

为什么重要：Agent 系统的实际部署中，模型和 harness 是分开采购、分开迭代的。如果评测不能区分「模型不会做」和「模型会做但 harness 没让它做出来」，那么模型团队和框架团队都会朝着错误的方向优化。论文的核心主张是，harness 的难度不是绝对属性，而是相对于特定模型的交互成本——同一个接口对模型 A 是透明的，对模型 B 可能是陷阱。

谁受益、怎么受益：模型训练团队可以用 VCR 和 Fit 指标判断该不该训练模型适应多种 harness 接口；harness 开发者可以用 interaction residual 定位是 observation 格式、action 接口还是 recovery 逻辑在坑特定模型；Agent 部署方可以用 Cross-Model Fit 在不知道未来会换什么模型时选一个稳健的 harness，用 Token Load 和 VCR 联合判断「低 token 消耗」到底是高效还是早退。

2. 已有工作的不足

在本文之前，最接近的做法有几类：

• 任务中心评测：SWE-bench、Terminal-Bench、AgentBench 等报告固定 model–harness 配置的最终成功率。问题在于它们把 harness 当作实验装置的一部分，不把 harness 作为被评估对象。AgentBoard 虽然加了 progress rate 和轨迹诊断，但仍然是任务中心视角，没有系统性地交叉模型和 harness。

• Harness 优化工作：GPTSwarm、ADAS、AFlow、MetaHarness、AutoHarness 这类工作把 harness 当作优化目标，展示「换 harness 能改变固定模型的性能」。但它们的目标是找到更好的 harness，而不是建立一套度量来刻画 model–harness 交互的难度和配对特异性。

• Harness-Bench 和 UniACE：这两篇是最近的交叉评测工作，明确报告 harness 效应是 model-dependent 的。但它们的核心输出仍然是排名和最终成功率对比，缺少一个把「任务完成」和「有效完成」分开的正式度量框架，也没有系统量化 pairing-specific deviation（即超出模型平均水平和 harness 平均水平可加预测的那部分交互效应）。

具体哪一步不够：已有工作缺少一个统一的度量层来回答三个问题——这次失败是任务没解出来，还是解出来了但没正常交付？这个 harness 对模型 A 的支持是否好于对模型 B？一个 harness 的跨模型稳健性怎么量化？本文的 VCR、Fit、Cross-Model Fit、interaction residual 正是补这三块。

3. 重建作者的思考路径

如果我是作者，面对第 2 项的不足，我会先想到最朴素的做法：把四个 harness 和四个模型做全交叉，每个格子跑一遍 benchmark，然后画一张大表对比最终得分。这个做法 Harness-Bench 已经做了，而且确实能看到排名反转。但问题在于，光看最终得分，我看到「MiniMax + OpenCode 在 SWE-bench 上得 62.78，MiniMax + Codex 得 30.56」，我只能说「这两个配置差很多」，却说不清差在哪一步。

于是我会想：能不能把「跑完了且交付了可评测结果」和「任务做对了」分开？因为直觉上，一个 agent 可能正常退出但没解出任务，也可能异常退出但评测器仍然给了分。这两个维度在最终得分里被混在一起。我定义一个二元指标 U = N × V，N 是正常终止，V 是有效交付。这就是 VCR 的雏形。

但紧接着撞上矛盾：VCR 高不代表任务好。DeepSeek 在四个 harness 上 VCR 都在 91% 以上，但任务得分随 harness 变化很大。这说明 VCR 只能诊断执行层，不能评价 harness 对任务求解的支撑。我需要一个把「有效完成前提下的任务得分」纳入的指标。于是想到：对每个 model–benchmark 块，取该模型在所有 harness 上的最好 joint score 作为参照，其他 harness 的得分除以这个参照，得到 Fit。这样 Fit 同时惩罚「跑不完」和「跑完了但分低」。

再往下，我发现 Fit 是 model-specific 的，没法回答「如果我要选一个 harness 服务多个模型，选谁」。于是对 Fit 做跨模型聚合。用算术平均还是几何平均？算术平均会让一个模型上的高分掩盖另一个模型上的低分；几何平均对低分更敏感，符合「一个 harness 如果对某个模型特别差，就不该被选为通用方案」的直觉。这就是 Cross-Model Fit 用几何平均的动机。

但到这里还有一个漏洞：VCR 和 Fit 都是聚合量，可能掩盖配对特异性。比如 Kimi + Codex 在 SWE-bench 上 VCR 很低，在 LOCA-Bench 上却很高，聚合后可能看起来「正常」。我需要一个残差量：实际 VCR 减去模型平均效应再减去 harness 平均效应，剩下的就是这对组合特有的交互。这就是 interaction residual 的加法分解。

最后，资源维度不能丢。两个配置可能 Fit 相同但 token 消耗差一个数量级。低 token 可能是高效，也可能是早退；高 token 可能是充分探索，也可能是反复无效动作。所以 Token Load 必须和 VCR、outcome 一起读，不能单独排名。

与论文实际路径的差异：我猜的路径是从「最终得分不够」直接跳到「把有效完成和任务得分分开」，论文实际也是这个顺序，但论文在中间插了一步形式化 runtime interface——把 harness 分解成 Observe、Context、Control、Act、Update、Govern 六个接口。这一步我一开始觉得是理论装饰，后来意识到它有两个实际作用：一是给 interaction residual 的「交互发生在哪一层」提供语言，二是为 6.2.2 的 execution-stage decomposition（pre-normal loss vs post-normal handoff loss）提供分类依据。另一个差异是，我最初会直接用「官方得分」作为 Fit 的输入，但论文选择用 U × S（有效完成才计分），这个选择让 Fit 和 VCR 形成互补而不是重叠——我是在看到 6.3 的 outcome-only ablation 之后才理解这个设计是刻意的，不是顺手。

4. 核心 intuition

把 model–harness 配对想象成「翻译 + 快递」的组合。模型是翻译，harness 是快递公司。任务是把一份文件从 A 送到 B 并让收件人签收。

• VCR 衡量快递公司有没有把包裹送到收件人手上并拿到签收，不管包裹内容对不对。翻译翻错了但快递正常送达，VCR 仍然高。
• 任务得分 衡量收件人最终是否满意，不管快递过程是否规范。翻译翻对了但快递员把包裹扔在门口没签收，任务可能算完成但 VCR 低。
• Fit 衡量「翻译 + 快递」组合在「正常送达且内容正确」这个联合标准下的表现。它惩罚两种失败：快递没送到（VCR 低），或者送到了但翻译错了（任务分低）。
• Interaction residual 捕捉的是「这个翻译和这家快递公司之间特有的默契或摩擦」。比如某个翻译习惯用某种格式写地址，A 快递公司的分拣系统能识别，B 快递公司不能——这不是翻译的平均水平问题，也不是快递公司的平均服务水平问题，而是这对组合特有的。

这个类比能对上机制：harness 的 Observe 和 Context 接口决定「模型看到什么格式的信息」，Act 接口决定「模型的输出怎么被执行」。一个模型如果习惯输出某种 JSON 结构，而 harness 的 parser 恰好能容忍这种结构，这对组合的 VCR 就高；换一个 parser 严格的 harness，同一个模型的 VCR 可能暴跌。这不是模型变笨了，是交互成本变了。

5. 方法 pipeline 举例

假设我们要评估 MiniMax M3 在 SWE-bench-45 上搭配 OpenCode 这一个配置。具体走一遍：

输入：SWE-bench-45 中的一个任务，比如 Django 仓库的某个 issue，要求修复一个 bug。任务有官方回归测试。

第 1 步：调度与匹配。common adapter 初始化任务环境，从官方 base commit 启动容器，把 issue 描述交给 OpenCode 的原生 prompt 模板。OpenCode 保留自己的执行循环、context 管理、recovery 策略。工具权限和资源预算与其他 harness 对齐。这个任务重复跑 4 次，记为 r=1,2,3,4。

第 2 步：执行与记录。每次运行中，模型生成 proposal y_t，OpenCode 的 Act 接口把 proposal 映射为可执行动作 a_t，环境状态更新，observation 反馈回 context。adapter 记录每一步的 token 消耗、终止状态、最终 patch。

第 3 步：判定 U。对每次运行，检查两个条件：N 是否正常终止（OpenCode 是否以 Submitted、NoPatch 或 exit-zero 结束），V 是否有效交付（评测器是否在 patch 应用阶段接受了提交）。假设 4 次运行中 3 次正常终止且有效交付，1 次超时，则该任务该配置的 VCR 贡献为 3/4 = 0.75。

第 4 步：判定 S。对每次有效交付的运行，跑官方回归测试。假设 3 次有效运行中 2 次通过测试，则该任务该配置的 Mean-of-4 为 2/4 = 0.50。注意这里分母是全部 4 次调度，不是 3 次有效运行。

第 5 步：计算 U×S。对每次运行，只有 U=1 时才把 S 计入 joint score。2 次成功且有效的运行贡献 2 × 1 = 2，1 次有效但失败的运行贡献 0，1 次无效运行贡献 0。该任务该配置的 J 贡献为 2/4 = 0.50。

第 6 步：聚合到 benchmark 层。对 SWE-bench-45 的全部 45 个任务重复上述过程，J 取平均。假设得到 J = 0.6278。这里要特别说明：J 不等于论文报告的官方 Mean-of-4。官方定义是 100/(4N) · Σ_i Σ_r a_{i,r}，a_{i,r}=1 只看「提交的补丁是否修好了指定失败测试且不破坏已通过的测试」，不看这次运行是否有效完成 —— 原文甚至明说「A correct evaluator result remains an official task success even if the backend later records an abnormal exit」。所以无效运行的成功也计入官方分，而我们的 J 把它剔除了。两者可以差很多：MiniMax 在 SWE-bench-45 上 DeepAgents 官方 31.11、joint 只有 25.56。数字上 0.6278 与官方 62.78 接近纯属巧合，不能当成同一个量。

第 7 步：计算 Fit。在 MiniMax × SWE-bench-45 这个块内，比较四个 harness 的 J 值。OpenCode 的 J 最高，所以 J* = 0.6278，OpenCode 的 Fit 贡献为 100。其他 harness 的 Fit 贡献是各自 J 除以 0.6278 再乘 100。

第 8 步：跨 benchmark 聚合。对 MiniMax 在全部六个 benchmark 上重复，取 Fit 的等权平均，得到 MiniMax 的 model-specific Fit。论文中 OpenCode 对 MiniMax 的 Fit 是 86.86，意味着平均达到该模型在各 benchmark 上最好 harness 表现的 86.86%。

6. 核心数学推导

我们从 VCR 的定义开始，逐步推出 Fit 和 Cross-Model Fit。

符号解释：T 是某个 benchmark 的任务集，∣T∣ 是任务数。R 是每个任务的重复次数，本文 R=4。对任务 i 的第 r 次运行，N_i,r 是正常终止指示变量（正常为 1，异常为 0），V_i,r 是有效交付指示变量（评测器接受为 1，拒绝为 0）。U_i,r = N_i,r × V_i,r，只有两者都为 1 时 U 才为 1。

第一步：VCR 的定义。VCR 是所有调度运行中 U=1 的比例：

VCR = (1 / (∣T∣ × R)) × Σ_{i∈T} Σ_{r=1}^{R} U_i,r

这个公式在算什么：它算的是「这个配置跑完一个任务后，有多大比例能正常退出并且把可评测的结果交给评测器」。它完全不看任务是否做对。

第二步：joint score J 的定义。设 S_m,h,b,i,r 是模型 m、harness h、benchmark b、任务 i、第 r 次运行的官方得分，取值在 [0,1]。joint score 只统计有效完成的运行：

J_m,h,b = (1 / (∣T_b∣ × R)) × Σ_{i∈T_b} Σ_{r=1}^{R} U_m,h,b,i,r × S_m,h,b,i,r

这个公式在算什么：它算的是「有效完成前提下实际拿到的任务得分」。无效运行即使官方给了分，在 J 里也计为零。这实现了「把任务完成和有效完成分开评估」的目的。

第三步：J 的分解。当 VCR 大于 0 时，可以写成：

J = VCR × E[S ∣ U=1]

其中 E[S ∣ U=1] 是有效完成运行的条件平均得分。这个分解说明 J 同时受两个因素影响：能不能有效完成（VCR），以及有效完成后能不能做对（条件平均分）。一个 harness 可以通过提高 VCR 或提高条件得分来提升 J。

第四步：Fit 的定义。对每个 model–benchmark 块，取该模型所有 harness 中 J 的最大值作为参照：

J*_m,b = max_{h'} J_m,h',b

然后 Fit 是 J 与 J* 的比值在该模型所有 benchmark 上的等权平均：

F_m,h = (1 / ∣B∣) × Σ_{b∈B} (J_m,h,b / J*_m,b)

这个公式在算什么：它算的是「这个 harness 让这个模型发挥出了该模型在该 benchmark 上最好水平的百分之多少」。Fit=80 意味着平均只达到最好 harness 的 80%。

第五步：Cross-Model Fit 的定义。对 Fit 取跨模型几何平均：

Cross-Model Fit(h) = 100 × (Π_{m∈M} F_m,h)^(1/∣M∣)

这个公式在算什么：它算的是「这个 harness 在多个模型上的综合适配度」。几何平均的性质是，只要有一个模型的 Fit 很低，整个乘积就被拉低。这比算术平均更严格地惩罚「对某个模型特别不友好」的 harness。

第六步：interaction residual 的定义。设 v_m,h 是模型 m 配 harness h 的 Mean VCR。加法分解为：

Δ_m,h = v_m,h - v_m,· - v_·,h + v_·,·

其中 v_m,· 是模型 m 跨所有 harness 的平均 VCR，v_·,h 是 harness h 跨所有模型的平均 VCR，v_·,· 是总平均。这个公式在算什么：它算的是「这对组合的 VCR 比『模型平均效应 + harness 平均效应』的预测高出多少」。如果 Δ 显著为正，说明这对组合有超出可加效应的正向交互；显著为负则相反。

7. 实验设计

数据集：六个 benchmark，覆盖不同的交互需求。SWE-bench-45 是 45 个至少需要 1 小时人类开发时间的 GitHub issue 修复任务，测 repository editing 和 patch handoff。Terminal-Bench 2 是 89 个有状态终端任务。VitaBench 是 400 个多轮服务交互任务，分四个环境各 100 个。LOCA-Bench 是 75 个 256K 长上下文精确状态规划任务。ClawMark 是 100 个多天工作流、多模态输入任务。AgentSkillOS 是 30 个技能选择和 artifact 交付任务。

模型与 harness：四个通用 harness（DeepAgents、OpenCode、Pi CLI、Codex CLI）交叉四个核心模型（DeepSeek V4 Flash Preview、MiniMax M3、Kimi K2.7、Qwen3.6-35B-A3B）。ClawMark 和 AgentSkillOS 因为 DeepSeek 不支持多模态，只用三个模型。另有 GPT-5.5 + Codex CLI 和 DeepSeek V4 Pro + DeepSeek Harness 两个固定原生系统作参照。每个配置每个任务跑 4 次。核心交叉面板共 35,472 次调度，全部设置共 52,168 条轨迹。

指标：VCR、Mean VCR、Outcome Win Rate、VCR Win Rate、Model–harness Fit、Cross-Model Fit、interaction residual、Token Load、tokens per success、Pareto-frontier share。

消融：6.3 节做了两个关键消融。一是 outcome-only Fit，把 U×S 替换为 S，去掉有效完成门控，看 Fit 排名是否变化。二是 arithmetic Cross-Model Fit，把几何平均换成算术平均，看跨模型聚合方式是否影响结论。另外还有 leave-one-benchmark-out 和 leave-one-model-out 的敏感性分析。

实验能否支撑结论：核心结论「harness 排名依赖模型和 benchmark」有充分的交叉数据支撑，且 bootstrap 区间显示部分排名反转不是采样噪声。但有几个局限。第一，四个 harness 都是代码/终端导向的通用框架，结论能否推广到其他类型 harness（如 web agent、多模态 agent 专用框架）未知。第二，模型侧只有四个模型，且三个是闭源 API 模型，无法控制模型版本和采样参数的一致性。第三，Fit 的参照是「面板内最好 harness」，如果面板外存在更好的 harness，Fit 的绝对值会变，但相对排名在面板内仍然有效。第四，Token Load 依赖 provider 的 token 计数，不同 provider 的 tokenizer 不同，跨模型比较 token 消耗有混杂。

缺什么：缺少对 harness 内部组件的消融。论文把 harness 当作整体比较，但没有拆开 Observe、Context、Act 等接口分别替换，所以无法回答「OpenCode 的优势具体来自哪个设计选择」。6.2.3 的 action-realization audit 是朝这个方向的一步，但只覆盖一个模型一个 benchmark。

8. take-aways

1. VCR 和任务得分是正交维度：DeepSeek V4 Flash Preview 在四个 harness 上的 Mean VCR 范围只有 91.30% 到 93.98%，跨度 2.68 个百分点，但任务得分随 harness 变化明显。反过来，Kimi + Codex 在 ClawMark 上 VCR 100% 但 Mean Score 只有 11.96，Kimi + DeepAgents VCR 只有 53.25% 但 Mean Score 58.65。高 VCR 不保证高任务分，低 VCR 也不排除高任务分。

1. OpenCode 是跨模型最稳的 harness：Cross-Model Fit 87.48，比第二名 Pi CLI 的 77.13 高 10.35 个百分点。且 leave-one-model-out 诊断中，三种留出法都选中 OpenCode，对 MiniMax 和 Kimi 的 regret 为 0，对 Qwen 的 regret 为 2.66 个 Fit 点。

1. 配对特异性残差可以跨 benchmark 变号：Kimi + Codex 在 SWE-bench-45 上的 VCR interaction residual 为负（低于可加基线），但在 LOCA-Bench 上为正。聚合残差会掩盖这种变号，必须看 benchmark 级别的残差剖面。

1. 低 token 消耗可能是早退而非高效：Kimi + Pi CLI 在 ClawMark 上 Token Load 只有 0.056M tokens/attempt，是全部配置中最低之一，但 Mean Score 只有 11.93。同一 benchmark 上 Kimi + OpenCode 用 3.217M tokens 得 70.36。Token Load 必须和 outcome 联合解读。

1. 几何平均对低 Fit 的惩罚有实际影响：Codex CLI 的 Cross-Model Fit 从算术平均的 74.68 降到几何平均的 73.62，下降 1.06 个点，是四个 harness 中降幅最大的。原因是 Codex 对 Kimi 的 Fit 只有 60.45，几何平均放大了这个低值的影响。

9. 最脆弱的假设

最脆弱的假设是：Fit 的归一化参照「面板内最好 harness 的 J 值」能够代表该模型在该 benchmark 上的可达上限。

这个假设如果倒了，Fit 的绝对值就失去意义。具体来说，如果面板外存在一个 harness 能让某模型的 J 值远高于面板内最好值，那么面板内所有 harness 的 Fit 都会被高估，而且高估的程度可能因模型而异。比如 MiniMax 在 SWE-bench-45 上 OpenCode 的 J 是 0.6278，被当作 J*，但如果存在一个未评测的 harness 能让 MiniMax 达到 0.85，那么 OpenCode 的真实 Fit 只有 0.6278/0.85≈73.9（百分制）而不是 100（这是假设推演，不是原文数据）。

论文有没有给出这个假设成立的证据？部分有。论文在 6.3 的 leave-one-benchmark-out 分析中展示了去掉任何一个 benchmark 后 OpenCode 仍然第一，说明 Fit 排名对 benchmark 组成不敏感。但这是对「面板内 benchmark 组成」的稳健性。论文其实也做了 leave-one-harness-out：6.3 原话是「Omitting any harness preserves the survivors' relative ordering, but changes their scores when the omitted harness supplied a best-score reference」。所以「去掉一个 harness 会不会改变排序」这一点它覆盖了；它没覆盖的是面板外的情况 —— 这四款之外的 harness 进来后参照怎么变，论文只把固定原生系统作为独立参照报告，没有纳入 Fit 的归一化。固定原生系统（GPT-5.5 + Codex、DeepSeek V4 Pro + DeepSeek Harness）提供了面板外的部分参照，但它们没有被纳入 Fit 的归一化，只是作为独立参照报告。如果这两个原生系统的 J 值被纳入参照，部分配置的 Fit 会显著下降。

10. 一周最小复现

目标：复现论文最核心的定性结论——「harness 排名依赖模型，VCR 和任务得分是分离的维度」。

资源约束：1 张 24GB 消费级显卡，1 周时间。不可能跑四个 API 模型加四个 harness 的完整交叉。需要缩小规模。

具体步骤：

第 1 天：选两个开源小模型，比如 Qwen3-8B 和另一个相近量级的模型，用 vLLM 或 SGLang 在 24GB 卡上本地部署。选两个 harness，建议 OpenCode 和 Codex CLI，因为它们安装简单、文档全、且论文中两者行为差异明显。

第 2 天：选 SWE-bench 的一个小子集。不要用完整 45 个任务，选 10 个任务，优先选论文中显示 harness 间差异大的任务。每个配置每个任务跑 2 次（论文用 4 次，但 2 次足够看趋势）。

第 3-4 天：跑 2 模型 × 2 harness × 10 任务 × 2 重复 = 80 次运行。每次运行记录：终止状态（正常/异常）、评测器是否接受提交、官方测试是否通过、token 消耗。

第 5 天：计算每个配置的 VCR 和 Mean-of-4。预期能观察到：两个模型在两个 harness 上的 VCR 排名可能不同；VCR 高的配置任务分不一定高。如果 80 次运行中能看到至少一个「VCR 高但任务分低」和一个「VCR 低但任务分不低」的配置，核心定性结论就复现了。

第 6 天：做一个简化版 interaction residual。对每个 benchmark（这里只有一个），计算每个模型跨 harness 的平均 VCR、每个 harness 跨模型的平均 VCR、总平均，然后算 Δ。看是否有配对残差异号。

第 7 天：整理结果，对比论文中 Qwen3.6-35B-A3B 在 SWE-bench-45 上的表现（论文中 Qwen 配 Codex VCR 98.33%，配 DeepAgents 80.56%，差异 17.77 个百分点）。你的小模型可能差异幅度不同，但方向应该一致。

预期指标：不要期待复现论文的具体数字，因为模型和任务子集都不同。关键是验证三个定性模式：VCR 跨 harness 有差异；VCR 和任务得分不单调相关；interaction residual 非零。如果这三个模式都观察不到，说明论文的核心主张在你的设置下不成立，这本身就是一个有价值的发现。

11. 反例设计

核心主张：harness 的适配度是 model-dependent 的，不存在一个对所有模型都最优的 harness；VCR 和任务得分是分离的维度，需要联合评估。

反例实验：构造一个「harness 绝对优势」的场景。选一个任务类型，其中某个 harness 提供了任务特定的 workflow 支持，使得无论换什么模型，这个 harness 都严格优于其他 harness，且 VCR 和任务得分完全单调相关。

具体设计：用 AgentSkillOS 的 skill_200 和 skill_900 条件。论文已经显示 skill_900 下 Pi CLI 的 VCR win rate 是 100%，而 skill_200 下 OpenCode 和 DeepAgents 并列 66.67%。如果进一步扩大 skill pool 到 2000，并且 Pi CLI 的 VCR 和 Task Score 对所有模型都严格最高，且 VCR 排名和 Task Score 排名完全一致，那么「harness 排名依赖模型」和「VCR 与任务得分分离」这两个主张在该 benchmark 上就被推翻。

判据：在 skill_2000 条件下，如果 Pi CLI 对全部三个模型的 VCR 和 Task Score 都严格第一，且其他三个 harness 的 VCR 排名与 Task Score 排名完全一致（Spearman 秩相关为 1.0），则本文核心主张在该设置下不成立。这不会完全推翻论文——论文承认 benchmark 间有差异——但会限定其结论的适用范围：当任务对 harness 的 workflow 支持高度敏感时，harness 效应可能压倒 model–harness 交互效应。

更尖锐的版本：用 GPT-5.5 和 DeepSeek V4 Pro 这两个更强的模型重复核心交叉面板。如果两个强模型在所有 benchmark 上的 harness 排名完全一致，且 VCR 都接近 100%，则说明 model–harness 交互效应只在较弱模型上显著，强模型对 harness 差异更鲁棒。这直接挑战「harness-use capability 是模型需要训练的可迁移能力」这一训练建议。

12. 落地判断

能否用于「抢占式 GPU 自托管 27B 模型做多智能体脚手架」：能，但需要先做一个适配层。

怎么用：你的场景是 27B 模型 + 自托管 + 多智能体。论文的直接结论是：不要假设某个 harness 对你的 27B 模型一定好，要先跑一个小规模交叉评测。具体做法：选 2-3 个候选 harness（建议 OpenCode 和 Codex CLI，因为论文中它们行为差异大且都支持本地模型），用你的 27B 模型在 3-5 个代表性任务上各跑 2 次，记录 VCR 和任务得分。如果发现某个 harness 的 VCR 显著低于另一个，优先排查是 action parsing 失败还是 recovery 逻辑不兼容——论文 6.2.2 的 execution-stage decomposition 给了排查路径。

成本量级：论文中 Qwen3.6-35B-A3B 在 SWE-bench-45 上单次运行的 Token Load 从 2.153M 到 19.018M 不等，取决于 harness。你的 27B 模型如果 tokenizer 效率相近，单任务单次运行大约 2-20M tokens。10 个任务 × 2 个 harness × 2 次重复 = 40 次运行，总 token 约 40×2M=80M 到 40×20M=800M。按 20 tokens/s 的生成速度，仅纯生成就要数千到上万小时 —— 单张 24GB 卡跑完整评测不现实；缩到 5 个任务 × 2 次重复（10 次运行）仍要上百到上千小时。想单卡做完只能砍到 2-3 个任务 × 1 次重复，并接受极宽的置信区间。这个量级判断比具体小时数更可靠，因为实际速度会随批次和上下文长度浮动。

最大的坑：抢占式 GPU 的随时中断会直接破坏 VCR 的测量。论文的 VCR 定义要求区分「正常终止」和「异常终止」，但如果你的 GPU 在运行中途被抢占，这次运行会被错误地记为「异常终止」，导致 VCR 被人为压低。必须在 adapter 层区分「外部中断」和「harness 自身异常」，前者不计入 VCR 的分母。另外，27B 模型的长上下文能力可能不如论文中的 35B-A3B 或 API 模型，LOCA-Bench 这类 256K 上下文任务可能直接爆显存，建议先用 SWE-bench 或 Terminal-Bench 这类上下文需求较低的任务做交叉评测。