作者：陈孟卓，中科院软件所 PhD

一次工具调用返回了 success，任务就真的完成了吗？

未必。

在一个应用自动化任务中，Agent 连续发起了 3 次付款请求。接口表面上返回“执行成功”，但由于请求缺少必填字段，预期的付款记录一条也没有生成。

更糟的是，错误被中间层吞掉，任务完成条件又只检查了返回状态，于是 Agent 顺利提交了一个实际上失败的结果。

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

这套包裹模型并决定其如何行动的基础设施，通常被称为 Agent Harness。

来自中国科学院软件研究所的团队提出的最新工作 HarnessFix 试图解决一个越来越重要的问题：

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

论文在 GAIA、SWE-Bench Verified、AppWorld 和 Terminal-Bench 2.0 Verified 四个基准上进行评估。相较初始 Harness，HarnessFix 将任务完成率提升了 6.3 至 18.4 个百分点。

论文题目：From Failed Trajectories to Reliable LLM Agents: Diagnosing and Repairing Harness Flaws  
作者：Mengzhuo Chen, Junjie Wang, Zhe Liu, Yawen Wang, Haiming Zheng, Qing Wang  
单位：中国科学院软件研究所、中国科学院大学、天津大学等  
论文链接：https://arxiv.org/abs/2606.06324 
项目代码：https://github.com/HarnessFix/HarnessFix

Agent 失败，为什么不能只怪模型？

一个 LLM Agent 通常可以看成两部分：

• 基础模型：负责理解、推理与生成；
• Agent Harness：负责给模型提供环境、工具、上下文、执行流程、日志、验证与安全约束。

按照 ETCLOVG 分类，Harness 覆盖七层职责：

1、 Execution：执行环境与沙箱；
2、 Tool Interface：工具描述、选择、参数与错误反馈；
3、 Context and Memory：上下文、会话状态、摘要与长期记忆；
4、 Lifecycle and Orchestration：循环、重试、任务状态、协作与终止；
5、 Observability：轨迹、日志、错误、成本与状态变化；
6、 Verification and Evaluation：中间检查、最终验证与回归测试；
7、 Governance and Security：权限、审批、策略与审计。

模型每一步能看到什么、能调用什么、错误如何返回、什么时候允许结束，实际上都由这些机制共同决定。

为了了解 Harness 问题在真实开发中有多普遍，我们分析了 30 个流行开源 LLM Agent 仓库中的约 57,780 条开发记录，包括 issue、pull request、commit 和 release note。其中 26,174 条与 Harness 相关，占 45.3%；30 个仓库全部出现过此类修改。

进一步分析发现，缺陷并不集中在 Prompt。Lifecycle、Tooling 和 Observability 是最常见的三类问题，30 个仓库中有 29 个涉及这三层中的缺陷。

图 1：Harness 相关开发记录占 45.3%，缺陷分布覆盖七层职责。

这也解释了为什么“再改一版 Prompt”经常不够。如果问题出在工具 Schema、上下文构造、控制器、日志钩子或验证脚本，仅根据最终成功率搜索提示词，很难触及真正的根因。

HarnessFix：先诊断，再限域修复

HarnessFix 的出发点很直接：先回答“哪里坏了、为什么坏、由哪段实现造成”，再决定“应该改什么”。

整个流程分为四个阶段：

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

图 2：HarnessFix 从执行证据出发，完成轨迹建模、缺陷诊断、限域修复和验证。

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

原始 Agent 轨迹往往是碎片化的：模型消息、工具调用、环境反馈、中间状态和最终提交交织在一起。它们记录了“发生了什么”，却很难直接说明“哪一步导致失败”。

HarnessFix 为此构造了 Harness-aware Trace Intermediate Representation（HTIR）。

HTIR 将一次执行拆成一系列 TraceStep。每个步骤不仅保存请求与响应，还标注：

• 这一步承担什么角色，例如工具调用、验证或最终提交；
• 执行状态是成功、失败、超时还是阻塞；
• 是否产生了文件、环境或应用状态变化。

随后，HTIR 重建两类跨步骤关系：

• 数据流链接：关键信息从哪里进入，后来是否被复用、遗漏、污染或错误摘要；
• 控制流链接：Harness 为什么选择继续、重试、委派、验证或结束。

更关键的是，HTIR 会为运行时证据建立 Implementation Anchor，把可疑步骤锚定到具体可编辑的 Harness Artifact，例如 Prompt 模板、工具规范、配置文件、适配器、控制器、日志钩子或验证脚本。

至此，“这次执行错了”才真正变成“这类运行机制可能需要修改”。

第二步：从失败症状回溯到责任步骤

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

1、 定位症状：外部评估器观察到了什么失败；
2、 回溯证据：哪些上游步骤与失败存在数据或控制关系；
3、 裁决责任：哪些步骤形成、传播、隐藏或未验证了关键错误；
4、 映射层级：问题属于 Harness 的哪一层或哪几层。

