本文介绍如何利用Claude Code搭建评测Harness对业务Agent进行系统性评测。传统评测方式存在启动成本高、人力密集、迭代慢等问题而Harness式评测通过将评测逻辑编码为Agent提示词实现了快速迭代和零部署。文章详细阐述了Harness的整体架构、搭建方法、指标框架以及实践经验并提供了快速上手指南。这套方法不仅适用于Prompt迭代频繁的场景还能大幅提升评测效率和质量是小白和程序员学习大模型评测的实用工具。用一个强 Agent 构建评测 Harness系统性评测一群业务 Agent一、背景与问题1 业务场景某业务系统的内容生成链路由多个子 Agent 协作完成每个 Agent 负责不同的任务图片理解、内容审核、文案生成、风格匹配等。这些 Agent 的 prompt 方案频繁迭代每次变更后需要快速验证效果。核心矛盾业务 Agent 迭代快天级但传统评测工程搭建慢周级。2 传统评测的痛点痛点表现启动成本高搭建评测工程、写脚本、部署服务还没开始评就花了一周人力密集标注数据集、写分析脚本、出报告每个环节都需人工介入迭代慢prompt 改了一行想看效果要等半天重新跑可复现性差评测逻辑散落在各种脚本和 Notebook 里指标不统一不同 Agent 各搞一套无法横向对比工程化沉重每换一个 Agent 就要新写一套评测代码3 我们的解法Harness 工程搭建式评测核心思路用一个顶级 AgentClaude Code作为 Harness 工程的搭建者和运行者系统性地对业务 Agent 进行评测。什么是 “Harness 工程搭建式”传统做法人写评测代码 → 跑脚本 → 看结果 → 改代码 → 再跑Harness 式做法顶级 Agent 搭建完整的评测骨架harness包括评测方案、数据集、评测逻辑以 Agent 提示词形式表达、分析流程。人只需提供被测对象和做关键决策。为什么 Claude Code 是合适的 Harness 搭建者能力在 Harness 中的作用深度理解 prompt分析被测 Agent 的逻辑设计针对性评测维度代码生成数据获取/处理脚本评测辅助工具结构化输出评测方案文档、评测 Agent 提示词、评测报告多轮协作跨版本持续迭代v1→v2→v3保持上下文连贯数据分析对跑批结果做统计、归因、对比关键洞察评测 Harness 的本质是一套结构化的评估规则 执行流程。传统做法把它编码为 Python 脚本而我们把它编码为 Agent 提示词——更灵活、更可读、更易迭代。二、Harness 工程整体架构1 三层架构2 Harness 搭建五步法3 与传统评测工程的类比传统评测工程Harness 式评测变化test_config.yaml评测方案 .md规则从配置文件变为自然语言文档test_data.json评测集 Excelsystem.question数据格式统一人可直接看懂test_runner.py数百行评测 Agent 提示词数千字执行逻辑从代码变为 Promptconftest.py fixturesGT 标注 ground_truth 字段预期结果内嵌在数据中report_generator.pyCC 实时分析报告生成从脚本变为交互requirements.txt CI评测平台一键跑批零部署成本4 职责分工角色职责不做什么人GT 标注、方案审核、最终决策不写评测脚本、不手动计算指标Claude CodeHarness 全链路搭建 结果分析不做批量推理主循环交给平台评测平台批量执行引擎逐行调用不做方案设计和指标汇总三、统一评测指标框架1 三层指标体系在评测 6 个不同类型的 Agent 后我们沉淀了一套通用的三层指标框架L1通用基础指标所有 Agent 必报指标含义为什么重要输出格式合规率JSON 可成功解析的比例下游消费方直接报错字段完整率必要字段均存在的比例缺字段 功能不可用L2按能力类型选用从菜单中按需勾选能力类型指标适用场景分类判断分类准确率枚举值选择如类型判断二元决策召回率 / 精确率过滤 / 准入决策数值提取精确匹配率离散数值的精确提取连续评分MAE 分档一致率内容质量打分文本生成LLM-as-Judge 1-5 分文案、描述等开放式输出L3Agent 专属指标按需自定义每个 Agent 可在 L1L2 基础上追加专有指标。例如●文案生成 Agent违禁词清洁率、关键信息保留率●风格匹配 Agent不适用风格过滤合规率2 新 Agent 接入时的指标选型流程确定 Agent 涉及的能力类型↓从 L2 菜单勾选对应指标↓按需追加 L3 专属指标↓设定每个指标的目标阈值四、Harness 各层的搭建方法1 规则层评测方案设计CC 角色方案架构师输入被测 Agent 的 prompt 文件 业务上下文描述CC 输出●完整的评测方案文档含维度、指标、阈值、数据集要求、错误分类体系●边界用例建议CC 分析 prompt 逻辑后主动提出应覆盖的场景实际效果从一个 prompt 文件到一份完整评测方案大约 10 分钟的交互。示例对话人这是新的内容审核 Agent 的 prompt帮我设计评测方案CC[分析 prompt] 我建议从以下维度评测1. 格式合规JSON可解析 字段完整2. 过滤决策召回率/精确率3. 评分准确性MAE 分档一致率需要覆盖的边界少量输入/全过滤/极端分数...目标阈值建议过滤精确率≥90%MAE≤3...人某个维度容易低估阈值放宽到 MAE≤5CC好的已更新。[输出完整方案文档]2 数据层黄金评测集构建CC 角色数据工程师CC 做的事数据获取编写脚本调用业务接口批量拉取候选数据数据处理格式化为评测所需的 JSON 结构GT 辅助标注对分类型指标CC 先给建议标注人工复核评测集打包生成评测平台可直接消费的 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 }}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_truth2.调用被测 Agent3.解析输出为 JSON4.硬规则自动检查格式/字段/枚举/字数/...5.LLM-as-Judge 打分对比 ground_truth 或按评分标准6.错误归因FORMAT_ERROR / WRONG_CHOICE / ...7.输出最终 JSON##输出 Schema{完整的 JSON schema 定义}为什么要这样设计优势说明逻辑可读评测逻辑以自然语言写在提示词里无需读代码快速迭代发现评测逻辑有误改一段文字就行不用改代码重部署统一执行所有 Agent 的评测逻辑结构一致只改内容不改框架评测即文档提示词本身就是评测标准的完整说明4 输出层结果分析与报告CC 角色数据分析师典型流程人跑批完了结果在 XXX.xlsx帮我出报告CC[读取 Excel]- 总量 50 条API 成功 46 条- 格式合规率 92%- 过滤 Recall 100% / Precision 18.2% ❌- 核心问题模型将评分维度误用为过滤条件- 建议修复 prompt 中过滤逻辑的边界定义[输出完整报告 Markdown]CC 在分析中的增值自动识别 pattern不只报数字还归因“18 条误过滤中12 条都是把某评分维度60 当过滤条件”跨批次对比和上一版结果对比明确哪些指标进步/退步给出可操作建议不只是分数低而是建议在 prompt 第三段加入明确的过滤条件边界五、关键实践经验1 评测集设计原则原则说明反例小而精20-55 条足够覆盖所有边界场景200 条但都是简单 case分布均衡正/负例比例合理边界场景必须有全是正例评不出问题GT 可复核每条 GT 标注有据可查GT 靠感觉打分版本化管理评测集跟随被测 prompt 版本变更用 v1 评测集评 v3 prompt2 评测 Agent 提示词的迭代策略我们发现评测 Agent 本身也需要迭代评测系统 bug ≠ 被测 Agent bug常见评测系统 bug问题表现修复方式匹配逻辑过严语义等价的判定原因被判错GT⊆AI 超集匹配硬编码规则误报排除列表不全导致误判改为动态语义比对Token 截断输出超长被评测平台截断正则容错提取关键字段GT 覆盖缺口新增选项未在 GT 中体现更新 GT 标注迭代节奏●v1基本逻辑跑通调试模式带推导过程●v2切换为跑批模式纯 JSON 输出修复首批发现的评测逻辑 bug●v3基于实际结果持续调优指标定义、匹配方式、容错逻辑3 LLM-as-Judge 的使用心得对文本生成类 Agent无法精确匹配 GT我们用 LLM 做评委做法在评测 Agent 提示词中嵌入评分标准1-5 分 rubric评测 Agent 同时扮演执行者和评委。有效的 rubric 设计5 分改写自然传达原文单一核心意图一次读完即懂4 分基本达标有轻微瑕疵但整体可读3 分勉强可接受但存在轻度问题2 分明显问题信息压缩过度或照抄原文1 分严重错误与输入无关或完全无法理解注意事项●每个分值必须有具体、可区分的判定标准●避免好/较好/一般这类主观描述●分值之间的差异应该一个正常人也能判断4 “评测 Agent 调被测 Agent” 的技巧评测平台→ 调用评测 Agent一个 LLM 实例→ 评测 Agent 通过工具调用被测 Agent另一个 LLM 实例→ 获得被测 Agent 的原始输出→ 评测 Agent 对输出进行多维度评分→ 返回结构化评测 JSON实际踩坑坑解法评测 Agent 忘记调用工具在 Constraints 中强调必须先调用工具工具参数传递失败在提示词中显式写明参数构造逻辑评测 Agent 重试耗尽 token添加禁止重试约束输出截断减少推导过程只输出最终 JSON六、效率对比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 天~5x2 质量保障CC 方案不仅更快分析质量往往更高●覆盖性CC 不会遗漏任何数据行人工数 50 行 Excel 容易看漏●一致性同样的评测标准CC 不会因为疲劳而评分漂移●溯源性每条评测结果都可追溯到 prompt 中的具体逻辑●可复现同一份评测 Agent 提示词 同一份评测集 结果可复现七、适用场景与局限1 适用场景场景适合度原因Prompt 迭代验证⭐⭐⭐⭐⭐改 prompt → 跑批 → 看报告闭环最快多 Agent 横向对比⭐⭐⭐⭐⭐统一指标框架 相同评测流程新 Agent 上线前验收⭐⭐⭐⭐系统性覆盖不依赖人工抽检线上问题复盘⭐⭐⭐可快速构造问题用例验证2 局限与建议局限建议LLM-as-Judge 本身有偏差对关键决策用人工抽检兜底评测集规模受限人工 GT小而精优于大而糙20-55 条覆盖边界即可依赖评测平台稳定性token 截断、API 超时需做容错首次搭建有学习成本第二个 Agent 起复用率很高八、可复用资产经过 6 个 Agent 的实战已沉淀的可复用资产资产说明复用方式三层指标框架模板L1/L2/L3新 Agent 对照选用评测方案文档模板目标维度数据集流程错误分类填空式生成评测 Agent 提示词模板角色工具约束工作流输出 schema替换业务逻辑即可| 评测集告诉 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 输出完整评测报告 优化建议。十、总结1 核心理念一句话用一个强 AgentClaude Code搭建评测 Harness 工程将评测逻辑从代码升级为Prompt实现业务 Agent 的系统性快速评测。范式转变传统人写评测代码 → 跑脚本 → 人看结果 → 人改代码 → 再跑周级启动天级迭代Harness式CC搭建Harness → 平台跑批 → CC分析 → CC调整Harness → 再跑天级启动小时级迭代2 核心收益收益具体表现从周到天单 Agent 评测全流程从 ~1.5 周压缩到 1-2 天一人成军一个人 Claude Code 完成原来需要测试开发 数据标注 分析师的工作可持续迭代每次 prompt 变更后的验证成本极低改提示词 → 重跑 → 看报告零部署评测逻辑是 Prompt 而非代码无需 CI/CD改完即生效方法论沉淀指标框架 Agent 提示词模板 错误分类体系可迁移复用到任何 Agent3 适用场景●任何有 Agent/LLM 应用、需要系统性评测能力的业务组●Prompt 迭代频繁天级/周级需要快速验证效果●多 Agent 协作系统需要分模块独立评测4 开放讨论问题思考评测 Agent 自身的准确性如何保证调试期用 2-3 条数据人工核对正式跑前先小批次验证能否替代人工测试不能完全替代但可以覆盖 80% 的重复劳动与 Evals 框架OpenAI的关系理念类似但我们的 Harness 更轻量、更灵活、无需工程部署能否跨团队复用可以——三层指标框架 评测 Agent 模板 工作流模板换被测对象即可最后如果说程序员已经是高薪职业那么干AI的程序员就是高薪中的高薪。现在的市场已经用数据给程序员指明了方向学AI大模型就是冲刺高薪的最优解看着身边越来越多的同行转型大模型、拿到高薪offer很多人心里都动了心但真正的难题来了零基础小白不知道从哪入门有基础的程序员找不到系统学习路径实战项目练手无门面试不知道考什么别慌今天就给大家整理了一份【2026年最新版】AI大模型免费学习资源包覆盖从入门到实战、从理论到面试、从基础到进阶的全流程所有资料均已整理归档无冗余、无套路免费分享给每一位想抓住AI风口的程序员和小白扫码免费领取全部内容1、大模型系统化学习路线2、大模型学习书籍文档3、AI大模型最新行业报告4、大模型项目实战配套源码5、大模型大厂面试真题四阶段精细化学习规划附时间节点可直接照做结合上述资源给大家整理了一份可直接落地的四阶段学习规划总时长约2个月小白可循序渐进程序员可根据自身基础调整节奏高效掌握大模型核心能力快速实现从“入门”到“能落地、能面试”的跨越。第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容6、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】