For the complete documentation index, see llms.txt. This page is also available as Markdown.

13.1 Harness 评估方法论

行业现状

LangChain《State of Agent Engineering》调研数据(1300+从业者):

  • 52.4% 的组织在测试集上运行离线评估

  • 37.3% 实施在线评估(online evaluations)

  • 22.8% 的生产阶段组织根本不做评估

  • 关键落差:可观测性采用率 89% vs 评估采用率 52%

这说明许多团队已经能“看到”智能体在做什么,但从可观测性到质量判断仍存在采用率落差。

13.1.1 评估的三个层级

智能体系统的质量评估需要在三个层级进行,从细到粗:

图 13-1:智能体三层评估架构

层级 1:步骤级评估

定义:评估单个工具调用是否正确。

关键问题

  • 工具选择是否正确?(调用了合适的工具吗?)

  • 参数是否正确?(参数值是否符合预期?)

  • 工具执行是否成功?(有无错误?)

评估指标

指标
定义
计算

工具准确率

选择正确工具的比例

correct_tools / total_calls

参数准确率

参数正确的比例

correct_params / total_params

执行成功率

工具调用不出错的比例

successful_calls / total_calls

计算示例

层级 2:轨迹级评估

定义:评估工具调用序列的效率和正确性。

关键问题

  • 是否走了弯路?(多余的调用?)

  • 调用顺序是否高效?(能否更快完成?)

  • 是否自我纠正?(遇到错误如何反应?)

评估指标

指标
定义
计算

轨迹长度效率

实际调用数 vs 最优调用数

optimal_steps / actual_steps

错误恢复率

遇到工具错误后成功恢复的比例

recovered_errors / total_errors

重复调用率

相同工具连续调用的次数

duplicate_calls / total_calls

平均调用深度

完成任务所需的平均步骤数

sum(trajectory_lengths) / num_tasks

计算示例

层级 3:任务级评估

定义:评估是否完成了用户的最终目标。

关键问题

  • 最终答案是否正确?

  • 完成任务的成功率是否足够高?

  • 花费的资源(token、时间、成本)是否可接受?

评估指标

指标
定义
范围

任务成功率

完成任务的比例

0-100%

执行时间

完成任务的平均时间

Token 效率

平均每个任务消耗的 Token

Token 数

成本效率

平均每个任务的 API 成本

美元

用户满意度

用户对结果的满意评分

1-5 分

计算示例

13.1.2 评估指标体系

综合三个层级,构建完整的评估指标体系:

13.1.3 评估框架架构

评估框架的核心架构实现:

13.1.4 技能训练评估闭环

前面的三层评估不仅能用于比较模型或 Harness 版本,也能用于优化 Skill 这类过程性知识资产。SkillOpt 一类方法的关键启发是:不要把 Skill 当作一次性手写说明,而要把它当作冻结智能体外部的一份可训练配置;模型、工具和 Harness 保持不变,真正被迭代的是指导证据收集、工具使用、验证和输出格式的 Skill 文档。

工程上可以把这个过程落成一个受控闭环:

  1. Rollout 采样:让目标智能体在训练任务上执行当前 Skill,记录消息、工具调用、验证反馈、任务元数据和最终得分。

  2. 成功/失败分组:分别分析高分轨迹和失败轨迹,从中提取可复用过程规则,而不是只总结某个样例答案。

  3. 受控文本编辑:只允许对 Skill 做小范围的新增、删除或替换,并设置文本级学习率,避免一次大改覆盖原本有效的规则。

  4. 验证集门控:候选 Skill 只有在 held-out 任务上严格优于当前版本时才被接受;否则进入拒绝编辑缓冲区,作为下一轮优化的负反馈。

  5. 产物导出:部署时只加载最终 Skill 文件,不加载优化器、训练轨迹或历史缓冲区,从而不增加推理时调用次数。

这个闭环把“反思后自动改提示词”升级为“有验证门禁的配置训练”。它对 Harness 评估体系提出了三个额外要求:

要求
工程含义

固定目标环境

比较 Skill 版本时,模型、工具、权限和任务集要保持一致

区分训练与选择

训练 rollout 的分数不能直接作为上线依据,必须保留未参与编辑的选择集

保留拒绝记录

被验证集拒绝的编辑是重要信号,可防止优化器反复提出破坏性改动

这类方法适合高重复、流程稳定、可自动评分的任务,如表格处理、搜索问答、文档理解和长时工具任务。对于低频、目标模糊或无法自动判分的任务,应优先采用人工审阅和小样本回归集,而不是让 Skill 自动演化;软件工程任务也可能受益,但需要单独设计可复现评分与回归验证。

13.1.5 评估结果可视化

把上面这套指标画成一页报告图,是让评估结果进入周会与版本决策的最省事方式。布局直接沿用三个层级:步骤级放工具与参数准确率,轨迹级放效率,任务级放成功率,再补上错误恢复率、平均耗时与综合评分——六个面板恰好覆盖 13.1.1 与 13.1.2 定义的全部口径,看图的人不必再回头翻指标定义。

具体的绘图实现属于工程细节,放在了仓库的 tools/eval_report.py:它自带与 13.1.2 一致的 EvaluationMetrics 定义,可直接运行看示例,也可以 import 其中的 visualize_evaluation() 传入自己流水线算出的指标。

读这张图时有一处要当心:六个面板里只有综合评分是加权合成的,其余五个是各自独立的口径,不要横向比高低——工具准确率 0.92 与轨迹效率 0.74 不构成「前者更好」,它们量纲不同。真正该盯的是同一格在版本之间的变化。


本节总结:Harness 系统的质量评估需要从步骤、轨迹、任务三个层级进行,每层都有特定的指标和计算方法。综合评分权衡了任务成功、效率、准确性和成本;当评估对象是 Skill 时,还要加入训练集与验证集分离、受控编辑和拒绝记录等门控机制。

最后更新于