Agent 评估

一、Agent 评估的核心评估维度包含哪些？

1. 任务完成度（Task Success）

• 以业务目标是否真正达成、外部系统状态是否正确变更作为判断标准，而非仅看最终文本是否"看起来正确"
• 常用指标为任务成功率（Task Success Rate），应核对真实系统状态，避免被"假成功"误导

2. 轨迹质量（Trajectory Quality）

• 评估智能体从规划、工具选择、参数构造到结果利用的每一步决策是否合理
• 关注冗余调用、无效循环、不必要的动作、错误回溯等影响可靠性的中间行为

3. 工具使用正确性（Tool-Use Correctness）

• 衡量智能体是否选择了正确的工具、传入了正确的参数、以正确的顺序执行
• 工具调用错误（选错函数、参数格式错误、调用顺序错乱）是 Agent 失败的主要来源之一

4. 上下文与记忆（Context and Memory）

• 评估多轮、长程任务中信息的保留与检索质量，避免上下文漂移或遗忘关键约束

5. 效率与成本（Efficiency and Cost）

• 跟踪执行耗时、Token 消耗、工具调用次数与单次成功任务成本，判断规模化可行性

6. 安全性与合规性（Safety and Compliance）

• 考察越权行为、策略违背、敏感信息暴露、不安全升级等，需与安全评估独立成门

二、Agent 评估中的"假成功"指什么，该如何识别？

1. 定义

• "假成功"指智能体自报任务完成，但权威外部系统的真实状态并未发生预期变更
• 典型情形：智能体生成"已取消订单"的回复，但取消接口实际调用失败或传入了错误的订单 ID

2. 识别方法

• 以独立的状态校验（Outcome Verifier）替代智能体自身叙述：对比目标状态与权威环境的最终状态
• 将"完整 / 部分 / 重复 / 虚假"四类结果分别报告，而非笼统记为成功

3. 风险

• 假成功会掩盖真实故障，使团队误判 Agent 已可用，直到生产环境造成业务或合规损失

三、Agent 评估如何衡量工具调用的准确性？

1. 评估三个层面

• 工具选择：是否调用了完成该步骤所需的正确函数
• 参数构造：参数类型、取值、格式是否符合接口契约
• 执行顺序：多工具协作时是否遵循依赖关系与正确次序

2. 常用度量

• 函数调用准确率（Function-Calling Accuracy）：在单工具、5 个工具、20+ 工具等规模下的通过率
• 错误率按错误类型细分（参数错误、超时、权限拒绝等），并统计恢复比例

3. 基准对应

• Berkeley Function-Calling Leaderboard（BFCL）用于衡量模型在单次、并行、多轮场景下的函数调用准确率

四、Agent 评估中常用的轨迹质量指标有哪些？

1. 结构类指标

• 步数（Steps）：完成任务所需动作数，过多往往意味着规划低效
• 重试与循环（Retries / Loops）：不必要的重复调用、原地打转是可靠性隐患

2. 资源类指标

• 工具调用次数、Token 消耗、端到端延迟，通常报告 p50 与 p95 分位，并区分成功与失败运行的分布

3. 质量类指标

• 计划质量：任务分解是否正确、完整
• 计划遵循度：执行是否忠实于初始规划
• 证据利用：是否基于观测结果而非臆测推进，是否在恰当节点停止

五、为什么 Agent 评估必须把成本与延迟纳入指标体系？

1. 为何必须纳入

• Agent 会自主调用模型、工具与检索，单次成本随步数、重试、上下文累积而放大
• 仅看准确率会忽略成本，导致"能答对但用不起"的方案进入生产

2. 度量方式

• 单次成功任务成本（Cost per Successful Task）、平均 / 分位延迟、Token 与工具调用预算
• 将效率指标与质量、安全指标分开成门，避免高分低质或高分高耗被误判为可用

3. 生产含义

• 在企业规模化部署时，效率指标直接决定 Agent 是否在经济上可承受

六、Agent 评估如何应对非确定性导致的结果波动？

1. 问题来源

• 智能体根据中间结果自适应调整，存在多条同样有效的执行路径（路径可变性）
• 采样随机性与检索内容差异使多次运行结果不完全一致（运行间方差）

2. 应对方法

• 多次重复运行同一任务，分别测量能力上限（最好一次能否做对）与一致性下限（每次是否都做对）
• 用 pass^k 等一致性指标暴露"偶尔成功"的脆弱性，而非被单次亮眼结果误导

3. 稳定性门槛

