当工具调用返回success状态时，是否就意味着任务真正完成了？

未必如此。

在一个自动化付款任务中，Agent连续发起了三笔付款请求，接口表面返回“执行成功”，但由于请求缺少必填的用户邮箱字段，最终没有生成任何实际的付款记录。更糟糕的是，中间层悄悄吞掉了错误，而任务完成条件仅检查了接口返回状态，导致Agent提交了一个实际上完全失败的结果。

这类问题看起来像是“模型粗心”，但真正需要修复的往往是模型外部的运行基础设施：比如工具参数未校验、错误未暴露、完成条件未检查真实状态变化等。

能否把失败轨迹从一个结果信号，转化为可定位、可归因、可修复、可回归验证的工程证据？

这套包裹模型并决定其如何行动的基础设施，通常被称为Agent Harness。来自国内科研团队的最新工作HarnessFix，正是为了解决这个越来越受关注的问题。

论文题目：From Failed Trajectories to Reliable LLM Agents: Diagnosing and Repairing Harness Flaws


单位：国内科研团队


论文链接：https://arxiv.org/abs/2606.06324


项目代码：https://github.com/HarnessFix/HarnessFix

LLM Agent失败，为何不能只归咎于模型？

一个LLM Agent通常可以拆分为两个核心部分：

• 基础模型：负责理解、推理与内容生成
• Agent Harness：负责提供运行环境、工具调用接口、上下文管理、执行流程控制、日志记录、验证约束与安全策略等

按照通用分类框架，Harness的职责可以分为七个层级：

• 执行环境与沙箱
• 工具接口：包括工具描述、选择、参数校验与错误反馈
• 上下文与记忆：管理会话状态、上下文摘要与长期记忆
• 生命周期编排：处理循环、重试、任务状态切换、协作与终止逻辑
• 可观测性：记录执行轨迹、日志、错误信息、成本与状态变化
• 验证与评估：包括中间检查、最终验证与回归测试
• 治理与安全：管理权限、审批、策略与审计流程

为了了解Harness问题在实际开发中的普遍性，研究团队分析了30个主流开源LLM Agent仓库的约5.7万条开发记录，包括issue、PR、提交记录与发布说明。其中超过45%的记录与Harness相关，且所有30个仓库都出现过Harness相关的修改。

进一步分析发现，缺陷并不集中在Prompt工程，最常见的三类问题分别是生命周期编排、工具接口与可观测性层面的问题，29个仓库都存在这三类中的至少一种缺陷。这也解释了为什么“再改一版Prompt”往往无法解决根本问题：如果问题出在工具Schema、上下文构造、控制器、日志钩子或验证脚本，仅根据最终成功率调整提示词，很难触及真正的根因。

HarnessFix：先诊断，再精准修复

HarnessFix的核心思路非常直接：先明确“哪里出了问题、为什么会出错、具体是哪一段代码或配置导致的”，再据此确定需要修改的内容，而不是盲目调整模型提示词。整个流程分为四个阶段：

1. 将原始轨迹与Harness实现编译为HTIR
2. 沿数据流和控制流进行失败归因
3. 将诊断映射为有明确边界的修复
4. 通过回归感知验证决定是否接受补丁，并记录修复记忆

第一步：用HTIR把轨迹变成可归因证据

原始的Agent执行轨迹往往是碎片化的，混合了模型消息、工具调用、环境反馈、中间状态与最终提交结果，只能记录“发生了什么”，却无法直接定位“哪一步导致了失败”。为此，HarnessFix构建了Harness-aware Trace Intermediate Representation（HTIR），将一次执行拆分为多个TraceStep，每个步骤不仅保存请求与响应内容，还标注了该步骤的角色（如工具调用、验证或最终提交）、执行状态（成功、失败、超时或阻塞）以及是否产生了实际的应用状态变化。

在此基础上，HTIR还会重建两类跨步骤关系：

• 数据流链接：用于追踪关键信息的流入、复用、遗漏或污染
• 控制流链接：用于解释Harness为何选择继续执行、重试、委派任务、验证或终止流程

更关键的是，HTIR会为运行时证据建立Implementation Anchor，将可疑步骤锚定到具体可编辑的Harness组件，比如Prompt模板、工具规范、配置文件、适配器、控制器、日志钩子或验证脚本，让“单次执行失败”转化为“特定运行机制需要优化”的明确指向。

第二步：沿数据流和控制流进行失败归因

HarnessFix的诊断过程并非让模型自由总结整条轨迹，而是沿着HTIR中的数据流与控制流逐步回溯：

1. 定位外部观察到的失败症状
2. 回溯与失败存在数据或控制关联的上游步骤
3. 裁决哪些步骤生成、传播、隐藏或未验证了关键错误
4. 将问题映射到对应的Harness层级

由于单次失败可能存在偶然性，HarnessFix会将多条轨迹中重复出现的诊断合并为Flaw Record，记录共同根因、涉及的Harness层级、责任步骤与支撑证据。

第三步：将诊断映射为有明确边界的修复

