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 文档。
工程上可以把这个过程落成一个受控闭环:
Rollout 采样:让目标智能体在训练任务上执行当前 Skill,记录消息、工具调用、验证反馈、任务元数据和最终得分。
成功/失败分组:分别分析高分轨迹和失败轨迹,从中提取可复用过程规则,而不是只总结某个样例答案。
受控文本编辑:只允许对 Skill 做小范围的新增、删除或替换,并设置文本级学习率,避免一次大改覆盖原本有效的规则。
验证集门控:候选 Skill 只有在 held-out 任务上严格优于当前版本时才被接受;否则进入拒绝编辑缓冲区,作为下一轮优化的负反馈。
产物导出:部署时只加载最终 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 时,还要加入训练集与验证集分离、受控编辑和拒绝记录等门控机制。
最后更新于
