基于顶级 Agent（Claude Code）的 Harness 工程搭建式业务 Agent 评测方案

用一个顶级 Agent 搭建评测框架，系统化解决业务 Agent 快速迭代中的评测难题，让评估从“周级”变为“天级”。

• Harness工程式评测的核心思路与架构设计
• 基于Claude Code搭建评测框架的五步法
• 与传统评测方法在效率与灵活性上的硬碰硬对比

先说几个核心判断。基于一次比较彻底的工程实践——用Claude Code这个强Agent来构建评测Harness，系统性地评测一群业务Agent，我们得出一个结论：评测这事儿，完全可以从“周级启动”进化到“天级启动”。

一、背景与问题

1.1 业务场景

某业务系统的内容生成链路由多个子Agent协作完成。图片理解、内容审核、文案生成、风格匹配……每个Agent各司其职，但Prompt方案迭代极快。每次变更之后，能不能快速看效果，成了阻碍迭代速度的核心瓶颈。

矛盾很直接：业务Agent迭代几乎是按天计算的，而传统的评测工程搭建却还是要按周来算。

1.2 传统评测的痛点

痛点	表现
启动成本高	搭建评测工程、写脚本、部署服务，还没开始评就花了一周
人力密集	标注数据集、写分析脚本、出报告，每个环节都需人工介入
迭代慢	Prompt改了一行，想看效果要等半天重新跑
可复现性差	评测逻辑散落在各种脚本和Notebook里
指标不统一	不同Agent各搞一套，无法横向对比
工程化沉重	每换一个Agent就要新写一套评测代码

1.3 我们的解法：Harness工程搭建式评测

核心思路并不复杂：用一个顶级Agent——Claude Code——作为Harness工程的搭建者和运行者，系统性地对业务Agent进行评测。

传统做法：人写评测代码 → 跑脚本 → 看结果 → 改代码 → 再跑。

Harness式做法：顶级Agent搭建完整的评测骨架（harness），包括评测方案、数据集、评测逻辑（以Agent提示词形式表达）、分析流程。人只需要提供被测对象和做关键决策。

能力	在Harness中的作用
深度理解prompt	分析被测Agent的逻辑，设计针对性评测维度
代码生成	数据获取/处理脚本，评测辅助工具
结构化输出	评测方案文档、评测Agent提示词、评测报告
多轮协作	跨版本持续迭代（v1→v2→v3），保持上下文连贯
数据分析	对跑批结果做统计、归因、对比

关键洞察在于：评测Harness的本质是一套结构化的评估规则 + 执行流程。传统做法把它编码为Python脚本，而我们现在把它编码为Agent提示词——更灵活、更可读、更易迭代。

二、Harness工程整体架构

2.1 三层架构

（原文此处内容需保留，但结构上已用H2和H3组织）

2.2 Harness搭建五步法

（原文此处内容需保留）

2.3 与传统评测工程的类比

传统评测工程	Harness式评测	变化
test_config.yaml	评测方案.md	规则从配置文件变为自然语言文档
test_data.json	评测集Excel（system.question）	数据格式统一，人可直接看懂
test_runner.py（数百行）	评测Agent提示词（数千字）	执行逻辑从代码变为Prompt
conftest.py + fixtures	GT标注 + ground_truth字段	预期结果内嵌在数据中
report_generator.py	CC实时分析	报告生成从脚本变为交互
requirements.txt + CI	评测平台一键跑批	零部署成本

2.4 职责分工

角色	职责	不做什么
人	GT标注、方案审核、最终决策	不写评测脚本、不手动计算指标
Claude Code	Harness全链路搭建 + 结果分析	不做批量推理主循环（交给平台）
评测平台	批量执行引擎（逐行调用）	不做方案设计和指标汇总

三、统一评测指标框架

在评测6个不同类型的Agent之后，我们沉淀了一套通用的三层指标框架。这大概是整个方案里最值得直接拿走的资产。

3.1 三层指标体系

指标	含义	为什么重要
输出格式合规率	JSON可成功解析的比例	下游消费方直接报错
字段完整率	必要字段均存在的比例	缺字段 = 功能不可用

能力类型	指标	适用场景
分类判断	分类准确率	枚举值选择（如类型判断）
二元决策	召回率 / 精确率	过滤 / 准入决策
数值提取	精确匹配率	离散数值的精确提取
连续评分	MAE + 分档一致率	内容质量打分
文本生成	LLM-as-Judge 1-5分	文案、描述等开放式输出

每个Agent可在L1+L2基础上追加专有指标。比如文案生成Agent可以加“违禁词清洁率”“关键信息保留率”；风格匹配Agent可以加“不适用风格过滤合规率”。

3.2 新Agent接入时的指标选型流程

流程其实很简单：先确定Agent涉及的能力类型，然后从L2菜单勾选对应指标，再按需追加L3专属指标，最后设定每个指标的目标阈值。

四、Harness各层的搭建方法

4.1 规则层：评测方案设计（CC角色：方案架构师）

输入是被测Agent的Prompt文件加上业务上下文描述。CC输出的，是一份完整的评测方案文档——包括维度、指标、阈值、数据集要求、错误分类体系，以及边界用例建议。

