Agent评测系统怎么建：两类评分器对比与选型

agent-">一、对比背景：为什么Agent评测不能照搬传统测试

随着大模型驱动的Agent（智能体）逐步进入生产环境，一个老问题以新形态出现：改动提示词、升级模型、调整工具链之后，怎么判断Agent到底是变好了还是变坏了？

传统软件测试体系已经相当成熟：单元测试、集成测试、回归测试、发布门禁，其判定逻辑几乎都建立在”确定性”之上——给定输入，断言输出。但Agent的行为模式打破了这套假设：

• 多步决策：一次任务涉及规划、工具调用、中间结果整合，存在大量合理分叉；
• 非确定性：同样的输入，两次运行的路径甚至结果表述都可能不同；
• 环境耦合：成败高度依赖运行环境的状态，例如残留的缓存文件、版本历史记录、外部接口的可用性；
• 判断主观化：很多任务的”好”不是布尔值，而是程度问题。

某头部AI厂商的工程团队曾公开分享过一篇关于Agent评测的工程实践，给出了”从0到1”的六步路线图，核心态度非常务实：不要等评测集”完美”才开始，20-50个基于真实失败案例的任务就足以启动。本文以这套实践为参照，将其中的关键决策点抽象出来，构成一篇对比分析，重点回答三个问题：

1. Agent评测与传统自动化测试的本质区别是什么？
2. 确定性评分器（代码评分）与LLM评分器（模型评分）各自适合什么场景？
3. 小样本快速起步与大规模平台化建设，两条路线如何取舍？

二、对象定义：本文在比较什么

为讨论清晰，先明确两组对比对象。

对比组一：传统自动化测试 vs Agent评测系统

• 传统自动化测试：以函数级、接口级断言为核心，输入输出可精确枚举，环境用替身（Mock/Stub）隔离，回归即失败，判定无歧义。
• Agent评测系统：以任务级成败为核心，关注最终结果与合规性而非具体路径，环境要求尽量贴近生产，评分逻辑可能混合代码规则与模型判断。

对比组二：确定性评分器 vs LLM评分器

• 确定性评分器（Code-based Scorer）：用代码规则判定成败，例如检查约定产出物是否存在、结果与参考方案是否一致、行为是否违反约束。
• LLM评分器（LLM-as-a-Judge）：由一个模型按照评分标准（Rubric）对开放性产出打分，适合规则无法穷举的主观或半主观任务。

这两组对比贯穿Agent评测建设始终：前者决定”评测怎么设计”，后者决定”成败怎么判定”。

三、相同点分析：共享的底层逻辑

尽管形态差异明显，这几类方案在底层逻辑上有大量共同点：

1. 目标一致：都是在变更前后提供质量信号、防止回归、支撑发布决策，本质上都是”质量门禁”。
2. 三要素结构一致：任何评测体系都由”任务集 + 运行环境 + 评分逻辑”构成，区别只在于每个环节的实现深度。
3. 都要求可重复性：环境有残留、结果不稳定，评测就失去信号价值。断言如此，模型打分同样如此。
4. 都依赖真实分布：脱离真实使用场景的用例，无论对传统测试还是Agent评测，都会制造虚假的置信度。

四、核心差异分析

4.1 判定逻辑：断言 vs 评价

传统测试的判定是布尔断言，粒度精确到字段；Agent评测的判定是任务级评价，粒度是”结果是否正确且过程是否合规”。这一差异直接导致后者的评分器设计空间更大，也更容易出错。

4.2 稳定性与可重复性

• 确定性评分器：判定结果确定、可复现，同条件多次运行结论完全一致，适合做发布门禁。
• LLM评分器：存在分数漂移风险——对表述顺序敏感、评分模型版本更换后标准整体偏移，必须配合校准与抽检机制才能进入关键链路。

4.3 覆盖能力与适用边界

• 确定性评分器：适合有明确契约的任务（文件生成、结构化输出、接口调用约定），但无法评价”摘要质量””语气是否得体”这类开放维度。
• LLM评分器：覆盖开放式产出，但边界在于：标准写得太松会倾向”全部通过”，写得太紧又会误伤合理结果，Rubric本身需要多轮打磨。

4.4 成本结构

• 确定性评分器：前期编写与维护规则的成本较高，但单次运行边际成本几乎为零。
• LLM评分器：前期搭建快，但每次评估都有推理开销，且需要持续投入人力校准标准，长期成本随任务量线性增长。

4.5 误判模式：工程上最值得关注的差异

• 确定性评分器的典型误判是”冤枉”Agent：任务描述含糊、参考方案又写得过窄时，Agent走了另一条合理路径却被判失败；或者只因步骤与预期不符就判错。业界实践普遍强调”关注结果而非路径”——只要结果正确且过程合规，应鼓励Agent的创造性解法。
• LLM评分器的典型误判是”放纵”与”漂移”：标准执行不严时给分偏松，评分模型升级后历史基线失效。

4.6 环境与运维复杂度

Agent评测对环境的要求显著高于传统测试：既要求贴近生产以保真，又要求每个用例在隔离的干净环境中运行，避免缓存、版本历史等残留状态在跑次间互相干扰。这带来额外的运维负担：环境编排、状态清理、结果归档与可观测性。

五、对比表格

表1：传统自动化测试 vs Agent评测系统

维度	传统自动化测试	Agent评测系统
判定单位	函数/接口级断言	任务级成败（结果+合规）
输入输出	可枚举、确定	开放、非确定
路径敏感度	通常只看输出	明确”结果导向，不锁路径”
环境要求	Mock/Stub为主	贴近生产且逐用例隔离
用例来源	需求规格推导	真实失败案例、手动验证、用户Bug
反馈粒度	精确定位到代码行	任务级信号，需二次归因
运行成本	低	高（多步推理+环境开销）

