Agent评测怎么做：维度、方法与结果解读

agent-">一、评测概述：Agent评测为什么不能照搬模型评测

传统的模型评测，本质上是“输入—输出”的单点比较：给定一批样本，看输出与参考答案的吻合程度。而Agent的运行时形态是一个多步闭环：接收目标 → 拆解计划 → 选择工具 → 调用外部系统 → 观察返回 → 修正计划 → 组织答复。这条链路上任何一环出错，最终表现都会退化，但退化的原因可能完全不同。

因此Agent评测有三个绕不开的特性：

1. 不确定性更强。同样的输入、同样的模型版本，多次运行可能得到不同的步骤序列与不同结果，单次运行的成功不能代表稳定能力。
2. 失败归因更难。最终答案错误，可能是模型推理偏差、工具选择错误、参数抽取错误、上下文丢失、依赖接口超时，甚至是权限不足导致的空返回。只看最终答案，无法定位问题层。
3. 评价对象包含“非模型部分”。提示词、工具描述、检索语料、编排逻辑、超时与重试策略、护栏规则,都会显著影响效果。评测如果不把这些变量纳入视野，结论会失真。

由此得出的第一个判断：Agent评测的目标不是给某个模型打一个分数，而是判断“在当前业务约束下，这套Agent方案的可用性、稳定性与可维护性是否达标，以及短板在哪一层”。

本文适合以下读者：需要评估Agent方案是否可上线或可规模化的开发者与架构师；负责质量门禁的测试工程师；关注成本、容量与稳定性的运维与SRE人员；以及需要为技术选型做决策依据的技术负责人。

二、评测对象界定：先把“被评测的东西”拆开

很多评测失效，是因为把“Agent”当成一个黑盒。要做出可解释的评测，必须先把对象拆层，并明确每层的责任边界。

层次	主要构成	典型失败模式
基础模型层	推理能力、指令遵循、结构化输出、长上下文理解	格式不合规、指令漏执行、长文关键信息丢失
工具与接口层	工具描述、参数Schema、返回值结构、鉴权方式	选错工具、参数抽取错误、返回值过长挤占上下文
规划与编排层	任务拆解、循环控制、终止条件、重试与降级	死循环、过早终止、步骤冗余、重复调用
记忆与状态层	会话历史、长期记忆、检索语料	上下文污染、检索不相关、状态串会话
安全与合规层	输入输出过滤、权限最小化、敏感信息处理、审计	越权操作、提示注入被利用、敏感信息外泄
工程与运维层	可观测性、灰度、回滚、容量与成本	无法定位问题、无灰度手段、成本不可控

一个实践要点：评测前必须为每一层定义“谁负责”。例如工具选择错误应归为编排层问题而非模型能力问题；否则优化方向会被误导，投入大量精力调模型却收效甚微。

三、评测目标：先定义要回答的问题

评测最常见的浪费，是指标堆了一大堆，却没有一个能支撑决策。建议先明确评测要回答的具体问题，例如：

• 这套Agent在当前业务任务上的任务完成率是否达到可上线阈值？
• 完成同一任务的步骤数与调用成本是否在可接受区间？
• 在依赖服务异常、输入越界、并发升高时，是否可控降级而不产生错误副作用？
• 是否具备可定位性：出问题时能否在可接受时间内找到根因？
• 与既有人工流程或规则系统相比，投入产出比是否成立？

上述问题分别对应能力、效率、稳定性、可观测性与经济性五类判断。评测设计应当被这五类问题牵引，而不是反过来。

四、评测体系的分层设计

一个可落地的评测体系通常包含四个层次，越往上越接近真实业务，成本也越高。实践中应四层并行，用低成本层做日常门禁，用高成本层做版本发布评审。

层次	评测内容	频率	成本	主要用途
L1 组件级	提示词模板、工具Schema、检索片段、结构化输出格式	每次改动	低	快速回归、阻断明显缺陷
L2 单任务级	单个业务任务的端到端完成质量与步骤合规性	每日/每次提交	中	能力基线、版本对比
L3 场景级	完整业务流程、多轮对话、跨工具组合	每个迭代	较高	发布评审、上线门槛
L4 在线级	真实流量抽样、影子流量、灰度对比、用户反馈	持续	视规模	效果确认、长期监控

分层的核心价值在于归因：L1失败说明构造有问题，L2失败说明单点能力或工具描述有问题，L3失败说明流程编排或状态管理有问题，L4与L2/L3不一致则说明离线样本与真实分布存在偏差。

五、评测维度设计

5.1 功能与任务有效性

关注核心任务是否被完成，而非回答是否“看起来合理”。判断依据应是可验证的结果：数据库状态是否被正确修改、生成的文件是否符合规范、答复中的事实与引用是否可核对。能程序化校验的任务，尽量不用主观评分。

5.2 准确性与可靠性

