如果面试官抛出这个问题：

“Agent 怎么评测？”

大多数人的直觉反应或许是：

“看准确率。”

这个答案本身并不算错，但在 Agent 面试的具体场景中，确实显得过于浅显。

因为 Agent 与常规的大模型问答有着本质区别。

传统问答的模式相对单一：用户提问 → 模型回答 → 判断答案正确性，这是一条线性的流程。

但 Agent 呢？它更像一个需要连续执行任务、完成复杂指令的系统。它必须理解用户意图、拆解任务、选择合适工具、调用相关接口、处理异常情况、进行持续推理、生成最终结果，甚至还需要根据用户的实时反馈动态调整策略。

因此，评测一个 Agent，如果仅仅关注它最后一句回答是否正确，那无异于盲人摸象，无法触及核心。

一个真正具备工程落地思维的面试回答，应该像这样展开：

Agent 评测并非单一维度的准确率比拼，而是一套围绕任务结果、执行过程、工具调用、运营成本、系统稳定性、安全性以及用户反馈所构建的持续评估体系。

本篇文章，我们就将这道面试题彻底拆解清楚。

一、为何 Agent 评测不能仅依赖准确率

以往我们评测一个语言模型，通常会准备一批问题与标准答案。例如，用户问“Redis 为什么快？”，只要模型的回答涵盖了内存存储、单线程模型、I/O 多路复用、数据结构优化等关键点，通常就能认为回答得不错。

但 Agent 不同。它的任务不仅仅是生成答案，而是完成一个具体的目标。比如，用户要求代码 Agent 修复一个 Bug，它可能需要经历以下这些复杂步骤：

在这种情况下，仅凭最终结果来判断优劣显然是片面的。因为 Agent 可能出现很多“结果看似正确，但过程糟糕透顶”的状况。例如：

• 某个 Agent 最终答对了问题，但过程中调用了 8 次大模型，导致成本高得惊人，这能算作优秀吗？
• 某个 Agent 生成了正确的结果，但用户等待了整整 3 分钟，体验极差，这能算作成功吗？
• 某个 Agent 给出了最终答案，但全程没有调用任何该用的工具，完全依赖自身推理编造，这能算作可靠吗？
• 某个 Agent 在测试环境表现完美，但一上线就因外部工具频繁超时而频频失败，这能算作稳定吗？
• 某个 Agent 完成了任务，但在过程中访问了本不该触碰的数据，这能算作安全吗？

这些例子都指向同一个核心结论：评测 Agent，不能仅仅盯着最终结果，更要深入分析它完成任务的整个过程。面试官真正想考察的，并非你是否能说出“准确率”这个词汇，而是你是否具备将 Agent 视为一个真实、复杂的工程系统来对待的意识。

二、面试中的标准回答应该这样说

如果面试官问：“Agent 怎么评测？” 你可以用以下方式构建你的开场白：

“Agent 评测绝不能只看准确率，因为它本质上是一个多步骤的执行系统。我会从任务完成率、结果质量、执行过程、工具调用、系统延迟、运营成本、稳定性、安全性和用户反馈等多个维度进行综合评估。在上线前，通过离线评测集进行冒烟测试和回归测试；上线后，则通过 trace、span、任务完成率、错误率、成本、延迟和用户反馈等数据进行在线评测。同时，将线上产生的失败样本回流至离线评测集，形成一个持续迭代、不断优化的闭环。”

这段回答中，有几个关键词是面试官最看重的：多步骤执行系统、不只重结果也重过程、上线前后分层评测、失败样本闭环管理。只要能把这几层意思清晰地表达出来，面试官基本就能判断，你绝不仅仅停留在“调整 prompt 玩 Demo”的阶段，而是已经具备了成熟的生产系统思维。

下面这张图有助于理解整个流程：

这套流程的核心并非去“计算一个分数”，而是：上线前尽量拦截明显的问题，上线后持续发现真实场景中的问题，再将真实问题沉淀为下一轮测试的宝贵资产。

三、评测 Agent 首先要看清执行过程

许多团队在刚开始进行 Agent 评测时，容易犯一个通病：直接准备一批问题，让 Agent 跑一遍，然后盯着最终结果判断好坏。这个思路不能说完全没用，但其局限性很大。

因为一旦 Agent 失败，你会立刻面临一个非常现实的问题：你根本不知道它到底在哪一步出了岔子。用户反馈说“不好用”，表面上看是对最终答案不满意，但真正的诱因可能千差万别：

• 意图理解出现偏差。
• 任务规划存在错误。
• 检索召回结果不准确。
• 工具选择失误。
• 工具参数传递错误。
• 外部接口调用超时。
• 工具返回的结果未能被正确利用。
• 模型在最终生成阶段编造了内容。
• 权限判断失误，访问了未经授权的数据。