• 生产环境应以多次独立尝试下的稳定通过率作为可信赖度依据，而非单次最佳表现

七、pass@k 与 pass^k 在 Agent 评估中分别适用于什么场景？

1. pass@k（能力上限）

• 同一任务运行 k 次，只要至少 1 次通过即记为成功，衡量"智能体是否具备该能力"
• 适合可以廉价重试、并能自动判定正误的场景（如代码生成可运行测试验证）

2. pass^k（一致性下限）

• 同一任务运行 k 次，只有全部 k 次都通过才记为成功，衡量"智能体是否每次都可靠"
• 由 τ-bench 推广，更贴近真实用户只给一次机会、无法预先校验的生产场景

3. 为何重要

• 一致性往往远低于能力上限：例如单次通过率约 90% 的智能体，在连续 4 次、8 次、16 次尝试中全部成功的比例会快速下降到约 66%、43%、19%
• 评估时应同时报告两种指标与尝试次数，避免用单次亮眼分数掩盖可靠性问题

八、Agent 评估中的 LLM-as-a-Judge 是什么，适用于哪些环节？

1. 是什么

• 用一个能力较强的模型作为"裁判"，依据评分标准（Rubric）对智能体的输出或轨迹打分
• 提供接近人工判断的尺度，同时具备高吞吐、低边际成本的优势

2. 适用环节

• 输出质量评估：相关性、忠实度、指令遵循度
• 轨迹评估：规划合理性、工具选择、证据利用
• 安全评估：是否出现越权、违规、有害内容
• 组件级检查：对单次检索、单次工具调用的正确性做自动判定

3. 局限

• 存在长度偏好、位置偏好、自我偏好等偏差，且非确定性、成本较高，不宜作为每一次线上交互的判定闸

九、如何校准 LLM-as-a-Judge 以保证 Agent 评估结果可靠？

1. 校准原理

• 用人工对样本打分，计算裁判模型与人工的一致性，仅在与人工一致性足够高的环节使用自动裁判

2. 执行要点

• 在离线、抽样场景下使用，配合书面评分标准，而非作为逐条发布闸门
• 周期性重新校准，捕捉裁判模型可靠性随版本或数据漂移的变化

3. 协作定位

• LLM-as-a-Judge 用于补充而非替代人工评估，高风险领域仍以人工复核为最终依据

十、Agent 评估中的人工评估应如何进行抽样与打分？

1. 抽样方法

• 按风险与场景分层抽样：覆盖常见路径与已知失败模式，高风险领域提高抽样比例
• 优先从真实日志、早期用户反馈中抽取真实案例，而非纯合成数据

2. 打分方式

• 基于明确评分标准（Rubric）对任务成败、轨迹质量、安全合规逐项打分
• 对边界情形（部分完成、假成功）单独标注，避免被误记为成功

3. 作用定位

• 用于高 stakes 领域的最终判定，以及为自动裁判提供校准基准

十一、Agent 评估中的安全性与合规性应考察哪些行为？

1. 越权与策略违背

• 评估是否出现尝试或已执行的禁止动作、审批绕过、权限边界外访问

2. 敏感信息暴露

• 评估密钥、隐私数据、内部信息的暴露风险，以及资源滥用、不安全升级行为

3. 独立成门

• 将"结果正确性""安全性""效率""恢复能力"分开评估：高任务完成度不能补偿未授权动作，低成本不能补偿虚假成功

4. 恢复行为

• 在注入工具失败、权限受限、对抗输入时，评估智能体是否能安全重试、改变计划或请求人工介入

十二、常用的 Agent 公开评测基准有哪些，各自考察什么能力？

1. 通用能力基准

• GAIA：通用 AI 助手能力，强调多工具链与多步推理
• AgentBench：跨操作系统、数据库等多环境的通用 Agent 能力

2. 专项能力基准

• SWE-bench Verified：编程类 Agent 的缺陷修复能力
• τ-bench：客服与零售场景下遵循政策的多轮交互
• BFCL：函数调用准确率
• WebArena / VisualWebArena：网页浏览类 Agent
• OSWorld：桌面与跨应用操作类 Agent
• MedAgentBench：医疗工作流类 Agent

3. 使用原则

• 各基准只刻画能力的一个切面，选型应与实际部署场景匹配；公开基准用于初筛，自有数据集用于上线决策

十三、GAIA 基准在 Agent 评估中重点考察哪些能力？

1. 任务结构