单条失败也可能只是偶然。因此，HarnessFix 会把多条轨迹中重复出现的诊断合并成 Flaw Record，记录共同根因、涉及的 Harness 层、责任步骤和支撑证据。

第三步：把诊断转换成有边界的 Repair Operator

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

例如：

• Tool Interface 问题可对应工具 Schema 收紧、参数校验、工具排序或错误信息修复；
• Lifecycle 问题可对应循环保护、重试上限、显式任务状态或验证后再结束；
• Observability 问题可对应错误日志、工具调用结果或状态差异记录；
• Verification 问题可对应预期/实际状态比较、效果证据检查或回归测试；
• Governance 问题可对应最小权限、高影响操作审批或越界行为阻断。

每次修复都会生成一份 Repair Specification，明确：

• 修复目标是什么；
• 允许编辑哪些 Artifact；
• 哪些范围禁止改动；
• 修复后必须满足什么行为。

它的作用类似一份针对当前缺陷的实现合同：把修改控制在证据支持的范围内。

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

候选补丁首先要通过语法、静态检查和修改范围检查，随后在保留的验证集上运行。

只有当补丁能够降低目标缺陷的出现频率，同时没有让原本成功的任务产生不可接受的回归时，才会被接受。无论接受还是拒绝，HarnessFix 都会记录本次缺陷、修复规范、代码差异、验证结果和适用条件，形成后续可复用的 Repair Memory。

这一步很重要。Agent Harness 横跨 Prompt、工具、状态与验证逻辑，一个局部“看起来有效”的修改，很可能在其他任务上制造新问题。

一个例子：API 返回成功，任务却没有完成

下面是论文中的 AppWorld 示例。

任务要求 Agent 根据三笔订单创建三条付款请求。工具文档明确要求 user_email，但 Agent 后续构造请求时漏掉了该字段。API 调用失败后，执行层捕获并吞掉异常，只向上返回 Execution successful。完成条件又把这个状态当作任务进展，最终允许 Agent 调用 complete_task()。

图 3：请求遗漏必填字段，错误被吞掉，Harness 仍允许提前完成任务。

如果只看最终结果，我们可能会得出“模型忘记填写参数”的结论。但 HTIR 能把整条证据链连接起来：

• S3 的工具文档给出了必填字段；
• S4 的请求体遗漏了 user_email；
• S5 没有产生预期的应用状态变化，错误信息也没有被暴露；
• S6 的完成条件仍然放行了最终提交。

因此，修复不应只是在 Prompt 中再提醒一句“记得填写邮箱”，还应考虑参数校验、错误暴露、状态变化检查和验证后再结束等 Harness 机制。

实验结果：提升来自诊断，而不只是更多搜索

论文在四类任务上评估 HarnessFix：

• GAIA：开放式研究与问答；
• SWE-Bench Verified：仓库级软件修复；
• AppWorld：带状态的应用自动化；
• Terminal-Bench 2.0 Verified：命令行工作流。

在 GPT-5 mini 设置下，任务完成率（TCR）结果如下。表中数值为三次独立运行的算术平均值。

在端到端比较中，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%；
• Implementation Anchor 准确率：81.3%；
• Harness 层级 Macro-F1：86.2%；
• Repair Operator 准确率：82.5%。

如果只输入原始轨迹，对应结果分别只有 55.0%、53.8%、50.0%、58.4% 和 51.3%。

消融实验也显示，以下任何一项被移除，最终表现都会下降：

• 只允许修改 Prompt；
• 去掉基于轨迹证据的诊断；
• 去掉限域 Repair Operator；
• 去掉回归感知的补丁验收。

此外，用 GPT-5 mini 轨迹修复得到的 GAIA Harness，在不进行目标模型专项分析的情况下，迁移到 Claude Sonnet 4.5、DeepSeek V3.2、Qwen3.5 Plus 和 Gemini 3 Pro 后，仍带来 5.5 至 9.5 个百分点的提升。

这说明至少一部分修复针对的是不同模型共享的 Harness 机制，而不是某个模型的偶然行为。

这项工作意味着什么？

HarnessFix 并不是在训练一个更强的基础模型，也不意味着所有 Agent 失败都能通过修改 Harness 解决。

它依赖足够完整的执行轨迹、能够定位和编辑的 Harness Artifact，以及可运行的验证任务。如果系统缺乏可观测性，或者任务没有可靠的结果检查，诊断和修复都会受到限制。

但这项工作提出了一个值得重视的工程视角：

当 Agent 开始承担长链路、工具密集、带状态的复杂任务时，可靠性问题不能被简单压缩成“模型能力不够”。

失败轨迹里包含因果证据，Harness 实现中存在可修复的机制。将二者对齐，能够让 Agent 系统从基于最终分数的反复调参，进一步走向 可诊断、可限域修复、可回归验证 的工程闭环。

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