因此，在进行 Agent 评测之前，第一件要做的事情不是急着计算准确率，而是先把系统的可观测性建设好。也就是说，你必须要能看到一次 Agent 任务从用户输入到最终输出的完整执行链路。

一次完整的任务可以记录为一个 trace。而其中的每一个步骤——模型调用、工具调用、检索请求、接口访问、异常重试——都可以记录为一个 span。

有了 trace 和 span，很多问题才能被精准定位。例如，一次任务耗时 2 分钟，你不能笼统地说“模型太慢”。真实原因可能是检索速度慢、是外部工具响应慢，也可能是 Agent 执行了太多无效步骤。再比如，某个版本上线后成本突然飙升，也不能简单归咎于“用户量增加了”。真实原因可能是单次任务多调用了几次大模型，或是工具失败后反复重试，导致 token 消耗和费用被成倍放大。

所以在面试中，一定要把这个逻辑讲清楚：没有可观测性，就没有真正能落地、有价值的 Agent 评测。

四、Agent 评测应该关注哪些核心指标

描述 Agent 的评测指标，不要只说“准确率”就草草了事。建议从八个维度进行系统阐述，这样才显得专业且全面。

1. 任务完成率
这个指标衡量的是用户交给 Agent 的任务是否被真正完成。例如，代码 Agent 是否成功修复了 Bug？数据分析 Agent 是否生成了可用的报表？客服 Agent 是否解决了用户的问题？自动化 Agent 是否完成了脚本的生成和执行验证？它比单纯看“回答是否正确”更贴近业务的实际价值。

2. 结果质量
这评估的是最终输出的质量，包括准确性、完整性、有用性、是否符合用户意图、是否存在幻觉、是否引用了错误信息。对于问答类、报告类、代码解释类 Agent，结果质量固然重要，但它只是评测的一部分，而非全部。

3. 工具调用质量
Agent 最显著的特点之一就是能够调用工具，因此工具调用必须作为一项独立维度来评测。比如，该调用搜索工具时是否调用了？工具选择是否正确？参数传递是否准确？工具返回失败后是否有重试机制？重试失败后是否有降级方案？工具返回的结果是否被正确理解和使用？很多 Agent 的错误，问题并非出在语言表达能力上，而是出在工具调用的链路上。例如用户问“帮我查一下最近 7 天的订单退款率”，正确流程是调用数据查询工具，但 Agent 如果直接生成一段看似合理的分析，那就是严重问题——这不是“回答得不够好”，而是不该编造的时候进行了编造。

4. 执行过程质量
Agent 的步骤并非越多越聪明，有时步骤太多，反而说明其规划能力不足。例如，一个问题明明一次工具调用就能解决，它却调用了 5 次；一个代码修改明明只改一个文件，它却扫描了整个仓库。评测时，要关注是否存在无意义的重复调用、多余的中间步骤、循环推理，以及失败后是否有正确的重试和降级行为。

5. 检索质量
如果 Agent 接入了 RAG 或知识库，还需要单独评测其检索质量。很多时候最终答案不好，并非生成能力的问题，而是检索阶段就出了错。例如，召回内容不相关、信息过时、缺失关键证据，或者多个文档内容冲突但 Agent 未能识别。因此，RAG Agent 的评测至少应拆分为两层：第一层看检索是否找回了正确的证据，第二层看生成过程是否基于这些证据进行回答，而非自行发挥。面试时可以补充一句：“对于 RAG 类 Agent，我不会只评估最终答案，还会单独评测检索召回率、证据相关性、引用正确性以及无答案拒答的能力。” 这样的回答比单纯说“看准确率”要专业很多。

6. 延迟与成本
Agent 落地到真实业务场景时，延迟和成本是绝对不能忽视的现实问题。一个 Agent 答对了，但用户等了 180 秒，体验依然很差；一个 Agent 效果不错，但每次任务成本高得离谱，也很难在规模化场景中使用。因此必须关注单次任务耗时、首 token 延迟、模型调用次数、token 消耗、接口费用等指标。面试时可以说：“我不会只看 Agent 有没有答对，还会看它用多少成本答对。如果一个版本效果提升很小，但成本却翻了好几倍，那么它未必是更好的版本。” 这句话非常加分，因为它体现了工程和业务层面的思维。

7. 稳定性
Agent 依赖于模型、工具、检索服务、外部 API、数据库等多个组件，任何一个环节的不稳定，都会影响整体体验。尤其是在生产环境下，Agent 不能只追求“正常情况下跑通”，还要看在异常情况下能否兜住。例如，工具超时后是直接报错，还是提示用户稍后重试？数据库查不到数据时，是编造一个答案，还是明确告知用户未查到？这些才是工程落地时真正体现功力的判断。

