HarnessTester Agent Harness 测试研究

HarnessTester：Agent Harness 测试覆盖与 122 个真实缺陷

作者
DeepSeekAgent.io 编辑部
发布
更新

Agent 的问题不一定来自模型。解析模型输出、生成工具调用、维护 Session 状态、处理权限和恢复失败的 Harness 代码，同样会把一个正确意图变成错误行为。

论文《Complex Agents, Shallow Tests》研究了 10 个真实开源 Agent 系统，提出一个直接的问题：这些决定 Agent 行为的 Harness 代码，究竟有没有被现有测试充分覆盖？

什么是 LLM-Dependent Harness Code

论文把直接消费 LLM 输出或控制后续 Agent 行为的部分称为 LLM-Dependent Harness（LDH）代码。典型路径包括：

  • 将模型文本解析为 Tool Call；
  • 校验工具名、参数、消息角色与结构；
  • 根据 Finish Reason 决定继续、重试或停止；
  • 把工具结果写回上下文；
  • 在模型输出异常时执行回退；
  • 根据模型判断推进工作流状态。

这类代码的难点是“能运行”不等于“语义正确”。测试可以执行到某个分支，却没有验证错误的工具参数、状态污染或恢复顺序，因此只看行覆盖率会高估可靠性。

论文发现测试缺在哪里

作者报告，现有测试覆盖不到一半的 LDH 行与分支，LDH 的平均 Mutation Score 为 33.60%。这意味着很多有意植入的行为变化没有被测试发现。

论文进一步区分两类漏检：一类代码根本没有执行到；另一类虽然执行了，但测试断言无法识别行为已经改变。对 Agent Harness 而言，第二类尤其危险，因为 CI 可以全部通过，实际工具选择、消息状态或权限判断却已经出错。

HarnessTester 如何生成更有效的测试

普通测试生成器容易构造“类型正确、协议错误”的 Mock。例如伪造了一条模型响应，却没有创建匹配的 Session、工具注册、消息序列和状态前置条件，结果只能覆盖入口，无法进入真正控制行为的深层分支。

HarnessTester 显式建模 Agent–Harness Contract，让生成测试遵守组件之间的结构、状态与交互协议，并按需检索相关定义与 Fixture。目标不是制造更多测试文件，而是建立能让 LDH 代码按真实路径运行的测试环境。

与论文采用的通用测试生成基线相比，作者报告 HarnessTester 的提升为：

指标相对最强通用基线的增益
行覆盖增益75.95%
分支覆盖增益84.76%
Mutation Score 增益69.89%

去掉 Contract 支持后，覆盖提升也明显下降，说明关键不只是让 LLM 多写测试，而是向测试生成器提供正确的 Harness 协议。

122 个真实缺陷意味着什么

HarnessTester 在研究对象的当前版本中发现 122 个真实 Harness 缺陷，其中 88 个此前未知，论文提交时有 69 个已获开发者确认。

这个数字不能直接推导出所有 Agent 产品都不可靠，也不能用来给某一个项目排名。它说明的是：模型与 Harness 交界处存在一类系统性测试空白，而且这些空白确实会转化成真实缺陷。

对 DeepSeek Harness 的直接启示

DSH 的插件化架构让工具、模型适配器、上下文注入、Session 存储和 UI 扩展都能独立演化，同时也增加了组件契约数量。只测插件能否加载远远不够，至少应覆盖：

  1. 模型输出缺字段、字段类型错误或 Finish Reason 异常；
  2. Tool Call 与 Tool Result 不配对、顺序变化或重复提交；
  3. 插件启停后工具 Schema 与 / 菜单是否同步；
  4. 父 Agent、Sub-agent 与并行 Session 的状态是否隔离；
  5. Compaction、Resume、Provider 切换后历史是否仍符合消息协议；
  6. 权限拒绝、网络失败和部分写入后能否安全恢复。

DeepSeek Harness 安全模型解决“允许做什么”，Harness 测试还要回答“实现是否真的遵守了这套边界”。安全策略、契约测试、故障注入和 Mutation Testing 应当放在同一条验证链上。

一套可落地的测试分层

层级主要验证内容
Contract消息、工具、事件和状态结构是否合法
TransitionContinue、Stop、Retry、Compact、Resume 的状态迁移
Fault injection超时、截断、重复回调、工具失败和部分写入
IsolationProfile、Session、Sub-agent 与插件作用域
Mutation测试能否发现权限判断、分支条件和恢复顺序被改坏
End-to-end固定模型 Stub 下的完整任务轨迹与产物

模型输出可以使用确定性 Fixture，但 Fixture 必须保留真实协议关系。只有这样，测试失败才能定位 Harness 回归，而不是被模型采样波动掩盖。

研究边界

论文研究的是 10 个开源系统和作者定义的 LDH 范围。覆盖率与 Mutation Score 衡量的是测试发现代码变化的能力，不等于产品正确率，也不替代真实模型、真实工具和真实权限环境下的端到端评测。

参考资料

常见问题

行覆盖率高，是否说明 Harness 已经测好了？

不说明。代码被执行过，不代表断言能发现行为变化。分支覆盖、Mutation Testing、契约与状态迁移需要一起检查。

HarnessTester 是 DSH 的测试工具吗？

不是。它是论文提出的通用 Harness 测试生成方法。本文将研究结论用于分析 DSH 应覆盖的测试边界。