Harness 进入“可归因时代”：智能体失败了，该怪模型还是怪框架？（深度版）

一、背景：智能体 = 模型 × Harness

Harness（智能体运行框架）是包在模型外面的那层代码：它决定模型看到什么（提示、工具结果如何序列化、历史保留多少），能做什么（工具接口、动作解析），以及何时停下（预算、验证、提交）。10 月 27 日的综述曾讨论“Harness 可以被优化”；这一周的研究更进一步：Harness 的贡献可以被测量、被归因。

这件事之所以紧迫，是因为排行榜上报告的几乎都是“模型 + 某个 Harness”的组合分数。一项针对轻量编程智能体的全因子实验早已显示：同一个模型换用不同 Harness，SWE-bench Verified 解决率最多相差 44 个百分点，而且 Harness 的排名会随模型变化 [11]。如果不能把功劳和责任拆开，企业就既无法正确选型，也无法有针对性地改进。

这项研究的细节同样值得一提。据论文数据，作者在统一的推理服务、计量和评分条件下，让六个开源 Harness 与三个轻量编程模型在 100 个 SWE-bench Verified 任务上全因子交叉，共 1,800 次评分运行；对其中 1,100 次失败运行做基于证据的失败归类后发现，一个模型在某个 Harness 下的主导失败模式，换到另一个 Harness 下未必还是主导；效率同样取决于组合，即使都是“模型主导循环”的 Harness，每解决一个任务的计费词元也能相差 20 倍以上 [11]。这意味着，“哪个 Harness 更好”本身就不是一个有确定答案的问题，它只有在给定模型、给定任务时才有意义。

10 月的研究可以归入四条主线：

1. 归因：失败是模型的、Harness 的，还是二者“配不上”[1][2][3][7][8]？
2. 损耗：信息在 Harness 内部的哪一段丢了 [4][6]？
3. 验证：检查和修订应该放在生命周期的哪一层 [5]？
4. 进化：Harness 根据经验自我修改，真的有用吗 [9][10]？

二、归因：先分清“完成了”和“做对了”

2.1 有效完成率：第一个被忽视的维度

When Agents Fail: Model or Harness（2026-10-23）[1] 提出，评价 Harness 不能只看任务得分，还要看有效完成率（VCR）：一次尝试是否正常结束、是否把可评估的结果交给评测器，无论答案对错。VCR 被分解为“正常终止 × 有效交接”。在此基础上，论文定义了模型—Harness 契合度、跨模型契合度（对各模型取几何平均）、交互残差（某一组合特有的强弱）和令牌负载（包括失败尝试的消耗）。

据论文数据，作者把 OpenCode、Codex CLI、Pi CLI、DeepAgents 四个通用 Harness 与四个核心模型交叉，再加上两个原生的模型—Harness 系统，在六个基准上共运行 111 种设置、52,168 条轨迹。结论包括：Harness 排名随模型和基准变化；任务得分高的组合与有效完成率高的组合可能不是同一个；分数相近的配置可能有截然不同的执行画像。OpenCode 的跨模型表现排在首位，而 DeepSeek V4 Flash Preview 在共享的四基准面板上于各 Harness 间都保持了较高的平均 VCR [1]。

Trial by Trace（2026-10-23）[2] 从另一侧切入：把 Harness 可靠性拆成上下文、执行、治理、生命周期、可观测性、工具、验证七个组件，设计 95 个面向机制的专家级任务，并用“轨迹追踪 + 多源证据获取 + 失败归因”三个模块，在单次运行层面给出机制链式的归因。据论文数据，4 个 Harness × 9 个模型 × 95 个任务共 3,420 次运行，Harness 宏平均得分在 59.8% 到 72.0% 之间；31.1% 的运行虽然任务成功，却至少违反了一条 Harness 准则 [2]。换言之，近三分之一的“成功”是带病成功。

2.2 原厂 Harness 离开原厂模型

kw-bench（2026-10-26）[7] 用一个非常“业务”的任务测试 Harness：跨三代 SAP 系统（旧版 ECC、部分迁移的 S/4HANA、顾问重新设计的版本）重建五年的增值税数据，输入是原始系统导出：页眉、本地数字格式、残缺的关联表，没有任何说明文档。评分完全确定，不用 LLM 裁判。

