一、背景与问题

1.1 业务场景

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

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

1.2 传统评测的痛点

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

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

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

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

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

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

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

二、Harness 工程整体架构

2.1 三层架构

2.2 Harness 搭建五步法

2.3 与传统评测工程的类比

2.4 职责分工

三、统一评测指标框架

3.1 三层指标体系

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

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

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

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≤5
CC：好的，已更新。[输出完整方案文档]

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.最终只输出一个合法 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 定义}

为什么要这样设计？

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

典型流程：

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

CC 在分析中的增值：

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

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

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

五、关键实践经验

5.1 评测集设计原则

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

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

常见评测系统 bug：

迭代节奏：

●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

实际踩坑：

六、效率对比

6.1 时间投入

6.2 质量保障

CC 方案不仅更快，分析质量往往更高：

●覆盖性：CC 不会遗漏任何数据行（人工数 50 行 Excel 容易看漏）

●一致性：同样的评测标准，CC 不会因为疲劳而评分漂移

●溯源性：每条评测结果都可追溯到 prompt 中的具体逻辑

●可复现：同一份评测 Agent 提示词 + 同一份评测集 = 结果可复现

七、适用场景与局限

7.1 适用场景

7.2 局限与建议

八、可复用资产

经过 6 个 Agent 的实战，已沉淀的可复用资产：

九、快速上手指南

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

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

●准备好被测 Agent 的 prompt 文件

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

●在 Claude Code 中打开项目目录

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

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

10.3 适用场景

●任何有 Agent/LLM 应用、需要系统性评测能力的业务组

●Prompt 迭代频繁（天级/周级），需要快速验证效果

●多 Agent 协作系统，需要分模块独立评测

10.4 开放讨论

十一、最后

感谢对营销消费清单 AI 项目评测专项给予大力支持和鼓励的各位老师：

团队战友：岑坚、茉书、沈芃、飘飘、鲜佳伟等同学

协作兄弟：危素、朱八、墨謧、临汀、图兔、书屹、深空等同学

来源  |  阿里云开发者公众号

作者  |  飞樰