如何系统评估一个有工具调用的 Agent？

面试时怎么答

Agent 评测不能只看最后一句是否“像正确答案”。应先定义可由环境验证的任务终态，再检查工具选择、参数、状态转换和禁用动作。开放式质量可交给人工或 Judge 辅助，但涉及付款、文件修改等结果要由规则或沙箱验证。被问线上评测时，再区分离线回放、灰度流量和故障注入。

可以这样答：

Agent 的评测对象是整条任务轨迹。先用环境状态判断任务是否真正完成，再检查工具是否选对、参数是否合法、步骤是否重复，以及有没有触发越权动作。开放式文本质量可以由人工或 LLM Judge 辅助，但关键副作用必须由规则、数据库状态或沙箱验证。还应同时关注成功率、违规率、完成步数、延迟和单任务成本。

核心回答

Agent 评估不能只看最终文字答案，要在可执行环境中检查真实终态、规则合规、完整工具轨迹和重复运行稳定性。任务成功应尽量由数据库或环境状态的确定性断言判断；过程指标包括工具选择、参数正确率、无效与重复调用、策略违规、步骤数、延迟和成本。对随机 Agent 需要多次运行，区分偶然成功与稳定成功。

展开说明

一套分层评估可包含：

终态正确性：订单、文件、数据库等真实状态是否达到标注目标，而不是模型是否声称完成。
里程碑检查：长任务的关键中间状态是否满足，便于定位首次偏离的位置。
策略与安全：是否越权、跳过确认、泄漏数据或违反领域规则。
工具能力：工具选择、参数、调用顺序、错误处理和信息不足时的追问。
效率与可靠性：步骤、token、费用、延迟，以及多次试验中的一致成功表现。

离线固定轨迹只能评价给定路径，无法覆盖模型根据实时 Observation 改变动作的 On-policy 行为。tau-bench 的 pass^k 表示同一任务在 k 次独立试验中全部成功的概率，用于衡量一致可靠性；它不同于“k 次中至少一次成功”的 pass@k。LLM Judge 可评开放文本，但应与确定性状态检查和人工标注结合。

工程实践

使用隔离 Sandbox、可重置数据库、可控时钟和故障注入构造测试。保存 Prompt、模型、工具 Schema、初始状态和随机配置版本。对每个场景重复运行并报告均值、方差和失败类型；新增线上 Bad Case 时加入对应状态断言，而不只保存最终回复文本。

常见追问

为什么最终回复正确不代表 Agent 任务成功？ Agent 可能偶然给对文本却调用了错误工具、修改了错误对象或违反权限；任务成功必须同时验证外部终态和过程约束。
pass^k 与单次成功率分别反映什么？ 单次成功率反映默认一次执行的可靠性；pass^k 反映允许 k 次独立尝试时至少一次成功的能力，但也对应更高成本。
如何评估需要多轮向用户追问的 Agent？ 应模拟信息逐步揭示，检查追问是否必要、是否复用已知信息，并统计最终完成率、平均追问轮数和用户放弃率。

一句话复习

Agent 评估要看真实终态、完整轨迹、规则合规、资源效率和重复运行可靠性。

参考资料

面经主题：Datawhale 真实面试题中的 Agent 评估维度
技术依据：ToolSandbox、tau-bench