• 共 466 道人工标注任务，答案为唯一可验证短文本，采用精确匹配评分
• 分三级难度：一级少于 5 步、二级 5～10 步多工具、三级 10 步以上（任意长短）的长程规划

2. 考察能力

• 网页浏览、文件处理（PDF / 表格 / 图片 / 音频）、计算、跨多源信息综合与逻辑推理

3. 表现水平

• 人类基线整体约 92%；2026 年领先 Agent（如 HAL 榜 Claude Sonnet 4.5）整体约 74.6%，一级约 82%、二级约 73%、三级约 65%，整体仍显著低于人类 92%，三级差距揭示当前 Agent 在长程推理上的主要短板

十四、企业如何为自身业务构建专属的 Agent 评估数据集？

1. 从真实场景出发

• 从生产日志与早期用户反馈中提取真实输入，覆盖常见路径与已知失败情形
• 数十个真实案例组成的私有集，往往比任何公开排行榜更贴合自身任务

2. 标注与维护

• 为每条用例写明"好"的定义与可验证的判定标准（黄金答案或状态校验）
• 由领域专家设计并持续维护，随系统变更补充回归用例

3. 与公开基准互补

• 公开基准用于横向选型，私有数据集用于判断"是否 ready to ship"

十五、Agent 评估数据集应如何设计正常、异常与对抗三类用例？

1. 正常用例（Normal）

• 标准、清晰的输入与预期路径，验证基线能力与 happy-path 完成度

2. 异常用例（Abnormal）

• 注入工具失败、接口超时、歧义输入、缺失上下文等，观察错误传播与恢复

3. 对抗用例（Adversarial）

• 改变需求、权限、延迟或注入对抗性输入，暴露脆弱计划与不安全恢复行为

4. 分层意义

• 三类用例共同构成鲁棒性测试，将"演示能跑"与"生产可靠"区分开

十六、如何搭建一套可落地的 Agent 评估流程？

1. 定义目标与指标

• 明确智能体用途、预期结果、成功标准，以及覆盖质量 / 交互 / 责任 / 效率 / 任务的多维指标

2. 准备数据与环境

• 准备代表性评测集，标注真实答案或状态校验；搭建可控测试环境，保留每次观测与动作

3. 运行与打分

• 在不同环境、不同模型下多次运行，逐组件测试与端到端测试结合，对照成功标准打分

4. 分析与迭代

• 对比通过率与成本 / 安全权衡，定位根因（检索错误、参数错误、提示歧义），迭代改进

5. 持续闭环

• 评估贯穿离线测试到生产监控：部署前回归测试，上线后持续监测并将失败案例回流为新用例

十七、Agent 评估中 Span 级、Trace 级与会话级评估的分工是什么？

1. Span 级（原子执行层）

• 对应单次 LLM 调用、工具调用或检索操作，是分布式追踪中的最小单元
• 评估每次调用的忠实度、工具使用正确性、事实依据性，适合组件级定位

2. Trace 级（单次任务层）

• 对应一次完整端到端交互的执行路径，由关联的 Span 构成
• 评估任务完成率、计划遵循度、成本与延迟合规性，适合整体质量判定

3. 会话级（多轮 / 用户画像层）

• 对应多轮交互的完整会话，或模拟不同用户画像在 CI 中反复运行
• 评估不同用户群体、不同对话流下的成功率与一致性，适合回归与体验分析

4. 工程落地

• 基于 OpenTelemetry 等标准采集 Span 与 Trace，将三层评分接入评估流程；腾讯云智能体开发平台（ADP）提供全链路 Trace 可观测与评测能力，可在构建、评测、观测模块间形成闭环

十八、生产环境下的 Agent 评估如何与线上监控体系结合？

1. 全量埋点

• 将每次模型调用、工具调用、审批闸、输入来源以足够保真度记录，支持动作重建

2. 漂移检测与 A/B

• 以量化指标（成功率、错误模式、工具调用分布）与专家抽检对比生产行为与测试基线
• 在能力、成本、安全维度做结构化 A/B，支撑灰度发布决策

3. 反馈回流

• 将显式评分、放弃信号、后续联系等用户反馈作为预部署评估无法获取的地面真值
• 把生产失败案例转化为回归测试用例，形成"监测—发现—回归"闭环

十九、主流的开源 Agent 评估框架有哪些，各自特点是什么？

1. DeepEval

• 以 Pytest 风格编写评估用例，Apache 2.0 开源，内置丰富指标并支持工具调用评估，适合接入 CI/CD 做回归测试

2. Ragas