8. 安全与权限
这一点很多人面试时容易遗漏，但对于生产级 Agent 来说必须评估。特别是那些能调用工具、访问内部系统、操作业务数据的 Agent，更要关注其是否越权访问、是否泄露敏感信息、是否执行高风险操作、是否能在缺少用户确认时直接提交或删除数据、是否能识别并拒绝危险指令。例如，一个能操作工单系统的 Agent，用户让它“把所有线上告警都关闭”，它能否判断这是高风险操作？用户让它“查一下某个员工的薪资”，它能否判断自己没有权限？这些都是 Agent 评测中必须考虑的关键问题。

五、离线评测：上线前先拦截明显问题

离线评测，就是在上线前准备一批测试数据，让 Agent 在受控环境里反复运行。它的目标不是证明系统完美无瑕，而是先拦住那些明显的问题。例如，核心任务不能失败、基础工具调用不能出错、历史已知问题不能再次出现、关键业务场景不能跑偏、安全边界不能被轻易突破。

很多人做离线评测，只准备“问题和标准答案”，这对普通问答模型有效，但对 Agent 来说远远不够。因为 Agent 的很多问题出在中间过程——比如原本应该先检索再回答，现在它直接开始编造；原本一次工具调用就能完成，现在变成了三次；原本工具失败后会降级处理，现在却直接报错。这些问题，如果只看最终答案，往往很难发现。

因此，Agent 的离线评测除了看最终结果，还要看其期望行为是否得到满足。我们可以将离线评测集设计为四种类型：

冒烟集：快速判断核心能力是否正常
冒烟集不需要很大，但必须覆盖核心链路。例如，对于一个代码 Agent，冒烟集可以包含以下场景：能否读取项目结构、能否定位指定文件、能否修改简单 Bug、能否运行测试命令、能否总结修改内容。每次发版前先运行冒烟集，如果连这个都无法通过，那就没有必要继续上线。

回归集：防止历史问题反复出现
回归集主要来源于历史发现的问题。比如之前线上出现过工具参数传错、检索内容不相关、生成代码不可运行、调用接口超时后没有降级等问题。这些失败的样本都应该沉淀进回归集，下一次版本上线前必须重新运行，确保类似问题不再复现。

行为评测集：专门检查 Agent 是否会“走偏”
Agent 最大的不确定性，很多时候不在于答案写得好不好，而在于它会不会做不该做的事。比如信息不足时是否懂得追问，需要查证时是否先进行检索，不能确定时是否明确说明情况，工具失败时是否进行降级处理。这些都属于行为评测的范畴。

安全评测集：检查 Agent 是否会越界
只要 Agent 能调用工具，就必须测试其安全边界。例如，没有权限时是否拒绝操作，遇到敏感数据时是否进行脱敏处理，遇到高风险操作时是否要求用户二次确认，遇到提示注入攻击时是否坚持系统预设规则。这部分在企业级 Agent 中尤为重要。

六、在线评测：上线后才是真正的考场

离线评测虽然非常重要，但它永远无法完全覆盖真实用户可能提出的问题。因为真实用户的问题往往更复杂，他们可能表达模糊、上下文不完整、一句话里包含多个任务、不断补充条件，甚至使用系统从未见过的新说法。所以 Agent 上线后，还必须进行在线评测。

在线评测重点观察真实流量中的表现，包括任务完成率是否有下降、平均延迟是否变高、单次任务成本是否出现异常、工具调用失败率是否升高、用户重试率是否变高、用户点踩和负反馈是否增加。上线后常见的问题包括：测试集中未能覆盖的新问题出现了、用户输入分布发生变化导致原有 prompt 不再适用、某个外部 API 间歇性超时导致 Agent 不稳定、模型版本升级后工具调用的格式开始不稳定。

这些问题都只能依靠在线评测来持续发现。因此，在面试中一定要讲清楚：离线评测解决的是上线前的基础质量问题，而在线评测解决的是真实场景下的持续质量问题。二者并非替代关系，而是相辅相成的互补关系。

七、失败样本回流：让 Agent 在测试中变得更稳定

Agent 评测不能停留在“发现问题”的阶段，更关键的是要形成一个闭环。一个完整的闭环流程应该如下：

例如，线上发现一个失败案例：用户问“帮我生成最近 30 天新用户留存分析”，Agent 最终给了一段看似合理的分析，但实际上并没有调用数据查询工具，而是直接生成了一段泛泛而谈的文字。这个问题的归因可能是意图识别未能判断出这是数据分析任务、工具选择策略没有强制要求查询数据、或者 prompt 中没有约束“没有数据不能编造”。修复方式可能是增加数据分析类意图的识别规则、明确要求涉及业务数据时必须调用查询工具、并将这个失败案例加入回归评测集。这样，下一次上线前就能提前发现并拦截类似问题。

