智能体面试准备（十一）：Agent 评估——怎么证明你的 Agent 真的“能用“

智能体面试准备十一Agent 评估——怎么证明你的 Agent 真的能用写在前面B1 到 B10 我们把 Agent 的架构、ReAct、工具、规划、记忆、多智能体、框架、工作流、Agentic RAG 全过了一遍。能写一个 Agent 不难能证明它可靠才值钱。这一篇讲评估evaluation——这是 B10 埋的轨迹级指标伏笔的真正展开。面试官问你怎么知道你的 Agent 比上版本好如果你答我试了几个例子感觉还行直接出局。一、先定义评估 Agent 和评估大模型有什么不同评估一个聊天模型如写首诗看输出文本质量就行输入→输出是单步映射。但 Agent 是多步决策系统它内部有一串思考→动作→观察的轨迹trajectory最终答案只是轨迹的终点。所以 Agent 评估至少有三层评估层看什么典型指标难度结果层最终答案对不对准确率/成功率/EM/F1低轨迹层走的路径合不合理工具选择正确率、步数效率中过程层单步动作/反思质量动作准确率、格式合规率中核心观点只看结果会漏掉瞎猫碰死耗子——Agent 走了一条烂路径碰巧答对了。评估必须同时看结果和轨迹。二、Agent 评估的四大维度2.1 任务成功率Task Success Rate最直觉的指标给定 N 个任务Agent 完整、正确完成的比例。难点在正确怎么判定——有标准答案如数学题直接比对。无标准答案如帮我订个会议室需要预定义成功标准success criteria例如产生了含时间地点的预订请求且未报错。2.2 工具选择准确率Tool Selection AccuracyAgent 在每一步是否选了该选的工具。比如问北京今天天气第一步就该调 weather 工具而不是先调 search。这一步选错后面全歪。评估方法用标注好的黄金轨迹gold trajectory做对比算动作序列和黄金序列的匹配度token/步级 F1、或编辑距离。2.3 轨迹效率Trajectory Efficiency完成同一任务步数越少越好但也不能跳步导致错。常用平均步数Avg # steps冗余步数占比走了回头路/无效调用是否触发护栏B9 讲的 max-steps / retry 兜底一个 10 步才答完、中途重试 3 次的 Agent和 4 步答完的成功率可能一样但效率和成本天差地别。面试官很看重你是否意识到这点。2.4 格式/协议合规Format ComplianceAgent 输出是否严格遵循约定的动作格式如 ReAct 的Action: xxx/Action Input: yyy。格式错了解析器解析不出来整个链路断掉。这是工程上最该先卡死的基础指标。三、一段能跑的 Agent 评估代码轨迹级下面用纯 Python 演示给定黄金轨迹和Agent 实际轨迹算任务成功率、工具选择准确率、平均步数三个指标。这是你面试白板能写出的评估骨架from typing import List def evaluate_agent(gold: List[str], pred: List[str], success_criteria) - dict: gold: 黄金动作序列, 如 [search, calc, answer] pred: Agent 实际动作序列 success_criteria: callable, 输入 pred 返回 bool任务是否成功 # 1) 任务成功率 success success_criteria(pred) # 2) 工具选择准确率逐位匹配padding 到等长 n max(len(gold), len(pred)) g gold [pad] * (n - len(gold)) p pred [pad] * (n - len(pred)) correct sum(1 for a, b in zip(g, p) if a b and a ! pad) valid sum(1 for a in g if a ! pad) tool_acc correct / valid if valid else 0.0 # 3) 轨迹效率 avg_steps len([x for x in pred if x ! pad]) return { success: success, tool_selection_acc: round(tool_acc, 3), steps: avg_steps, } # ---- 演示一个查天气再回答的任务 ---- def criteria(pred): # 成功 调了 weather 且最后一步是 answer return weather in pred and pred[-1] answer gold_traj [weather, answer] cases { 完美轨迹: [weather, answer], 多走一步: [search, weather, answer], 选错工具: [calc, answer], 没答就停: [weather], } for name, pred in cases.items(): r evaluate_agent(gold_traj, pred, criteria) print(f{name:8} - 成功{r[success]!s:5} 工具准确率{r[tool_selection_acc]} 步数{r[steps]})跑出来你会看到完美轨迹三项全满多走一步成功、工具准确率下降多调了 search、步数 3——效率差但结果对选错工具失败、工具准确率 0——典型的轨迹错没答就停失败——过程不完整。这段代码的价值在于它把成功/工具准确率/步数三个维度分离开了你一眼能看出 Agent 是哪类失败。面试时画出这个表格比空说我评估了强十倍。四、无标准答案时怎么办LLM-as-Judge很多 Agent 任务客服、写报告没有唯一正确答案。现代主流做法是用另一个强模型当裁判LLM-as-a-Judge给 judge 模型任务描述 Agent 轨迹 最终输出 评分维度有用性/忠实度/安全。judge 输出分数如 1–5或等级 理由。评估方式成本可复现偏差风险适用人工标注高高低金标准/校验规则/脚本低高中有确定标准LLM-as-Judge中中中(位置/长度偏差)开放任务在线 A/B高高低生产迭代面试考点LLM-as-Judge 有哪些偏差——位置偏差放前面的答案分高、长度偏差越长显得越认真、自我偏好偏好同家族模型输出。缓解对拍swap 顺序、用强模型、给 rubric、多人裁判取共识。五、生产环境的评估体系压轴真实团队不会只跑几个样例而是建评估集eval set 持续回归建评估集覆盖典型任务 边界非法输入、工具超时、多跳各几十到几百条带标注的 success criteria。离线回归每次改 prompt / 换模型 / 调工具重跑全量评估集对比成功率/工具准确率/步数/成本四项。在线监控生产流量里采样记录轨迹、成功率、人工抽检发现退化就回滚。轨迹可视化把失败案例的轨迹画出来哪一步选错工具、哪一步卡护栏定位根因。呼应 B10Agentic RAG 的评估器兜底就是轨迹层评估的工程落地——用一个小评估器判断当前检索结果够不够好不够就继续检索。评估不是事后的是嵌入 Agent 运行时的。六、面试高频追问自测成功率 100% 但步数翻倍算变好吗 → 不算要综合成功率效率成本可能只是更啰嗦地答对了。怎么评估没有标准答案的 Agent → LLM-as-Judge 人工抽检 在线 A/B三管齐下。轨迹评估和结果评估冲突听谁的 → 看业务客服类重结果用户拿到答案即可审计类重轨迹每一步要可解释。评估集怎么建才不作弊 → 评估集要和训练/调参数据隔离且持续补充失败 casefailure-driven 扩充。小结Agent 评估分结果/轨迹/过程三层核心指标是成功率 工具选择准确率 轨迹效率 格式合规。那段能跑的评估代码把成功 vs 工具准确率 vs 步数解耦正好帮你定位 Agent 是答错了还是走歪了。无标准答案用 LLM-as-Judge注意三大偏差生产要建评估集做持续回归。下篇 B12我们从零手写一个完整的 ReAct Agent把 B1–B11 的所有零件焊成一台能跑的机器。本篇 B11 完。B 系列评估篇收尾B12 起进入完整代码实例收官阶段B13/B14 继续两个完整 Agent 实战。