3420次实测：Agent把任务做成了，系统却未必可靠，Harness藏着多少盲区？

模型和 Harness，也会互相“甩锅”？

AI Agent 没有完成任务，问题出在哪里？

是模型理解错了要求，是工具执行出了异常，还是运行框架在传递信息时漏掉了关键内容？

只看最终结果，很难分清是哪一种。更麻烦的是，即使任务完成了，过程中的问题也可能被成功的结果掩盖。

近日，来自 TraceLite AI、中国科学院相关研究机构、清华大学和北京理工大学等机构的研究团队发布 TraceTrial-Bench，首次尝试将 Agent 的任务表现与 Harness 的机制可靠性拆开评估。

据报告显示，4 套 Harness、9 个模型、95 个任务，共 3,420 次计分运行，其中两层检查全部达标的只有 8.4%。另有 31.1% 的运行完成了任务，却至少有一项 Harness 判据未通过。

TraceTrial-Bench 基本信息：

• 技术报告：https://arxiv.org/abs/2610.32285

• 项目主页：https://tracelite.ai/trial-by-trace 

• GitHub：https://github.com/TraceLite-AI/TraceTrial-Bench

眼下多数 Agent 榜单只给出一个成功率。开发者拿到低分，往往说不清该换模型，还是改运行框架。拿到高分，也不代表过程中没有出问题。

为此，团队提出了评测基准 TraceTrial-Bench，将任务表现（Agent 层）与运行框架的可靠性（Harness 层）分开评估，并在此基础上沿着执行轨迹收集证据，追查失败的根源。

这项研究要追问的，既包括 Agent 有没有把事情做完，也包括问题出现在哪个环节，以及这个问题是否影响了 Agent 的后续行为。

模型之外的那一层：Harness

我们说“Agent 在工作”，做决策的是模型，但模型并不直接接触外部世界。读取文件、执行命令、调用工具，以及把任务交给另一个 Agent 时，都要经过包裹在模型外面的一层系统。这层系统负责组织上下文、传递工具结果、管理进程和权限，以及保存和恢复会话状态，通常被称为Harness，可以理解为支撑智能体工作的运行框架。

换句话说，模型能看到什么，由Harness 决定。工具结果有没有完整送达，长输出被截断后留下了什么，任务交接或会话恢复之后哪些信息还在，这些都发生在模型看不见的地方。

所以，一个看似是模型犯的错误，可能需要沿着整条执行链检查。例如，Agent 没有用上某条关键信息，就需要逐环追问：

• 这条信息在工具的原始输出里吗？如果不在，问题出在工具或环境；

• 经过截断、整理之后，它还在吗？如果被删掉了，问题出在Harness；

• 它已经进入模型的上下文，模型却没有用上？那才是模型的问题。

三个问题的答案不同，对应的修复方向也完全不同。

两层评分，再加一步归因

为此，团队设计了 95 个机制导向任务，覆盖上下文、执行、治理、生命周期、可观测性、工具和验证七个维度，并为每次运行设置两层评分，由此构建了 TraceTrial-Bench。

评测时，各 Harness 以原生方式在同一套受控环境中运行，系统完整记录执行轨迹。每次运行分两层打分，每一层都由若干条检查项（即“判据”）组成：

• Agent 层：检查 Agent 的行为和交付物是否满足任务要求；

• Harness 层：检查 Harness 是否尽到了任务所考察的职责。

在此基础上，TraceTrial-Bench 又加了一步——基于执行证据的失败归因。

图 1：TraceTrial-Bench 的整体框架。

右下角展示归因路径：检查 Harness 职责未满足、可观察的信息或状态变化，以及 Agent 后续表现之间的联系。图源：TraceLite AI。

归因怎么做：沿着证据走

归因分三步。

第一步，说清楚查什么、在哪查。TraceTrial-Bench 首先明确 Harness 的一项职责，以及应在哪个环节检查它。例如，要查的职责是“截断工具输出时，保留继续读取所需的线索”，检查位置应在截断之后、模型实际能看到的内容。

第二步，收集三类证据，分别是：

