企业Agent评测：脚本式与Harness式方案对比

agent-">一、对比背景：评测工程为何成为Agent研发的瓶颈

在企业级内容生成等场景中，业务链路往往不是单次模型调用，而是由多个子Agent协同的分布式架构（常见如Master-Slave结构）完成：图片分类、内容审核、文案生成、风格匹配、质量评分等原子能力分别由不同子Agent承担。业务需求演进时，各子Agent的Prompt方案与架构规格频繁变更，每次变更后都需要快速、量化地验证生产环境效果。

这里存在一个核心矛盾：业务Agent的迭代速度是天级的，而传统评测工程的搭建与联调往往是周级的。评测一旦跟不上，团队要么“凭感觉”上线（即行业俗称的Vibe Coding），要么被沉重的评测工程拖住节奏。围绕“评测到底该怎么做”，实践中形成了两类代表性方案，也是本文的对比对象：

• 方案A：传统脚本式评测——以人工编写评测代码为中心的工程化路线；
• 方案B：Harness（驾驭层）式评测——以自然语言化评测方案为中心、由通用编码Agent生成并驾驭评测骨架的路线。

需要说明的是，这里的Harness指“Agent = Model + Harness”体系中的驾驭层概念，即围绕模型组织的工具、上下文、流程与规则的工程封装，属于通用架构模式，并非特指某一厂商产品。

二、对象定义：两类方案分别是什么

2.1 传统脚本式评测

典型工作流是“人写评测代码 → 跑脚本 → 看结果 → 改代码 → 再跑”。团队需要手工抽取与标注数据集、为每类指标手写计算脚本、为每个子Agent配置独立测试桩，再把整套流程接入CI/CD。它的本质是把评测当作一个独立的软件工程项目来做，评测逻辑以硬编码脚本形态存在。

2.2 Harness式评测

将“Agent = Model + Harness”的视角迁移到评测领域：评测系统同样可以拆为“评测能力 + 评测Harness”。评测方案、数据集、打分规则、报告模板以自然语言化、结构化文件的形式沉淀为一套可版本管理的“骨架”，再由具备代码工程能力的通用编码Agent按方案生成执行脚本、指标计算器与报告工具。评测逻辑从“硬编码脚本”升格为“可编程、自然语言化、由Agent生成与维护的提示词与规则文件”，人的职责前移到定义方案与评审结果。

三、相同点分析

两类方案在目标与基本要素上高度一致，这也是它们可以互相替换、组合的前提：

1. 目标一致：都是为了量化验证Agent效果、支撑迭代决策，回答“这次变更到底是变好还是变坏”。
2. 要素一致：都需要数据集、指标定义、执行流程、结果报告四个基本要素，无论以代码还是以规则文件承载。
3. 都可接入回归体系：都能纳入CI/CD，在Prompt或架构变更时自动触发回归评测。
4. 都是旁路系统：两者都不改变被测Agent本身，评测逻辑与业务逻辑解耦。
5. 都依赖标准对齐：无论打分逻辑写在代码里还是提示词里，评分口径最终都要与业务评审标准对齐，否则量化结果没有业务意义。

四、核心差异分析

4.1 技术架构：以代码为中心 vs 以方案为中心

传统脚本式评测中，逻辑分散在各类脚本文件与交互式分析环境中，代码即唯一事实源，指标定义、数据清洗、打分、报告耦合在一起，系统边界模糊。Harness式评测则以评测方案与规则文件为唯一事实源，代码降级为“生成物”：方案改了就由Agent重新生成脚本；脚本腐化了也能从方案随时重建，形成“方案层（人负责）—骨架层（Agent生成）—执行层（流水线自动跑）”的清晰分层。

4.2 接入与构建方式：周级搭建 vs 小时级起骨架

传统方式启动成本高：必须拉起评测工程、手写测试脚本、配置CI/CD与环境，常常“还没开始评测，一周时间已经过去”。Harness式由编码Agent根据自然语言方案快速搭起结构化骨架，人工只需评审修正，启动成本可压缩到小时至天级。

4.3 迭代速度与反馈链路

传统方式下，业务Prompt哪怕只改一个词也要重跑沉重的测试流水线，反馈以半天或天为单位；指标口径变化还要改代码、再发版。Harness式调整的往往只是评测提示词或规则文件，改完即生效，反馈可缩短到分钟至小时级，与业务侧的天级迭代相匹配。

4.4 可复现性与指标体系

传统方式打分标准零散分布，代码版本一乱结果就无法对齐；且各子Agent各搞一套标准，指标孤岛化，缺乏统一的“度量衡”。Harness式将方案、规则、数据集统一入库与版本化，天然形成一致度量衡，支持跨子Agent的全局横向对比与归因。

4.5 成本结构与人力模型

传统方式人力密集，严重依赖测试开发与数据分析角色，难以规模化，长期陷入“写代码维护测试代码”的泥潭，每换一个Agent就要重写一套测试桩。Harness式把人力重心从编码前移到方案设计与评审，执行交给Agent与流水线，边际成本低，属于“前置设计成本换长期维护成本”的结构。

4.6 安全、合规与审计