实际效果如何？从一个Prompt文件到一份完整评测方案，大概10分钟交互就搞定了。

示例对话：

人：这是新的内容审核Agent的prompt，帮我设计评测方案
CC：[分析prompt] 我建议从以下维度评测：
1. 格式合规（JSON可解析 + 字段完整）
2. 过滤决策（召回率/精确率）
3. 评分准确性（MAE + 分档一致率）
需要覆盖的边界：少量输入/全过滤/极端分数...
目标阈值建议：过滤精确率≥90%，MAE≤3...
人：某个维度容易低估，阈值放宽到MAE≤5
CC：好的，已更新。[输出完整方案文档]

4.2 数据层：黄金评测集构建（CC角色：数据工程师）

CC在这里做的事不少：首先写脚本调用业务接口，批量拉取候选数据；然后格式化为评测所需的JSON结构；对于分类型指标，CC会先给建议标注，人工复核即可；最后生成评测平台可直接消费的Excel。

关键设计是system.question列。每行数据都有这一列，格式为JSON，包含被测Agent所需的全部输入字段和ground_truth——人工标注的黄金答案。评测Agent读取这一列就能获得输入和预期输出，完全不需要额外配置。

{
  "sample_id": 243,
  "title": "XX品牌零食合集...",
  "content": "最近发现了...",
  "items": [...],
  "ground_truth": {
    "should_filter": false,
    "total_score": 64,
    "dimension_a": 22,
    "dimension_b": 22,
    "dimension_c": 20
  }
}

4.3 执行逻辑层：评测Agent提示词（CC角色：Harness工程师）

这是整套方案最核心的创新：把传统的评测脚本替换为一份评测Agent提示词。逻辑从“代码”变成了“自然语言指令”，一个Agent来评测另一个Agent。

评测Agent的工作流程如下：读取system.question → 调用被测Agent获取实际输出 → 解析输出 → 硬规则自动检查 → LLM打分 → 输出结构化JSON。

提示词的结构模板大致是这样：

##角色定义
你是一个严谨的AI评测专家，负责对「XXX」Agent进行单条样本评测。

##工具声明
- {agentId}：调用被测Agent，传入XXX，返回原始输出

##约束
1. 必须先调用工具获取Agent输出，再评测
2. 最终只输出一个合法JSON
3. 数值统计必须精确计算，不可估算

##工作流程
1. 解析输入（提取post_id、输入数据、ground_truth）
2. 调用被测Agent
3. 解析输出为JSON
4. 硬规则自动检查（格式/字段/枚举/字数/...）
5. LLM-as-Judge打分（对比ground_truth或按评分标准）
6. 错误归因（FORMAT_ERROR / WRONG_CHOICE / ...）
7. 输出最终JSON

##输出Schema
{完整的JSON schema定义}

为什么要这样设计？好处是显然的：逻辑可读——评判逻辑以自然语言写在提示词里，不用读代码；快速迭代——发现逻辑有误，改一段文字就行，不用改代码重部署；统一执行——所有Agent的评测逻辑结构一致，只改内容不改框架；评测即文档——提示词本身就是评测标准的完整说明。

4.4 输出层：结果分析与报告（CC角色：数据分析师）

典型流程是：人告诉CC跑批完成了，结果在某个Excel里，CC读取后直接出报告——总量多少条，API成功多少条，格式合规率多少，哪些指标有问题，核心模式是什么，以及具体修复建议。

CC在分析中的增值体现在三方面：自动识别pattern——不只报数字，还会归因；跨批次对比——和上一版结果对比，明确哪些指标进步或退步；给出可操作建议——不只是“分数低”，而是告诉你应该怎么改。

五、关键实践经验

5.1 评测集设计原则

原则	说明	反例
小而精	20-55条足够，覆盖所有边界场景	200+条但都是简单case
分布均衡	正/负例比例合理，边界场景必须有	全是正例，评不出问题
GT可复核	每条GT标注有据可查	GT靠感觉打分
版本化管理	评测集跟随被测prompt版本变更	用v1评测集评v3 prompt

5.2 评测Agent提示词的迭代策略

需要明确的是，评测Agent本身也需要迭代——评测系统bug不等于被测Agent bug。

常见的评测系统bug包括：匹配逻辑过严（语义等价的判定被错判），硬编码规则误报（排除列表不全导致误判），Token截断（输出超长被截断），以及GT覆盖缺口（新增选项未在GT中体现）。

迭代节奏建议这样：v1先让基本逻辑跑通，用调试模式带推导过程；v2切换为跑批模式，纯JSON输出，修复首批发现的评测逻辑bug；v3+基于实际结果持续调优指标定义、匹配方式和容错逻辑。

5.3 LLM-as-Judge的使用心得

对文本生成类Agent——没法精确匹配GT的那种——我们用LLM做评委。具体做法是在评测Agent提示词中嵌入评分标准（1-5分rubric），评测Agent同时扮演“执行者”和“评委”。

有效的rubric示例：

