Agent单元测试为何失效：如何评测非确定性系统

一、评测概述

agent-">1.1 为什么要单独评测“Agent的评估体系”

单元测试的底层假设是“相同输入得到相同输出”，面向的是确定性软件。Agent的决策来自概率模型，输出具有随机性；它调用的外部工具状态随时变化；执行路径也由它自主决定。这三点叠加，使传统断言在Agent面前只能完成很浅层的检查。

更隐蔽的风险在于，评估体系本身也可能“失灵”。以下是一段真实的项目复盘：

• 一个客服Agent上线前，测试覆盖率超过八成，所有用例通过，压测也顺利通过。
• 上线72小时内，用户反馈集中在某类投诉场景：Agent反复追问同一个问题，陷入死循环。
• 回查代码没有发现逻辑缺陷，再看测试，断言几乎都在验证“输出是否包含某些关键词”。没有任何一条用例检验“多轮对话中Agent会不会陷入逻辑死循环”。

代码没有问题，测试全部通过，线上却出现了严重缺陷。问题不在单个用例，而在评估体系：它测的是“字符串是否出现”，而不是“Agent做了什么”。

评估体系失灵，不只发生在单个团队。公开基准测试同样出现了信任危机。某开源社区2026年发布的一份分析报告指出：

• 有团队仅用约10行脚本，借助某常见测试框架的钩子机制篡改测试结果，在某公开代码修复基准上拿到满分。
• 研究发现，28个模型的提交存在作弊行为，8个主流基准受到影响。

当一个基准可以被“针对测试机制”而非“针对问题本身”优化时，榜单分数的参考价值就会下降。多数团队既没有能力验证外部榜单，内部评估体系又尚未建立，很容易陷入“盲飞”。

1.2 本文评测什么，读者能获得什么判断

本文的评测对象是“一套面向Agent的评估体系”，重点回答四个问题：

• 它测的是不是Agent真正的业务行为？
• 给出的分数是否值得信任？
• 能否稳定拦住已知的失败模式？
• 每次Prompt调整或模型升级，验证成本是否可控？

读完本文，读者可以建立一套结构化的检查清单，判断现有评估体系是否足以支撑上线与迭代决策；如果不足，也知道应当优先补齐哪些环节。

本文适合以下读者：

• 正在开发或维护Agent应用的工程师与测试人员；
• 需要为AI应用搭建质量门禁的架构师与技术负责人；
• 关注AI应用稳定性与风险的运维及企业技术团队。

需要说明的是，评测不等于判定“好不好”，而是回答“在什么条件下、对哪类任务、以多大代价，这套体系能给出可信结论”。

二、评测目标

本次评测围绕五个目标展开：

1. 断言有效性：用例是否在验证Agent的行为，而不只是在匹配文本；
2. 任务成功的定义质量：“成功”是否被拆解为可观察、可判定的层次；
3. 评分可靠性：自动评分与人工判断是否一致，偏差能否被发现并纠正；
4. 失败拦截能力：已知异常行为是否被沉淀为回归用例并被稳定捕获；
5. 迭代验证成本：Prompt调整或模型升级后，完成验证需要多长时间和多少人力。

三、评测对象说明：Agent的非确定性从哪里来

Agent通常由模型、工具集、上下文与运行框架组成，接收用户请求后自主规划、调用工具，并整合结果给出回复。它的输出同时受以下因素影响：

• 采样随机性：同样的输入，采样参数不固定时可能产生不同表述与不同决策；
• 外部状态变化：工具返回的数据、接口可用性、权限状态都可能随时间变化；
• 路径自主性：面对同一目标，模型可能选择不同的规划路径和工具调用顺序。

因此，单次运行的通过与否只能说明“这一次没出错”，不能说明“它可靠”。评估体系必须把随机性、外部依赖和路径多样性都纳入考虑。

对比项	传统确定性软件	Agent系统
输入输出关系	相同输入得到相同输出	相同输入可能产生不同输出
失败来源	代码逻辑缺陷、边界条件遗漏	模型决策偏差、工具异常、上下文管理失误
测试对象	函数、接口的返回值	多步行为链及其最终影响
断言方式	精确匹配返回值	分层判定目标达成与行为合理性
通过标准	用例全部通过	在多次采样下稳定达标，且异常模式可控
变更影响	可由代码差异分析	需整链回归验证

