这道题出现的频率没有 RAG 那道高，但它是三面、交叉面的常客——因为它考的不是你知不知道某个框架，而是你有没有真的为一套系统的长期质量负过责。我把当时卡住的地方和后来补上的完整体系写在这里。
面 试 现 场 · 复 盘
三面。面试官没有问技术细节，先抛了一个听起来像管理的问题。
「你们那个 Agent 上线之后，怎么知道它没有变差？」
我：我们跑准确率。
「哪个准确率？」
我：……
后面我们又聊了二十分钟，但第一个回合我已经输了。
当时我以为自己答的是一个指标口径问题，其实暴露的是另一件事：我把 Agent 当成了一个分类模型来评测。
分类模型有明确的正负样本，所以有准确率。可 Agent 输出的不是一个标签，而是一整条执行轨迹：它先理解你要什么，再决定怎么做，然后去查资料、调工具、最后组织语言回给你。这四五个环节里任何一个出错，最后都表现为同一句话——「这个 Agent 不好用」。
所以「怎么评测」这道题真正的考点是一句话：你能不能不靠猜，把一次失败定位到具体某一层。
下面分三层拆。第一层讲为什么必须先把可观测性做出来；第二层是八层评测模型；第三层是三个取舍，最后给一个归因法和一条很多人不敢说的负向边界。
一、第一层：Agent 的故障是连锁的，所以评测必须分层
先给一个反常识的判断：「Agent 不好用」是现象，不是根因。 同一句抱怨背后，至少有五条互不重叠的故障路径。
| | |
|---|
| | 后面每一步都执行得很正确，错得很自信，日志看着毫无异常 |
| | |
| | |
| | |
| | |
最关键的一句认知Agent 的故障大多是跨模块的连锁问题：一个早期的意图误读，会被后面的规划、检索、生成逐级放大，最后在你面前呈现为一个「生成质量」问题。
这就是为什么「算一个总分」在 Agent 上几乎没用——平均分会把所有层的错误互相抵消，最后你只得到一个数字，却仍然不知道该改哪一行代码。
▍所以第一步不是评测，是可观测性
做 Agent 评测，第一步真的不是急着算准确率，而是先让一次任务从用户输入到最终输出的完整链路可被回放。
工程上的标准做法是 trace + span：一次完整任务记成一条 trace，其中每一次模型调用、工具调用、检索请求、接口访问、异常重试，各记成一个 span。没有这两样东西，你连「这个问题出在哪一层」都问不出来。
有了 trace 和 span，很多原本吵架的问题会立刻变成算术题：
落库时字段不用多，但有两列必须留，少一个后面全都做不成。下面是最小集：
// trace_span 最小落库字段（节选，按 span 逐条记录）{"trace_id": "tr_9f3c...", // 一次完整任务"span_id": "sp_02","parent_span_id": "sp_01","span_type": "llm | tool | retrieval | guard","duration_ms": 8420,"token_in": 3187,"token_out": 412,"status": "ok | error | timeout","retry_count": 0,// ★ 第一个必须留的字段：调用了哪个工具、参数是什么"tool_name": "search_flight","tool_args_digest":"{ budget:1500, date:'2026-10-01' }",// ★ 第二个必须留的字段：检索回来的文档 id 与分数// 缺了它，召回层的 Recall / Precision 事后无法回溯计算"retrieval_doc_ids": ["doc_883", "doc_1204", "doc_77"],"retrieval_scores": [0.83, 0.61, 0.44],"retrieval_stage": "hybrid_recall | rerank"// 区分召回首轮和重排后}
字段来自实际排障需求反推：没有 retrieval_doc_ids，你永远无法回答「到底是没召回，还是召回了没用」
这是全文最容易被忽略的一句绝大多数团队建 trace 时只记「模型输入输出了什么」，不记「检索召回了哪几条、分数多少」。结果就是——线上真的出问题时，你只能猜。
把 retrieval_doc_ids 和 retrieval_stage 补上，召回层的所有指标就都能离线重算，不需要重放整个请求。
二、第二层：八层评测模型
下面是我最终落下来的完整分层。顺序本身就是执行顺序——从上往下走，任何一层不过关就不要往下看，因为上面一层的错误会污染下面所有层的结论。
1 门禁层 · 安全与权限
零容忍：不达标直接拦截上线，不参与平均分
↓
2端到端任务完成度
任务完成率 · 结果质量 · 约束遵循率 · 波动系数 CV
判定：规则 + Judge
↓
3意图理解
意图分类准确率 · 指代消解 · 意图切换感知 · 模糊追问率
判定：规则 / 小模型 / Judge
↓
4任务策划
目标拆解 · 需求匹配 · 逻辑顺序 · 规划一致性 · 动态重规划
判定：只能靠 Judge
↓
5召回检索
Context Recall / Precision · 重排命中 · 引用可溯源
判定：RAGAS / DeepEval
↓
6工具执行
工具选择 · 参数合法 · 结果解析 · 异常恢复 · 越权率
判定：Schema + 脚本
↓
7表达生成
忠实度 · 答案相关性 · 格式遵循 · 拒答正确率
判定：RAGAS / Judge
↓
8 横切层 · 稳定性与成本
pass^k · 波动系数 CV · P95 端到端延迟 · 单任务 token 与工具步数
↓
底座 · 可观测性 trace / span
落库必须带 retrieval_doc_ids，否则上面每一层都无法归因与复现
顺序即执行顺序：门禁在最上（不过就不看别的），底座在最下（没有它上面全部失效）
▍每一层的判定方法不一样，选错了等于白做
1 · 安全
核心指标：越权率、PII 泄露率、风险操作拦截率
主判定方法：规则脚本（必须）
为什么：这类判定不允许有概率
2 · 端到端
核心指标：完成率、结果质量、约束遵循率、CV
主判定方法：规则 + Judge 双重
为什么：硬约束用脚本，开放性用裁判
3 · 意图
核心指标：分类准确率、指代消解、切换感知、追问率
主判定方法：规则 / 小模型 / Judge
为什么：明确意图可枚举，模糊意图只能判语义
4 · 策划
核心指标：拆解、匹配、顺序、一致性、动态重规划
主判定方法：只能靠 Judge
为什么：规划合理性无法用规则统一量化
5 · 召回
核心指标：Context Recall / Precision、重排命中
主判定方法：RAGAS / DeepEval
为什么：有成熟指标库，别自己造
6 · 工具
核心指标：选择正确率、参数合法率、无效调用占比
主判定方法：Schema + 脚本
为什么：能自动化，且应该是自动化程度最高的一层
7 · 表达
核心指标：忠实度、答案相关性、格式遵循率
主判定方法：RAGAS / Judge
为什么：忠实度不需要 ground truth，性价比高
8 · 横切
核心指标：pass^k、CV、P95 延迟、token、步数
主判定方法：重复执行 + 日志统计
为什么：全部可从 trace 自动提取
执行时的三条铁律先可观测，后评测——没有 trace 就没有归因，先建底座。
先结果，后过程——端到端完成度是核心验收标准，不要一上来就抠单步指标。
先底线，后优化——安全合规是零容忍门禁，它不参与平均分，不过关就不上线。
▍第 3 到 7 层里，几个容易答错的细节
意图层：模糊追问能力的评判标准是「一次性补齐关键参数」，而不是「追问次数多」。如果把追问次数当正向指标，会训练出一个特别烦人的 Agent。另外多轮场景要单独测两件事——指代消解（「它」「那个」「上次说的」指的是什么）和意图切换感知（用户中途改需求时，Agent 会不会抱着旧意图不放）。
策划层：这一层有一个判定方法上的坑——评测「步骤可行性」时必须把当前环境的可用工具与权限清单一起喂给裁判模型。不给环境约束去评判可行性，裁判会默认一切都可执行，分数虚高得离谱。另外「规划一致性」这个指标专门抓两类病：规划写得漂亮但执行完全跑偏，以及无理由频繁改规划。
工具层：参数校验要覆盖跨参数依赖规则（比如「结束日期必须晚于开始日期」），否则会出现「每个参数单独看都合法、组合起来逻辑错误」的漏网之鱼。异常测试集至少要覆盖四类：网络超时、参数非法、工具离线、业务接口报错。
表达层：这里要区分两个幻觉概念，术语别说错——标准二分是 事实性幻觉（factuality） 与 忠实性幻觉（faithfulness）（Huang et al., arXiv:2311.05232，哈工大与华为联合）。事实性幻觉是模型压根不知道、记错了，那是检索层该解决的；忠实性幻觉是资料明明给了、模型却不照着答，那才是表达层的问题。这两个概念在上一期 RAG 那篇里展开过，这里只说一句：分不清这两个，你的归因方向会整整差一层。
三、第三层：三个取舍
层搭出来只是及格线。面试官真正在听的是取舍——同样的目标，你选哪条路，代价是什么。
▍取舍一：算一个总分，还是分层归因
新手做法
把所有指标加权成一个 0–100 的「健康分」，挂在大屏上每日监控。分数掉了 8 分，团队开始开会讨论。
问题是：总分只能告诉你「变差了」，不能告诉你「改哪里」。 讨论两小时，最后靠猜。
正确做法
总分可以有，但只作为告警触发器，不作为决策依据。真正看的是分层指标。
分数掉了 8 分，先看是哪一层掉的：召回层掉的就去查切分和召回策略，工具层掉的就去查参数边界。指标本身就要能指向代码位置。
这就是归因树的价值。把「不好用」拆成五条互不重叠的路径，每一条挂上独立的、可测的指标：
↓
1 意图理解错了
看意图分类准确率与指代消解正确率 —— 这一层错得最隐蔽，因为后面全对
2 任务策划错了
看目标拆解完整度与实际执行的路径偏离度 —— 症状是绕路和重复调用
3 召回不准
先隔离调试：固定生成环节，单跑检索看 Recall / Precision —— 最容易被误判成幻觉
4 工具调用错了
看工具选择准确率与参数 Schema 校验通过率 —— 症状是同一任务时好时坏
5 表达时编造了
检索结果明明在上下文里却不用 —— 看忠实度与引用可溯源率
召回那一支被标红，是因为它最常被误判：明明是没召回，却被人当成模型幻觉去换模型
召回层有一个必须主动说的前提评测召回时，一定要先做隔离调试：把生成环节固定住，单独跑纯检索评测，再跑端到端。
原因是——检索质量和生成质量是两个完全独立的故障源。 端到端分数差，可能只是检索差，也可能检索满分但生成不忠实。混在一起测，你永远分不清该改哪一边。这个问题上一期讲 RAG 三分法时展开过，到 Agent 这一层它变成了一个必测项，因为检索是 Agent 的常态动作，不再是可选项。
▍取舍二：裁判模型直接上，还是先校准
新手做法
写好提示词就上线，用 LLM 给所有输出打分。某天分数掉了 10 分，团队紧张地回滚了模型版本。
问题是：你根本不知道掉的是模型，还是裁判的偏见。 大模型当裁判有四类已知的系统性偏见，不校准就测不出真问题。
正确做法
先用人工标注一批样本作基准，让裁判在基准上跑一遍，要求与人工判断的一致率达到 90% 以上才允许启用。
不达标就先改评分维度的定义、加分数锚点，而不是急着换裁判模型——一致率低，十有八九是你的评分标准本身写得不清楚。
还有一条铁律，说错了会被直接质疑：硬性约束（预算、时间、权限）禁止交给裁判模型判定。 因为这些约束违规了但「回答得好听」，裁判很可能给高分。正确做法是脚本强制校验，违规直接记 0 分。
下面是我实际在用的裁判提示词骨架，直接改就能用：
# 评测裁判提示词骨架你是专业评测裁判，严格依据给定标准打分，禁止主观发挥。打分区间 1-5 分。# 评测输入用户任务：{task}Agent 实际输出 / 完整执行日志：{output}可用工具与权限清单：{tools} # 策划类评测必填，否则分数虚高# 子维度评分（必须给分 + 扣分理由，不要只给总分）① 目标拆解（30%）：1-5 分，说明扣分理由② 需求匹配（40%）：1-5 分，说明扣分理由③ 逻辑顺序（30%）：1-5 分，说明扣分理由# 硬性约束（脚本层已校验，这里只做交叉确认）违反约束 {constraint} 的，总分直接记 0 分。# 评分锚点（不给锚点，模型会自己发明标尺，批次间不可比）5 分：粒度适中、边界清晰、无核心缺失3 分：粒度不均、存在非核心子任务缺失1 分：未拆解或拆解完全错误，无法执行# 输出格式目标拆解（30%）：分 理由需求匹配（40%）：分 理由逻辑顺序（30%）：分 理由综合得分：加权平均，四舍五入取整
锚点描述是这份提示词里最重要的部分，很多人只写了权重就上了
▍取舍三：公开基准的分数，还是自建的评测集
新手做法
拿 SWE-bench、GAIA、τ-bench 的公开分数当作「我们这个 Agent 的能力水平」，写进汇报材料。
两个问题：其一，同一个模型在不同 scaffold 下分数差异巨大，跨榜单数字根本不可比；其二，它完全测不到你自家的业务口径。
正确做法
公开基准只做外部校准——看方向、看量级、看同类 Agent 的合理区间。所有上线决策的依据，永远是自建业务集。
看到一个分数，第一反应应该是反问：这是哪个 harness 跑的？ 这个问题问出来，面试官就知道你真读过榜单，而不是只看过标题。
常用基准的定位，选型时按 Agent 类型对号入座：
| | |
|---|
| 真实 GitHub Issue 修复，PR 需通过仓库测试套件 | |
| | |
| | 浏览器 Agent；人类基线约 78%，2023 年首批 Agent 约 14% |
| | Computer-use Agent；2.0 支持长程任务 + 部分得分检查点 |
| | |
| 双控制客服对话 + 策略遵循，指标是 pass^k | 最贴近生产；注意它已演进到 τ³-bench，各版本分数不可跨版本比较 |
| | |
| 函数调用可靠性（串行、并行、多轮有状态、Schema 异常） | 所有工具调用 Agent；上生产前建议对自家 Schema 跑一遍 |
| | |
这里有一组数据值得单独说，因为它解释了一个很常见的困惑——为什么 demo 里表现很好的 Agent，一上真实用户就崩。
τ-bench 用的是双控制设计：AI Agent 和模拟用户都在主动修改同一个共享环境，用户会改主意、给不完整信息、中途加条件。公开报道的现象是：从单控制切到双控制，Agent 表现会急剧退化——一个在剧本化评测里能拿 85% 的 Agent，当模拟用户引入模糊信息时可能掉到 60% 以下。
这个现象对做评测的指导意义它说明沟通能力、而不是原始任务能力，往往是生产场景的主要瓶颈。 所以你的评测集里必须有角色扮演式的多轮用例，而不能只有「单轮问答 + 标准答案」。
另外注意一个方法论细节：pass^k（连续 k 次独立试验全部成功的概率）比单次成功率更贴近生产体感。一个 90% 成功率的 Agent，pass^3 可能只有 73%——这就是用户实际感受到的「它有时候行有时候不行」。
▍自建评测集：四步，别一次贪多
1采集真实任务——从用户日志、客服工单、自己和同事的真实使用中抽取。建议 50–200 条，代表性优先，不要贪多。
2人工标定验收口径——这一步最反直觉：不是记「正确答案」，而是记「什么算通过」。开放型任务往往没有唯一正确答案，但一定有明确的通过边界。记正确答案的数据集无法扩展，记通过边界的才能被机器判定。
3定义指标——任务完成率、轮次效率、无效工具调用占比、错误恢复率。指标要和第 2 步的验收口径一一对应。
4自动化评测——裁判和规则检查器都需要在第 2 步的标注集上校准，与人工一致率 ≥ 90% 才启用。
数据集建完不是终点，而是起点。真正让它长期有效的是故障驱动的回归集：每一个线上失败案例，都转成一条回归用例。
// regression_cases.jsonl —— 每条线上坏例都变成一条防退化用例{"id": "REG-017","trigger_date": "2026-09-15","description": "用户中途把预算从 1500 改成 2000，Agent 仍按旧预算过滤，导致结果为空","task": "帮我查明天北京飞上海的机票，预算 1500 以内","turns": ["把预算改成 2000"],"pass_criteria": "第二轮必须继承新预算并重新检索，返回结果中至少一条价格 > 1500","fail_criteria": "仍使用 1500 作为过滤条件，或未重新检索直接复用上一轮结果","layer": "intent | plan | retrieval | tool | express"// 标注归属层，便于分层统计}
注意最后那个 layer 字段——它让回归集同时具备了分层诊断能力
这套机制的关键在于把「修 bug」自动转化为「防退化」。流程上固定成：任何改动 prompt、hook、配置之前，先跑全量记录基线 → 改完跑同一套 → 通过率下降超过 5% 就回滚，不要抱着「再调一版试试」的侥幸。
四、杀手锏：归因法和一条负向边界
▍归因法：先归因，再优化
这是整道题最能拉开差距的地方。大厂面试真正想听的，不是你会用哪个工具，而是你在动手之前有没有先定位。
我把它固定成一张对照表，线上排障和面试答题都直接套：
| | |
|---|
| | 分类体系是否覆盖长尾；多轮上下文注入是否完整；是否缺主动追问 |
| | 目标拆解粒度；约束是否在规划阶段就被声明；失败后有无回溯修正 |
| Context Recall 低，或关键文档没进候选集 | 切分策略；embedding 与数据分布是否匹配；是否缺关键词那一路 |
| | top-k 截断；重排后位置排布；长上下文中间被忽略 |
| | 工具描述清晰度；跨参数依赖规则；异常重试与降级策略 |
| | 提示词约束强度；上下文噪声比例；是否需要强制引用与 claim 级校验 |
其中「组装问题」这一支最容易漏，也最像幻觉：资料召回来了，但在塞进 prompt 的过程中被截断、被重排挤掉、或者落在长上下文的中间位置被模型忽略了。 典型症状是把 top-k 从 5 加到 20，召回率上去了、答案质量反而掉了——那不是模型变笨，是你把噪声引了进来。
所以要养成一个动作：看到「检索对了但答错了」，先确认资料到底有没有进最终 prompt。 这个确认动作只需要一行日志，但能省掉一整轮无效的调参。
▍负向边界：主动说出「这三件事我不测」
这一节是我认为最能体现工程成熟度的地方。面试里敢于划出「测不了什么」的人，比宣称「我全都能测」的人可信得多。
| | |
|---|
| 没有 ground truth，强行造一个只会得到一个自欺欺人的数字 | |
| | |
| 公开研究里，绝大多数评估只测技术指标，人本与业务维度严重缺失；而且跨 harness 的分数不可比 | |
还有一条边界要主动声明，因为它直接关系到合规：安全、权限、隐私这类的判定，我不接受任何概率性的评测方式。 越权调用率、PII 泄露率这些必须由脚本全链路校验，结果只有「0」和「不为 0」两种，而且不参与平均分。
最后一条工程判断还有一句话值得在面试里主动说：能用 DAG 工作流解决的问题，不要上自主 Agent。
自主编排的代价是评测难度指数级上升——步骤不固定，你就无法预先定义「正确路径」，评测只能退回成主观打分。如果你的场景本身流程确定，用工作流换来的不只是稳定性，还有可评测性。这句话一出口，面试官会知道你考虑过评测成本，而不是只想着炫技。
五、回到那个「哪个准确率」
回到开头那个场景。面试官问的是同一句话：
「你们那个 Agent 上线之后，怎么知道它没有变差？」
现在的我可以这样答——
我不会给你一个准确率，因为 Agent 输出的是轨迹而不是标签，单一数字说明不了任何问题。我会先说三件事。
第一，可观测性我是先建的。 每一次任务都有完整的 trace 和 span，检索结果我留了文档 id 和分数，所以任何一次线上失败我都能离线回放、能重算召回指标，不需要靠猜。
第二，我的最上层是门禁，不是指标。 安全、越权、隐私是零容忍，脚本全链路校验，结果只有 0 和不为 0 两种，它不过关就不上线，而且不参与平均分——我不会让安全问题和回答质量问题在同一张表里被平均掉。
第三，业务指标我不给总分，按五层分开看。 意图、策划、召回、工具、表达，每一层的指标都要能指向代码位置。
所以你要问「有没有变差」，我的答案不是「分数没掉」。我的答案是：分数掉了 5% 的时候，我知道该改哪一层。
从「我们跑准确率」，到「分数掉了我知道该改哪一层」——这就是差距。
这道题真正在考的，从来不是你会不会用某个评测框架。它考的是你有没有想过：一个会自己规划、自己调工具、自己组织语言的系统，你打算靠什么相信它。
AI面试真题拆解系列 · 第 02 期
每一期拆一道大厂 AI 应用岗真题：现场还原 · 反常识切入 · 结构化解法 · 取舍对比 · 归因方法。不讲概念，只讲线上真会踩的坑。
关注「Fox爱分享」