据论文数据，在同一个模型 DeepSeek v4.1 Flash、两小时时限下，两个与模型无关的独立 Harness 交付了结果（OpenCode 0.542，micro-cc 0.528），两个实验室自家的 Harness 离开自家模型后得 0 分。作者把失败原因归结为“惯性”：在长会话里让许多微弱信号同时保持存活的能力不足。换到前沿模型 Claude Opus 5.5 上，micro-cc 和 Claude Code 分别在 22 分钟和 25 分钟内得到 0.9986 和 1.000 [7]。作者的总结是：在前沿模型之下，Harness 决定了模型能走多远。

Free to Look, Free to Reason（2026-10-26）[8] 在微服务根因分析上得到相似结论：三个“不预设调用流程”的简单 Harness（对证据包一次调用、SQL 智能体、Codex 编程智能体），在三个中档模型上的 PR@1 为 65%–77%，高于五个已发表的手工编排 RCA 智能体（16%–53%）和统计、因果方法（6%–39%）。案例分析显示，预设流程会跳过决定性的证据 [8]。

2.3 算法拆解 ①：天花板减失配——为什么“冻结权重比 Harness”会误判

直觉。通常的做法是：拿一个训练好的模型，分别放进旧 Harness 和新 Harness，谁分高用谁。Your Policy Is Secretly a Harness（2026-10-27）[3] 指出，这种“冻结比较”混淆了两件事：新 Harness 本身能提供多少（天花板），以及这个模型在新 Harness 里用得好不好（失配）。

类比。一位熟练的左舵司机换到右舵车上，第一周开得比原来差。这不说明右舵车更慢；车的性能上限（天花板）没变差，只是司机的习惯（失配）还没调过来。练一段时间后，他在右舵车上可能开得更好。

形式化。在 KL 正则化控制下，最优策略是动作得分的 softmax：

F(s,a) = Q(s,a) + τ·log π_ref(a|s)， Π(·|s) = softmax(F(s,·)/τ)

论文证明：一个在某 Harness 下训练到最优的策略，其两个动作的对数几率恰好等于该 Harness 诱导的得分差——策略在权重里“携带”了 Harness 的偏好，尽管它不包含 Harness 的任何代码，这就是标题“策略其实是一个 Harness”的含义。进而得到恒等式 [3]：

部署回报 J = 天花板 C − 失配 M

其中 C 是该 Harness 下任何策略能达到的最好回报，与模型权重无关；M 是策略偏离最优策略的 KL 散度沿自身轨迹的累积。训练只改变 M；换 Harness 同时改变 C 和 M。

小例子（据论文数据）。

• 只换顺序：把网页观测 JSON 里的字段顺序颠倒，内容、动作、奖励、参考策略都不变，因此所有最优决策不变（C 不变）；但训练过的模型在约一半状态上改变了首选动作，成功率从 85.0% 降到 19.2%——全部损失来自“读出漂移”造成的 M 上升 [3]。
• 加一个更好的动作：新 Harness 支持“一次决策执行两次点击”，可达到的最好回报上升了，但冻结模型的失配增幅约为天花板增幅的十倍，成功率从 85.0% 降到 72.9%，冻结比较会否决它。在两个 Harness 下用相同预算继续训练后，新 Harness 下的模型达到 88.2%，既高于原检查点的 85.0%，也高于旧 Harness 下继续训练的 83.4%——最初“伤害”模型的 Harness，最后给出了最好的智能体 [3]。

怎么用。论文在 Terminal-Bench Lite 上，用更强的模型代替未知的最优策略来估计 C 和 M，“C − M”复现了五个编程 Harness 的准确率排序，而单看 C 或单看 M 都不行 [3]。

# 评估一个候选 Harness H_new（相对现有 H_old）
C_new  = estimate_ceiling(H_new, proxy=stronger_model)   # 用强模型近似最优
M_new  = estimate_mismatch(policy, H_new, proxy)         # 当前模型的 KL 偏离
J_frozen = C_new - M_new
if J_frozen < J_old and (C_new > C_old):
# 冻结比较会否决，但天花板更高：值得在 H_new 下继续训练或微调提示
candidate_for_adaptation(H_new)