四、评测维度设计

评估体系不能只报一个总分，应拆成可观察、可验证、可解释的维度。下表给出建议的评测框架。

维度	关注问题	主要观察对象	验证方式	解读要点
任务完成度	是否真正解决用户问题	任务结果、交付物	结果判定加抽样人工复核	区分“碰巧答对”与“稳定答对”
指令与约束遵循	是否遵守格式、口径与禁止项	输出结构、约束条件	规则校验加评分器	多项约束需逐项检查
行为链合理性	过程是否存在逻辑问题	完整执行轨迹	轨迹级检测规则	结果正确不代表过程合理
评分可靠性	分数能否代表质量	自动评分与人工评分	定期抽样做一致性对比	关注系统性偏差，而非个别误差
可复现性	结论能否重复得到	参数配置、外部依赖	固定参数并多次运行	波动大的结论需扩大样本
可观测性	失败后能否定位原因	日志、指标、追踪	故障注入与回溯演练	缺少轨迹时只能看到结果，看不到过程
回归效率	变更后验证要多久	回归流程与耗时	模拟Prompt或模型升级	周期越长，迭代越保守
成本与可维护性	维护代价是否可持续	数据维护、评分调用、人力	记录每轮评估投入	评估成本过高会导致体系荒废

4.1 任务完成度：拆成三个层次

单一的“对/错”判定无法反映Agent的真实水平。建议把任务成功拆为三层：

1. 能力层：能否完成任务。 目标是否达成，结果是否正确、完整；
2. 安全层：有没有搞坏其他流程。 是否越权、误写数据、重复下单、触发无关业务动作；
3. 体验层：边界情况下行为是否合理。 信息不足时是否澄清，遇到无法处理的情况能否恰当转交人工，语气是否符合业务规范。

这三层对应三类不同风险。能力层不达标会损失效率，安全层不达标可能造成直接经济损失，体验层不达标会侵蚀用户信任。三层应分别设定判定标准和统计口径，不能合并成一个笼统分数。

4.2 指令与约束遵循：逐项可判定

Agent的输出通常包含多项约束，如格式要求、事实口径、不得作出的承诺、必须转交人工的条件。验证时应把约束拆成独立的可判定项：

• 规则能判定的，用程序校验，如结构字段是否齐全、是否出现禁止表述；
• 语义层面的要求，如回答是否贴合用户诉求、是否遗漏关键信息，再交给评分器或人工判断。

约束项全部通过，只能说明“守规矩”；目标是否达成，仍要由任务完成度维度回答。

4.3 行为链合理性：过程审计比结果匹配更重要

开头的死循环案例，问题不在单次输出，而在多步交互形成的模式。只看最终结果，这类缺陷几乎不可能被发现。评估体系需要记录并检测以下轨迹级异常：

• 重复追问：同一问题连续多轮重复，用户已给出信息却未被采用；
• 目标漂移：多轮之后偏离最初诉求；
• 跨轮遗忘：此前已确认的约束在后文失效；
• 工具误用累积：参数错误未被纠正，错误沿着调用链放大；
• 轮次或成本超限：为完成简单任务消耗了过多轮次与调用。

这些数据可以来自两部分：

• 轨迹中的结构化信息，如重复问题的相似度、调用次数、错误码序列；
• 线上日志的聚合统计。

4.4 评分可靠性：自动评分必须经过校准

在大规模评估中，人工逐条打分难以为继，“用模型给模型打分”成为常见做法。但自动评分有自身的系统性偏差，需要持续校准：

• 长度偏好：倾向给更长、更详尽、措辞更华丽的输出打高分；
• 表面特征偏好：重视格式工整与语气礼貌，对实质正确性评价不足；
• 标准漂移：评分提示词调整后，同一输出得分明显变化；
• 位置影响：成对比较时，先后顺序可能影响结论。

校准方法：