5分：改写自然，传达原文单一核心意图，一次读完即懂
4分：基本达标，有轻微瑕疵但整体可读
3分：勉强可接受，但存在轻度问题
2分：明显问题：信息压缩过度或照抄原文
1分：严重错误：与输入无关或完全无法理解

需要注意：每个分值必须有具体、可区分的判定标准，避免用“好/较好/一般”这类主观描述，分值之间的差异应该一个正常人也能判断。

5.4 "评测Agent调被测Agent"的技巧

整个调用链路是这样的：评测平台调用评测Agent → 评测Agent通过工具调用被测Agent → 获取原始输出 → 进行多维度评分 → 返回结构化评测JSON。

实际踩过的坑包括：评测Agent忘记调用工具，在Constraints中强调“必须先调用工具”即可；工具参数传递失败，需要在提示词中显式写明参数构造逻辑；评测Agent重试耗尽token，添加“禁止重试”约束；输出截断，减少推导过程，只输出最终JSON。

六、效率对比

6.1 时间投入

阶段	传统方式	CC协助	加速比
评测方案设计	1-2天	10-30分钟	~10x
评测集构建	2-3天	半天（含人工标注）	~5x
评测脚本/Agent开发	2-3天	1-2小时	~10x
跑批执行	同（平台执行）	同	1x
结果分析 + 报告	半天-1天	10-20分钟	~5x
单Agent全流程	~1.5周	~1-2天	~5x

6.2 质量保障

CC方案不仅更快，分析质量往往更高。覆盖性上，CC不会遗漏任何数据行——人工数50行Excel容易看漏；一致性上，同样的评测标准，CC不会因为疲劳而评分漂移；溯源性上，每条评测结果都可追溯到prompt中的具体逻辑；而且同一份评测Agent提示词加同一份评测集，结果完全可以复现。

七、适用场景与局限

7.1 适用场景

场景	适合度	原因
Prompt迭代验证	⭐⭐⭐⭐⭐	改prompt → 跑批 → 看报告，闭环最快
多Agent横向对比	⭐⭐⭐⭐⭐	统一指标框架 + 相同评测流程
新Agent上线前验收	⭐⭐⭐⭐	系统性覆盖，不依赖人工抽检
线上问题复盘	⭐⭐⭐	可快速构造问题用例验证

7.2 局限与建议

局限	建议
LLM-as-Judge本身有偏差	对关键决策用人工抽检兜底
评测集规模受限（人工GT）	小而精优于大而糙，20-55条覆盖边界即可
依赖评测平台稳定性	token截断、API超时需做容错
首次搭建有学习成本	第二个Agent起复用率很高

八、可复用资产

经过6个Agent的实战，已经沉淀了一套可复用的资产列表。这些算是整个方案里可以直接拿走用的部分：三层指标框架模板、评测方案文档模板、评测Agent提示词模板、评测集Excel格式、评测报告模板、错误分类体系，以及Agent平台调用经验。

九、快速上手指南

想复用这套方案的话，按这几个步骤来就好。

——准备好被测Agent的prompt文件，确认接口信息和调用方式，在Claude Code中打开项目目录。

——告诉CC被测Agent的prompt，CC会输出维度、指标、阈值、数据集要求和错误分类，你来审核和调整。

——告诉CC从接口拉取数据并格式化为评测集，CC输出候选数据Excel，你做GT标注（CC可以先给AI建议，你复核），最后CC打包为带system.question列的最终评测集。

——告诉CC基于评测方案写评测Agent提示词，CC输出完整System Prompt，上传到平台后用1-2条数据调试，根据调试结果让CC修改。

——上传评测集到平台等待跑批完成，下载结果Excel后告诉CC分析，CC输出完整评测报告和优化建议。

十、总结

10.1 核心理念

一句话总结：用一个强Agent搭建评测Harness工程，将评测逻辑从“代码”升级为“Prompt”，实现业务Agent的系统性快速评测。

范式转变很清晰：传统是人写评测代码跑脚本，人看结果改代码再跑，周级启动天级迭代；Harness式是CC搭建Harness，平台跑批，CC分析，CC调整Harness再跑，天级启动小时级迭代。

10.2 核心收益

收益	具体表现
从周到天	单Agent评测全流程从~1.5周压缩到1-2天
一人成军	一个人+Claude Code完成原来需要测试开发+数据标注+分析师的工作
可持续迭代	每次prompt变更后的验证成本极低
零部署	评测逻辑是Prompt而非代码，无需CI/CD
方法论沉淀	指标框架+Agent提示词模板+错误分类体系，可迁移复用到任何Agent

10.3 适用场景

任何有Agent/LLM应用、需要系统性评测能力的业务组，Prompt迭代频繁需要快速验证效果，或者多Agent协作系统需要分模块独立评测的场景，都值得一试。

10.4 开放讨论

问题	思考
评测Agent自身的准确性如何保证？	调试期用2-3条数据人工核对；正式跑前先小批次验证
能否替代人工测试？	不能完全替代，但可以覆盖80%+的重复劳动
与Evals框架（OpenAI）的关系？	理念类似，但Harness更轻量、更灵活、无需工程部署
能否跨团队复用？	可以——三层指标框架+评测Agent模板+工作流模板，换被测对象即可