表2：确定性评分器 vs LLM评分器

维度	确定性评分器	LLM评分器
判定方式	代码断言/规则	模型按Rubric打分
稳定性	高，可复现	有漂移风险，需校准
适用任务	有契约、客观结果	开放、主观、半结构化
成本结构	前期高、边际低	前期快、随量增长
可解释性	明确	可给理由但需人工抽检
典型误判	冤枉合理路径	放宽标准或基线漂移
工程定位	基础层，优先使用	补充层，处理复杂任务

六、六步实操路线：把对比结论落到工程上

结合上述差异，六步实践可重新组织为一条可执行路线：

Step 1 及早起步，小样本即可有效。 不要因为没有成百上千个任务而推迟建设。早期系统变化的影响通常很明显，20-50个基于真实失败案例的任务就足以提供有效反馈。小样本路线的价值在于快速建立”改动-反馈”闭环，而不是统计意义上的覆盖率。

Step 2 从手动测试内容沉淀用例。 把开发中反复手动检查的行为、发布前的验证步骤、用户反馈的Bug转化为测试用例。相比凭空设计，这条路线能保证评测集反映真实日常使用，并天然按用户痛点排好了优先级。

Step 3 编写无歧义任务并附参考方案。 一个可操作的标准是：任务描述应清晰到两位领域专家能独立给出一致的通过/失败判定。每个任务附一个参考方案，作用有二：证明任务可解、验证评分逻辑配置是否正确。这是消除”冤枉式失败”的第一道防线。

Step 4 构建平衡的问题集。 评测集必须同时包含”该做某事”和”不该做某事”两类场景。若只测”需要搜索时是否搜索”，Agent可能被训成”过度触发”、无谓地消耗调用；反之则会出现”漏触发”。平衡的用例集是在两类错误之间寻找最优点的量化手段。

Step 5 稳健框架与稳定环境。 评测环境尽可能贴近生产，每个用例在隔离的干净环境中运行，消除缓存文件、版本历史等残留状态的跨跑次干扰，确保结果真实且可重复。

Step 6 分层设计评分器。 先用确定性评分器打底，复杂或主观任务再辅以LLM评分器；判定关注结果而非路径。示意性伪代码如下：

# 示意性伪代码：分层评分器的基本结构
def evaluate(task, agent_run):
    # 第一层：确定性检查（优先）
    if not check_artifacts(task.expected_artifacts, agent_run.outputs):
        return verdict("FAIL", reason="缺少约定产出物")
    if not task.reference_solution.matches(agent_run.final_result):
        return verdict("FAIL", reason="最终结果与参考方案不符")
    if violates_constraints(agent_run.actions, task.constraints):
        return verdict("FAIL", reason="行为违反任务约束")
    # 第二层：主观维度交给LLM评分器（按需启用）
    if task.needs_subjective_judge:
        judged = llm_judge(agent_run.final_result, rubric=task.rubric)
        queue_for_human_review(judged, sample_rate=task.audit_rate)  # 抽检防漂移
        return judged
    return verdict("PASS")

七、典型场景下怎么选

• 内部工具型Agent（数据查询、报表生成等契约清晰的任务）：确定性评分器为主，LLM评分器可省略，维护成本最低。
• 生产级对话/助理类Agent：混合方案——结构化维度（是否调用工具、是否给出引用）走代码断言，语言质量走LLM评分并配人工抽检。
• 开放式创作类Agent（写作、总结）：LLM评分器为主，但必须建立黄金集定期校准，防止标准漂移。
• 发布门禁/回归链路：确定性优先。门禁的第一属性是稳定，可复现的失败才有拦截价值。

八、选型建议（条件化）

• 团队处于早期、尚无专职评测人力时，优先小样本真实任务路线，而非先搭大规模平台；
• 任务存在明确契约时，先写确定性评分器，不要一上来就引入模型评分的不可控变量；
• 输出天然开放时，引入LLM评分器，但同时必须配套抽检与一致性校验；
• 若Agent部署在云上，可借助百度智能云的容器平台、日志服务、监控告警等通用基础设施承载评测环境的隔离编排与可观测性，减少自建运维负担；
• 所有场景下，都应保留”结果导向”原则：只要结果正确且过程合规，不要因路径不同而判失败。

九、迁移与使用注意事项

1. 从手动验证迁移到自动评测：先把手头重复检查项清单化，再逐项转化为用例，避免一次性重写造成断层。
2. 从代码评分扩展到LLM评分：建立黄金集（人工标注的标杆答案）做校准，定期比对双评分一致性；评分器升级后必须重新对基线。
3. 评测集版本管理：把评测集当作代码来管理，每次变更记录动机与预期影响，否则纵向对比将失去意义。
4. 环境治理：每轮运行前清理缓存与版本历史，用例间互不感知，杜绝”上一轮污染下一轮”。
5. 警惕两类系统性偏差：持续监控漏触发率与过触发率，发现单边抬升时优先补充对立方向的反例用例。

十、总结

Agent评测与传统自动化测试共享”任务集+环境+评分”的骨架，但判定对象从精确断言变为任务级成败，设计重心也随之转向：用真实失败案例驱动小样本起步、用无歧义任务与参考方案消除冤枉式失败、用平衡问题集在漏触发与过触发之间找点、用隔离环境保证可重复。评分器层面，确定性评分器稳定廉价但覆盖有限，LLM评分器灵活但需要校准与抽检——工程上的稳妥做法是分层：代码打底、模型补充、结果导向。选型的核心不是”哪个更好”，而是任务契约的清晰程度、团队的校准能力与门禁的稳定性要求三者之间的匹配。