告别主观评价：用可量化考试体系驱动Harness工作流持续进化

当团队花费数周精心调教的Harness工作流上线后，你如何判断它是否真的在进步？大多数团队的答案是：「感觉这版稳了不少」「昨天那版好像更聪明」「我这边挺好用，你那边咋不行」。这种主观评价驱动的模式，恰恰是Harness工作流面临的最大隐患——改了一版Rule或Skill，到底是进步还是退步？答案无从得知。

概述

Harness工作流本质上是一种「规则驱动的概率程序」，与传统软件的确定性输出截然不同。同样的输入今天跑出A结果，明天可能跑出B结果。更棘手的是，你甚至无法简单判定A比B好还是B比A好，因为「好」本身就缺乏统一定义。这种系统如果没有评测体系兜底，面对的不是「缓慢退化」，而是薛定谔式的退化——你永远不知道它什么时候变差了。

从「测试」到「考试」的思维跃迁

传统软件工程的单元测试、集成测试逻辑移植到Harness上是远远不够的。传统测试验证的是「对不对」——二值判定；而Harness工作流需要的是「好不好」——多维度打分与证据支撑。一个工作流完成任务的方式可以有无数种，有些优雅有些笨拙，有些主动有些被动，有些严谨有些草率。你不能简单地assert output == expected，你需要的是一场考试——出考卷、组织考试、培养阅卷官。

闭环评测系统的核心设计

整套系统围绕三个不可妥协的原则展开：可重复优于精确——一道题跑多次，结果的分布比单次分数更有价值，追求的是统计显著的趋势而非单次满分；可归因优于高分——失败时系统必须能告诉你为什么失败，是工作流规则漏洞、题目歧义还是模型能力不足；闭环优于单向——评测终点不是出一份成绩单，而是驱动下一次改进。

系统设计包含三大核心环节：出题环节采用四文件结构（meta.yaml定义题目身份、task.md提供题面、rubric.md设定阅卷标准、env.yaml配置环境前提），让非技术人员5分钟即可新增一道题；答题环节引入Examiner角色模拟真实用户进行多轮交互，而非简单地把任务丢给Agent——因为Agent的真实能力不仅体现在最终结果，更体现在过程中的每一步决策；判卷环节由独立的Judge进程基于完整对话记录进行多维度评分，每个判定都必须附上证据引用，并强制输出分类改进建议。

如有侵权，请联系删除。