任务成功不等于系统可靠：TraceTrial-Bench 如何审视 AI Agent Harness

导语

在评估 AI Agent 时，最容易观察到的指标是任务是否完成。但一个代理给出正确结果，并不意味着它在运行过程中遵守了上下文约束、正确调用了工具，或留下了足够的审计证据。结果正确有时可能只是偶然，甚至可能掩盖了系统层面的失效。

Hugging Face Daily Papers 收录的研究提出 TraceTrial-Bench，试图把注意力从单纯的模型能力和最终成功率，转向支撑 Agent 运行的 Harness 可靠性。这里的 Harness 可以理解为连接模型、上下文、工具、执行环境和控制机制的系统层。

核心要点

• 把可靠性拆成七个维度。 基准从上下文、执行、治理、生命周期、可观测性、工具和验证七个组件检查 Harness，而不是把所有问题压缩成一个最终得分。
• 任务关注机制，而非表面答案。 研究团队设计了 95 个专家级、面向机制的任务，并使用可执行或基于状态的真实标签，使不同 Harness 能在语义等价的条件下比较，同时保留各自原生行为。
• 分别评估代理表现和 Harness。 两层评估框架将任务结果与系统运行可靠性分离，避免用一次成功的最终输出替代对整个执行过程的检查。
• 让执行过程变得可追踪。 Trajectory Tracing 模块负责记录代理运行轨迹；Multi-source Evidence Acquisition 模块则从代理上下文、Harness 和执行环境收集证据，为基于大模型的评估提供依据。
• 尝试解释失败来自哪里。 Failure Attribution 模块通过明确的机制链，在单次运行层面分析失败原因，而不是只报告一个笼统的失败标签。

实验揭示了什么

研究覆盖 4 个 Harness、9 个模型和 95 个任务，共分析 3,420 次运行。不同 Harness 的宏平均得分处于 59.8% 至 72.0% 之间，说明在相同或相近的模型条件下，支撑系统本身仍可能带来明显差异。

更值得注意的是，31.1% 的运行虽然完成了任务，却至少未通过一项 Harness 标准。这一结果并不表示这些运行的最终答案必然错误，而是说明“任务成功”和“系统可靠”是两个不能互相替代的概念。一个系统可能在特定输入上得到正确答案，同时在工具调用、状态管理、验证或可观测性方面留下隐患。

意义与影响

这项工作的价值首先在于改变了 Agent 评估的观察对象。未来的基准如果只比较模型回答质量，可能会忽略运行框架对结果稳定性、可审计性和安全边界的影响。对于开发者而言，轨迹记录和多源证据能够帮助团队定位问题究竟发生在模型决策、Harness 控制逻辑，还是外部执行环境。

不过，基准分数仍应被视为诊断工具，而非系统可靠性的最终证明。Harness 的优劣会受到任务设计、证据质量和评估规则影响；不同场景也可能对七个组件赋予不同权重。TraceTrial-Bench 的重要贡献，是提供了一种更细粒度、可复现且便于追责的讨论框架：Agent 是否完成任务只是起点，系统如何完成、哪里可能失效，以及失败能否被解释，同样需要进入评价体系。

来源：Hugging Face Daily Papers