什么是 Agent 评测：从轨迹审读到发布门禁

agent-">一、概念定义：Agent 评测是什么

Agent 评测，是针对大模型驱动的智能体系统建立的一套质量评估与发布控制方法：它以 Agent 完成任务的完整执行轨迹为证据，以“可失败”的业务断言为评判标准，最终把通过标准固化为一道发布门禁。

要理解这个定义，先要理解被评对象。Agent 是能接收自然语言任务、自主规划步骤、调用外部工具、并根据中间结果调整后续行为的软件系统。与确定性程序不同，Agent 的执行路径不固定：同一个任务可能走出多条不同路线，可能重试、可能绕路、也可能在失败后“体面地”编出一个答案。因此，只对最终回复做断言，无法覆盖这类系统真正的风险。

可以从三个视角进一步拆解这个概念：

• 技术视角：Agent 评测 = 轨迹数据 + 断言规则 + 门禁策略。评测系统采集一次完整任务的 Trace（轨迹），包括规划步骤、每次工具调用的参数与返回值、重试行为、Token 消耗、延迟和对外部系统产生的副作用，然后逐条判定这些行为是否越界。
• 业务视角：Agent 评测 = 用户旅程承诺的可验证化。产品对用户的每一条承诺，例如“必须先确认身份”“不得猜测答案”，都必须能被一条可失败的测试判据检验。
• 工程视角：Agent 评测 = 回归测试体系向非确定性系统的延伸。它回答的不是“模型聪不聪明”，而是“这一版 Agent 能不能上线”。

业界头部技术团队在公开的评测实践中给出过一个刺眼的提醒：Agent 可能已经陷入循环、重复调用工具、烧掉大量 Token，最后却仍然交出一段礼貌、通顺、甚至看起来正确的回答。这不是虚构事故，而是被明确列出的典型失效方式。Agent 评测的核心使命，正是处理“昂贵且危险的错误往往发生在最终输出之前”这一长期被忽略的问题。

二、背景与价值：为什么“最像成功的失败”最容易逃过回归

传统软件测试习惯拿最终输出做断言：输入一个请求，检查返回值或页面结果。这套方法对确定性程序有效，但对 Agent 几乎失效，原因在于 Agent 的错误大多不体现在最终文本上，而体现在到达文本之前的执行过程里。

以一个常见场景为例：客服 Agent 接到“帮我查一下退款进度”。它先调用订单查询工具，发现订单号为空；随后自行重试三次，又调用退款详情接口；最后根据缓存里的信息回复“退款正在处理中”。用户暂时没有发现问题，测试截图里也有一个合理答案——看起来一切正常。

但这条链路至少暴露四个风险：

1. Agent 没有在缺少关键参数（订单号）时停下来向用户澄清；
2. 重复调用浪费了调用额度与 Token 成本；
3. 缓存信息可能不属于当前订单，存在数据错配与越权风险；
4. 多个失败的工具调用被最终一句得体的文本掩盖。

如果测试只断言“回复包含‘处理中’”，上述四个风险全部会被判为通过。这正是“最像成功的失败”：结果合理、过程失控，而过程恰恰是成本、合规和安全风险的主要来源。

由此可以得出 Agent 评测的第一个关键结论：测试对象要从“答案断言”升级为“旅程断言”。旅程断言不是把 Agent 的每个内部思考都锁死，而是明确三类边界——哪些业务节点不能跳过、哪些动作不能重复、哪些数据必须来自可信工具；同时规定失败后必须落到什么状态，例如转人工。

它的价值体现在三方面：第一，把最贵的错误（无效重试、越权访问、副作用失控）前置到发布前暴露；第二，让回归测试具备可复现的判据，而不是依赖人工抽检；第三，让“灵活”与“风险边界”共存——Agent 仍然可以自由选择语言路径和执行顺序，但不能越过业务底线。

三、核心组成：Agent 评测体系的四个模块

3.1 旅程定义：先把“成功”写成可失败的句子