何时失效。机制实验在 MiniWoB++ 上把控制问题编译成有限图，可以精确计算最优解；在真实编程任务中只能用强模型做代理，估计误差取决于代理与真实最优的差距 [3]。对于不做后训练、只能换 Harness 的企业，这个分解的价值主要在于提醒：一次 A/B 的输赢，不等于 Harness 本身的好坏。

三、损耗：上下文是一条管道，不是一个窗口

3.1 算法拆解 ②：五段管道与“行感知截断”

现象。Context Is a Pipeline, Not a Window（2026-10-26）[4] 研究了一个根据 Linux 内核追踪诊断注入故障的工具型智能体。720 次运行中，单次最大的提示只有 2.3 万词元，占 40 万窗口的 5.75%。但 11,189 个工具结果里，有 3,827 个（约三分之一）在送达模型之前被截断，而且每一个都成了坏掉的 JSON。原因是 Harness 按固定字符数切掉 JSON 文本的尾部，而 JSON 的键顺序固定，于是排在后面的字段被整段删除：同一批结果中，一个容器列表只在 4.7% 的调用中送达模型，相邻的另一个列表送达率为 99.3% [4]。

更关键的是，哪个列表承载故障证据，取决于故障进程在追踪中何时启动。“新启动进程”类故障的证据在前面的列表里，得分 40–55/60；“已在运行的容器”类故障的证据在后面的列表里，得分 0–24/60。作者原以为这是内核追踪本身的局限，测量后才发现 Harness 难辞其咎 [4]。

五段模型。论文把上下文建模为五个边界，每一处都有实测失败：

类比。快递从仓库到收件人要经过分拣、装车、中转、派送、签收五个环节。只看“签收率”，看不出包裹是在哪一站被压坏的；必须在每一站称重。

修复：行感知截断。把“按字符切前缀”改为“按记录行整行保留并注明省略了多少”。论文在 864 个真实工具结果上重放两种规则：超预算的结果在前缀截断下全部损坏，在行感知截断下没有一个损坏 [4]。

def deliver(result, budget):
rows = flatten_to_records(result)            # 每个字段的每条记录
keep, used = [], 0
for field in result.fields:                  # 按字段轮转，避免后序字段整段丢失
for row in round_robin(rows[field]):
if used + len(row) > budget: break
keep.append(row); used += len(row)
note = {f: f"{len(rows[f]) - kept(f)} rows omitted" for f in result.fields}
return valid_json(keep, note)                # 永远输出可解析的结构

度量。作者建议在准确率旁边报告每个边界的“存活量”，并给出一个汇总指标“产出率”= 记录下来的发现数 / 运行的计算数 [4]。

受控实验的结论比直觉更微妙。在逐个重新引入缺陷的预注册实验中，S1 截断的真实代价首先表现为额外工作，而不是错误答案：工具调用多 43%，计算量翻倍，产出率从 0.61 降到 0.31；当智能体还有别的路径能拿到证据时，它仍能找到正确答案。作者坦承，“截断是否导致准确率下降”仍是开放问题 [4]。

普遍性。作者检查了七个智能体框架当前版本的工具输出裁剪代码：两个通用裁剪器都按位置切（一个只保留前 500 字符，一个删除超过 2 万字符观测的中间部分）；三个根本不裁剪，等于把同样的损失推迟到上下文窗口里；只找到一个按整行切并注明的实现，但它不是默认选项 [4]。

何时失效。行感知截断保证结构完整，但仍需要决定“哪些行更重要”；对于长度本身就是信号的结果（例如日志频次），轮转保留会改变分布，需要额外注明统计摘要。

3.2 执行前就拦住“幻觉工具调用”