• 环境状态和产出文件——环境里实际发生了什么；
  

• Harness 的运行记录——它向模型交付了什么；
  

• Agent 的上下文——模型最终看到了什么。

将这些证据放在一起，才能核对“环境中发生了什么”“框架交付了什么”和“模型看到了什么”之间是否存在差异。

第三步，沿着机制链逐段审查。在看评测结果之前，团队就为每一类问题写明了它应如何传导：

Harness 的某项职责未尽到→模型所见信息或环境状态出现可观察的偏差→ Agent 的后续行为或任务结果受到影响。

这条链上的每一段都需要相应证据支持。TraceTrial-Bench 会自动做一轮初筛：如果同一次运行中，某项Harness 判据和与之相关的 Agent 判据都没有通过，系统就把两者标记为一组“候选关联”。但这只是提醒“这里可能有因果联系，值得查一查”，并不是结论。要断定 Harness 的问题确实影响了 Agent，还得沿着链条逐环核对证据。

这样一来，“大概是框架的问题”这种模糊猜测，就被推进为针对具体环节、依据具体证据的核查。

案例一：截断吃掉了恢复线索

案例一的任务要求 Agent 从一份工单导出记录中找回 12 个升级代码，并生成对应文件。这项任务设有三条硬性约束：导出操作只能执行一次，后续每次读取必须针对同一份快照，不允许猜测缺失代码。

因此，一旦导出内容过长、可见输出被截断，快照标识就成了找回剩余数据的关键入口。

报告展示了同一个模型Claude Opus 5 在两套 Harness 中的运行轨迹。在模型相同的条件下，仍需结合执行轨迹检查两套 Harness 的信息交付差异：

在 Claude Code 的轨迹中，截断后，可见输出里保留了快照标识和工单总数。Agent 据此继续读取，最终找回全部 12 个代码。

在 OpenClaw 的轨迹中，截断后，模型只看到一条“内容已截断”的提示，快照标识没有保留下来。Agent 使用「UNKNOWN」作为快照参数发起请求，被工具拒绝。

图 2：输出恢复案例。

左侧保留了后续读取所需的快照标识，右侧的恢复请求因无效快照标识遭到拒绝。分数为通过判据数／判据总数。图源：TraceLite AI。

只看任务评分，结论只有一句：一条轨迹通过了全部 5 项 Agent 判据，另一条全部没有通过。分数说明了谁成谁败，却说不出原因。

执行轨迹则给出了一条完整的证据链：

可见输出未保留快照标识（Harness 未尽职责）→模型看到的结果里找不到继续读取所需的参数（可观察的偏差）→Agent 发出带「UNKNOWN」参数的请求，被工具拒绝（Agent 受到影响）

有了这条证据链，排查范围就从“整个系统哪里出了问题”收敛到了“输出截断与恢复信息交付”这一具体机制。开发者可以直接对照检查截断策略保留了什么？恢复入口如何呈现？关键信息在哪个观察边界丢失？

需要说明的是，这个运行案例解释了问题在这条轨迹中是如何发生的，但不能据此认为OpenClaw 处理截断普遍更差，或推断出其他普遍因果结论。

案例二：该记在 Agent 头上的问题

归因还有另一项作用：避免把 Agent 自己的错误地记到 Harness 上。

案例二是一项跨会话任务：Agent 需要依次校验 12 组数据，并保存每次获得的校验码。任务明确规定，每组数据只能校验一次。

报告展示了同一模型Qwen3.8-Max 在两套 Harness 中的运行轨迹：

Codex 的轨迹共 12 次调用，对应 12 组不同数据，没有重复校验。Claude Code 的轨迹则出现了重复校验，即使最终文件里的校验码都正确，操作过程仍违反了“每组数据只能校验一次”的任务约束。

跨会话任务出现重复操作，人们的第一反应往往是Harness 恢复会话时把进度弄丢了。但评分给出了不同的答案，Agent 层，Codex 一侧通过了全部 17 项判据，Claude Code 一侧通过 15 项。Harness 层，两边均为 12/12，全部通过。

