7.1 智能体评测：从答题对错到任务完成
7.1 智能体评测：从答题对错到任务完成
本节摘要：智能体评测的度量单位不是"答案对不对"，而是"任务成没成、花了多少步、费了多少钱"。本节给出任务级评测集的结构、四类核心指标的定义与判分脚本骨架，并用一次真实的回归事故说明评测如何把"感觉变差了"变成可定位的工程事实。
聊天应用的评测习惯——攒一批问答题对答案——搬到智能体上会全面失灵。同一个任务，两次执行的工具路径可以完全不同；文本回答相似，中间动作却可能一个越权一个合规。智能体评测必须以任务为单位、以轨迹为材料、以终态为判据，这是本节全部方法论的出发点。
图：智能体评测矩阵——能力维度与场景维度的交叉度量
评测集与判分：结构化的做法
{ "case_id": "expense_017", "scenario": "报销查询", "input": "帮我看看上周提交的差旅报销到哪一步了", "context": {"user": "u1001", "known_expense_id": "BX-0892"}, "expected": { "terminal": "回答包含 BX-0892 的当前状态", "must_call": ["query_expense"], "must_not_call": ["create_expense", "send_mail"], "max_steps": 4 } }
每个用例的 expected 三件套对应三类判分：terminal（终态判分，规则或判分模型打对错）、must_call 与 must_not_call（动作判分，直接比对工具调用序列——越权调用在这里现形）、max_steps（效率判分，步数超标即预警）。判分脚本骨架：
def judge(case, trace) -> dict: final = trace.answer calls = [c.name for c in trace.tool_calls] r_terminal = rule_or_llm_judge(final, case["expected"]["terminal"]) r_action = (set(case["expected"]["must_call"]) <= set(calls) and not (set(calls) & set(case["expected"]["must_not_call"]))) r_eff = len(trace.steps) <= case["expected"]["max_steps"] return {"case": case["case_id"], "pass": r_terminal and r_action and r_eff, "detail": {"terminal": r_terminal, "action": r_action, "eff": r_eff}}
四类指标随跑批产出：任务成功率（判分通过占比）、平均步数与步数长尾（成本与走偏的信号）、单任务成本（token 总消耗）、动作违规率（must_not_call 命中次数，安全红线指标）。
案例：一次被评测拦下的回归
背景：团队把记忆系统从滚动窗口升级成分层记忆（第 3 章），上线前跑评测，成功率从九成一跌到八成四。
操作：按用例分组看跌幅，损失集中在长会话类用例；读这批轨迹发现新记忆层的检索回填挤占了窗口，长会话后半程的工具定义被截断（正是 3.1 节预警过的挤占次序错误），模型开始调用不存在的工具。
结果：回滚该版本，把检索回填的预算上限调低并纳入 3.1 节的挤占次序规则后，成功率回到九成二，改进真正上线。
解读：这个案例里评测扮演的角色是变更的闸门——没有它，这次回归会以客诉的形式在生产环境暴露。智能体的每个组件改动（提示词、记忆、检索、模型版本）都可能牵动全局，跑批评测是唯一经济可行的回归手段。
变式：判分模型本身的可靠性需要校准——抽一批用例人工复核判分结论，一致率低于九成就该修判分提示词或换规则判分。判分模型是度量衡，度量衡本身失准，一切指标都是空中楼阁。
⚠️ 常见坑：评测集一劳永逸。线上会持续出现评测集没覆盖的新场景，每月把典型的线上轨迹（尤其是失败案例）补充进评测集——评测集应当是系统的活档案，而不是一次性的考试卷。
本节要点回顾
- 任务即单位：以轨迹为材料、终态为判据；文本相似度式的评测对智能体无效。
- 三件套判分：终态、动作（含禁调清单）、步数——越权调用在动作判分里现形。
- 四类指标：成功率、步数分布、单任务成本、动作违规率；违规率是安全红线。
- 评测是变更闸门：任何组件改动都跑批回归；判分模型自身也要定期校准。
评测能发现问题，但发现不等于拦截——下一节讲三道闸，让错误在发生前被挡住。
从零起步的最小评测闭环
不是每个团队一上来就需要整套矩阵。一个两人小团队的最小闭环可以压缩成四周的节奏：第一周，从原型期收集的失败模式里挑出十余条，写成第一批评测用例（用 7.1 的三件套格式，缺的 expected 字段先空着人工判）；第二周，写判分脚本的动作与步数部分（这两项纯规则，最容易自动化），终态判分先用人工过一遍；第三周，接入发布流程——任何改动提交前跑一遍，不过线不合并；第四周起，每次线上故障倒灌一条用例。四周后你拥有的东西很小但极其耐用：一份随系统长大的评测集、一个自动的动作判分器、一道发布闸门。行业里见过太多反例——评测体系设计了一个月，系统已经带着没人发现的回归跑了两个月。
另一个降低起步门槛的技巧：用历史轨迹做用例矿。原型期与试运行期的每一条真实轨迹都是现成的评测素材——成功的轨迹取其场景做正例，失败的轨迹修一修就是最有价值的负例。评测集不必凭空编写，它应该是系统历史的一半复刻。
指标呈现：让非技术相关方读得懂
评测结果迟早要拿去和业务方开会，呈现方式决定沟通效率。三条经验：一，用区间不用单点——"成功率八成七"后面永远带上样本量与置信区间，避免拿三个百分点的差异当重大结论；二，用分组不用总分——按场景类型、按难度档位拆开呈现，总分掩盖的恰恰是决策需要的细节（整体九成，但高风险场景只有七成，这才是要汇报的数字）；三，用趋势不用快照——指标随版本的变化曲线比单次数值更有信息量，一次改动让某场景下跌五个点，趋势图一眼可见。评测的价值一半在度量，另一半在让度量结果驱动正确的决策，呈现层就是这后半程的全部。