StateMirror（2026-10-23）[6] 处理的是 S1 的反方向——模型发给环境的动作。编程智能体常提出在当前环境下不成立的动作：访问不存在的路径、导入未安装的包。作者分析 4,398 条轨迹，发现这类“幻觉工具调用”普遍且昂贵，每次恢复的中位成本是 3 个额外交互步和 2.24 万词元。StateMirror 在 Harness 边界拦截动作，用 AST 与命令分析提取前置条件（“路径存在”“包已安装”），再对实时仓库做确定性校验。据论文数据，在 2,508 个动作上精确率 0.940、F1 0.817，比最强的 LLM 裁判高 35.3%（F1），检测延迟从 17.73 秒降到 1.50 毫秒且不消耗词元；超过 95% 的幻觉调用在收到预执行反馈后被纠正；在 79 个任务的实时缓解中，执行时间减少 15.8%，词元消耗减少 11.8%，解决率保持不变 [6]。

四、验证：检查放在哪一层，比检查多少更重要

4.1 算法拆解 ③：四层验证框架

Rethinking Verification in Agent Harnesses（2026-10-25）[5] 把“验证”当作测试时扩展的一条轴，按智能体生命周期分为四层：

为什么需要这样分。作者观察到，在检测到的编辑轮次中，只有 6.2%–13.6% 在下一次编辑或运行结束前跟着一条可识别的检查命令 [5]——智能体本能上并不爱检查。

结果（据论文数据）。作者在 Terminal-Bench（TB）与 SWE-bench Verified（SWE）上比较 17 种设计、7 个前沿编程模型：

• L0、L1 带来的平均收益不大且依赖模型，输出词元约为基线的 0.90–1.00 倍和 0.75–0.93 倍。
• L2 可能带来更大收益，但“拒绝式”闸门的成本在 TB 上为基线的 1.60–1.76 倍，在 SWE 上为 1.48–1.56 倍。
• L3 独立审查的性价比更好：TB 平均准确率提升 5.9–9.5 个百分点，SWE 提升 3.9–6.6 个百分点，成本分别只有基线的 1.13–1.25 倍和 1.00–1.04 倍（含评审与修订）。
• 在 18 个视觉与交互任务组成的 VisualBench 上，四种独立审查设计的净偏好为 +13.2 到 +23.8 分，均优于 L0–L2；基于“改动”的审查优于基于“完整轨迹”的审查。追加审查轮次或独立评审者，可使 TB 平均准确率再提高至多 3.5 个百分点 [5]。

类比。一篇稿子：L0 是交代“写完自己读一遍”；L1 是每写一段提醒一次；L2 是作者说“写完了”时编辑说“你再检查一遍”；L3 是交给另一位编辑审读。经验告诉我们，换一双眼睛往往比让作者多读三遍更有效——实验数据支持了这个直觉。

何时失效。独立评审者看的是“改动”而非“完整轨迹”时效果更好，说明评审的输入需要设计；如果改动本身很分散（例如跨几十个文件的重构），评审成本会快速上升。此外，七个模型均为中国厂商的前沿编程模型，结论在其他模型家族上的强度有待验证 [5]。

五、进化：Harness 自我修改，要能证明它有用

How Do Coding-Agent Harnesses Self-Evolve?（2026-10-26）[9] 研究了一个让智能体“复盘会话、提出 Harness 修改”的技能。作者在 30 个 SWE-bench Verified 问题上运行 Claude Code，对 125 条修改建议做质性编码，落地 24 条，并在同仓库后续问题上用“有/无该修改”的新会话评估了 12 条。据论文数据，多数建议都指向会话中的某个具体事件，但 43 条与代码规范检查相关的建议里有 18 条是不论发生了什么都会推荐的“通用好习惯”。在 7 次“无修改的会话确实遇到了目标问题”的评估中，2 个修改消除了目标动作，1 个减少了它，4 个没有减少；有的修改还给无关问题增加了工作量 [9]。