得到Flaw Record后，HarnessFix不会允许修复代理随意修改整个仓库，而是根据缺陷类型选择有限的Scoped Repair Operator：

• 工具接口问题：可对应收紧工具Schema、添加参数校验、调整工具调用顺序或修复错误提示信息
• 生命周期问题：可对应添加循环保护、设置重试上限、明确任务状态或要求验证通过后再结束任务
• 可观测性问题：可对应优化错误日志、记录工具调用结果或状态差异
• 验证问题：可对应添加预期与实际状态对比、验证效果证据或增加回归测试
• 治理与安全问题：可对应设置最小权限、高风险操作审批或阻断越界行为

每次修复都会生成一份Repair Specification，明确修复目标、允许编辑的组件范围、禁止改动的边界以及修复后需要满足的行为要求，相当于针对当前缺陷的实现合同，将修改控制在证据支持的范围内。

第四步：通过回归感知验证决定是否接受补丁

候选补丁首先需要通过语法检查、静态检查与修改范围检查，随后在保留的验证数据集上运行。只有当补丁能够降低目标缺陷的出现频率，同时不会让原本成功的任务出现不可接受的回归时，才会被正式接受。

无论补丁被接受还是拒绝，HarnessFix都会记录本次缺陷、修复规范、代码差异、验证结果与适用条件，形成可复用的Repair Memory。这一步至关重要，因为Agent Harness横跨Prompt、工具、状态与验证逻辑，局部看似有效的修改很可能在其他任务中引入新的问题。

实战案例：接口返回成功，任务却未实际完成

我们可以用论文中的AppWorld示例来具体说明：任务要求Agent根据三笔订单创建三条付款请求，工具文档明确要求提供user_email字段，但Agent在构造请求时遗漏了该字段。API调用失败后，执行层捕获并吞掉了异常，仅向上返回“Execution successful”，而完成条件将这个状态当作任务进展，最终允许Agent调用complete_task()。

如果只看最终结果，我们可能会得出“模型忘记填写参数”的结论，但通过HTIR可以完整还原证据链：工具文档明确列出了必填字段，请求体遗漏了user_email，没有产生预期的应用状态变化且错误信息未被暴露，最终完成条件放行了提交。因此，修复不应仅在Prompt中提醒“记得填写邮箱”，还需要考虑添加参数校验、暴露错误信息、检查实际状态变化以及验证通过后再结束任务等Harness机制。

实验效果：性能提升源于结构化诊断

研究团队在四个基准任务上评估了HarnessFix的效果：GAIA（开放式研究与问答）、SWE-Bench Verified（仓库级软件修复）、AppWorld（带状态的应用自动化）与Terminal-Bench 2.0 Verified（命令行工作流）。

在GPT-5 mini的设置下，三次独立运行的平均任务完成率（TCR）显示，相较于初始Harness，HarnessFix将任务完成率提升了6.3至18.4个百分点。具体数据如下：

端到端对比显示，HarnessFix的平均任务完成率比人工设计的Harness高出6.3个百分点，比基于同一初始Harness的自动Self-evolution/Repair基线高出6.9个百分点。即使与最强的自动基线Meta-Harness相比，HarnessFix仍高出2.6至5.0个百分点，而Meta-Harness的离线演化与修复的Token消耗则高出63.5%至100.5%。

诊断实验进一步验证了结构化轨迹的价值：与人工标注结果相比，完整HTIR实现了85.0%的责任步骤准确率、83.8%的根因准确率、81.3%的Implementation Anchor准确率、86.2%的Harness层级Macro-F1值以及82.5%的Repair Operator准确率。如果仅输入原始轨迹，对应指标分别仅为55.0%、53.8%、50.0%、58.4%与51.3%。

消融实验显示，移除任何一个核心模块（仅允许修改Prompt、去掉基于轨迹证据的诊断、去掉限域修复操作符、去掉回归感知的补丁验收）都会导致最终性能下降。此外，用GPT-5 mini轨迹修复得到的GAIA Harness，在不针对目标模型进行专项分析的情况下，迁移到其他主流模型后仍带来5.5至9.5个百分点的提升，说明部分修复针对的是不同模型共享的Harness机制，而非单个模型的偶然行为。

这项研究的价值与启示

HarnessFix并非旨在训练更强的基础模型，也不意味着所有Agent失败都可以通过修改Harness解决，它依赖足够完整的执行轨迹、可定位与编辑的Harness组件以及可运行的验证任务。如果系统缺乏可观测性，或者任务没有可靠的结果检查，诊断与修复都会受到限制。

但这项工作提出了一个值得重视的工程视角：当Agent开始承担长链路、工具密集、带状态的复杂任务时，可靠性问题不能被简单压缩为“模型能力不足”。失败轨迹中包含因果证据，Harness实现中存在可修复的机制，将二者对齐可以让Agent系统从基于最终分数的反复调参，进一步走向可诊断、可限域修复、可回归验证的工程闭环。

失败轨迹不再只是一次失败的记录，更可以成为下一次系统性改进的起点。