别再手写评测脚本了：用顶级 Agent 搭建评测 Harness，效率提升 10 倍

一、痛点直击：AI Agent 评测的”老大难”

做过 AI Agent 落地的团队，十有八九都踩过这个坑——业务 Agent 迭代飞快（天级），但评测工程搭建缓慢（周级）。

这不是个别现象，而是一个系统性的矛盾。来看看传统评测的”六宗罪”：

如果你正在被这些问题困扰，这篇文章将给你一个经过 6 个 Agent 实战验证的系统性解法——用一个顶级 Agent（Claude Code）搭建评测 Harness，将评测逻辑从”代码”升级为”Prompt”。

二、核心思路：用强 Agent 搭建评测骨架

什么是”Harness 工程搭建式”评测？

先厘清概念。传统做法是：人写评测代码 → 跑脚本 → 看结果 → 改代码 → 再跑。

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

graph LR
    subgraph 传统评测
        A1[人写评测代码] --> A2[跑脚本] --> A3[人看结果] --> A4[人改代码] --> A2
    end
    
    subgraph Harness式评测
        B1[CC搭建Harness] --> B2[平台跑批] --> B3[CC分析] --> B4[CC调整Harness] --> B2
    end

传统：周级启动，天级迭代；Harness 式：天级启动，小时级迭代。

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

Claude Code 在评测场景中展现出五项关键能力：

三、Harness 工程整体架构

3.1 三层架构总览

整套 Harness 采用清晰的三层架构设计：

graph TD
    subgraph "规则层（Rule Layer）"
        R1[评测方案文档]
        R2[评测维度定义]
        R3[指标阈值设定]
    end
    
    subgraph "数据层（Data Layer）"
        D1[黄金评测集 Excel]
        D2[system.question 列]
        D3[ground_truth 标注]
    end
    
    subgraph "执行层（Execution Layer）"
        E1[评测 Agent 提示词]
        E2[评测平台跑批]
        E3[结果分析报告]
    end
    
    R1 --> D1
    R2 --> D2
    R3 --> D3
    D1 --> E1
    D2 --> E2
    D3 --> E3

3.2 与传统评测工程的类比

3.3 职责分工

这套架构的核心在于清晰的职责分离：

四、统一评测指标框架——三层指标体系

在评测 6 个不同类型的 Agent 后，沉淀了一套通用的三层指标框架。这是我认为本文最有复用价值的部分。

mindmap
  root((三层指标体系))
    L1 通用基础指标
      输出格式合规率
      字段完整率
    L2 按能力类型选用
      分类准确率
      召回率/精确率
      精确匹配率
      MAE+分档一致率
      LLM-as-Judge 1-5分
    L3 Agent专属指标
      违禁词清洁率
      关键信息保留率
      风格过滤合规率

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

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

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

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

• 文案生成 Agent：违禁词清洁率、关键信息保留率
• 风格匹配 Agent：不适用风格过滤合规率

新 Agent 接入时的指标选型流程：确定 Agent 涉及的能力类型 → 从 L2 菜单勾选对应指标 → 按需追加 L3 专属指标 → 设定每个指标的目标阈值。

五、Harness 各层的搭建实战

5.1 规则层：评测方案设计

Claude Code 角色：方案架构师

输入是被测 Agent 的 Prompt 文件 + 业务上下文描述，CC 输出完整的评测方案文档（含维度、指标、阈值、数据集要求、错误分类体系）和边界用例建议。

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

5.2 数据层：黄金评测集构建

Claude Code 角色：数据工程师

CC 完成四件事：

1. 数据获取：编写脚本调用业务接口，批量拉取候选数据
2. 数据处理：格式化为评测所需的 JSON 结构
3. GT 辅助标注：对分类型指标，CC 先给建议标注，人工复核
4. 评测集打包：生成评测平台可直接消费的 Excel

其中关键设计是 system.question 列——每行数据包含被测 Agent 所需的全部输入字段和 ground_truth（人工标注的黄金答案），评测 Agent 读取这一列即可获得输入和预期输出，无需额外配置。