传统方式下评测数据散落在个人环境中，权限与脱敏难以统一管控；但确定性指标由代码断言，结果稳定、可审计性强。Harness式数据集与规则集中托管，便于统一权限、脱敏与审计；但引入“模型评判模型”环节后，需要额外做评分一致性校准。落地时可借助百度智能云等云平台的大模型服务、对象存储、监控告警等通用产品能力，把数据托管、模型调用与评测监控纳入统一底座，降低自建成本。

五、对比表格总结

对比维度	传统脚本式评测	Harness 驾驭层式评测
事实源	评测代码本身	自然语言方案 + 结构化规则文件
启动成本	搭工程、写脚本、配流水线，周级	Agent生成骨架、人工评审，小时～天级
迭代反馈	改一词也要重跑流水线，半天～天级	改评测提示词即生效，分钟～小时级
可复现性	逻辑散落，版本一乱即失配	方案/规则/数据集统一版本化，可对齐
指标体系	各子Agent各自为政，指标孤岛	统一度量衡，支持全局横向对比
人力模型	依赖测试开发与分析师，难规模化	重心在方案设计与评审，执行自动化
扩展方式	新Agent常需重写测试桩	复用骨架，追加规则与数据集
确定性	代码断言，稳定可审计	主观维度靠模型评判，需一致性校准
适用边界	客观指标为主、低频变更	主观维度多、高频迭代、多Agent协同

六、示意：Harness式评测骨架的典型结构

eval-harness/
├── eval-plan.md              # 自然语言评测方案：目标、指标定义、评分口径
├── datasets/                 # 数据集（带版本与来源标注）
│   ├── image_classification.jsonl
│   └── copywriting.jsonl
├── rubrics/                  # 各子Agent的结构化打分规则
│   ├── image_classifier.yaml
│   └── copywriter.yaml
├── runners/                  # 由编码Agent生成的执行器（可随时重建）
└── reports/                  # 归因报告与历史结果归档

# rubrics/copywriter.yaml（通用示意格式）
agent: copywriter
metrics:
  - name: 风格匹配度
    type: llm_judge          # 主观维度：评测模型按提示词打分
    scale: 1-5
    prompt_ref: rubrics/style_judge.md
  - name: 违禁词命中
    type: rule_assert        # 确定性维度：直接断言守住底线
    assert: "not_contains ['示例违禁词A', '示例违禁词B']"
pass_threshold: 4.0          # 质量门禁：低于阈值阻断发布

构建流程示意：人工输入评测方案与抽样数据 → 编码Agent生成骨架 → 人工评审指标口径与阈值 → 方案/规则/数据集版本化入库 → Prompt变更触发回归并输出归因报告。

七、典型场景选择

• 多子Agent协同、Prompt高频迭代的内容生成业务：主观质量维度多、变更频繁，Harness式收益最大。
• 以准确率、召回等客观统计指标为主的模型能力验证：变更频率低、口径稳定，传统脚本式足够且更可控。
• 强合规、强审计的上线门禁：建议混合形态——确定性断言守住底线，提示词评分覆盖体验维度。
• 缺乏专职测试开发的团队：Harness式可显著降低对编码人力的依赖。
• 早期探索性实验：先用Harness式快速起骨架验证方向，方案成熟后再固化指标与门禁。

八、选型建议

选型判断应基于条件而非绝对优劣：若指标以确定性统计为主、团队测试开发能力成熟、变更频率低，传统脚本式更稳；若业务以主观维度为主、多Agent协同且高频迭代，Harness式在速度与统一度量衡上优势明显。更常见且推荐的是混合策略：确定性指标用规则断言，主观维度用评测提示词，两者沉淀在同一套骨架与指标字典中。无论选择哪种形态，都建议先统一指标字典与数据集治理，再决定工具与工程形态。

九、迁移与使用注意事项

1. 存量盘点：将现有脚本中的指标逐一映射到统一指标字典，明确哪些保留为确定性断言、哪些转为提示词评判。
2. 数据集治理：抽样式构建并覆盖边界样例；涉及业务数据需脱敏并统一权限管理。
3. 评分一致性校准：模型评判结果需与人工标注做一致率对齐并定期回归，防止“评测漂移”。
4. 版本对齐：评测方案、规则、数据集的版本必须与被测Prompt版本对齐，否则结果不可比。
5. 质量门禁：对Agent生成的评测脚本设置评审与回归门槛，避免未经评审的生成物进入生产评测链路。
6. 成本控制：评估评测调用量与并发，必要时使用缓存与抽样，避免评测成本反噬业务。
7. 警惕两个极端：既不要回到“每个Agent重写一套测试桩”的泥潭，也不要把Harness理解为“不要工程”——工程并未消失，而是被固化到了方案与骨架之中。

十、总结

两类方案的分野，本质是“以代码为中心”与“以方案为中心”的架构选择差异。传统脚本式胜在确定性与可控性，代价是周级搭建成本与孤岛化指标；Harness式通过“Agent = Model + Harness”的思路，把评测逻辑升格为可编程、自然语言化、由通用编码Agent生成与维护的规则体系，将启动成本从周级压缩到小时级，并以统一度量衡支撑多子Agent的全局对比。对企业而言，多数多Agent、高频迭代场景更适合Harness式或其与传统方式的混合形态，而确定性要求高的指标仍应保留代码级断言。选型的关键不在于哪种方案“更先进”，而在于哪一种与团队的迭代速度、人力结构和合规要求相匹配。