97-Agent面试题精讲：评测篇
前言
如何评估一个 Agent 的任务完成率？
我一般会先确定这个 Agent 什么情况下算“完成任务”，然后准备一批测试问题，让 Agent 批量跑一遍，看有多少任务真正完成了。
最核心的就是看任务完成率，比如测试 100 个任务，成功完成了 90 个，那完成率就是 90%。
但我不会只看最后的答案，还会看它工具有没有调用对、参数对不对、执行过程有没有走歪、最终答案对不对。同时也会关注它用了多少次模型、调用了多少次工具、花了多长时间以及用了多少 Token。
对于一些结果比较明确的任务，可以直接写程序自动判断；如果是一些比较开放的问题，比如总结、问答，就可以让另一个 LLM 当“裁判”来打分，再抽一些结果人工检查。
最后把这些测试任务保存下来，每次修改 Prompt、模型或者 Agent 流程之后，重新跑一遍，看看完成率有没有提升，有没有把原来能做对的任务改坏。
常用的 Agent 基准测试集有哪些？什么场景下实用哪个
| Benchmark | 主要测什么 | 适合什么场景 |
|---|---|---|
| GAIA | 综合任务、工具使用、多步推理 | 通用 Agent |
| τ-bench | 多轮对话 + 工具调用 + 业务规则 | 客服、订单、业务 Agent |
| AgentBench | 多种 Agent 环境下的综合能力 | 通用 Agent 能力对比 |
| SWE-bench | 根据真实 GitHub Issue 修改代码 | Coding Agent |
| WebArena | 在真实网站环境完成任务 | Web Agent、浏览器 Agent |
| BrowserGym | 浏览器环境中的任务执行 | Browser / Web Agent |
| OSWorld | 操作电脑、GUI、办公软件 | Computer Use Agent |
| ToolBench | 工具调用、API 使用能力 | Tool Calling Agent |
| BFCL | Function Calling 能力 | 工具调用 / Function Calling |
常见的 Agent Benchmark 有 GAIA、τ-bench、AgentBench、SWE-bench、WebArena、OSWorld、ToolBench 和 BFCL 等。
我觉得主要还是要根据 Agent 的场景来选择。比如通用 Agent 可以用 GAIA，业务流程和客服类 Agent 比较适合 τ-bench，Coding Agent 用 SWE-bench，Web Agent 用 WebArena，Computer Use Agent 用 OSWorld。如果主要评估 Function Calling 和工具调用能力，可以看 BFCL 或 ToolBench。
实际项目中，我不会完全依赖这些公开 Benchmark，还会根据自己的业务场景构建一套 Evaluation Dataset，因为公开 Benchmark 和真实业务场景不一定完全匹配。
人工评估 vs 自动评估：各自的优缺点？
人工评估优点是准确、能够理解复杂任务，但成本高、速度慢，而且有主观性；自动评估效率高、成本低，适合大规模和持续回归测试，但准确性和泛化能力有限。所以实际项目一般是自动评估为主，人工抽样校验，用两者结合来保证评估结果的可靠性。
如何设计端到端的 Agent 测试用例？
端到端 Agent 测试，我会先根据业务定义任务成功标准，然后围绕真实用户场景设计测试集，不只覆盖正常流程，也会覆盖参数缺失、Tool 异常、权限、边界情况和多轮对话。测试时从用户输入开始，完整跑一遍 Agent，检查最终任务是否完成，同时检查 Tool 调用、参数、执行轨迹、异常处理以及耗时和 Token 成本。最后把这些用例沉淀成 Evaluation Dataset，每次修改 Prompt、模型或者 Workflow 后重新执行，做回归测试，确保 Agent 效果没有下降。
工具调用准确率如何量化？
工具调用准确率我一般不会只看一个指标，而是拆成工具选择准确率、参数准确率和工具执行成功率。比如先判断 Agent 有没有选对 Tool，再判断参数是否正确，最后看 Tool 是否成功执行。对于 Agent 整体效果，还会进一步看它能不能通过正确的 Tool 调用最终完成任务。
所以可以分别统计 Selection Accuracy、Argument Accuracy、Tool Success Rate，以及最终的 Task Success Rate。对于明确的工具调用任务，这些指标都可以通过程序自动校验。
如何模拟真实用户与 Agent 的交互？
模拟真实用户，我会先定义真实业务场景和用户目标，然后覆盖多轮对话、模糊表达、需求变更、输入错误以及 Tool 异常等情况。除了人工设计测试用例，也可以用另一个 LLM 模拟用户，根据 Agent 的回复动态生成下一轮输入，让 Agent 真正跑完整个任务流程。最后再从任务完成率、Tool 调用、上下文理解、异常恢复以及成本和延迟等方面进行评估。
多轮对话中的上下文一致性如何评估？
多轮对话的上下文一致性，我主要看 Agent 能不能正确记住前面的关键信息、前后回答有没有冲突，以及用户修改信息后能不能以最新信息为准。
实际评估时，我会设计多轮对话测试集，提前定义每一轮应该维护的状态，然后检查 Agent 在后续对话中是否正确使用这些信息。除了正常场景，还会重点测试长对话、信息修改、用户纠正、指代和信息冲突等情况，最后统计上下文一致率。