我要投稿

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

发布日期：2026-06-05 08:37:02 浏览次数： 1573

作者：阿里云开发者

微信搜一搜，关注“阿里云开发者”

阿里妹导读

用一个强 Agent 构建评测 Harness，系统性评测一群业务 Agent（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）

一、背景与问题

1.1 业务场景

某业务系统的内容生成链路由多个子 Agent 协作完成，每个 Agent 负责不同的任务（图片理解、内容审核、文案生成、风格匹配等）。这些 Agent 的 prompt 方案频繁迭代，每次变更后需要快速验证效果。

核心矛盾：业务 Agent 迭代快（天级），但传统评测工程搭建慢（周级）。

1.2 传统评测的痛点

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

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

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

什么是 "Harness 工程搭建式"？

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

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

为什么 Claude Code 是合适的 Harness 搭建者？

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

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

二、Harness 工程整体架构

2.1 三层架构

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 全链路搭建 + 结果分析	不做批量推理主循环（交给平台）
评测平台	批量执行引擎（逐行调用）	不做方案设计和指标汇总

三、统一评测指标框架

3.1 三层指标体系

在评测 6 个不同类型的 Agent 后，我们沉淀了一套通用的三层指标框架：

L1：通用基础指标（所有 Agent 必报）

指标

含义

为什么重要

输出格式合规率

JSON 可成功解析的比例

下游消费方直接报错

字段完整率

必要字段均存在的比例

缺字段 = 功能不可用

L2：按能力类型选用（从菜单中按需勾选）

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

L3：Agent 专属指标（按需自定义）

每个 Agent 可在 L1+L2 基础上追加专有指标。例如：

●文案生成 Agent：违禁词清洁率、关键信息保留率

●风格匹配 Agent：不适用风格过滤合规率

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

确定 Agent 涉及的能力类型↓从 L2 菜单勾选对应指标↓按需追加 L3 专属指标↓设定每个指标的目标阈值

四、Harness 各层的搭建方法

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

输入：被测 Agent 的 prompt 文件 + 业务上下文描述

CC 输出：

●完整的评测方案文档（含维度、指标、阈值、数据集要求、错误分类体系）

●边界用例建议（CC 分析 prompt 逻辑后主动提出应覆盖的场景）

实际效果：从一个 prompt 文件到一份完整评测方案，大约 10 分钟的交互。

示例对话：

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

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

CC 做的事：

1.数据获取：编写脚本调用业务接口，批量拉取候选数据

2.数据处理：格式化为评测所需的 JSON 结构

3.GT 辅助标注：对分类型指标，CC 先给建议标注，人工复核

4.评测集打包：生成评测平台可直接消费的 Excel（含 system.question 列）

关键设计：system.question 列

每行数据都有一个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 工程师）

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

评测 Agent 的工作流程：

读取 system.question（一行数据）       ↓调用被测 Agent（获取实际输出）       ↓解析输出 → 硬规则自动检查 → LLM 打分       ↓输出结构化 JSON（所有指标的计算结果）

评测 Agent 提示词的结构模板：

##角色定义你是一个严谨的 AI 评测专家，负责对「XXX」Agent 进行单条样本评测。##工具声明-{agentId}：调用被测 Agent，传入 XXX，返回原始输出##约束1.必须先调用工具获取 Agent 输出，再评测2.最终只输出一个合法 JSON3.数值统计必须精确计算，不可估算##工作流程1.解析输入（提取 post_id、输入数据、ground_truth）2.调用被测 Agent3.解析输出为 JSON4.硬规则自动检查（格式/字段/枚举/字数/...）5.LLM-as-Judge 打分（对比 ground_truth 或按评分标准）6.错误归因（FORMAT_ERROR / WRONG_CHOICE / ...）7.输出最终 JSON##输出 Schema{完整的 JSON schema 定义}

为什么要这样设计？

优势	说明
逻辑可读	评测逻辑以自然语言写在提示词里，无需读代码
快速迭代	发现评测逻辑有误，改一段文字就行，不用改代码重部署
统一执行	所有 Agent 的评测逻辑结构一致，只改内容不改框架
评测即文档	提示词本身就是评测标准的完整说明

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

典型流程：

人：跑批完了，结果在 XXX.xlsx，帮我出报告CC：[读取 Excel]- 总量 50 条，API 成功 46 条- 格式合规率 92%- 过滤 Recall 100% / Precision 18.2% ❌- 核心问题：模型将评分维度误用为过滤条件- 建议：修复 prompt 中过滤逻辑的边界定义[输出完整报告 Markdown]

CC 在分析中的增值：

1.自动识别 pattern：不只报数字，还归因（"18 条误过滤中，12 条都是把某评分维度

2.跨批次对比：和上一版结果对比，明确哪些指标进步/退步

3.给出可操作建议：不只是"分数低"，而是"建议在 prompt 第三段加入明确的过滤条件边界"

五、关键实践经验

5.1 评测集设计原则

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

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

我们发现评测 Agent 本身也需要迭代（评测系统 bug ≠ 被测 Agent bug）：

常见评测系统 bug：

问题	表现	修复方式
匹配逻辑过严	语义等价的判定原因被判错	GT⊆AI 超集匹配
硬编码规则误报	排除列表不全导致误判	改为动态语义比对
Token 截断	输出超长被评测平台截断	正则容错提取关键字段
GT 覆盖缺口	新增选项未在 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（一个 LLM 实例）→ 评测 Agent 通过工具调用被测 Agent（另一个 LLM 实例）→ 获得被测 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 的实战，已沉淀的可复用资产：

资产	说明	复用方式
三层指标框架模板	L1/L2/L3	新 Agent 对照选用
评测方案文档模板	目标+维度+数据集+流程+错误分类	填空式生成
评测 Agent 提示词模板	角色+工具+约束+工作流+输出 schema	替换业务逻辑即可
评测集 Excel 格式	system.question 列规范	标准化接入评测平台
评测报告模板	执行情况+指标汇总+问题分析+建议	CC 自动填充
错误分类体系	FORMAT_ERROR/WRONG_CHOICE/...	按需扩展
Agent 平台调用经验	接口格式/参数/踩坑记录	减少试错

九、快速上手指南

想要复用这套方案的同学，按以下步骤操作：

Step 1：准备工作（5 分钟）

●准备好被测 Agent 的 prompt 文件

●确认被测 Agent 的接口信息和调用方式

●在 Claude Code 中打开项目目录

Step 2：设计评测方案（10-30 分钟）

告诉 CC：这是被测 Agent 的 prompt [粘贴/路径]，帮我设计评测方案。CC 会输出：维度、指标、阈值、数据集要求、错误分类。你来审核和调整。

Step 3：构建评测集（半天，含人工标注）

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

Step 4：编写评测 Agent 提示词（1-2 小时）

告诉 CC：基于评测方案，帮我写评测 Agent 的提示词。CC 输出：完整的评测 Agent System Prompt。上传到评测平台，用 1-2 条数据调试。根据调试结果让 CC 修改（通常需要 2-3 轮）。

Step 5：跑批 + 出报告（30 分钟）

上传评测集到平台 → 等待跑批完成。下载结果 Excel → 告诉 CC：帮我分析这份结果。CC 输出：完整评测报告 + 优化建议。

十、总结

10.1 核心理念

一句话：用一个强 Agent（Claude Code）搭建评测 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 模板 + 工作流模板，换被测对象即可

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业