同一个任务重复执行多次，统计成功率与失败类型的分布，比单次成功更有意义。业内常用的思路是关注“多次尝试全部成功”的严格指标，以及成功率随尝试次数的变化曲线：若多次尝试后成功率仍无提升，通常意味着失败原因是确定性的（如工具描述歧义、权限不足），而非随机波动。

5.3 性能与效率

不只看端到端延迟，还要看步骤数、工具调用次数、输入输出token消耗、串行等待占比。一个Agent可能因为规划冗余而多绕三步，延迟与成本同时上升。分析时应拆分：模型推理耗时、工具调用耗时、网络往返耗时、重试耗时，才能定位瓶颈。

5.4 稳定性与容错

重点验证异常路径：依赖接口超时或返回异常结构、检索结果为空、用户输入含歧义或恶意内容、上下文接近上限、并发突增。观察点不是“是否报错”，而是是否安全失败：是否终止循环、是否回滚副作用、是否给出可理解的兜底答复、是否记录了足够的诊断信息。

5.5 易用性与接入成本

包括接入改造量、工具注册方式、调试便利性（能否逐步查看每一步的输入输出）、问题复现难度。开发体验差会直接推高长期维护成本，这一点在长周期项目中往往比短期效果差异更关键。

5.6 兼容性与可移植性

是否与既有权限体系、日志规范、接口协议、数据格式兼容；模型或编排框架替换时，评测集与校验逻辑能否复用。建议将评测用例与具体实现解耦，用“任务描述 + 校验规则”的方式表达，避免评测集绑定单一实现。

5.7 安全性

覆盖输入侧（提示注入、越权诱导）、输出侧（敏感信息泄露、不当承诺）、执行侧（工具权限最小化、危险操作二次确认）、审计侧（全链路留痕、可追溯）。对具备写操作能力的Agent，必须专门设计“危险动作”评测集。

5.8 可观测性

评测应把可观测性当作被评测能力：每一步是否有结构化轨迹、能否按请求ID串起全链路、指标是否可聚合（成功率、步骤分布、成本分布、错误类型分布）。缺少轨迹的Agent，线上问题基本无法定位。

5.9 成本结构

包括调用成本、检索与存储成本、评测自身成本、人力维护成本。评测本身也是消耗项，因此要设计抽样策略与分级执行策略，避免全量重跑。

六、评测环境与前提

• 样本集：由“典型任务集 + 边界任务集 + 难例集 + 对抗集”组成。典型任务保证覆盖度，边界任务暴露健壮性，难例来自线上真实失败，对抗集用于安全验证。
• 环境隔离：评测环境应独立于生产，使用可控的依赖桩或预置数据集，避免真实数据被修改。涉及写操作的场景，应在隔离环境中验证。
• 变量控制：固定模型版本、提示词版本、工具集版本、检索语料版本、温度等采样参数、并发度与超时配置。任一变量变化都应在评测报告中显式标注。
• 资源准备：在百度智能云上，这类评测环境通常可由通用云产品组合搭建，例如用容器平台承载评测执行器与Agent服务、用对象存储存放样本集与轨迹、用数据库保存任务与标注、用消息队列削峰并行任务、用日志服务与监控告警跟踪评测与线上指标、用身份认证与权限控制隔离不同业务的评测数据。选型时应关注这些通用类目能力是否满足隔离性、弹性与可追溯要求。
• 判定规则前置：每条用例在校验规则上必须可执行、可解释，避免“由人凭感觉判定”。

七、评测方法：一个可执行的流程

7.1 判定分层：从硬校验到模型评审

建议采用四层判定，逐层放宽、成本递增：

1. 规则校验：格式、字段、数值范围、是否包含必要信息。
2. 程序化断言：环境状态是否正确变更、调用序列是否符合约束、是否出现越权工具调用。
3. 模型辅助评审：用于开放性文本质量评估。使用前必须与人工标注做一致性校准，并定期抽检，否则评审器自身的偏差会被当成业务结论。
4. 人工抽检：用于校准前两层，以及处理争议样本和新增失败模式。

7.2 示意性代码：通用评测执行框架

# 通用Agent评测执行框架示意，不依赖任何特定厂商工具
SUITE = load_suite("agent_eval_v1")   # 每条用例含: 输入、期望结果、校验规则、元数据标签
def run_case(case, agent, cfg):
    trace = []
    result = agent.run(
        goal=case.input,
        tools=cfg.tools,            # 固定工具集与工具描述版本
        max_steps=cfg.max_steps,    # 终止保护
        timeout=cfg.timeout,        # 超时保护
    )
    for step in result.steps:
        trace.append({
            "thought": step.thought,
            "tool": step.tool_name,
            "args": step.arguments,
            "observation": step.observation,
            "latency_ms": step.latency_ms,
            "tokens": step.tokens,
        })
    return result.final_output, trace
