外观
Harness 工程搭建式业务 Agent 评测（模式）
摘要：用一个顶级 Agent（如 Claude Code）搭建评测 Harness 工程，系统性地评测一群业务 Agent。核心创新：把传统评测逻辑从"Python 脚本"升级为"Agent 提示词"——更灵活、更可读、更易迭代。单 Agent 评测全流程从约 1.5 周压缩到 1-2 天（stated）。
定义
Harness 工程搭建式评测 = 用强 Agent 作为评测工程的"搭建者和运行者"，把评测方案、数据集、评测逻辑（以提示词形式表达）、分析流程全部自动化，人只提供被测对象和做关键决策。
范式转变（stated）：
- 传统：人写评测代码 → 跑脚本 → 人看结果 → 人改代码 → 再跑（周级启动，天级迭代）
- Harness 式：CC 搭建 Harness → 平台跑批 → CC 分析 → CC 调整 Harness → 再跑（天级启动，小时级迭代）
关键洞察：评测 Harness 的本质是一套"结构化的评估规则 + 执行流程"。传统做法把它编码为代码，此模式把它编码为 Agent 提示词（stated）。
适用场景
| 场景 | 适合度 |
|---|---|
| Prompt 迭代验证（改 prompt → 跑批 → 看报告） | ⭐⭐⭐⭐⭐ |
| 多 Agent 横向对比（统一指标框架） | ⭐⭐⭐⭐⭐ |
| 新 Agent 上线前验收 | ⭐⭐⭐⭐ |
| 线上问题复盘 | ⭐⭐⭐ |
核心前提：业务 Agent **迭代快（天级）**而传统评测搭建慢（周级）—— 评测速度跟不上迭代速度的矛盾（stated）。
角色分工
| 角色 | 职责 | 不做什么 |
|---|---|---|
| 人 | GT 标注、方案审核、最终决策 | 不写评测脚本、不手动算指标 |
| Claude Code | Harness 全链路搭建 + 结果分析 | 不做批量推理主循环 |
| 评测平台 | 批量执行引擎（逐行调用） | 不做方案设计和指标汇总 |
统一评测指标框架（三层）
L1 通用基础指标（所有 Agent 必报）：
- 输出格式合规率（JSON 可解析比例）
- 字段完整率（必要字段存在比例）
L2 按能力类型选用（菜单勾选）：
| 能力类型 | 指标 | 适用场景 |
|---|---|---|
| 分类判断 | 分类准确率 | 枚举值选择 |
| 二元决策 | 召回率 / 精确率 | 过滤/准入决策 |
| 数值提取 | 精确匹配率 | 离散数值提取 |
| 连续评分 | MAE + 分档一致率 | 内容质量打分 |
| 文本生成 | LLM-as-Judge 1-5 分 | 开放式输出 |
L3 Agent 专属指标（按需自定义）：如文案生成 Agent 的违禁词清洁率、风格匹配的过滤合规率。
五步搭建流程
- 规则层：评测方案设计（CC 角色：方案架构师）—— 输入被测 Agent prompt，输出完整评测方案（维度/指标/阈值/数据集要求/错误分类体系），约 10 分钟
- 数据层：黄金评测集构建（数据工程师）—— 拉数据 → 格式化 → GT 辅助标注 → 打包 Excel（核心设计：
system.question列含全部输入字段 + ground_truth） - 执行逻辑层：评测 Agent 提示词（Harness 工程师）—— 整套方案的核心创新：评测逻辑从代码变为自然语言指令，"一个 Agent 评测另一个 Agent"
- 输出层：结果分析与报告（数据分析师）—— 自动识别 pattern、跨批次对比、给可操作建议
- 迭代：v1 调试模式 → v2 跑批模式 → v3+ 持续调优
评测 Agent 提示词模板结构
# 角色定义（严谨的 AI 评测专家）
# 工具声明（{agentId}：调用被测 Agent）
# 约束（必须先调用工具；只输出合法 JSON；数值精确计算）
# 工作流程（解析输入 → 调用被测 Agent → 硬规则检查 → LLM 打分 → 错误归因 → 输出 JSON）
# 输出 Schema（完整 JSON schema）优势：逻辑可读（自然语言）、快速迭代（改文字即可）、统一执行（结构一致只改内容）、评测即文档（提示词本身就是评测标准说明）（stated）。
关键实践
评测集设计原则
- 小而精：20-55 条足够，覆盖所有边界场景（反例：200+ 条但都是简单 case）
- 分布均衡：正/负例比例合理，边界场景必须有
- GT 可复核：每条标注有据可查
- 版本化管理：评测集跟随被测 prompt 版本变更
LLM-as-Judge 心得
- 在评测 Agent 提示词中嵌入评分标准 rubric（1-5 分）
- 有效 rubric 设计：每个分值有具体可区分的判定标准，避免"好/较好/一般"主观描述，分值差异应正常人也能判断（high）
"评测 Agent 调被测 Agent"的坑与解法
| 坑 | 解法 |
|---|---|
| 评测 Agent 忘记调用工具 | Constraints 强调"必须先调用工具" |
| 工具参数传递失败 | 提示词显式写明参数构造逻辑 |
| 重试耗尽 token | 添加"禁止重试"约束 |
| 输出截断 | 减少推导过程，只输出最终 JSON |
评测 Agent 自身也需要迭代
常见评测系统 bug（≠ 被测 Agent bug）：匹配逻辑过严（改 GT⊆AI 超集匹配）、硬编码规则误报（改动态语义比对）、Token 截断（正则容错提取）、GT 覆盖缺口（更新标注）。
效率与质量收益
时间加速：方案设计 ~10x、评测集构建 ~5x、脚本/Agent 开发 ~10x、结果分析 ~5x，单 Agent 全流程 ~5x（1.5 周 → 1-2 天）（stated）。
质量保障：覆盖性（不遗漏数据行）、一致性（无疲劳漂移）、溯源性（结果可追溯到 prompt 逻辑）、可复现（同一提示词+同一评测集 = 同一结果）。
局限与建议
- LLM-as-Judge 本身有偏差 → 关键决策人工抽检兜底
- 评测集规模受限（人工 GT）→ 小而精优于大而糙
- 依赖评测平台稳定性 → token 截断、API 超时需容错
- 首次搭建有学习成本 → 第二个 Agent 起复用率高
可复用资产
三层指标框架模板、评测方案文档模板、评测 Agent 提示词模板、评测集 Excel 格式（system.question 规范）、评测报告模板、错误分类体系、Agent 平台调用经验。
关联词条
- Harness（智能体执行框架）（concept）
- Harness 专题总览（overview）
- DeepSeek Harness 与 Pi 的架构拆解对比（comparison）