AI Applications

Agent Harness Engine: Evaluating Tool-Using Agents Under Controlled Context

Misaya Yang 2026-05-31T00:10:00.000Z

从一次难以复盘的 Agent trace 开始，拆出 task spec、context builder、tool sandbox、trace store 与 evaluator。

RAG, Agent Systems, Context Engineering, Evaluation, Observability, Tool Use, Harness Engine, Fine-tuning

Agent Harness Engine: Evaluating Tool Using Agents Under Controlled Context 第一次认真看 Agent trace 时，最不舒服的地方不是模型答错了，而是很难说清楚它到底从哪一步开始错。它可能检索到了相似但无关的材料，可能工具参数少了一个字段，可能在第三轮 observation 后忘了最初的约束，也可能只是被一个看起来合理的中间结果带偏。最后用户看到的是一句“助手没有完成回答”，但工程上这句话没有任何诊断价值。更稳妥的做法，是把 Agent 开发拆成两个问题： Agent Harness Engine 关心的是第二个问题。它不是为了让一次 demo 看起来更厉害，而是把工具型 Agent 的运行过程变成可比较、可复现、可定位的实验对象。 1. 先别急着调 prompt 工具型 Agent 的失败经常被归因于 prompt 不够好，但很多问题其实不在 prompt 里。几个博客 Agent 和代码 Agent 都容易遇到的症状：模型知道要查资料，但查的是全站而不是当前文章。工具调用成功了，但返回结果没有进入下一轮上下文。回答里引用了来源，但 source card 指向了错误页面。任务其实已经失败，运行时仍然继续烧 token。一次回归通过了，换一个相邻问题就完全不稳定。如果没有 harness，这些问题会混在一起。开发者只能在聊天记录里猜：是不是检索差？是不是模型差？是不是上下文太长？是不是 UI 没传 route context？ Harness 的价值，是先把这些变量拆开。这条链路里的每一层都应该留下证据。否则所谓“Agent 质量”只是对一次 transcript 的印象。 2. Task Spec: 把任务写成可失败的东西一个好的任务规格不只是用户问题，它至少要包含：关键在于：任务必须允许系统明确失败。比如“解释这篇文章的核心机制”不是一个完整 task spec。更好的写法是：这样失败才会变成具体类型，而不是一句“模型没答好”。 3. Context Bu...