Lessons Outlive Their Failures（2026-10-23）[10] 是一份为期六周的个人案例研究：三个 AI 工具每天在同一套规则下编辑一个纯 Markdown 仓库。作者建立了 118 次智能体失败的台账。据论文数据，文档漂移（过时的陈述）是最大的失败类别（48/118）；单次 LLM 文档审计能找到约一半的已知漂移（Claude Sonnet 5.5 平均 50%），且至少 93% 的发现是正确的；在 Sonnet 5.5 上重放的五次历史失败中，有四次任务完成，其中三次无论有无修复都不再出现失败 [10]。只有一个在去掉检查后复发，即“计数过时”类失败，而对应的机械检查在每次运行中都拦住了它 [10]。作者的结论是：为修复某次失败而写下的规则，可能比那次失败本身活得更久——模型升级后失败已不再发生，规则却还留在文件里；而文档漂移不会因模型升级自动消失，仍然需要机械检查。自我进化工具添加规则的速度快于退役规则的速度，因此应定期重测规则，退役过时的部分 [10]。

两项研究都指向同一个缺口：Harness 进化需要的不只是“生成并实现修改”，还需要证明修改在后续任务上有用，并能修订或删除没用的修改 [9][10]。

六、横向对比

注：各研究的任务、模型与评价口径不同，数值不可直接横比。

七、我们的观点

第一，Harness 评测要从“一个分数”变成“一张体检表”。任务得分、有效完成率、准则违反、词元负载、各边界存活率，至少五个维度要并列报告 [1][2][4]。31.1% 的“带病成功”[2] 意味着，只看成功率的企业会把隐患带进生产。

第二，“原厂 Harness + 原厂模型”的组合优势，在换模型时可能变成劣势。kw-bench 的 0 分 [7] 和天花板—失配分解 [3] 讲的是同一件事：模型与 Harness 之间存在相互适应。多模型战略的企业，应优先选择与模型无关、行为透明的 Harness，并对每个组合单独验收。

第三，低成本的改进往往在管道里，而不在模型里。行感知截断 [4]、执行前校验 [6]、独立审查 [5]，都不需要更换模型或重新训练，却能直接减少浪费和错误。我们建议企业在“升级模型”之前，先给 Harness 的每个边界装上计量。

第四，自我进化必须配对照实验。让智能体“复盘并改规则”很容易，证明改动有用很难 [9]；规则只增不减，最终会成为新的漂移源 [10]。Harness 的规则库应像代码一样有测试、有负责人、有退役流程。

八、未来展望

6–12 个月：

• 主流 Harness 会默认提供结构感知的工具输出裁剪，并在日志中同时记录“工具产生了什么”和“模型收到了什么”[4]。
• 排行榜会开始报告“模型 × Harness”矩阵和有效完成率，而不只是单一组合的分数 [1][11]。
• 独立审查（L3）会成为编程智能体的常见默认配置，审查输入以“改动”为主 [5]。

1–3 年：

• 后训练会显式考虑 Harness 迁移：训练时轮换 Harness 呈现方式，降低“读出漂移”，让模型学会可迁移的 Harness 使用能力 [1][3]。
• Harness 本身会出现“规则的持续集成”：每条规则附带触发它的历史失败用例，定期重放，不再生效的规则自动提示退役 [9][10]。
• 对于高价值的调查型知识工作（审计、税务、尽调），“调查型基准 + 确定性评分”会成为采购评估的常用方式 [7]。

落地清单：一次 Harness 体检的六个步骤

1. 固定模型，轮换 Harness；再固定 Harness，轮换模型。至少做一个 2×2 的交叉，才能看出交互残差 [1][11]。
2. 同时记录四类结果：任务是否成功、是否正常终止并有效交接、是否违反 Harness 准则、消耗了多少词元（包括失败尝试）[1][2]。
3. 在每个上下文边界计量存活量：工具产生了多少记录、模型收到了多少、保留了多少、移交了多少 [4]。
4. 在动作发出前做确定性校验，把能用规则判断的错误挡在执行之前 [6]。
5. 为接受结果设置独立审查，审查输入以改动为主，并记录审查带来的额外成本 [5]。
6. 每条新增规则附带触发它的历史用例，定期重放，不再生效的规则进入退役评审 [9][10]。

这六步不需要更换模型，也不需要训练，任何一个已有智能体项目都可以在一到两周内完成第一轮。它的产出不是一个更高的分数，而是一张能回答“问题出在哪里”的体检表。

九、对金融风控与企业落地的启示

