Agent评测框架（重要）
一、面试官在这一题里真正想考什么
当面试官问你怎么评估一个 Agent，他往往不是想听你罗列几个指标，更不是想听我会看准确率、人工满意度、成功率这种泛化回答。他想知道的是，你是否理解 Agent 的评测对象已经从单个模型输出扩展成了多步系统行为。
单轮问答时代，很多问题可以通过看最终答案来判断。但 Agent 不一样。一个 Agent 往往会经历规划、检索、调用工具、读取外部上下文、结构化输出、状态转移、多轮自我修正，最后才产生一个结果。于是，评测对象天然变成了多层结构：
- 最终结果是否正确？
- 中间过程是否可靠？
- 是否正确选择了工具？
- 是否过度规划或无效循环？
- 是否遵守了安全边界？
- 成本和延迟是否可接受？
- 对业务 KPI 有没有正向影响？
因此，Agent 评测的本质，是把什么叫一个好的系统行为定义清楚，并把它变成可重复、可比较、可自动化执行的质量体系。
如果你想在面试里答得更上一个层次，必须先把一句话讲出来：
Agent 评测不是只评答案，而是要评任务、轨迹、工具、环境交互、安全与业务效果。
下面给一个可以直接背诵、再根据项目替换细节的标准答案。
:::color1
我会把 Agent 评测分成七个部分。第一先定义任务和成功标准，明确最终完成什么算成功、哪些行为算失败。第二按核心场景、边界场景、历史失败场景和对抗场景构造数据集。第三设计评测环境，决定工具是真实调用还是 mock、检索语料是否固定快照。第四设计打分器，能规则判的优先规则判，比如结构化输出、工具参数、测试通过率；开放式质量再引入 LLM-as-a-Judge；关键高风险 case 保留人工复核。第五指标上我会同时看结果指标和过程指标，因为 Agent 失败很多时候不是最终答案错，而是规划、检索、工具选择或权限控制出了问题。第六把评测接到门禁，比如 PR 回归、版本对比、灰度门限。第七把失败 case 沉淀回数据集，形成持续优化闭环。这样做的目标不是得到一个孤立分数，而是建立一套可上线、可回归、可解释的质量体系。
:::
二、为什么 Agent 评测比普通 LLM 评测更难
Agent 评测之所以难，不是因为指标更多这么简单，而是它同时具备下面几个特点。
1. 轨迹不唯一
同一个任务，Agent 可能存在多条都能成功的路径。比如帮我预订明天下午去上海的高铁票，有的系统会先查日期、再查车次、再校验余票；有的会先问补充信息；有的会并发查询多个接口。也就是说，Agent 的正确性往往不是唯一轨迹的正确，而是多种可接受策略中的任一成功轨迹。
这意味着你不能简单用中间步骤和参考答案一模一样去判定对错。
2. 外部环境会变化
Agent 常常与搜索、数据库、企业系统、浏览器、代码仓库、工单系统等外部环境交互。环境会变，返回结果会变，权限会变，接口会抖动，页面会改版。一个离线看起来完美的任务，到了线上可能因为网页 DOM 变化、API 限流、权限收紧而失败。
所以 Agent 评测必须考虑环境耦合，而不是只考虑模型本身。
3. 结果和过程都重要
有些系统最终答对了，但过程很差：绕了十步才完成、本来一个工具就能做完却调用了五个工具、对敏感操作差点越权、重复检索三次才拿到结果。对企业来说，这不是表现良好，而是勉强成功，但效率与风险不可接受。
4. 安全与治理已经成为评测维度
Agent 能动手，风险就成倍上升。你不能只问它会不会做，还要问它会不会在不该做的时候做。所以现代 Agent 评测必须把安全评测、权限边界评测、审批链路评测纳入体系。
5. 业务价值不一定与技术指标线性对应
一个客服 Agent 如果答案更长、更像人，也许技术评测分数更高，但真实业务上可能降低转化率、增加用户等待时间、提高人工复核成本。评测框架最终要服务业务目标，而不是服务论文指标。
三、先给出一套最实用的总框架
在校招面试里，你可以把 Agent 评测框架总结成七层。这个框架既容易记忆，也便于展开。
flowchart TD
A[1. 任务定义] --> B[2. 成功标准]
B --> C[3. 数据集与场景集]
C --> D[4. 环境与执行器]
D --> E[5. 评测器与打分器]
E --> F[6. 报告与门禁]
F --> G[7. 反馈与优化闭环]第 1 层：任务定义
先定义你评的到底是什么任务。不是评一个 Agent，而是评具体的任务单元，比如：
- 企业知识问答中的政策问答
- 工单助手中的工单归类 + 回复建议
- 代码 Agent 中的根据 issue 修复 bug
- 浏览器 Agent 中的在指定网站完成表单填写
- 办公自动化 Agent 中的拉取报表并生成摘要
任务定义不清，后面所有指标都会漂浮。
第 2 层：成功标准
成功标准是评测的核心。要明确回答：什么叫成功，什么叫失败，什么叫部分成功。比如：
- 最终答案必须正确且引用充分；
- 必须使用指定工具或禁止使用某些工具；
- 必须在 5 步内完成；
- 必须返回合法 JSON；
- 不允许泄露敏感信息；
- 涉及外部写操作时必须先发起审批。
很多候选人答题时最大的问题，就是指标先行、目标后置。正确顺序应当是：先定义成功，再选择指标。
第 3 层：数据集与场景集
Agent 评测不能只靠一两个 demo case，而要有分层场景集。常见分法包括：
- 黄金集：最典型、最重要、可重复的核心任务；
- 边界集：长上下文、歧义输入、缺信息输入；
- 失败集：历史上出过问题的 case；
- 对抗集：恶意输入、越权诱导、提示注入；
- 线上回放集：从真实流量中抽样沉淀；
- Benchmark 映射集：用公共 benchmark 作为外部参照。
第 4 层：环境与执行器
对 Agent 来说，评测不是单纯给 prompt 看输出，而是需要一个执行环境。你要考虑：
- 工具是 mock 还是真实调用？
- 检索语料是否固定快照？
- 浏览器页面是否稳定？
- API quota 是否充足？
- 随机性是否需要固定？
- 是否支持多次重复试验？
环境设计决定结果是否可复现。
第 5 层：评测器与打分器
这层决定怎么判分。常用方法包括：
- 规则评分：精确匹配、结构校验、字段完整性；
- 程序评分：执行测试、运行单元测试、SQL 执行验证；
- 轨迹评分：是否调用了正确工具、是否发生死循环；
- 模型评分：LLM-as-a-Judge / model grader；
- 人工评分：小样本高价值 case 复核；
- 混合评分：规则优先 + 模型补充 + 人工兜底。
第 6 层：报告与门禁
评测不是为了出一张表，而是为了做决策。所以最终必须回答：
- 这个版本能不能上线？
- 哪些维度变好，哪些维度变差？
- 退化是否在容忍区间内？
- 是否要阻断 merge / deploy？
- 哪些 case 需要人工复核？
第 7 层：反馈与优化闭环
评测的终点不是打分，而是找到优化方向。一个成熟系统会把失败 case 送回：
- Prompt 优化
- Tool schema 优化
- 检索链路优化
- 权限边界优化
- 路由策略优化
- 数据集扩充
- 评测器修正
这样才能形成真正的 eval flywheel。
四、Agent 评测要评哪些维度
下面这张表是面试里非常常用的回答框架。你不一定真的用表格呈现，但脑子里必须有这几类维度。
1. 任务结果质量
这是最直观的维度，问的是任务做成了吗。常见指标包括：
- task success rate / completion rate
- answer correctness
- groundedness / citation coverage
- patch pass rate（代码任务）
- structured output validity
- business acceptance rate
它回答的是终局是否合格。
2. 过程质量
这是 Agent 区别于普通问答系统的关键。常见指标包括：
- 规划是否合理
- step 数是否过多
- 是否存在重复行动
- 是否选择了正确工具
- 是否过度调用工具
- 是否在中间状态卡死
- 自我修正是否有效
它回答的是它是怎么做成或做失败的。
3. 效率与资源消耗
企业很关心值不值得跑。常见指标包括：
- 总 token 消耗
- 每成功任务成本
- 端到端延迟
- 工具调用次数
- 并发下稳定性
- cache hit rate
- 重试次数
它回答的是代价是否可接受。
4. 安全与合规
能做不等于该做。常见指标包括：
- 危险工具误调用率
- 越权请求拦截率
- 注入攻击成功率
- 审批缺失率
- 敏感信息泄露率
- 不当内容触发率
- 审计日志完整率
它回答的是有没有越界。
5. 稳健性与泛化
有些系统在标准样例上很好，但输入一变就崩。要看：
- 对歧义输入的稳定性
- 对缺信息输入的追问能力
- 对外部工具错误的恢复能力
- 对页面变化 / schema 变化的鲁棒性
- 多轮上下文下的一致性
- 不同租户 / 不同知识域上的泛化表现
它回答的是遇到现实世界的脏数据和变化还能不能活。
6. 业务效果
这是最高层。比如：
- 工单处理时长是否下降
- 人工接管率是否降低
- 用户满意度是否提升
- 转化率 / 成交率是否改善
- 首解率是否上升
- 审批成本是否减少
它回答的是这个 Agent 是否真正创造价值。
在面试里，如果你能把这六类维度按结果---过程---效率---安全---稳健性---业务讲出来，往往就已经是高质量回答。
五、评测单元应该怎么切
Agent 评测的另一个关键点是：你评测的对象粒度是什么。
很多系统出了问题，是因为把所有东西都塞到最终成功率里，导致定位不了问题。更科学的做法是把评测单元拆成四层。
1. Response-level
评估单个模型输出，比如某一次分类、某一次 JSON 结构化结果、某一次工具参数生成。适合看底层能力。
2. Step-level
评估 Agent 单步行为，比如这一步是否应当调用工具、调用了哪个工具、参数是否正确、是否应该继续规划。适合分析过程质量。
3. Episode-level
评估整个任务 episode 是否完成，包括多步轨迹、环境交互、最终结果。很多 Agent benchmark 的基本单元都是 episode。
4. Session / Business-level
评估更长时间尺度上的用户会话和业务目标，比如一次多轮客服会话是否最终解决问题、一个工作流是否真正流转成功、一个用户在一周内是否满意。
不同层级对应不同的指标与打分器。面试官很喜欢问你如何定位失败，实际上他想听到的就是你是否知道不同层级需要不同观测点。
六、怎样设计一套校招也能说清楚的 Agent 评测流程
如果让你回答你会怎样从零设计一个 Agent 评测体系，一个很实用的说法是下面六步。
第一步：定义业务目标和任务边界
先问业务方或自己：这个 Agent 是干什么的？成功意味着什么？失败会带来什么代价？是否涉及真实写操作、审批、用户数据？
第二步：拆出关键能力
不要一上来就测全链路。先把系统拆成几个能力层：
- 理解输入
- 任务规划
- 检索 / 读上下文
- 工具选择
- 参数生成
- 输出生成
- 审批与安全控制
这样做的好处是，当全链路退化时，你知道先去看哪一层。
第三步：构造分层数据集
至少准备四类 case：
- 核心高频 case
- 历史失败 case
- 边界 case
- 对抗 / 风险 case
没有失败集的评测体系，几乎一定会高估系统质量。
第四步：选择评测器
按能规则判就规则判，规则不够再用模型判，实在关键再人工判的顺序。理由是规则最稳定、成本最低、可解释性最好。LLM judge 很强，但不是第一选择。
第五步：建立基线与门禁
任何评测都需要 baseline。否则你只是在看一个孤立数字，不知道它是变好还是变差。建立 baseline 后，要明确：
- 哪些维度必须不下降；
- 哪些维度允许小幅波动；
- 哪些维度需要显著提升才值得上线；
- 哪些 case 的失败属于 blocker。
第六步：把结果接回开发循环
评测报告最终要转成行动：
- 加入新的回归 case；
- 修 Prompt；
- 改 tool description；
- 调路由；
- 改安全策略；
- 做环境 mock；
- 拆能力边界。
这一步没做，评测就会退化成形式主义。
七、规则评测、模型评测、人工评测怎么组合
这是面试中的高频追问。最好的回答方式不是偏袒某一种，而是说明它们的边界。
1. 规则评测
适用于：
- 分类标签是否正确
- JSON / schema 是否合法
- 数值是否落在范围内
- 引用字段是否齐全
- 工具参数是否满足格式要求
- 代码 patch 是否通过测试
优点是稳定、便宜、可解释。缺点是覆盖不了开放式质量。
2. 模型评测（LLM-as-a-Judge / model grader）
适用于：
- 答案是否切题
- 解释是否完整
- 回复语气是否符合要求
- 总结是否覆盖关键点
- 多候选答案的 pairwise 比较
- 模糊正确性的开放式任务
优点是可扩展、能覆盖开放任务。缺点是自身也会漂移，需要做校准、一致性测试和 prompt 版本管理。
3. 人工评测
适用于：
- 高风险业务
- 难以自动判分的复杂任务
- 新任务早期基线建立
- Judge 校准与抽检
- 线上事故复盘
优点是最符合真实偏好，缺点是慢且贵。
最佳组合思路
在实际系统里，通常是：
规则评分做底座，模型评分补开放维度，人工复核做关键抽样。
这句话建议直接背下来。它几乎适用于所有 eval 话题。
八、为什么说失败分类是评测框架的一部分
成熟团队做评测，绝不会只看分数，还会看失败是怎么失败的。因为不同类型的失败对应完全不同的改法。你可以把失败粗分成下面几类：
- 理解失败：用户意图都没识别对；
- 规划失败：知道要做什么，但步骤安排错了；
- 检索失败：没拿到正确上下文；
- 工具选择失败：该调 A 调成 B，或根本不该调工具却调了；
- 参数失败：工具选对了，但参数构造错；
- 执行失败：外部 API / 页面 / 权限 / 超时问题；
- 整合失败：拿到信息后最终答案组装错；
- 安全失败：越权、泄露、危险调用；
- 效率失败：虽然做成，但成本和延迟不可接受；
- 治理失败：缺审批、缺审计、状态不一致。
面试时，如果你能说我不会只统计失败率，还会做 failure taxonomy，面试官会很容易判断你真的做过复杂系统，或者至少理解复杂系统是如何被管理的。
九、Agent 评测框架如何映射到不同项目类型
1. RAG Agent
重点评：
- 命中正确证据的能力；
- 引用覆盖；
- 答案与证据一致性；
- 无依据臆造率；
- 检索失败后的追问或降级能力。
2. 工具型 Agent
重点评：
- 工具选择准确率；
- 参数构造正确率；
- 工具链路成功率；
- 无效工具调用率；
- 风险操作确认率。
3. 浏览器 / GUI / Computer-use Agent
重点评：
- 环境适应能力；
- UI 选择器或页面理解能力；
- 任务 episode 成功率；
- 页面变化下的稳健性；
- 错误恢复能力；
- 多步长任务中是否出现迷航。
4. 代码 Agent
重点评：
- 是否理解 issue；
- patch 是否通过测试；
- 是否引入新 bug；
- 修改范围是否过大；
- tool / repo / terminal 使用是否安全；
- 单任务 token 与耗时是否可接受。
5. 企业工作流 Agent
重点评：
- 状态机是否正确推进；
- 审批链是否遵守；
- 数据写入是否一致；
- 幂等、重试、回滚是否可靠；
- 审计字段是否完整。
这类项目映射很适合在面试中展示你知道方法怎么迁移。
十、常见追问与拆解
追问 1：为什么不能只看任务成功率？
因为任务成功率是结果指标，只告诉你成没成，不告诉你为什么没成。Agent 往往是多组件系统，定位问题必须看过程指标和 trace。
追问 2：为什么不全部用人工评测？
因为昂贵、慢、不可扩展。系统一旦高频迭代，需要自动化门禁。人工更适合用于关键 case、抽检和 judge 校准。
追问 3：LLM-as-a-Judge 会不会不稳定？
会，所以要做几件事：固定 judge prompt 与版本、构建校准样本、做一致性抽检、必要时多次采样或 pairwise 比较，并用规则评分兜底关键维度。
追问 4：公共 benchmark 和内部评测哪个更重要？
内部评测更重要，因为它直接对应你的业务目标；公共 benchmark 更像外部参照系，用来判断你的系统处于什么水平、关注什么任务族群。
追问 5：评测框架会不会限制创新？
不会。真正成熟的评测体系不是为了束缚模型，而是为了让团队在快速试验时仍然知道哪些变化安全、哪些退化不可接受。
十一、校招生最容易掉进的坑
- 把评测说成测试模型；
- 只提成功率，不提过程；
- 不区分离线和在线；
- 不区分规则判分和模型判分；
- 不考虑安全 / 权限 / 审批；
- 没有 failure taxonomy；
- 没有 baseline，只会说绝对分数；
- 没有说数据集从哪里来；
- 没有说如何接到工程流水线；
- 没有讲评测结果如何反哺系统优化。
十二、高频面试题
1. 为什么 Agent 评测不能只看最终答案？
因为 Agent 是多步系统，最终答案只是表面现象。失败可能来自规划、工具、检索、权限或环境。
2. 你会如何设计一个 Agent 评测框架？
从任务定义、成功标准、数据集、环境、打分器、门禁、反馈闭环七层来设计。
3. Agent 评测里结果指标和过程指标分别有哪些？
结果指标如任务成功率、正确率、业务转化；过程指标如 step 数、工具调用正确率、重试率、回退率、审批触发率。
4. 为什么要保留失败集和对抗集？
因为平均样例会掩盖系统最脆弱的边界，而生产事故往往都来自边界和历史失败模式。
5. 什么时候用规则评分，什么时候用 LLM Judge？
结构、格式、测试通过率等优先规则；开放式、主观式、多候选比较用 judge；关键高风险 case 加人工复核。
6. 你怎么避免评测集被刷分？
按时间和风险分层维护数据集，保留隐藏集、线上回放集和新失败样本，避免只优化公开样例。
7. 公共 benchmark 的作用和局限是什么？
作用是提供外部参考；局限是与业务不完全同构，且容易被过拟合。
8. 为什么 baseline 很重要？
没有 baseline，你无法判断一次改动是提升、波动还是退化。
9. 为什么评测器本身也要版本管理？
Judge prompt、规则逻辑、数据集都在变，不做版本管理就无法解释分数变化来自模型还是来自评测器。
10. 如果系统上线后效果下降，你会先看哪几类信息？
先看线上结果指标、过程指标和 trace，再看发布变化、环境变化、权限变化、知识库变化和外部 API 状态。
十三、参考资料与延伸阅读
- OpenAI, Working with evals
- OpenAI, Evaluation best practices
- OpenAI, Testing Agent Skills Systematically with Evals
- OpenAI, Getting Started with OpenAI Evals
- OpenAI, Eval Driven System Design - From Prototype to Production
- Anthropic, Define success criteria and build evaluations
- Anthropic, Using the Evaluation Tool
- LangSmith, Evaluation concepts
- Braintrust, Autoevals / Create scorers
十四、最后的总结
把这一篇压缩成一句话就是：
Agent 评测框架的核心，不是找到一个万能指标，而是把任务、轨迹、工具、环境、安全和业务效果变成一套可重复、可解释、可持续迭代的质量系统。
如果你把这个总框架建立起来，后面的离线与在线评测、过程与结果指标、Harness、可观测、安全、治理、灰度和回滚，都会自然接上。
更新: 2026-04-02 15:51:43