很多评测项目第一步就走错了：团队先挑选指标，再想拿什么数据去喂指标。更可靠的顺序是反过来的——先写关键用户旅程，再把旅程中的每一条承诺改写成可失败的判断。

以退款查询为例，产品定义不能只写“用户能够查询退款状态”，而要补齐类似这样的约束：

• 必须确认用户身份；
• 必须拿到有效的订单标识；
• 只能读取属于当前用户的订单；
• 退款状态必须来自订单服务，不得使用来路不明的缓存；
• 查询不到结果时不得猜测；
• 超过时限时必须给出人工入口。

这六句话各自对应一类证据：身份校验记录、参数来源、权限判断、工具返回内容、回复与工具结果的事实一致性、失败分流行为。它们共同回答“为什么通过”，而不是只留下一个模型评分。

测试团队可以先建一张最小矩阵：行是旅程节点，列是证据类型、断言写法、失败等级。这张表的价值在于：它不要求 Agent 每次走完全相同的语言路径，却约束了业务上不可接受的行为。灵活可以保留，但灵活不能越过风险边界。

3.2 Trace 人工审读：第一阶段不追求自动化

成熟团队的路径有一个反直觉之处：起步阶段不急着搭自动评分，而是由工程师和测试人员人工精读一批完整的 Trace。原因很直接——如果团队还不知道 Agent 真实会怎样失败，自动生成的评分规则大概率只是把想象中的风险写得更工整，看起来严谨，实际上没有命中要害。

人工审读重点看几类信息：规划步骤是否合理、工具调用序列与参数来源、失败后的重试行为、回复中引用的数据能否在 Trace 中找到出处、终止条件是否正确、单次任务的 Token 成本与延迟分布。审读的产出是两样东西：一份真实失败模式清单，以及评分规则（Rubric）的初稿。行业常说的 Day 0 阶段，指的就是这个以理解为主的时期。

3.3 断言化：把人工判断转成可执行判据

人工审读的结论必须沉淀为机器可执行的判断，否则无法回归。这一步（大致对应路径中的 Day 1 阶段）的做法是把评分规则拆成两层：

• 硬断言：涉及安全、权限、成本、必须节点的规则，结果为布尔值，失败即阻断。例如“未确认身份不得调用订单查询”“同一失败工具连续重试不得超过两次”。
• 软评分：涉及语气、格式、表达质量的条目，按分值累积，设定阈值而不是一票否决。

示意性的判定逻辑如下：

for case in 旅程用例集:
    trace = 运行_agent(case)
    assert 身份已校验(trace)
    assert 订单标识来源合法(trace)
    assert 工具调用次数 <= 上限(trace)
    assert 无未收敛的重复失败调用(trace)
    assert 回复事实与工具返回一致(trace)
    assert 超时场景已分流到人工(trace)
    assert token成本 <= 预算(trace)

这段伪代码体现的原则是：断言检查的是轨迹属性，而不是最终文本的表面特征。

3.4 发布门禁：让成本、延迟与副作用进入上线条件

评测的出口不是一份报告，而是一道门禁。所谓发布门禁（大致对应 Day 2 阶段的固化成果），是指在版本合入或上线流程中设置自动关卡：只有当关键旅程断言全部通过、成本与延迟处于阈值内、工具副作用符合白名单时，新版本才被允许发布。

这意味着三件过去常被排除在测试之外的事，正式进入上线条件：

• 成本：单次任务 Token 消耗上限、工具调用次数上限；
• 延迟：端到端耗时与首响应时间的目标区间；
• 副作用：哪些工具允许真实执行、哪些只能在隔离环境模拟、写操作是否需要二次确认。

门禁的判定结果应当是明确的放行或阻断，并附带证据链，方便研发定位失败原因。

四、工作原理：从一次执行到一次判决

把四个模块串起来，Agent 评测的一次完整运转可以概括为六步：

