面试官问：Agent 怎么评测？

如果面试官问你：

“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 评测不能只看准确率，因为 Agent 是一个多步骤执行系统。我会从任务完成率、结果质量、执行过程、工具调用、延迟、成本、稳定性、安全性和用户反馈这几个维度来评估。上线前，通过离线评测集做冒烟测试和回归测试；上线后，通过 trace、span、任务完成率、错误率、成本、延迟和用户反馈来做在线评测。同时，把线上的失败样本回流到离线评测集，形成一个持续迭代的闭环。”

这段回答里，有几个关键词是面试官最看重的：多步骤执行系统、不只看结果也看过程、上线前后分层评测、失败样本闭环。能把这几层意思讲清楚，面试官基本就能判断，你绝不是停留在“调 prompt 玩 Demo”的阶段，而是有生产系统意识。

下面这张图可以帮助理解整个流程：

这套流程的核心不是去“算一个分数”，而是：上线前尽量拦住明显的问题，上线后持续发现真实的问题，再把真实的问题沉淀为下一轮测试的资产。

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

很多团队刚开始做 Agent 评测时，容易犯一个错误：直接准备一批问题，让 Agent 跑一遍，盯着最终结果看好不好。这个思路不能说完全没用，但远远不够。

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

• 意图理解错了。
• 任务规划错了。
• 检索召回不准。
• 工具选择错了。
• 工具参数传错了。
• 外部接口超时了。
• 工具返回结果没被正确使用。
• 模型在最终生成阶段编造了内容。
• 权限判断没做好，访问了不该访问的数据。

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

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

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

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

四、Agent 到底应该评测哪些指标

Agent 的评测指标，不要只说“准确率”三个字就完事。建议从八个维度展开，这样才够系统、够专业。

评测维度	关注点	典型问题
任务完成率	用户任务有没有完成	代码是否修复、报表是否生成、流程是否走完
结果质量	最终输出是否有用	是否准确、完整、符合用户意图
过程质量	执行步骤是否合理	是否绕路、重复调用、循环推理
工具调用质量	工具是否用对	工具选择、参数生成、返回结果使用是否正确
检索质量	知识是否找对	召回是否相关、证据是否可靠
性能与成本	是否能规模化使用	延迟、token、模型调用次数、接口费用
稳定性	是否经常失败	超时率、错误率、重试成功率、降级能力
安全与权限	是否可控	是否越权、是否泄露敏感信息、是否执行高风险操作

这个指标关注的是用户交给 Agent 的任务，到底有没有真正完成。比如，代码 Agent 有没有成功修复 Bug？数据分析 Agent 有没有生成可用的报表？客服 Agent 有没有解决用户的问题？自动化 Agent 有没有完成脚本生成和执行验证？它比单纯看“回答是否正确”更贴近业务本质。

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

Agent 最大的特点之一就是会调用工具，所以工具调用必须单独评测。比如，该调用搜索工具时有没有调用？工具选得对不对？参数传得对不对？工具返回失败后有没有重试？重试失败后有没有降级方案？工具结果有没有被正确利用？很多 Agent 的错误，问题不是出在语言表达能力上，而是出在工具调用链路上。比如用户问“帮我查一下最近 7 天的订单退款率”，正确流程应该是调用数据查询工具，但 Agent 如果直接生成一段看似合理的分析，那就是严重问题——这不是“回答不够好”，而是不该编的时候编了。

Agent 不是步骤越多越聪明，有时候步骤越多，反而说明规划能力越差。比如一个问题明明一次工具调用就能解决，它却调用了 5 次；一个代码修改明明只改一个文件，它却扫描了整个仓库。评测时，要关注有没有无意义的重复调用、有没有多余的中间步骤、有没有循环推理、失败后有没有正确重试和降级。

如果 Agent 接入了 RAG 或知识库，还要单独评测检索质量。很多时候最终答案不好，不是生成能力的问题，而是检索阶段就错了。召回内容不相关、过旧、缺失关键证据，或者多个文档内容冲突但 Agent 没识别，这些都是常见问题。所以 RAG Agent 的评测至少要拆成两层：第一层看检索有没有把正确证据找回来，第二层看生成有没有基于证据回答，而不是自己发挥。面试时可以补一句：“对于 RAG 类 Agent，我不会只评最终答案，还会单独评检索召回、证据相关性、引用正确性和无答案拒答能力。” 这个回答会比单纯说“看准确率”专业很多。

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

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

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

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

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

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

所以，Agent 的离线评测除了看最终结果，还要看期望行为。可以把离线评测集设计成四类：

冒烟集不需要很大，但一定要覆盖核心链路。比如一个代码 Agent，冒烟集可以包含能否读取项目结构、能否定位指定文件、能否修改简单 Bug、能否运行测试命令、能否总结修改内容。每次发版前先跑冒烟集，如果连这个都过不了，就不要继续上线。

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

Agent 最大的不确定性，很多时候不是答案写得不好，而是它会不会做不该做的事。比如信息不足时是否追问，需要查证时是否先检索，不能确定时是否明确说明，工具失败时是否降级。这些都属于行为评测。

只要 Agent 能调用工具，就必须测安全边界。比如没有权限时是否拒绝，遇到敏感数据时是否脱敏，遇到高风险操作时是否二次确认，遇到提示注入时是否坚持系统规则。这部分在企业级 Agent 里尤其重要。

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

离线评测很重要，但它永远覆盖不了真实用户。因为真实用户的问题更复杂，他们可能表达模糊、上下文不完整、一句话里包含多个任务、不断补充条件，甚至使用系统没见过的新说法。所以 Agent 上线后，还要做在线评测。

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

这些都只能靠在线评测持续发现。所以面试里一定要讲清楚：离线评测解决上线前的基础质量问题，在线评测解决真实场景下的持续质量问题。两者不是替代关系，而是互补关系。

七、失败样本回流：让 Agent 越测越稳

Agent 评测不能停留在“发现问题”，更关键的是形成闭环。一个完整的闭环应该是这样的：

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

这就是 Agent 评测闭环的价值——不是为了做一张漂亮的报表，而是让系统在真实使用中持续变稳。

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

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

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

九、面试时可以直接复用的完整回答

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

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

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

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

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

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

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

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

Agent 评测这道题，表面上问的是“怎么评估效果”，但面试官真正想看的，是你有没有把 Agent 当成一个真实的工程系统来看。只答“准确率”，说明你还停留在模型问答层面；能回答 trace、span、工具调用、离线评测、在线评测、失败样本回流，说明你已经具备了工程落地意识；如果还能补充安全权限、成本控制、隐式反馈、LLM-as-Judge 校准，那你的回答就更加完整了。

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

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