Agent Evaluation & Benchmarking/ 智能体评估与基准测试

评估一个LLM和评估一个Agent是完全不同的两件事——LLM看输出质量就够了，但Agent还要看任务完成率（端到端成功了吗？）、工具调用准确度（该调哪个API、参数对不对？）、推理链质量（走对路了吗，还是绕了远路？）。没有科学的评估体系，Agent开发就是在「盲飞」——靠感觉调prompt，永远不知道是改好了还是改坏了。

Agent评估需要三个维度的组合，单一维度无法全面衡量Agent能力：

**1. 端到端任务成功率（Task-Level / End-to-End）**

• 最接近用户感知的指标：给Agent一个完整任务（如「在GitHub上为这个issue找到修复代码并提交PR」），看它能否从头到尾独立完成

• 典型基准：SWE-bench（1964个真实GitHub issue，Agent需定位代码→写patch→通过测试）、WebArena（模拟电商/社交/论坛网站上的真实任务）、GAIA（需要推理+多工具协同的多模态问答）

• 指标：Success Rate（任务完成率）、Pass@k（k次尝试内至少一次成功的概率）

**2. 组件级能力评估（Component-Level）**

• 拆解Agent的每个子能力独立评测：工具选择准确率（该用search却用了read_file？）、参数填充正确率、规划质量（分解的子任务是否合理）

• 典型工具：BFCL（Berkeley Function Calling Leaderboard，评测模型原生函数调用能力的标准基准）、τ-bench（工具使用基准，覆盖电商/航空等真实API交互场景）

• 指标：Tool Selection Accuracy、Argument F1、Plan Coherence Score

**3. 轨迹级效率评估（Trajectory-Level）**

• 不只是「最终做没做对」，还要看「做得漂不漂亮」：同样的任务，Agent A走了3步、Agent B绕了15步，两者成本可能差5倍

• 评估维度：步骤数（steps taken）、Token消耗、工具调用次数、无效操作占比（调了工具但结果未被使用）

• 指标：Step Efficiency（完成任务所需的最少步骤比）、Cost per Task、Action Precision（有效工具调用/总工具调用）

• 测试一：SWE-bench 真实代码修复评估

• 操作：从 SWE-bench Lite（300个精选issue，更轻量）中抽取20个issue，让Agent（如Devin/OpenHands/自建Agent）逐个尝试修复。每个issue提供代码仓库+问题描述，Agent需返回patch文件。用SWE-bench官方评测脚本（基于Docker执行测试）验证patch是否通过

• 工具：SWE-bench（https://www.swebench.com/）+ SWE-bench Lite子集（https://github.com/princeton-nlp/SWE-bench）+ OpenHands（https://github.com/All-Hands-AI/OpenHands）作为Agent框架

• 指标：Resolved Rate（测试通过的issue占比）≥ 目标基线（如SWE-bench Lite当前SOTA约40-50%，自建Agent争取 ≥ 20%），平均修复时间 ≤ 10分钟/issue

• 测试二：BFCL 函数调用准确度评测

• 操作：用 BFCL 数据集（涵盖单函数/多函数/并行调用等7类场景，共1700+测试用例）评测Agent的函数选择与参数填充能力。在自己的Agent框架中接入BFCL评测脚本，对比切换不同底层模型（GPT-4o vs Claude vs DeepSeek）的函数调用准确度差异

• 工具：Berkeley Function Calling Leaderboard（https://gorilla.cs.berkeley.edu/leaderboard.html）+ BFCL GitHub仓库（https://github.com/ShishirPatil/gorilla/tree/main/berkeley-function-call-leaderboard）

• 指标：Overall Accuracy ≥ 80%（SOTA现已超90%），AST/Executable Evaluation通过率（实际可执行的函数调用占比），Simple vs Multiple vs Parallel 三类场景的准确度差异 ≤ 15%

• 测试三：自建回归测试套件（Agent Regression Suite）

• 操作：选取团队Agent最常处理的20个真实用户场景（如「查天气+订机票」「分析财报+生成摘要」「Debug某个错误日志」），录制为标准化测试用例（固定输入→期望输出/行为）。每次修改prompt、更新工具定义、切换模型后，运行全部20个用例对比通过率变化

• 工具：pytest（https://pytest.org）+ 自定义Agent harness（封装Agent调用为pytest fixture）+ LangSmith（https://smith.langchain.com）记录每次运行的完整轨迹用于diff对比

• 指标：回归通过率 ≥ 95%（修改后不应降低之前已通过的用例），新版本首次通过率变化趋势（上升/下降），轨迹步骤数变化（是否引入了冗余操作）

1. **过度拟合基准测试（Benchmark Overfitting）**：SWE-bench高分 ≠ Agent真能修bug。很多团队针对SWE-bench做特化——如硬编码「先找最近commit → 看diff → 模仿修改」策略，但这在真实代码库中面对不熟悉的项目结构完全失效。正确做法：基准测试只作为「健康检查」的底线，真正的评估来自线上真实任务的持续监控（production shadow evaluation）。

1. **LLM-as-Judge的偏见陷阱**：用GPT-4评估自建Agent的轨迹质量时，GPT-4天然倾向于给「和自己风格相似」的答案打高分（position bias）。同样一个答案放在第一位还是第二位，评分可能差20%。解决：① 交叉Judge——用Claude评估GPT-4o Agent的输出、用GPT-4o评估Claude Agent的输出；② 位置交换——同一对答案正反各评一次取平均；③ 混合人工抽检——每50条LLM-as-Judge结果随机抽3条人工复核。

1. **忽视了「什么都不做」也是正确行为**：很多Agent评估只看最终输出是否正确，但忽略了Agent是否做了不该做的事。例如Agent被问到「帮我查一下今天天气」，它先去读你的私人文件、再搜你的联系人——虽然最终天气报对了，但中间步骤是隐私泄露。评估体系必须包含「过度行动检测」（over-action detection）：检查Agent的工具调用是否最小必要化，不该碰的数据是否被访问。

• SWE-bench：代码Agent的事实标准评测基准: https://www.swebench.com/

• Berkeley Function Calling Leaderboard (BFCL)：函数调用能力权威排行榜: https://gorilla.cs.berkeley.edu/leaderboard.html

• GAIA：多模态Agent综合推理评测（Meta/Facebook AI提出）: https://huggingface.co/gaia-benchmark

• WebArena：真实Web环境下的Agent评测平台: https://webarena.dev/

• LangSmith Evaluation：生产级Agent轨迹评测与对比: https://docs.smith.langchain.com/evaluation