1. 用例触发：从旅程用例集中选取用例，覆盖正常路径、缺参、越权、工具故障、超时等场景；
2. 执行采集：在受控环境中运行 Agent，记录完整 Trace，包括每一步工具调用、参数、返回、耗时与 Token 计量；
3. 结构化解析：把非结构化的轨迹日志解析成可判定的事件序列；
4. 断言判定：硬断言逐条给出真伪，软评分逐条打分，所有结论附带指向 Trace 的证据；
5. 汇总比较：将结果与版本阈值比较，生成通过率、失败模式分布与成本画像；
6. 门禁决策：达到标准则放行，否则阻断并回传失败证据。

整个机制的关键在于：判定依据来自轨迹而非最终答案，阈值来自真实失败模式而非主观估计，证据链让每一次“不通过”都可解释、可复现。

五、典型应用场景

Agent 评测适用于所有“由大模型驱动、会调用工具、对外提供服务”的系统，典型包括：

• 客服与售后 Agent：涉及订单、退款、工单等查询，风险集中在数据越权与信息虚构，旅程断言价值最高；
• 流程自动化 Agent：表单填写、审批流转、数据录入，风险集中在重复执行与错误写入，副作用门禁是重点；
• 数据分析 Agent：生成查询语句、产出报表，风险集中在幻觉数据与权限越界，事实一致性断言是核心；
• 运维与研发助手 Agent：告警处置、变更执行，副作用高危，必须在隔离环境回归，并对写操作设置最严格的门禁。

在落地方式上，团队既可以完全自建轨迹采集与判定流水线，也可以借助百度智能云等平台提供的模型服务、日志服务、监控告警等通用能力组合搭建。关键是保证三件事成立：Trace 完整、断言可执行、门禁可阻断。

六、与相关概念的区别

• 与传统单元测试、接口测试的区别：被测对象从确定性函数变成非确定性的规划体，断言对象从返回值扩展到完整轨迹；同一输入不再对应唯一合法输出，而是对应一片合法的行为边界。
• 与模型离线评测（基准测试）的区别：基准测试衡量模型的通用能力，如推理、问答；Agent 评测衡量的是特定业务旅程中的行为边界，同一个模型在不同业务里的合格线完全不同。
• 与可观测性、链路追踪的区别：追踪回答“发生了什么”，评测回答“这能不能接受、能不能上线”。追踪提供数据，评测消费数据做判定，前者是后者的原料。
• 与运行时护栏的区别：护栏在运行时实时拦截危险行为，评测在发布前批量验证行为边界，二者互补而非替代。

七、使用注意事项

• Trace 采集必须完整，并包含成本与延迟计量，否则断言无从谈起；缺少计量数据的评测体系会退化为又一层“答案断言”。
• 评分规则要随失败模式持续演进，定期用新采集的 Trace 校准，避免过拟合到历史案例。
• 硬断言与软评分必须分层：不要把风格偏好写成阻断条件，也不要把安全规则降级为扣分项。
• 保留一部分不参与提示词调优的隐藏用例，防止团队针对评测集“应试”，导致线上表现与评测结果脱节。
• 成本与延迟阈值应分场景设定：查询类与写操作类旅程的风险和预算不同，不能一刀切。
• 所有带副作用的工具调用必须在隔离环境中模拟，绝不能在真实生产资源上跑回归。
• 人工审读是起点而不是终点：目标是从人工读 Trace 起步，逐步把经验沉淀为自动断言，而不是永远依赖人眼。

八、总结

回到定义本身：Agent 评测是一种以完整执行轨迹为证据、以可失败的业务断言为标准、以发布门禁为出口的质量工程方法。它的出现，源于 Agent 类系统“过程昂贵、结果体面”的特殊失效形态——最像成功的失败，恰恰最容易逃过传统回归。这套方法的核心价值，是把用户旅程承诺翻译成机器可执行的判据，把成本、延迟与副作用纳入上线条件，让 Agent 的灵活性运行在明确的风险边界之内。对测试与工程团队而言，理解 Agent 评测，本质上是理解一件事：在智能体时代，质量的判断依据正在从“最终答案是否好看”转向“整段旅程是否可信”。