• 定期抽取固定规模的样本，由人工按同一标准重新打分，与自动评分逐条对比；
• 关注偏差方向，而不仅是平均差距。例如长度偏好会系统性抬高冗长但价值有限的回答；
• 偏差超过预设阈值时，先修正评分标准与评分提示词，再重新评估历史结论；
• 评分提示词本身应像代码一样进行版本管理。

4.5 可复现性：让结论可被重复验证

参数固定、依赖稳定，是结果可比较的前提。建议固定采样参数与模型版本，用可回放的模拟工具替换外部依赖。同一任务集多次运行时，重点关注：

• 结果判定是否一致；
• 行为路径是否出现新的异常模式；
• 评分波动幅度有多大。

波动明显偏大的任务，应扩大采样次数，或拆分为多个可判定的子任务。

4.6 可观测性：能否回答“为什么失败”

评估体系的价值不只在于给出分数，更在于失败时能否说清原因。每次评估至少应记录：

• 任务标识、输入、模型与Prompt版本；
• 完整的思考、工具调用与返回；
• 每轮耗时与调用次数、判定结果、失败原因标签。

这些数据可用于线上回放、失败聚类与回归集扩充。轨迹数据往往包含用户信息或业务数据，在云上搭建评测环境时，应利用日志服务、对象存储的访问控制与加密能力，并结合身份认证做权限隔离。

4.7 回归效率：验证周期决定迭代速度

回归效率可用三项指标衡量：

• 从触发变更到拿到结论的耗时；
• 其中人工介入的比例；
• 漏检率，即上线后新发现的问题中有多少本应被回归用例拦截。

自动化程度越高、轨迹检测规则越完整，回归越快，团队越敢于频繁调整Prompt和升级模型。

五、评测环境与前提

1. 环境隔离：评测环境应与生产环境隔离，使用镜像化的数据副本，避免评估过程影响线上业务。
2. 参数固定：固定模型版本、采样参数和工具版本。每轮评估只有单一变量发生变化，结论才可归因。
3. 依赖可控：外部工具使用模拟实现，覆盖正常返回、超时、限流、空结果、格式异常等情况。
4. 样本有代表性：任务集应覆盖高频场景、长尾场景和已知问题场景，并定期根据线上反馈补充。
5. 人工基线：保留一批人工标注样本作为“标尺”，自动评分只在与标尺对齐后才可用于决策。
6. 测试边界：明确说明哪些行为被覆盖、哪些没有覆盖，避免用局部结论推断整体能力。

六、评测方法与实施流程

建议按以下流程实施：

1. 定义问题：列出本轮评估要回答的问题，如“新Prompt是否加重了重复追问”；
2. 准备样本：从线上日志或业务知识中整理任务集，去标识化后入库；
3. 建立基线：固定参数，在变更前完整运行一次，记录各维度结果；
4. 分维验证：按任务完成度、约束遵循、行为链、评分可靠性等维度分别执行；
5. 轨迹检测：用规则与统计方法扫描执行轨迹中的异常模式；
6. 人工校准：抽样复核自动评分，计算一致率，必要时调整评分标准；
7. 汇总报告：给出分维度结果、失败样本聚类、结论边界与改进建议。

以下为示意性伪代码，只描述流程，与具体框架和工具无关：

# 输入：任务集 tasks、待测配置 config、基线结果 baseline
# 输出：分维度评估报告 report
function evaluate(config, tasks):
    for task in tasks:
        # 同一任务多次采样，观察稳定性
        runs = [run_agent(task, config) for i in 1..N]
        results = []
        for run in runs:
            checks = {
                "task_success":   judge_goal(task, run),        # 目标是否达成
                "side_effect":    check_side_effects(run),      # 是否产生越权或副作用
                "constraints":    check_constraints(task, run),  # 逐项校验约束
                "trace_anomalies": scan_trace(run)               # 重复追问、工具误用累积等
            }
            results.append(checks)
        task_report = {
            "pass_rate": ratio_passed(results),   # 多次采样的通过比例
            "variance":  variance(results),        # 结果波动
            "anomalies": collect_anomalies(results)
        }
    # 人工校准：抽样复核自动评分，与人工基线对比
    deviation = compare_with_human(sample(tasks), config.scorer)
    if deviation > config.threshold:
        report.warning = "评分偏差过大，本轮评分结果仅供观察，不进入决策"
    return report