1. 把 Harness 当作被审计对象。智能体参与的授信材料核查、反洗钱线索分析，除了模型版本，还应记录 Harness 版本、工具输出裁剪规则与验证配置，否则事后无法归因 [1][2]。
2. 在每个边界计量“证据存活率”。征信报告、流水明细这类长结构化结果，很容易被前缀截断“整段删除”；应改为按记录行裁剪并注明省略数量 [4]。
3. 用确定性规则做执行前校验。查询不存在的字段、调用未授权的接口，应在执行前被规则拦住，而不是等报错后再恢复 [6]。弘犀智能的规则引擎实践表明，这类校验成本很低、收益明确。
4. 为高风险结论配置独立审查。审查者只看“改动和结论”，而不是整条推理轨迹，性价比更高 [5]。
5. 规则库要有退役机制。为某次事故临时加的规则，应在后续版本中重放验证，不再需要的及时下线，避免规则堆积导致口径冲突 [10]。

十、结语

智能体时代的工程问题，正在从“模型够不够强”转向“系统能不能被看清”。10 月的这批研究给出了让 Harness 可归因的工具：分清完成与做对、分清天花板与失配、分清每一段管道的损耗、分清哪一层验证真正有效。看清了，才谈得上改进。

想了解弘犀智能在规则引擎与智能决策系统方面的实践，欢迎点击文末「阅读原文」访问 www.hxallai.com。

参考文献

1. [1]Shao Zhang, Hangfan Zhang, Yuanyuan Shi, Hao Li et al. When Agents Fail: Model or Harness—Who's to Blame? arXiv, 2026-10-23. https://arxiv.org/abs/2610.32483
2. [2]Zhiyong Cao, Hengjie Zhu, Yongxin Wang, Xuchen Li et al. Trial by Trace: Benchmarking AI Agent Harnesses for Reliability and Failure Attribution. arXiv, 2026-10-23. https://arxiv.org/abs/2610.32285
3. [3]Jian Mu, Ruibo Shen, Yao Shu. Your Policy Is Secretly a Harness: The Decision Geometry of Agent Interfaces. arXiv, 2026-10-27. https://arxiv.org/abs/2610.37255
4. [4]Yuvraj Sehgal, Mahsa Panahandeh, Naser Ezzati-Jivan. Context Is a Pipeline, Not a Window: Information Attrition in LLM Agent Harnesses. arXiv, 2026-10-26. https://arxiv.org/abs/2610.36114
5. [5]Zhengxin Zhang, Erkang Zhu, Yin Lin, Claire Cardie et al. Rethinking Verification in Agent Harnesses. arXiv, 2026-10-25. https://arxiv.org/abs/2610.34577
6. [6]Shiwen Shan, Yintong Huo, Zhiying Wu, Yuxin Su. StateMirror: Pre-Execution Detection of Hallucinated Tool Calls in Coding Agents. arXiv, 2026-10-23. https://arxiv.org/abs/2610.32648
7. [7]George Juraj Salapa. kw-bench: Breaking Frontier Harnesses on Real-World Tasks. arXiv, 2026-10-26. https://arxiv.org/abs/2610.36405
8. [8]Tingzhu Bi, Xun Zhang, Jinglin Li, Ping Wang, Meng Ma. Free to Look, Free to Reason: Simple LLM Harnesses Outdiagnose Hand-Crafted Root Cause Analysis Agents. arXiv, 2026-10-26. https://arxiv.org/abs/2610.35767
9. [9]Christoph Treude, Sebastian Baltes. How Do Coding-Agent Harnesses Self-Evolve? An Empirical Study of Retrospective Adaptation. arXiv, 2026-10-26. https://arxiv.org/abs/2610.34938
10. [10]Hassan Hassanzadeh Aliabadi. Lessons Outlive Their Failures: A Case Study of Rules for AI Coding Agents. arXiv, 2026-10-23. https://arxiv.org/abs/2610.32578
11. [11]Lu Zhao, Christopher M. Poskitt, David Lo. Pairing Matters: Performance, Failures, and Efficiency in Lightweight Coding Agents. arXiv, 2026-10-23.（背景文献）https://arxiv.org/abs/2610.32131