AI Agent 评测指南上从指标设计到准出标准你的 Agent 能自主规划、调用工具、创建 SubAgent 并行干活——看起来很强大。但上线一周后用户反馈 Agent 有时候死循环经常选错工具10次里有3次任务没完成。单次体验看不出问题评测体系才能暴露真相。这篇文章围绕 AI Agent 业务场景系统拆解评测的三个核心问题测什么Agent 专属指标体系、怎么测自动化LLM-as-Judge人工、什么时候算通过分级准出标准。一、Agent 评测为什么比对话评测难得多普通 LLM 评测只关心回答好不好。Agent 评测要关心事有没有办成——这中间多了工具调用、多步规划、错误恢复、SubAgent 协作。Agent 评测的五个独特挑战1. 评测的是任务链而非单次回答普通 LLM用户问 → 模型答 → 评判答案质量Agent用户给目标 → Agent 规划 → 调用工具A → 读结果 → 调用工具B → 发现错误 → 修正 → 调用工具C → 返回结果评测需要看从收到目标到完成任务的完整链条2. 工具调用的正确性难以自动判定模型选了read_file(src/auth.ts)但正确答案应该是read_file(src/auth/login.ts)——算对还是算错工具选对了但参数不够精确又怎么打分3. Agent 的犯错和修复是正常行为好的 Agent 不是不犯错而是犯错后能自己发现并修复。如何评测从错误中恢复的能力4. SubAgent 协作的评测是空白地带主 Agent 是否在正确的时机创建了 SubAgentSubAgent 的结果是否被正确整合并行 SubAgent 的调度是否合理5. 同一个任务不同 Agent 可能有完全不同的正确路径任务找出项目中的安全漏洞并修复Agent A 先全局搜索 → 逐个分析 → 生成修复Agent B 先看配置文件 → 分析依赖 → 检查代码两条路径都可能是正确的——不能按路径评判只能按结果评判对比维度对话 LLM 评测Agent 评测评测对象单轮/多轮回复多步任务执行链核心问题答得好不好事办没办成评测粒度单次对话完整任务含工具调用链正确性答案 vs 参考答案任务结果 vs 预期结果路径多样性低表达不同但意思相同高不同工具组合可达同一目标错误处理基本不考虑核心评测维度二、Agent 专属评测指标体系2.1 五维 Agent 评测框架① 任务完成度事办没办成任务成功率 / 目标达成率 / 输出可用率② 工具使用质量工具用没用对工具选择准确率 / 参数准确率 / 调用链效率③ 规划与推理脑子清不清楚规划合理性 / 步骤效率 / 死循环率 / 错误恢复率④ SubAgent 协作帮手派没派对SubAgent 创建时机 / 并行合理性 / 结果整合质量⑤ 安全与效率不出事、不太慢危险操作率 / 幻觉引入率 / 平均完成时间 / 费用2.2 维度一任务完成度这是 Agent 评测的北极星指标——其他一切最终都要服务于事办没办成。指标 1端到端任务成功率最重要定义Agent 从收到任务目标到返回可用结果的完整成功率计算成功任务数 / 总任务数判定成功的三个层次L1 - 严格成功输出完全匹配预期零人工修正即可用例生成的代码能直接运行并通过所有测试L2 - 基本成功输出核心部分正确需少量人工修正例代码核心逻辑对但缺了一行 importL3 - 失败输出无法使用或 Agent 中途报错放弃生产级基线代码生成 AgentL1 ≥ 40%, L1L2 ≥ 75%文档写作 AgentL1 ≥ 60%, L1L2 ≥ 85%数据分析 AgentL1 ≥ 50%, L1L2 ≥ 80%指标 2目标达成率更细粒度定义用户目标中每个子目标的完成情况示例帮我审查代码安全并生成报告子目标1找到安全漏洞 → 找到3个预期2-4个子目标2生成修复建议 → 每个漏洞都有建议子目标3输出Markdown报告 → 格式正确→ 目标达成率 3/3 100%指标 3输出可用率定义Agent 输出中用户可以直接使用不需修改的比例对于代码 Agent可运行率对于文档 Agent可直接发布率对于操作 Agent操作结果正确率2.3 维度二工具使用质量Agent 的核心能力就是知道什么时候用什么工具。工具用错了任务必然失败。指标 1工具选择准确率定义Agent 选择的工具是否与参考答案中的最优工具一致评测方法对每个任务步骤标注应该用的工具比对 Agent 实际调用的工具允许等价工具如 Agent 用 grep 代替 search_code视为等价分场景基线单一工具场景只有1个合适的工具≥ 95%多工具场景2-3个都合理选到任一合理工具 ≥ 90%需特定工具的场景只有1个正确≥ 85%指标 2参数准确率定义工具调用的参数是否完全正确评分方式非0/1而是分档3分参数完全正确2分核心参数正确可选参数有出入但不影响结果1分核心参数部分错误但方向对0分参数完全错误或缺失必要参数示例参考答案read_file(pathsrc/auth/login.ts, encodingutf-8)Agent调用read_file(pathsrc/auth/login.ts)→ 2分缺了 encoding 但不影响读取指标 3调用链效率定义完成同一任务Agent 调用工具的次数 vs 最优次数计算最小必要调用次数 / Agent 实际调用次数解读效率 1.0 → Agent 做了多余的工具调用浪费时间和费用效率 1.0 → Agent 调用次数最优效率 0.5 → Agent 用了最优次数2倍的工具调用生产基线≥ 0.6允许有一些探索性调用工具调用评测示例def evaluate_tool_call_chain(agent_trace, reference_trace): 评测 Agent 的工具调用链 agent_trace: [{tool:read_file,args:{path:...}}, ...] reference_trace: 标注的最优调用链 score { tool_selection: 0, # 工具选择分 parameter_accuracy: 0, # 参数准确分 chain_efficiency: 0, # 链效率分 } # 工具选择逐步骤比对 selection_correct 0 for step in agent_trace: if step[tool] in allowed_tools_for_step(reference_trace, step): selection_correct 1 score[tool_selection] selection_correct / len(agent_trace) # 参数准确率分档打分 param_scores [] for step in agent_trace: ref find_matching_step(reference_trace, step) if ref: param_scores.append(score_params(step[args], ref[args])) score[parameter_accuracy] sum(param_scores) / len(param_scores) # 链效率 score[chain_efficiency] len(reference_trace) / len(agent_trace) return score2.4 维度三规划与推理Agent 的思考质量——从接收到目标到开始执行之间的决策链路。指标 1规划合理性定义Agent 制定的执行计划是否合理评测方式人工/LLM-as-Judge 审阅 Agent 的 thinking/planning 输出评分标准1-5分5分计划完整、步骤清晰、考虑了异常情况3分计划基本合理但遗漏了边缘情况1分计划有根本性错误按此执行必然失败指标 2死循环率 Agent 特有指标定义Agent 陷入无限循环反复调同一工具、无法跳出决策循环的比例检测方式连续 5 次调用同一工具且参数相同 → 判定死循环上下文窗口内出现 3 次以上相同决策模式 → 判定死循环Agent 自身发出我无法完成信号 → 不算死循环正确行为生产级红线 2% 必须修复指标 3错误恢复率定义Agent 在工具调用失败后能否成功恢复并最终完成任务计算从错误中恢复并最终成功的任务数 / 遇到错误的任务总数场景示例Task: 读取 config.json 并修改端口号 Agent: read_file(config.json) → 文件不存在 Agent: search_file(config*) → 找到 config.yaml Agent: read_file(config.yaml) → 成功 → 判定遇到了错误但成功恢复生产基线≥ 60%遇到错误后仍能完成任务的概率2.5 维度四SubAgent 协作当 Agent 需要并行处理多个子任务时SubAgent 的创建和协作质量直接影响效率。指标 1SubAgent 创建时机合理性定义Agent 在适当的时候创建了 SubAgent在不需要的时候没有创建评测方式需要并行但没用 → 扣分不需要但创建了 → 扣分用了但不如自己干 → 扣分判定应该并行的场景独立模块搜索前端 后端 数据库独立文件分析多个不相关文件多维度审查安全 性能 规范判定不该并行的场景简单搜索单文件单关键词强依赖步骤必须先找到文件再分析结果需要实时交互判断的指标 2结果整合质量定义主 Agent 是否完整、准确地汇总了所有 SubAgent 的结果评测方式检查主 Agent 的最终输出是否① 包含了所有 SubAgent 的关键发现② 没有重复或矛盾的信息③ SubAgent A → SubAgent B 的依赖传递正确④ 如有 SubAgent 失败主 Agent 是否做了兜底处理2.6 维度五安全与效率安全指标危险操作率定义Agent 执行了危险操作rm -rf、drop table、force push的比例目标0%检查是否在操作前向用户确认是否有只读模式幻觉引入率定义Agent 在任务执行中引入的虚假信息比例Agent 特有场景编造不存在的 API 接口虚构文件内容读文件后编造了不存在的代码错误理解工具返回结果基线≤ 3%效率指标平均任务完成时间从收到任务到返回最终结果的时间分场景基线简单任务 30s复杂任务 5min平均费用/任务包括 API 调用费用 工具执行费用需要持续监控趋势Token 效率完成任务消耗的 Token 数如果改了一版 PromptToken 消耗翻倍但质量只提升 5% → 值得讨论三、Agent 评测方法3.1 评测数据集Agent 需要专属测试集通用 BenchmarkMMLU、HumanEval只能测基础能力Agent 需要端到端任务测试集。Agent 评测集的三层设计Layer 1单工具任务集覆盖基础工具调用规模200-500 个任务类型read_file 类读取 package.json告诉我项目名search 类找到所有使用了 useState 的组件execute 类运行 npm test 并告诉我结果用途回归测试每次变更必跑Layer 2多工具链任务集覆盖规划和编排规模100-200 个任务类型搜索→读取→分析找到认证相关代码分析安全风险编辑→验证修改配置文件然后运行测试验证SubAgent 类同时审查前端和后端代码质量用途核心评测决定能否上线Layer 3对抗/边界任务集覆盖异常和边界规模50-100 个任务类型工具不可用用 tool_x 做Ytool_x 不存在文件不存在修改不存在的文件权限不足删除系统文件超长任务需要 20 步的复杂任务用途安全评测 鲁棒性测试3.2 Agent 任务标注格式{ task_id: agent-eval-001, category: multi-tool-chain, difficulty: medium, context: { project: nodejs-web-app, files: [src/auth.ts], constraints: [] }, instruction: 分析项目的认证逻辑找出所有安全问题并生成修复报告, expected_outcome: { type: file_created, must_contain: [XSS漏洞, CSRF防护], must_not_contain: [删库], files_expected: [security-report.md] }, reference_trace: [ {tool: search_code, args: {query: auth}}, {tool: read_file, args: {path: src/auth/login.ts}} ], key_tools: [search_code, read_file] }3.3 LLM-as-JudgeAgent 任务评测的核心引擎由于 Agent 的输出是非确定性的不同路径可能都对LLM-as-Judge 是做 Agent 评测最实用的方式。模式 1结果评判最常用不看执行路径只看最终结果是否符合预期。Judge Prompt 你是一个Agent评测员。给定一个编程任务和Agent的执行结果 判断结果是否符合任务要求。 任务{instruction} 预期结果要点{expected_outcome} Agent输出{agent_output} 请判断 1. 任务是否完成完成/部分完成/未完成 2. 输出是否包含预期要点 3. 整体质量评分1-5分 4. 评分理由模式 2工具链评判评估 Agent 的工具使用是否合理。Judge Prompt 以下是Agent完成任务的工具调用记录。请评估 1. 工具选择是否合理合理/基本合理/不合理 2. 是否有冗余调用有/无如有请列出 3. 是否有更好的工具选择有/无如有请说明 4. 整体效率评分1-5分模式 3对比评判A/B实验用两个 Agent 执行同一任务判断哪个更好。Judge Prompt 以下两个Agent执行了相同的任务。请比较并判断哪个更好。 考虑因素 - 最终结果质量 - 执行效率步骤数、时间 - 错误处理能力 - 输出可用性 哪个Agent的表现更好A / B / 平局3.4 自动化回归测试# Agent 评测自动化的核心流程 class AgentEvaluator: def __init__(self, test_suite, judge_modelgpt-4o): self.test_suite test_suite # Agent评测集 self.judge_model judge_model def run_full_evaluation(self, agent_config): 运行完整评测 results { task_success_rate: 0, tool_accuracy: 0, planning_score: 0, efficiency_score: 0, details: [] } for task in self.test_suite: # 1. 让 Agent 执行任务 trace self.run_agent_task(agent_config, task) # 2. 用 Judge 评判结果 outcome_judge self.judge_outcome(task, trace.final_output) tool_judge self.judge_tool_chain(task, trace.tool_calls) planning_judge self.judge_planning(task, trace.planning) # 3. 汇总 results[details].append({ task_id: task[task_id], outcome: outcome_judge, tools: tool_judge, planning: planning_judge, trace: trace }) # 4. 计算聚合指标 results[task_success_rate] self.calc_success_rate(results) results[tool_accuracy] self.calc_tool_accuracy(results) return results def run_agent_task(self, agent_config, task): 执行单个 Agent 任务记录完整 trace # 启动 Agent注入任务 # 记录每一步的 tool_call / tool_result / thinking # 检测死循环超过最大步数或重复调用 # 返回完整 trace pass
AI Agent 评测指南上从指标设计到准出标准你的 Agent 能自主规划、调用工具、创建 SubAgent 并行干活——看起来很强大。但上线一周后用户反馈 Agent 有时候死循环经常选错工具10次里有3次任务没完成。单次体验看不出问题评测体系才能暴露真相。这篇文章围绕 AI Agent 业务场景系统拆解评测的三个核心问题测什么Agent 专属指标体系、怎么测自动化LLM-as-Judge人工、什么时候算通过分级准出标准。一、Agent 评测为什么比对话评测难得多普通 LLM 评测只关心回答好不好。Agent 评测要关心事有没有办成——这中间多了工具调用、多步规划、错误恢复、SubAgent 协作。Agent 评测的五个独特挑战1. 评测的是任务链而非单次回答普通 LLM用户问 → 模型答 → 评判答案质量Agent用户给目标 → Agent 规划 → 调用工具A → 读结果 → 调用工具B → 发现错误 → 修正 → 调用工具C → 返回结果评测需要看从收到目标到完成任务的完整链条2. 工具调用的正确性难以自动判定模型选了read_file(src/auth.ts)但正确答案应该是read_file(src/auth/login.ts)——算对还是算错工具选对了但参数不够精确又怎么打分3. Agent 的犯错和修复是正常行为好的 Agent 不是不犯错而是犯错后能自己发现并修复。如何评测从错误中恢复的能力4. SubAgent 协作的评测是空白地带主 Agent 是否在正确的时机创建了 SubAgentSubAgent 的结果是否被正确整合并行 SubAgent 的调度是否合理5. 同一个任务不同 Agent 可能有完全不同的正确路径任务找出项目中的安全漏洞并修复Agent A 先全局搜索 → 逐个分析 → 生成修复Agent B 先看配置文件 → 分析依赖 → 检查代码两条路径都可能是正确的——不能按路径评判只能按结果评判对比维度对话 LLM 评测Agent 评测评测对象单轮/多轮回复多步任务执行链核心问题答得好不好事办没办成评测粒度单次对话完整任务含工具调用链正确性答案 vs 参考答案任务结果 vs 预期结果路径多样性低表达不同但意思相同高不同工具组合可达同一目标错误处理基本不考虑核心评测维度二、Agent 专属评测指标体系2.1 五维 Agent 评测框架① 任务完成度事办没办成任务成功率 / 目标达成率 / 输出可用率② 工具使用质量工具用没用对工具选择准确率 / 参数准确率 / 调用链效率③ 规划与推理脑子清不清楚规划合理性 / 步骤效率 / 死循环率 / 错误恢复率④ SubAgent 协作帮手派没派对SubAgent 创建时机 / 并行合理性 / 结果整合质量⑤ 安全与效率不出事、不太慢危险操作率 / 幻觉引入率 / 平均完成时间 / 费用2.2 维度一任务完成度这是 Agent 评测的北极星指标——其他一切最终都要服务于事办没办成。指标 1端到端任务成功率最重要定义Agent 从收到任务目标到返回可用结果的完整成功率计算成功任务数 / 总任务数判定成功的三个层次L1 - 严格成功输出完全匹配预期零人工修正即可用例生成的代码能直接运行并通过所有测试L2 - 基本成功输出核心部分正确需少量人工修正例代码核心逻辑对但缺了一行 importL3 - 失败输出无法使用或 Agent 中途报错放弃生产级基线代码生成 AgentL1 ≥ 40%, L1L2 ≥ 75%文档写作 AgentL1 ≥ 60%, L1L2 ≥ 85%数据分析 AgentL1 ≥ 50%, L1L2 ≥ 80%指标 2目标达成率更细粒度定义用户目标中每个子目标的完成情况示例帮我审查代码安全并生成报告子目标1找到安全漏洞 → 找到3个预期2-4个子目标2生成修复建议 → 每个漏洞都有建议子目标3输出Markdown报告 → 格式正确→ 目标达成率 3/3 100%指标 3输出可用率定义Agent 输出中用户可以直接使用不需修改的比例对于代码 Agent可运行率对于文档 Agent可直接发布率对于操作 Agent操作结果正确率2.3 维度二工具使用质量Agent 的核心能力就是知道什么时候用什么工具。工具用错了任务必然失败。指标 1工具选择准确率定义Agent 选择的工具是否与参考答案中的最优工具一致评测方法对每个任务步骤标注应该用的工具比对 Agent 实际调用的工具允许等价工具如 Agent 用 grep 代替 search_code视为等价分场景基线单一工具场景只有1个合适的工具≥ 95%多工具场景2-3个都合理选到任一合理工具 ≥ 90%需特定工具的场景只有1个正确≥ 85%指标 2参数准确率定义工具调用的参数是否完全正确评分方式非0/1而是分档3分参数完全正确2分核心参数正确可选参数有出入但不影响结果1分核心参数部分错误但方向对0分参数完全错误或缺失必要参数示例参考答案read_file(pathsrc/auth/login.ts, encodingutf-8)Agent调用read_file(pathsrc/auth/login.ts)→ 2分缺了 encoding 但不影响读取指标 3调用链效率定义完成同一任务Agent 调用工具的次数 vs 最优次数计算最小必要调用次数 / Agent 实际调用次数解读效率 1.0 → Agent 做了多余的工具调用浪费时间和费用效率 1.0 → Agent 调用次数最优效率 0.5 → Agent 用了最优次数2倍的工具调用生产基线≥ 0.6允许有一些探索性调用工具调用评测示例def evaluate_tool_call_chain(agent_trace, reference_trace): 评测 Agent 的工具调用链 agent_trace: [{tool:read_file,args:{path:...}}, ...] reference_trace: 标注的最优调用链 score { tool_selection: 0, # 工具选择分 parameter_accuracy: 0, # 参数准确分 chain_efficiency: 0, # 链效率分 } # 工具选择逐步骤比对 selection_correct 0 for step in agent_trace: if step[tool] in allowed_tools_for_step(reference_trace, step): selection_correct 1 score[tool_selection] selection_correct / len(agent_trace) # 参数准确率分档打分 param_scores [] for step in agent_trace: ref find_matching_step(reference_trace, step) if ref: param_scores.append(score_params(step[args], ref[args])) score[parameter_accuracy] sum(param_scores) / len(param_scores) # 链效率 score[chain_efficiency] len(reference_trace) / len(agent_trace) return score2.4 维度三规划与推理Agent 的思考质量——从接收到目标到开始执行之间的决策链路。指标 1规划合理性定义Agent 制定的执行计划是否合理评测方式人工/LLM-as-Judge 审阅 Agent 的 thinking/planning 输出评分标准1-5分5分计划完整、步骤清晰、考虑了异常情况3分计划基本合理但遗漏了边缘情况1分计划有根本性错误按此执行必然失败指标 2死循环率 Agent 特有指标定义Agent 陷入无限循环反复调同一工具、无法跳出决策循环的比例检测方式连续 5 次调用同一工具且参数相同 → 判定死循环上下文窗口内出现 3 次以上相同决策模式 → 判定死循环Agent 自身发出我无法完成信号 → 不算死循环正确行为生产级红线 2% 必须修复指标 3错误恢复率定义Agent 在工具调用失败后能否成功恢复并最终完成任务计算从错误中恢复并最终成功的任务数 / 遇到错误的任务总数场景示例Task: 读取 config.json 并修改端口号 Agent: read_file(config.json) → 文件不存在 Agent: search_file(config*) → 找到 config.yaml Agent: read_file(config.yaml) → 成功 → 判定遇到了错误但成功恢复生产基线≥ 60%遇到错误后仍能完成任务的概率2.5 维度四SubAgent 协作当 Agent 需要并行处理多个子任务时SubAgent 的创建和协作质量直接影响效率。指标 1SubAgent 创建时机合理性定义Agent 在适当的时候创建了 SubAgent在不需要的时候没有创建评测方式需要并行但没用 → 扣分不需要但创建了 → 扣分用了但不如自己干 → 扣分判定应该并行的场景独立模块搜索前端 后端 数据库独立文件分析多个不相关文件多维度审查安全 性能 规范判定不该并行的场景简单搜索单文件单关键词强依赖步骤必须先找到文件再分析结果需要实时交互判断的指标 2结果整合质量定义主 Agent 是否完整、准确地汇总了所有 SubAgent 的结果评测方式检查主 Agent 的最终输出是否① 包含了所有 SubAgent 的关键发现② 没有重复或矛盾的信息③ SubAgent A → SubAgent B 的依赖传递正确④ 如有 SubAgent 失败主 Agent 是否做了兜底处理2.6 维度五安全与效率安全指标危险操作率定义Agent 执行了危险操作rm -rf、drop table、force push的比例目标0%检查是否在操作前向用户确认是否有只读模式幻觉引入率定义Agent 在任务执行中引入的虚假信息比例Agent 特有场景编造不存在的 API 接口虚构文件内容读文件后编造了不存在的代码错误理解工具返回结果基线≤ 3%效率指标平均任务完成时间从收到任务到返回最终结果的时间分场景基线简单任务 30s复杂任务 5min平均费用/任务包括 API 调用费用 工具执行费用需要持续监控趋势Token 效率完成任务消耗的 Token 数如果改了一版 PromptToken 消耗翻倍但质量只提升 5% → 值得讨论三、Agent 评测方法3.1 评测数据集Agent 需要专属测试集通用 BenchmarkMMLU、HumanEval只能测基础能力Agent 需要端到端任务测试集。Agent 评测集的三层设计Layer 1单工具任务集覆盖基础工具调用规模200-500 个任务类型read_file 类读取 package.json告诉我项目名search 类找到所有使用了 useState 的组件execute 类运行 npm test 并告诉我结果用途回归测试每次变更必跑Layer 2多工具链任务集覆盖规划和编排规模100-200 个任务类型搜索→读取→分析找到认证相关代码分析安全风险编辑→验证修改配置文件然后运行测试验证SubAgent 类同时审查前端和后端代码质量用途核心评测决定能否上线Layer 3对抗/边界任务集覆盖异常和边界规模50-100 个任务类型工具不可用用 tool_x 做Ytool_x 不存在文件不存在修改不存在的文件权限不足删除系统文件超长任务需要 20 步的复杂任务用途安全评测 鲁棒性测试3.2 Agent 任务标注格式{ task_id: agent-eval-001, category: multi-tool-chain, difficulty: medium, context: { project: nodejs-web-app, files: [src/auth.ts], constraints: [] }, instruction: 分析项目的认证逻辑找出所有安全问题并生成修复报告, expected_outcome: { type: file_created, must_contain: [XSS漏洞, CSRF防护], must_not_contain: [删库], files_expected: [security-report.md] }, reference_trace: [ {tool: search_code, args: {query: auth}}, {tool: read_file, args: {path: src/auth/login.ts}} ], key_tools: [search_code, read_file] }3.3 LLM-as-JudgeAgent 任务评测的核心引擎由于 Agent 的输出是非确定性的不同路径可能都对LLM-as-Judge 是做 Agent 评测最实用的方式。模式 1结果评判最常用不看执行路径只看最终结果是否符合预期。Judge Prompt 你是一个Agent评测员。给定一个编程任务和Agent的执行结果 判断结果是否符合任务要求。 任务{instruction} 预期结果要点{expected_outcome} Agent输出{agent_output} 请判断 1. 任务是否完成完成/部分完成/未完成 2. 输出是否包含预期要点 3. 整体质量评分1-5分 4. 评分理由模式 2工具链评判评估 Agent 的工具使用是否合理。Judge Prompt 以下是Agent完成任务的工具调用记录。请评估 1. 工具选择是否合理合理/基本合理/不合理 2. 是否有冗余调用有/无如有请列出 3. 是否有更好的工具选择有/无如有请说明 4. 整体效率评分1-5分模式 3对比评判A/B实验用两个 Agent 执行同一任务判断哪个更好。Judge Prompt 以下两个Agent执行了相同的任务。请比较并判断哪个更好。 考虑因素 - 最终结果质量 - 执行效率步骤数、时间 - 错误处理能力 - 输出可用性 哪个Agent的表现更好A / B / 平局3.4 自动化回归测试# Agent 评测自动化的核心流程 class AgentEvaluator: def __init__(self, test_suite, judge_modelgpt-4o): self.test_suite test_suite # Agent评测集 self.judge_model judge_model def run_full_evaluation(self, agent_config): 运行完整评测 results { task_success_rate: 0, tool_accuracy: 0, planning_score: 0, efficiency_score: 0, details: [] } for task in self.test_suite: # 1. 让 Agent 执行任务 trace self.run_agent_task(agent_config, task) # 2. 用 Judge 评判结果 outcome_judge self.judge_outcome(task, trace.final_output) tool_judge self.judge_tool_chain(task, trace.tool_calls) planning_judge self.judge_planning(task, trace.planning) # 3. 汇总 results[details].append({ task_id: task[task_id], outcome: outcome_judge, tools: tool_judge, planning: planning_judge, trace: trace }) # 4. 计算聚合指标 results[task_success_rate] self.calc_success_rate(results) results[tool_accuracy] self.calc_tool_accuracy(results) return results def run_agent_task(self, agent_config, task): 执行单个 Agent 任务记录完整 trace # 启动 Agent注入任务 # 记录每一步的 tool_call / tool_result / thinking # 检测死循环超过最大步数或重复调用 # 返回完整 trace pass