七、结果解读：什么样的结果才可信

• 看分布，不只看均值。 如果多数任务表现良好，但少数高风险任务反复失败，整体均值会掩盖风险。
• 看分层，不只看总分。 能力层表现良好而安全层频繁失败，意味着不宜直接接入生产业务流程。
• 看一致性，不只看单次得分。 自动评分与人工评分一致率稳定，评分结果才可作为决策依据。
• 看失败聚类，不只看失败数量。 失败若集中在少数几类模式，针对性修复往往比整体调优更有效。
• 看回归集命中率。 历史问题若在回归中被稳定拦截，说明评估体系在持续积累价值。

结果差异背后的技术原因，通常需要进一步排查：

• 得分波动大，可能来自采样随机性或外部依赖不稳定；
• 评分偏高，可能源于评分器的长度偏好；
• 某一类任务集中失败，可能源于上下文过长导致关键信息被稀释，或工具返回格式与模型预期不匹配。

八、适用场景分析

业务场景	重点评测维度	关注原因
客服、售后问答	任务完成度、重复追问、转人工判断	直接影响用户满意度和投诉率
涉及下单、支付、数据写入	安全层行为、工具调用正确性	错误操作可能造成直接经济损失
内部知识问答、办公助手	事实准确性、信息时效性、引用可核验性	错误信息会误导业务决策
多工具编排的复杂任务	路径合理性、错误累积、轮次与调用次数	链路越长，偏差累积越明显
高频迭代的早期产品	回归效率、评分可靠性	迭代越快，评估体系越需要自动化
合规要求较高的行业	可观测性、权限控制、日志审计	需要可追溯、可审计的运行记录

九、风险与限制

1. 基准不可全信：公开基准存在被针对测试机制优化的可能，分数应结合测试设计审查来判断。
2. 评分偏差难以根除：自动评分只能降低偏差，无法彻底消除，必须保留人工校准环节。
3. 样本偏差：任务集若主要来自开发者想象，会与真实用户分布产生偏差；应持续用线上反馈修正。
4. 环境差异：模拟工具无法完全复现真实依赖的复杂性，评测通过不等于线上无忧。
5. 过度拟合：长期围绕回归集优化，可能只修好了“已知问题”，对新型失败缺乏防御力。
6. 评测成本：模型调用、数据存储与人工复核都有成本，体系过于庞大反而难以维持。

十、选型与使用建议

判断是否值得建设完整的Agent评估体系，可参考以下清单：

• 用户规模较大或业务关键程度较高；
• Prompt与模型迭代频繁；
• Agent会执行写操作或访问敏感数据；
• 曾因Agent异常行为引发投诉或损失。

满足其中任意一项，就值得投入建设。

建议按阶段推进：

• 起步阶段：建立分层任务集，加入轨迹级异常检测，所有自动评分结果抽样人工复核；
• 成长阶段：形成行为回归集，评分偏差定期校准，评估流程自动化，纳入持续集成流程；
• 成熟阶段：以线上反馈驱动任务集更新，在每次模型升级前完成整链回归，再决定灰度放量。

不建议跳过轨迹检查直接依赖整体评分，也不建议在没有人工标尺的情况下直接采用自动评分作为上线依据。在百度智能云等云平台上搭建评测流水线时，可结合容器服务、对象存储、日志与监控服务等通用云产品完成环境隔离、数据存储与运行观测，但技术选型仍应以自身业务场景和验证结果为准。

十一、总结

Agent评估的核心转变，是从“验证输出”转向“评估行为链”。传统单元测试并非毫无价值，它能有效校验确定性逻辑和工具实现；但它不是衡量Agent能力的合适工具。

一套可信的Agent评估体系应具备五项能力：

1. 分层定义任务成功；
2. 检测轨迹级异常；
3. 校准自动评分；
4. 沉淀行为回归集；
5. 控制验证成本。

评测结论始终是有条件的：它只在特定任务分布、特定参数配置和特定评分标准下成立。把评测当作持续校准的过程，而不是一次性打分，才能在非确定性系统中做出可靠的发布决策。