你大概率干过这件事给 Agent 接上 Langfuse或者别的 LLM 可观测平台trace 画得漂漂亮亮然后点开 “Dataset → Run Experiment”跑出一个绿油油的通过率——92%。你松了口气评估过了可以上线。结果上线没几天投诉来了该退款的没退、简单问题绕了五个工具、偶尔还答得驴唇不对马嘴。你回头盯着那个 92% 发懵评估明明过了怎么线上还这样问题就出在这儿——你点的那个现成按钮评的压根不是 Agent 的行为。上一篇结尾我说过坎 6 是比接一个 Agent本身更难的话题值得单开一篇。就是这篇。读完你会想清楚三件事为什么现成评估对 Agent 会失效——它错在哪个假设上Agent 到底该评什么——而不是那段最终回答一套能进 CI 的分层评估怎么搭——附关键代码骨架。沿用上一篇的订单助手order-assistant设定代码是可迁移的通用工程模式不涉及具体业务。先分清你评的是聊天还是Agent这是所有误会的根。一个普通 chatbot 的执行模型很简单输入一句话输出一段话。你要评的就是这段话——答得准不准、口气好不好。终答质量基本等于它的全部。Agent 不是。Agent 的执行是多步循环模型先想决定调哪个工具拿到结果再想可能再调下一个工具循环往复最后才吐出那段话。它真正的行为是这中间一整条工具调用轨迹trajectory。图 1聊天是输入 → 一段话的单发式Agent 是想 → 调工具 → 看结果 → 再想 → 再调的多步循环——它的行为是整条轨迹不是末尾那段话。只评最终那段话等于只看考卷上的答案、不看解题过程。答案蒙对了、过程全是错的你照样发现不了——而 Agent 恰恰特别擅长用错误的过程凑出一个看起来对的答案。一句话记住聊天评答得对不对Agent 还得评做得对不对。下面 5 个坑全是从这句话里长出来的。坑 1 · 只评最终那段话不评怎么走到的现象数据集里放的是输入 期望回答评分器拿模型的最终输出跟期望答案比或者用 LLM-as-judge 打个分。分数挺高线上却状况不断。根因这套评估默认了一个聊天时代的假设——“输出那段话 Agent 的行为”。可对 Agent 来说风险和价值都在轨迹里它有没有调该调的工具、参数抽得对不对、有没有多调了不该调的比如把查询走成了退款、有没有为了一件小事绕五轮。这些终答里一个字都看不出来。一个把 refund 误调了、但话术圆回来的回答终答评估会开心地给它打通过。下面这张表最能说明问题——同一个用户问题三条完全不同的轨迹最终回答几乎一样现成的终答评估会给它们全部打通过轨迹模型实际做了什么最终回答终答评估真相AqueryOrder(ORD-123)“已发货预计明天送达”✅ 通过干净、正确B绕三步queryOrder → queryLogistics → queryOrder“已发货预计明天送达”✅ 通过答对了但烧了 3 倍 tokenCrefund(ORD-123)→queryOrder“已发货预计明天送达”✅ 通过误触发了退款终答里一个字都看不出C 是灾难终答评估却和 A 打一样的分。这就是只看答案不看过程的代价。解法把评估对象从终答换成轨迹做轨迹级断言。跑完一条 case把这一轮实际发生的工具调用抓出来针对调了什么、参数对不对、有没有碰红线来断言// 跑完一条 case拿到这一轮实际发生的工具调用序列 ListToolCall actual runAndCaptureToolCalls(assistant, testCase.input()); // 断言行为而不是逐字匹配终答 assertThat(actual) .extracting(ToolCall::name) .containsExactly(queryOrder); // 期望只调这一个工具 assertThat(actual.get(0).arguments()) .containsEntry(orderNo, ORD-123); // 关键参数必须抽对 assertThat(actual) .noneMatch(call - call.name().equals(refund)); // 红线退款工具绝不能被误调关键不是逐字匹配终答而是断言行为。尤其 noneMatch 这类红线断言——危险工具绝不能被误调——比任何终答相似度都重要。至于怎么把工具调用抓出来给模型挂一个 ChatModelListener或者用下面坑 2 的工具包装类顺手记录都行。坑 2 · 重放根本没复现现象同一条 case今天跑通过、明天跑失败换个时间点跑通过率还不一样。你开始怀疑评估本身能不能信。根因你以为在重放历史 case其实没有。现成按钮的重跑是拿旧的输入、重新真跑一遍你的 Agent——而 Agent 里的工具是真调下游的。可下游的库存、订单状态、当前时间早就跟当初录 case 时不一样了。模型这一次看到的工具返回observation和当初那条 golden trace 根本不是一回事。输入相同、观测不同轨迹自然就飘了。这不叫评估这叫掷骰子。说白了你在同时测两样东西——模型 一直在变的下游环境。变量没锁死结论就不可复现。解法冻结环境。把 golden case 里每个工具的入参 → 出参录下来评估时不碰真实下游直接把当初录好的结果确定性地喂回给模型VCR / 磁带式回放。这样模型每次面对的观测完全一致轨迹才可复现、可回归。图 2重跑时工具真打下游、库存和时间都在变回放时把录好的观测原样喂回下游被钉死——评估才测得准。public class ReplayableOrderTools { private final OrderService realService; // 真实下游 private final ToolCassette cassette; // 录制/回放的磁带 private final Mode mode; // RECORD 或 REPLAY public ReplayableOrderTools(OrderService realService, ToolCassette cassette, Mode mode) { this.realService realService; this.cassette cassette; this.mode mode; } Tool(根据订单号查询订单的当前状态和物流信息) public String queryOrder(P(订单号) String orderNo) { if (mode Mode.REPLAY) { // 评估时直接返回当初录下来的结果完全不碰真实下游 return cassette.get(queryOrder, orderNo); } // 录制时真调下游并把 入参 → 出参 存进磁带 String result realService.describeStatus(orderNo); cassette.put(queryOrder, orderNo, result); return result; } }录制一次RECORD 模式打一条真实链路之后所有回归都在 REPLAY 模式下进行。从此评估只测模型这一个变量下游环境被钉死了。坑 3 · 数据集从哪来、golden 怎么定现象道理都懂可你手上根本没有标准答案。人肉去标注每条 case 该走什么轨迹又贵又慢标着标着就放弃了。根因Agent 的对往往不是唯一解。查订单可以先反问单号再查、也可以直接查一件事有好几条都合理的轨迹。你要是按唯一正确轨迹去标既标不出来也不该那么标。解法两步走。第一步数据集从线上捞别凭空造。你都接可观测了真实 trace 就是最好的素材库——按场景采样高频的、出过错的、边界的人工挑出这条走得对的连同当时的工具 I/O 一起固化成一个 golden case。它天然自带坑 2 要的那盘磁带。第二步期望值写成可接受的轨迹不是逐字答案。用宽松匹配关注该调的工具集合、关键参数、绝不能碰的红线以及终答里必须出现的要点而不是逐 token 对比。一条 golden case 大概长这样{ id: order-status-happy-path, input: 帮我查下订单 ORD-123 到哪了, toolOutputs: { queryOrder|ORD-123: 已发货预计明天送达 }, expect: { tools: [queryOrder], mustNotCall: [refund, cancelOrder], answerContains: [已发货] } }toolOutputs 就是冻结环境用的磁带expect 就是轨迹断言的依据。这么一条 JSON坑 1、坑 2、坑 3 全串起来了。坑 4 · 拿跑一次当结论现象同一条 case你手动跑了一次、过了就把它记成通过。可换个人跑、或者过两天再跑结果变了。根因LLM 本身是非确定性的。温度、采样决定了同一个输入可能走出不同轨迹。单次运行的方差很大拿一次结果当结论等于用一个样本估计整体——不靠谱。解法同一条 case 多跑几次看通过率而不是看一次的成败passk 的思路。比如跑 5 次3 次以上走对才算稳定通过偶尔飘一次是概率问题次次飘就是真有毛病。做严格回归时再固定温度、固定随机种子把非确定性尽量压到最低。你要的是这个行为稳不稳定不是这次蒙没蒙对。坑 5 · 评估没进 CI模型悄悄退化现象上线前热热闹闹评了一轮过了。之后有人改了 prompt、有人把模型从大换成小省成本、有人顺手调了个工具描述——没人再评。直到线上出事才发现某个能力早就退化了。根因把评估当成上线前的一次性验收活动而不是持续的回归闸门。可 Agent 的行为对 prompt、模型、工具描述极其敏感任何一处改动都可能悄悄改变轨迹。一次性评估保质期只有一次提交。解法把离线评估集接进 CI。prompt、模型版本、工具描述——任何一项变更都触发这套 offline eval 跑一遍设一条分数闸门比如核心 case 通过率不得低于上次基线不达标就卡住合并。因为坑 2 已经把环境冻结了这套评估不依赖任何外部下游纯离线、够快、够稳进 CI 毫无障碍。这一步才是把前四个坑的收益锁死的地方——评估不进流水线写得再好也只是一次性的自我感动。一张图收尾分层评估长什么样把前面 5 个坑收敛起来就是一套按成本和频率分层的评估体系——越便宜的越靠前、跑得越勤越贵的越靠后、跑得越省图 3分层评估像一道层层放行的漏斗——顶部宽口最便宜、跑得最勤越往下越贵、跑得越少只有少数用例流到最下面那道最贵的评估。下面这张表是每一层的明细。层评什么成本跑的频率1 · 单工具选择给一句话模型该不该调工具、调哪个、参数抽得对不对便宜每次提交2 · 多步轨迹冻结环境回放断言整条工具调用轨迹是否可接受中等改 prompt、换模型时3 · 端到端终答真实或高保真环境LLM-as-judge 人工抽检看最终回答贵发版前三层是层层放行的闸门上一层通过率达标才轮得到跑下一层——把最贵的评估留到最后既省钱又能在前面几层提前拦掉大部分问题。对照开头的三个问题为什么现成评估失效坑 1、坑 2、Agent 该评什么轨迹而非终答、怎么搭一套进 CI 的分层评估坑 3、坑 4、坑 5这篇都给到了。写在最后Agent 的评估之所以难不是因为工具不够花哨而是因为它逼你先想清楚一件事你的 Agent做得对到底是什么意思。想清楚了评估只是把这个定义翻译成断言和数据集想不清楚再贵的平台也只是给你一个会骗人的绿色数字。这也正好是后端工程师的主场——定义正确性、锁死变量、把验证塞进流水线这些本来就是你写了很多年测试练出来的肌肉只不过这次被测的对象换成了一个非确定性的模型。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
)
