你让 AI 助手改一份文件。它最后交出了正确版本，看起来一切顺利。但后台记录显示，它中途丢过上下文、误报过命令结果，只是后来碰巧补救成功。反过来，它也可能收到完整信息、工具运行正常，却自己做错判断。
过去的智能体评测通常只看最终得分，很容易把两种情况混在一起。两项新工作把镜头转向 agent harness——智能体运行框架，也就是包在大模型外面的整套“工作台”。它负责整理上下文、调用工具、保存状态、处理异常和检查结果。智能体掉链子，未必都该怪模型；即使模型相同，换一套工作台，表现也可能不同。
《Trial by Trace》提出 TraceTrial-Bench，试图沿着运行轨迹追查责任。《When Agents Fail》则用五项指标比较模型与运行框架是否合拍。两项研究都测试了四种通用或独立框架，共同推进了一个重要变化：不再只问“得了几分”，而是继续追问“系统到底在哪里出了问题”。本文数字与排名分别来自两篇论文；其中 TraceTrial-Bench 有全文材料，另一项工作只有摘要，不能把两边的结果直接横向比较。
先把“交卷”和“答对”分开
《When Agents Fail》提出的第一项指标是 Valid Completion Rate（VCR，有效完成率）。它先不管答案正确与否，只检查智能体有没有正常跑到终点，并交出可供评判的结果。就像考试先看考生是否完整交卷，再批改内容。
这一区分很实用。一个组合可能任务得分不错，却经常超时、异常退出，或者没有留下可评判的产物。另一个组合也许答对率相近，但每次都能稳定完成流程。只看总分，两者似乎一样；从执行可靠性看，却不是同一种系统。
论文还提出 Model-Harness Fit、Cross-Model Fit、Interaction Residuals 和 Token Load。它们分别考察某个模型与框架是否合拍、框架跨模型的整体适用性、特定配对中被平均数掩盖的强弱项，以及一次执行消耗的 token——模型处理文字时使用的计量单位，其中也包括失败尝试的消耗。
研究测试了 OpenCode、Codex CLI、Pi CLI 和 DeepAgents 四个通用框架，搭配四个核心模型；另外纳入两个固定的原生模型—框架系统。实验覆盖六个基准，涉及上下文管理、工具使用、长上下文规划、多模态交互和产物交接。计入原生参照与压力条件后，共有 111 种评测设置、52,168 条运行轨迹。
结果显示，框架排名会随模型和基准变化。任务得分与 VCR 也可能偏好不同配对；相似的任务得分，背后可能是完全不同的执行状态。在论文选定的范围及其 Cross-Model Fit 定义下，OpenCode 排名第一。共享的四基准面板中，DeepSeek V4 Flash Preview 在不同框架下保持较高的 Mean VCR。不过摘要没有给出具体数值或显著性信息，因此不能把“较高”改写成“始终最佳”。
Trace 不只看终点，还看沿途发生了什么
TraceTrial-Bench 走得更细。它把框架可靠性拆成七部分：上下文、执行、治理、生命周期、可观测性、工具和验证。简单说，它既检查信息有没有完整送到模型，也检查命令结果是否如实返回、权限和安全边界是否生效、长任务能否正确恢复，以及最终完成声明是否符合真实状态。
基准包含 95 个专家级、面向具体机制的任务。每个任务不只规定最终产物，还预先写明框架应履行什么义务，并尽量用可执行检查或环境状态作为“标准答案”。其中有 46 个单轮任务、45 个固定多轮任务和 4 个模拟器驱动任务。场景包括输出过长后的恢复、命令失败却留下貌似成功的产物、尚未完成的后台任务，以及跨会话传递信息。
它的关键做法是建立两张成绩单。Agent 层检查任务动作和最终产物，Harness 层检查运行框架有没有忠实传递信息、执行工具并维护状态。于是，“任务成功”不再自动等于“框架可靠”，“任务失败”也不自动等于“框架有错”。
为了给判断留下证据，Trajectory Tracing（轨迹追踪）模块把不同框架的原生运行记录整理成统一格式，同时保留原始来源。Multi-source Evidence Acquisition（多源证据获取）再结合轨迹、工作区文件、模拟器状态和执行探针，为每条判据准备证据。最后，Failure Attribution（故障归因）模块依据预先声明的机制链，寻找框架问题与任务失败之间可能存在的联系。
这里有一道重要的谨慎线。框架判据和任务判据同时失败，只能激活一个“候选联系”，不能直接证明前者导致后者。论文要求进一步核对事件顺序、观察中间信息如何失真，并排除其他解释，才能把它提升为经过验证的传播关系。测量装置本身若出错，也不算框架缺陷。
31.1% 为什么值得留意
TraceTrial-Bench 比较了 Codex、Claude Code、OpenClaw 和 DeepSeek Harness，搭配 9 个模型与 95 个任务，共选取 3,420 次运行。四个框架的宏平均可靠性得分落在 59.8% 至 72.0%。所谓宏平均，是先分别计算各部分或各组表现，再给予相同权重求平均，避免任务多的类别完全主导结果。
更醒目的数字是：31.1% 的运行完成了任务，却至少没有通过一项框架判据。这不代表“31.1% 的成功其实发生了框架故障”，更不能据此推出这些运行都只是侥幸成功。它准确表达的是：最终产物合格，并不足以证明运行过程中的每项框架义务都已履行。
这正是只看终点会漏掉的风险。一次丢失状态或不忠实的工具回报，可能没有影响当前任务，却会暴露系统在其他场景中的脆弱点。反过来，如果框架忠实工作，而模型在完整信息面前做错决定，责任也不应被含混地记在整个“智能体”名下。
为什么现在值得关注
这两项工作的共同价值，不是再造一张排行榜，而是改变评测对象。智能体表现是模型、运行框架与任务共同作用的结果。跨模型评测——让同一框架搭配多个模型反复测试——可以看出它是普遍可靠，还是只与某个模型特别合拍；同样，也能观察一个模型换了工作台后是否仍能稳定执行。
这会影响研发判断。如果失败来自上下文被截断、工具结果传递失真或生命周期控制异常，单纯更换更强模型未必解决问题。如果某套框架只在特定模型和任务上表现好，把它的单次领先当成普适能力也会误导选择。
局限与未知
- 两项研究采用不同任务集、指标和实验规模。59.8% 至 72.0%、31.1%、OpenCode 的排名与 DeepSeek V4 Flash Preview 的 VCR 表现不能直接比较，也不能推出普适排名。
- TraceTrial-Bench 的判据、证据选择和故障归因依赖论文定义的边界。判据失败是操作性结果；确认框架缺陷或因果传播，还需要按相应证据来源复核。
- 《When Agents Fail》的供稿只有论文摘要。关于训练可迁移的框架使用能力、为模型和任务设计适配框架等内容，目前应视为作者建议，而非已被独立验证的效果结论。