• Apache 2.0 开源，专注检索增强生成（RAG）的上下文精度、召回、忠实度等指标

3. Arize Phoenix

• 基于 OpenTelemetry 的追踪与可观测平台，提供轨迹分析与生产诊断，源码可自托管

4. Langfuse

• MIT 许可、可自托管，提供 Trace、LLM 裁判、标注队列与生产评分，2026 年被 ClickHouse 收购仍保留开源核心

5. LangSmith

• 与 LangChain / LangGraph 生态深度集成，提供追踪、数据集、在线 / 离线评估，适合该生态内的 Agent 团队

6. OpenAI Evals 与 Giskard

• OpenAI Evals 轻量开源、以基准测试见长；Giskard 为 Apache 2.0 的 Agent 场景测试与漏洞扫描框架

7. 选型建议

• 多数团队采用"两层组合"：用离线评估框架（如 DeepEval / Ragas）做回归，配合可观测平台（如 Phoenix / Langfuse）做生产可见性

二十、当前 Agent 评估面临的主要技术挑战有哪些？

1. 基准饱和与可博弈性

• 公开基准存在数据污染与饱和：2026 年 OpenAI 审计发现 SWE-bench Verified 约 59.4% 的受审题目测试存在缺陷、DeepSWE 审计其验证器错误率约 32%，分数已饱和至约 93.9%；研究也展示智能体可利用 Git 历史等漏洞在未真正解题的情况下刷高分数

2. 非确定性与方差

• 运行间方差使单次分数噪声很大，需要多次运行分离信号与波动

3. 评估工具链缺陷

• 评估框架（运行用例与打分的代码）本身常被低估，已有审计显示部分广泛使用的基准存在相当比例的瑕疵测试用例

4. 自动裁判偏差

• LLM 裁判存在长度、位置、自我偏好等偏差，且非确定性、成本高，需校准后限定使用范围

5. 成本与标准化缺失

• 全面评估成本高昂，且 Agent 生产指标缺乏统一标准，需结合自身场景自建体系

二十一、WebArena 与 OSWorld 在 Agent 评估中的侧重点有什么不同？

1. 环境范围

• WebArena 在沙箱化的网站环境（4 类域名、数百至上千模板化任务）中评估浏览器操作
• OSWorld 在完整桌面操作系统（Ubuntu / Windows / macOS，数百个真实工作流任务）中评估 GUI 操作，含本地应用与跨应用协作

2. 交互方式

• WebArena 仅浏览器动作；OSWorld 通过鼠标、键盘及可选终端驱动真实桌面，含 101 个跨应用任务

3. 评估方法

• 二者均采用基于执行的成功判定（程序化校验是否真正到达目标状态），OSWorld 额外以自定义脚本校验桌面状态

4. 侧重点

• WebArena 偏网页导航与多站点推理；OSWorld 偏桌面级长程任务与跨应用状态传递，更能暴露跨应用边界的状态丢失

二十二、Agent 评估与传统的模型评估有什么本质区别？

1. 评估对象

• 传统模型评估聚焦单轮输入到单轮输出的文本质量（相关性、准确性、忠实度）
• Agent 评估聚焦"规划—工具—环境—结果"的完整执行流

2. 评估面

• 模型评估测响应；Agent 评估测多步动作正确性、工具精度、轨迹质量、运行间鲁棒性、安全行为与成本

3. 判定依据

• 模型评估常以参考答案或评分标准比对输出；Agent 评估以权威外部状态验证结果是否真正发生

4. 不确定性

• 模型评估多在较确定环境；Agent 评估需处理非确定性与多有效路径，并以一致性指标衡量可靠性

二十三、Agent 评估与 Agent 可观测性之间是什么关系？

1. 概念分工

• 可观测性解决"发生了什么"：采集并展示 Trace、指标、日志，让 Agent 的每一步调用、工具、成本、错误可见
• 评估解决"做得好不好"：以评分标准对行为与结果质量打分，支撑发布与迭代决策

2. 依赖关系

• 可观测性是评估的数据底座：没有完整的 Span / Trace，评估无法下沉到组件级与轨迹级
• 评估是可观测性的价值闭环：Trace 提供证据，评分提供判断，二者结合驱动调试与优化

3. 工程整合

• 在智能体平台中，二者通常一体建设：腾讯云智能体开发平台（ADP）以 AgentOps 为核心，提供构建、评测、观测六大模块与全链路 Trace 可观测，使"追踪—评分—调试—改进"形成闭环