5.3 执行逻辑层：评测 Agent 提示词（最核心创新）

Claude Code 角色：Harness 工程师

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

sequenceDiagram
    participant 评测平台
    participant 评测Agent
    participant 被测Agent
    
    评测平台->>评测Agent: 调用（传入 system.question）
    评测Agent->>评测Agent: 解析输入数据 + ground_truth
    评测Agent->>被测Agent: 工具调用（获取实际输出）
    被测Agent-->>评测Agent: 返回原始输出
    评测Agent->>评测Agent: 硬规则自动检查（格式/字段/枚举...）
    评测Agent->>评测Agent: LLM-as-Judge 打分
    评测Agent->>评测Agent: 错误归因
    评测Agent-->>评测平台: 输出结构化 JSON（所有指标结果）

评测 Agent 提示词的结构模板包含：角色定义、工具声明、约束条件、工作流程、输出 Schema。

为什么把评测逻辑编码为 Prompt 而非代码？

5.4 输出层：结果分析与报告

Claude Code 角色：数据分析师

CC 在分析中的增值体现在三个方面：

1. 自动识别 pattern：不只报数字，还归因（”18 条误过滤中，12 条都是把某评分维度<60 当过滤条件”）
2. 跨批次对比：和上一版结果对比，明确哪些指标进步/退步
3. 给出可操作建议：不只是”分数低”，而是”建议在 prompt 第三段加入明确的过滤条件边界”

六、关键实践经验（踩坑总结）

6.1 评测集设计原则

6.2 LLM-as-Judge 的使用心得

对文本生成类 Agent（无法精确匹配 GT），用 LLM 做评委。核心是设计有效的 rubric：

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

三个注意事项：

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

6.3 “评测 Agent 调被测 Agent” 的踩坑记录

6.4 评测 Agent 自身的迭代策略

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

迭代节奏建议：v1 基本逻辑跑通 → v2 切换跑批模式修复评测逻辑 bug → v3+ 基于实际结果持续调优。

七、效率对比：实测数据说话

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

• 覆盖性：CC 不会遗漏任何数据行（人工数 50 行 Excel 容易看漏）
• 一致性：同样的评测标准，不会因为疲劳而评分漂移
• 溯源性：每条评测结果都可追溯到 Prompt 中的具体逻辑
• 可复现：同一份评测 Agent 提示词 + 同一份评测集 = 结果可复现

八、适用场景与局限

适用场景

局限与建议

九、总结与思考

这套方案的核心理念可以用一句话概括：用一个强 Agent 搭建评测 Harness 工程，将评测逻辑从”代码”升级为”Prompt”，实现业务 Agent 的系统性快速评测。

经过 6 个 Agent 的实战验证，沉淀下来的可复用资产包括：

• 三层指标框架模板（L1/L2/L3）——新 Agent 对照选用
• 评测方案文档模板——填空式生成
• 评测 Agent 提示词模板——替换业务逻辑即可
• 评测集 Excel 格式规范——标准化接入评测平台
• 错误分类体系——按需扩展

几点个人思考

作为长期关注 AI Agent 工程化落地的实践者，我认为这套方法论抓住了一个关键洞见：在 AI 时代，评测 AI 的最佳方式可能就是让另一个 AI 来做。这不是简单地”用 AI 替代人工测试”，而是通过结构化的 Harness 设计，让强 Agent 的推理能力和理解力为评测服务。

但也要注意几个边界：

1. LLM-as-Judge 不是万能的——对于高风险决策场景，人工抽检仍然是最后防线
2. 评测集的质量决定上限——再好的 Harness 也救不了糟糕的 GT 标注
3. 方法论沉淀比工具更重要——三层指标框架和评测 Agent 模板的可迁移性，才是这套方案最大的价值

本文内容参考自阿里云开发者公众号文章《基于顶级 Agent（Claude Code）的 Harness 工程搭建式业务 Agent 评测方案》，作者泊予。在此基础上结合了个人在 Agent 工程化领域的实践经验进行总结与点评。