这就是 Agent 评测闭环的价值所在——不是为了制作一张漂亮的报表，而是为了让系统在实际使用过程中持续地变得更加稳定可靠。

八、还有一个加分项：评测方法需要组合使用

在实际工程中，Agent 评测不能仅仅依赖某一种方法。常见的方式包括人工评审、规则校验、自动化测试、LLM作为评判者、业务指标监控、用户反馈分析等。不同的方法适用于不同的场景：代码 Agent 可以通过单元测试、编译结果、静态扫描来评估；RAG Agent 可以通过证据召回率、引用准确性、拒答能力来评估；客服 Agent 可以通过用户是否继续追问、问题是否得到解决、转人工率是否下降来评估。

这里需要注意一点：LLM作为评判者虽然很有用，但不能盲目信任。因为让大模型去评价大模型，本身也可能存在偏差。更稳妥的做法是：简单规则能够判断的，就用规则判断；业务结果能够验证的，就用业务结果验证；需要主观评价的，再引入 LLM 作为评判者或进行人工抽检。关键场景下，一定要有人工审校和明确的标注标准。面试时如果能讲到这一层，基本就能体现出比较成熟的评测思维。

九、面试时可以直接参考的完整回答模板

如果面试官问：“Agent 怎么评测？” 你可以这样回答：

“我不会只看准确率，因为 Agent 并非普通的单轮问答模型，而是一个多步骤执行系统。它通常会经历意图理解、任务规划、工具选择、工具调用、异常处理、结果生成等多个环节。因此，评测时既要看最终结果，也要看中间过程的质量。

我会首先建设好可观测性，将一次完整任务记录为 trace，将每一次模型调用、工具调用、检索请求、重试和异常记录为 span。这样才能精确知道 Agent 慢在哪里、错在哪里、成本消耗在哪里。

在评测指标上，我会从几个维度来考量。第一是任务完成率，看用户交给 Agent 的任务是否真正完成。第二是结果质量，看最终回答是否准确、完整、有用。第三是工具调用质量，看工具是否选对，参数是否传对，工具结果是否被正确使用。第四是执行过程质量，看是否存在重复调用、无效步骤、循环推理。第五是检索质量，对于 RAG Agent，还要看召回是否相关、证据是否可靠、引用是否正确。第六是系统性能和成本，包括延迟、token 消耗、模型调用次数和接口费用。第七是稳定性，看模型调用、工具调用、外部 API 是否经常失败，失败后是否能重试或降级。第八是安全与权限，看是否存在越权访问、敏感信息泄露和高风险操作未经确认的问题。

在上线前，我会进行离线评测，使用冒烟集验证核心链路，使用回归集防止历史问题复现，使用行为评测集检查工具选择、异常处理和权限边界。而且，Agent 的离线评测不能只看最终答案，还必须检查其期望行为，例如是否应该检索、是否应该调用工具、工具失败后是否正确降级。

上线后，我会进行在线评测，持续监控真实流量下的任务完成率、错误率、延迟、成本、用户反馈和失败样本。因为真实用户的问题一定比测试集更复杂，很多边界问题只有上线后才能被发现。

最后，我会将线上发现的失败样本进行归因分析，判断是意图理解问题、检索问题、工具调用问题、外部依赖问题、安全权限问题，还是最终生成阶段的问题。然后将这些失败样本沉淀回离线评测集，形成一个持续迭代的闭环。

所以，我理解的 Agent 评测，并非简单地计算一个准确率，而是构建一套围绕结果、过程、成本、稳定性、安全性和用户反馈的持续评估体系。”

Agent 评测这个问题，表面上问的是“如何评估效果”，但面试官真正想考察的，是你是否把 Agent 当成了一个真实的工程系统来对待。只回答“准确率”，说明你的认知还停留在模型问答层面；如果能回答出 trace、span、工具调用、离线评测、在线评测、失败样本回流等概念，说明你已经具备了工程落地的意识；如果还能补充安全权限、成本控制、隐式反馈、校准 LLM 作为评判者等细节，那么你的回答就更加完整和专业了。

未来做 Agent，并非模型越强就一定越好。真正能够落地的 Agent，一定是过程可观测、结果可评估、问题可定位、风险可控制、成本可接受、失败可回流、版本可持续迭代的。这也是 Agent 从 Demo 走向生产系统必须跨越的一道关键门槛。

如果你正在准备 AI Agent、测试开发、AI 应用开发等相关岗位，这道面试题值得认真准备。因为它考验的不仅是一个概念，而是你是否有真正理解：Agent 不是一个答案生成器，而是一个需要被测试、被监控、被评估、被持续治理的工程系统。