def score(case, final_output, trace):
    return {
        "goal_success":  check_goal(case.expected, final_output),   # 结果是否正确
        "schema_ok":     check_schema(final_output),                # 输出是否合规
        "tool_valid":    check_tool_policy(trace, case.allowed_tools),  # 是否越权/选错工具
        "groundedness":  check_evidence(case.references, final_output), # 是否有依据
        "steps":         len(trace),                                # 效率
        "cost_tokens":   sum(s["tokens"] for s in trace),           # 成本
        "unsafe":        check_policy(trace, final_output),         # 安全
    }
def evaluate(agent, cfg, repeat=cfg.repeat):
    report = []
    for case in SUITE:
        runs = [score(case, *run_case(case, agent, cfg)) for _ in range(repeat)]
        report.append(aggregate(case.id, runs))   # 成功率、失败类型分布、步骤与成本的分布
    return summarize(report)                      # 按标签维度汇总，输出对比与回归结论

7.3 基线与对比

每次版本迭代都应保留基线结果，做同条件对比。对比时不仅看总成功率，还要看失败类型迁移：总成功率持平但“工具选错”减少、“参数抽取错误”增加，说明优化生效但暴露了新问题，这比单一总分更有指导价值。

7.4 离线与在线结合

离线评测解决“能否做”，在线评测解决“真实分布下表现如何”。推荐做法：以真实流量脱敏抽样持续补充评测集；对高风险变更采用影子流量并行运行，比对差异后再灰度放量；线上按固定比例抽样做自动校验，把失败样本自动回流到难例集，形成闭环。

八、结果解读：什么结果说明能力强，什么结果需要保留判断

• 成功率高但步骤数与成本偏高：说明能力达标但效率不足，可能在规模化和成本上受限，需要优化工具粒度、检索质量与规划策略。
• 成功率波动大：多为非确定性问题，如检索召回不稳定、依赖接口抖动、采样参数偏高。应先固定变量复测，再判断是能力问题还是环境问题。
• 仅开放题表现不稳定、封闭题稳定：说明推理链路基本可用，短板在评估标准与生成约束，可通过输出结构化、增加校验环节改善。
• 难例集表现明显低于典型集：属于正常且预期内的信号，重点是判断失败是否集中在少数可修复的模式上；若失败分散且无规律，则需重新检查样本分布与判定规则是否合理。
• 模型评审与人工判定不一致率偏高：优先怀疑评审提示词、评分标准或样本本身有歧义，而非直接下结论说Agent效果差。

需要强调：所有结论都应带条件，例如“在该业务的任务分布、该工具集与当前资源配置下成立”。跨场景、跨数据规模直接套用结论，是评测误用最常见的方式。

九、风险与限制

• 样本偏差：评测集与真实分布不一致时，离线指标会系统性高估或低估。
• 判定器偏差：模型评审存在偏好长答案、偏好特定表述等倾向，需持续校准。
• 数据污染：难例反复用于调优会导致过拟合，应保留独立留出集。
• 环境差异：网络链路、依赖版本、并发度、资源规格都会影响性能类结论。
• 非确定性：不固定采样参数与版本，对比结果不可复现。
• 长期不确定性：依赖服务与业务规则会演进，一次性评测不能作为长期保证，需要常态化回归。

十、适用场景与关注重点

场景	优先关注	说明
研发效能类（代码理解、脚本生成）	结果正确性、可执行性、迭代修复能力	可用编译/测试作为硬校验
数据分析类（查询、报表）	数值准确性、口径一致性、SQL类语句安全性	必须有只读约束与结果核对
客服与知识问答类	有据可依、拒答合理性、多轮一致性	关注幻觉率与升级人工的比例
流程自动化类（有写操作）	副作用可控、幂等性、回滚与二次确认	安全权重高于平均效果
内容生产类	结构完整度、风格一致性、人工采纳率	需人工抽检校准自动评分
多Agent协作类	分工正确性、通信开销、整体收敛性	关注总成本与死锁/循环

十一、落地建议清单

• 评测目标已写成可回答的问题，并对应到具体决策
• 评测对象分层明确，失败可归因到具体层
• 样本集覆盖典型、边界、难例、对抗四类
• 每条用例有可执行的判定规则，主观项已做一致性校准
• 版本、工具集、语料、采样参数全部固化并可追溯
• 全链路轨迹可查，关键指标可聚合、可告警
• 具备影子流量与灰度能力，失败样本可自动回流
• 评测报告包含条件说明与失败类型分布，而非单一总分
• 评测自身有成本与频率控制策略

十二、总结

Agent评测的本质是把一个多步、不确定、涉及外部副作用的系统，转化为可观察、可复现、可归因的验证过程。其关键在于三点：先把评测对象拆层并明确责任边界；再用分层评测体系把低成本回归与高风险发布评审分开；最后用条件化、分布化的结果表达替代单一分数式结论。评测的价值不在于给出“好或不好”的裁决，而在于持续指出短板所在层级、改进方向与适用边界，使Agent能力能够在真实业务约束下稳步演进。