也就是说，在评测检查过的每一项职责上，Claude Code 都做到位了。在已检查的职责范围内，未发现 Harness 失职，重复操作记录在 Agent 层，进一步归因仍需更多证据。

那么，同一个模型在两套Harness 中表现不同，会不会仍然和 Harness 有关？证据只能回答到这一步，即在已检查的职责范围内，没有发现 Harness 的问题。

这也体现了证据归因的价值：证据没有覆盖到的地方，归因不替任何一方下结论。

两个案例放在一起看：

• 案例一里，证据链把失败追溯到了Harness；

• 案例二里，证据则替Harness 排除了嫌疑。

归因，让每一个判断都止步于证据所能支持的范围。

榜单该怎么读

先看两层各自的排名。Agent 层，Claude Code 的任务全通过率在四套Harness 里最高，为 44.0%。也就是说，它有44.0% 的运行通过了全部 Agent 判据。

这两个“最高”衡量的不是同一件事：前者看任务有没有做成，后者看 Harness 有没有把该交付的信息交付到位。

如果需要综合参考，报告还提供了 Overall 综合指标，将 Agent Score 与 Harness Macro 各按 50% 加权。模型中排名第一的是Claude Opus 5，Harness 中排名第一的是 Claude Code。

比排名更值得注意的，是两层结果之间的分歧。在全部3,420 次运行中，两层判据全部通过的只有 8.4%。另有 31.1% 的运行虽然完成任务，却至少有一项 Harness 判据没有通过。换句话说，在任务全部达标的运行里，近八成仍存在 Harness 没有尽到的职责。

31.1% 描述的是两层检查结果的分歧，不能直接当成“Harness 导致任务失败的比例”。具体问题是否影响了任务、影响发生在哪个环节，仍需要回到执行证据中审查。

对开发者有什么用

TraceTrial-Bench 带来的最大变化，是让评测结果不再只是一个分数，而成为一份诊断线索。

任务失败时，开发者可以顺着证据往下查。工具结果是否准确交付、上下文是否保留了必要信息、会话中断后状态是否正确恢复。任务成功时，也可以回头看看：过程中是否留下了被结果掩盖的未达标项。

当问题能够落到具体职责、具体事件和具体证据上，该修哪里、修完后怎么回归检查就有了更清楚的对象。

下一次 Agent 任务失败时，第一步不妨先问一句：它当时看到的上下文里，到底有没有完成任务所需的那条信息？而当任务成功时，也值得多问一句：这次成功，是不是恰好掩盖了某个问题？

未来展望

未来，团队希望进一步探索从失败归因到后训练的路径。通过受控对照和重复运行，核查具体问题如何影响 Agent 的后续行为，再将有证据支持的归因结果转化为训练样本和过程奖励，为模型的决策、工具使用与异常恢复提供更细致的反馈。

其中，一个关键问题是区分模型在已有信息下的决策失误与 Harness 造成的信息缺失，减少将系统层面的失败简单归结为模型能力不足的风险，已确认的 Harness 问题，也可以为框架修复提供明确依据。

训练或修复之后，还需要在未参与优化的任务和不同 Harness 配置上检验效果，确认改进能否迁移、是否引入新的问题。团队希望由此逐步建立“执行-归因-改进-验证”的反馈循环，为模型与 Harness 的持续改进提供可检验的依据。

团队介绍

TraceLite AI 是一个学术驱动的开放研究团队，研究 AI Agent 评测与后训练所用的基础组件，包括证据采集、失败归因、评测环境、奖励建模和数据生成，本文中的证据收集与归因方法即出自其中。团队计划探索这些组件在模型和 Harness 选型、训练及上线前验收中的应用，并逐步衔接成持续改进的训练框架。

2026 奇点智能技术大会将于 11 月 20—21 日在北京万达文华酒店举行。大会现面向 AI、开发工具、数据平台、系统软件等领域开放合作，诚邀希望进行产品展示、技术品牌传播、用户连接与生态共建的企业及技术伙伴参与，与企业代表、技术决策者和一线研发者展开深入交流。

扫描下方海报二维码，了解合作详情。