简介：企业级 Agent 以天级节奏迭代，传统脚本式评测却常以周级节奏搭建，工程矛盾日益突出。本文系统对比传统脚本式评测与 Harness 工程搭建式评测两条路线，从架构载体、启动与迭代效率、可复现性、指标统一、成本结构与适用边界等维度拆解差异，并给出条件化选型建议与迁移注意事项，帮助读者快速判断哪条路线更适合自己。
在企业级内容生成、智能审核等业务中，一条完整链路往往由多个子 Agent 协同构成的分布式（或主从式）架构支撑：图片分类、内容审核、文案生成、风格匹配、质量评分等原子能力各司其职。随着业务演进，这些业务 Agent 的提示词方案与架构规格频繁迭代，每次变更之后，团队都需要快速、量化地验证变更在生产环境中的真实效果。
由此形成一个尖锐的工程矛盾：业务 Agent 的迭代节奏是“天级”的，而传统评测工程的搭建与联调往往是“周级”的。评测本应是迭代的加速器，却经常变成拖住研发效率的“重担”。
在传统模式下，这一矛盾具体表现为六大痛点：
| 痛点维度 | 传统评测表现 | 负面影响 |
|---|---|---|
| 启动成本高 | 必须拉起评测工程、手写测试脚本、配置流水线与环境 | 尚未开始评测，一周时间已经消耗 |
| 人力密集 | 手工抽取与标注数据集、手写指标计算脚本、人工提炼归因报告 | 严重依赖测试开发与分析师，难以规模化 |
| 迭代链路长 | 提示词哪怕只改一个词，也要重跑沉重的测试流水线 | 反馈周期以半天或天为单位 |
| 可复现性差 | 评测逻辑与打分标准零散分布在各类脚本与交互式分析笔记本中 | 代码版本一乱，评测结果无法对齐 |
| 指标孤岛化 | 各个子 Agent 各搞一套评测标准 | 缺乏统一的“度量衡”，无法横向对比 |
| 工程化沉重 | 要么“凭感觉”式调参，要么每换一个 Agent 就重写一套测试桩 | 陷入“写代码维护测试代码”的泥潭 |
正是这些痛点，催生了另一条技术路线：把评测逻辑从“硬编码脚本”升格为“可编程、自然语言化、由顶级 Agent 驾驭的 Harness 提示词”。本文即围绕传统脚本式评测与Harness 工程搭建式评测这两条路线展开系统对比，回答“区别是什么、如何选、迁移要注意什么”。
评测逻辑以通用编程语言代码（如主流脚本语言）为载体，由工程师手工实现数据加载、指标计算、断言校验与报告生成，并通常接入持续集成流水线。其典型工作闭环是：
人写评测代码 → 跑脚本 → 看结果 → 改代码 → 再跑。
在这条路线中，评测系统是一个标准的软件工程资产：仓库、版本、测试桩、流水线任务一应俱全。它适合解决“Agent 相对稳定、评测标准固定”场景下的质量门禁问题，优势是执行确定、逐行可审计。
这条路线基于“Agent = Model + Harness”的体系化思维。Harness 指模型外围的“驾驭层”，包括提示词、工具、编排逻辑与评测脚手架。其核心做法是：把评测逻辑表达为一份结构化的自然语言规格（Harness 提示词），再交给一个具备强工程能力的顶级通用 Agent（例如编码型 Agent）按规格快速搭建整套结构化评测体系——抽取数据、定义指标、生成打分器与报告模板，并根据自然语言反馈持续修正评测口径。
此时，人的角色从“写评测代码的人”转变为“驾驭构建过程的人”：下达规格、评审产物、修正方向、沉淀资产。它适合解决“评测标准频繁变化、多子 Agent 需要统一度量”阶段的问题，把评测工程从周级搭建压缩到分钟级搭建。
尽管形态差异很大，两条路线在更深层面高度一致：
换言之，两者争的不是“要不要严谨”，而是“严谨性的表达方式与生产方式”。
脚本式的“单一事实来源”是代码仓库；Harness 式的“单一事实来源”是提示词规格与被锁定的模型版本。前者机器可执行、人类可读；后者人类天然可读、需经转换才可执行。示意对比如下：
# 传统脚本式：评测逻辑 = 代码def eval_copywriting(sample, output):relevance = relevance_score(sample["query"], output)style = style_match_score(sample["style_ref"], output)compliance = compliance_check(output)return {"relevance": relevance, "style": style,"compliance": compliance}
# Harness 式：评测逻辑 = 自然语言规格harness_task: 评测文案生成子 Agenttarget: copy_agent@prompt_v1.2dataset: copywriting_eval_v3（含风格参考与金标答案）metrics:- 相关性: 0-10 分，判断输出与输入主题的贴合程度- 风格匹配: 0-10 分，判断输出与风格参考的一致性- 合规性: 通过 / 不通过report: 结构化结果 + 失败样本归因note: 由通用 Agent 按规格搭建运行，产物经人工评审后沉淀
脚本式依赖测试开发工程师与分析师，门槛在编码与数据工程能力；Harness 式依赖“会写清楚验收标准”的提示词工程能力与评审能力。前者人力密集但技能成熟，后者人力轻量但要求团队具备驾驭通用 Agent 的新技能。
脚本式启动是周级，反馈周期是半天到天级；Harness 式启动是分钟到小时级，且修改评测标准只需改一段自然语言描述，无需重写测试桩。但需要说明：Harness 式的首次冷启动并非零成本，生成的评测工件仍需评审、调试与校准，复杂指标（如需自建评判器的场景）仍可能需要人工介入。
脚本式执行是确定性的，可复现性完全取决于代码与数据版本管理是否严格；其风险在于逻辑散落各处导致“版本一乱、结果不对齐”。Harness 式则引入两层不确定性：构建 Agent 的生成结果可能随模型版本漂移；若指标由大模型评判，打分本身也存在波动。缓解手段包括锁定模型版本、冻结已评审的评测工件、多次采样取多数、控制采样参数等。可复现性可以做到，但必须“把提示词当代码一样管理”，否则评测标准可能被“悄悄改写”。
脚本式天然容易走向指标孤岛：各子 Agent 团队各自实现打分逻辑，口径不可比。Harness 式可通过统一的规格模板约束指标定义，天然适合建立全局“度量衡”，支撑多 Agent 横向对比与全局看板。
脚本式是“前置人力成本高、边际运行成本低”，但长期维护成本随 Agent 数量线性增长（不断重写测试桩）。Harness 式是“人力成本低、按次产生推理成本”，费用随评测频次与数据集规模增长，需要显式做预算与频次控制。
脚本式可逐行调试、以代码差异作为审计证据，便于插入合规检查点。Harness 式中的构建 Agent 需要访问文件、数据与执行环境，必须施加最小权限、沙箱隔离与人工评审门禁；其生成产物在进入长期资产库之前应被冻结并留痕。
脚本式适合沉淀为长期回归资产；Harness 式更适合探索期快速搭建与一次性深度归因分析。实践中两者常常互补：Harness 负责快速“生成”，脚本负责长期“沉淀”。
| 维度 | 传统脚本式评测 | Harness 工程搭建式评测 |
|---|---|---|
| 逻辑载体 | 代码脚本、测试桩、流水线配置 | 自然语言规格 + 生成的评测工件 |
| 构建主体 | 测试开发工程师 | 顶级通用 Agent + 人工评审 |
| 启动周期 | 周级 | 分钟至小时级 |
| 反馈周期 | 半天至天级 | 分钟级 |
| 人力密集度 | 高（标注、写指标、写报告） | 低（写标准、做评审） |
| 确定性 | 高 | 中，需版本锁定与护栏 |
| 可复现性 | 依赖代码与数据版本管理 | 依赖提示词与模型版本管理 |
| 指标一致性 | 易孤岛化 | 易全局统一 |
| 边际运行成本 | 低 | 随频次产生推理成本 |
| 维护成本 | 随 Agent 数量线性增长 | 随规格复杂度增长 |
| 审计合规 | 强，代码即证据 | 需补齐评审记录与产物冻结 |
| 典型风险 | 拖慢迭代、脚本腐化 | 生成漂移、口径被隐性改写 |
若团队使用百度智能云等平台提供的模型服务与 Agent 应用开发能力，两条路线均可与之集成：脚本式通过标准接口调用模型服务，Harness 式可让通用 Agent 在编排评测工件时调用平台的模型与工具能力。关键都在于将评测资产版本与所调用的模型服务版本对齐，保证前后指标可比。
选型没有绝对答案，建议按以下条件判断：
多数团队的务实路径是双轨制：探索期用 Harness 快速验证，稳定后把高频回归部分固化为脚本资产，两者各司其职。
从脚本式向 Harness 式（或反向）切换时，建议关注以下事项：
传统脚本式评测与 Harness 工程搭建式评测的目标完全一致——为 Agent 的每次变更提供快速、量化、可信的验证。两者的根本差异在于：评测逻辑放在哪里（代码还是自然语言规格），由谁来生产（工程师还是顶级 Agent 加人工评审）。由此衍生出迭代效率、确定性、可复现性、指标统一与成本结构上的全面分野。
决策思路可以归纳为一句话：迭代速度优先时选 Harness，确定性与审计优先时选脚本，成熟团队往往两者并用——让 Harness 负责快，让脚本负责稳。理解这一取舍框架，结合自身团队的迭代节奏、合规要求与技能结构，即可做出合适的选择。