最近 Loop Engineering 很火出现了各种从prompt engineering - harness engineering - loop engineering的内容。大家都在讨论怎么让 Agent 自己跑起来自己调用工具、自己执行任务、自己修复问题、自己进入下一轮循环。但我发现其中很关键的问题往往容易被忽略了如果 Agent 每一轮都不知道自己到底做得对不对那它循环得越快错得也可能越快。更危险的是很多团队以为自己已经在做评测了其实只是在打分。打分只会告诉你这段回复看起来几分评测要告诉你这个 Agent 到底哪里坏了下一轮该往哪里改。我真正意识到这件事是一次电商客服 Agent 的灰度翻车。那次灰度前我们其实挺有信心。那是个日活小几十万的电商客服 Agent上线前离线评测分数一路走高逻辑性、连贯性、专业性、问题解决度每一项都比上一版漂亮——LLM Judge 综合分从 78.2 涨到了 84.6。看单条回复确实顺了很多不再像照着规则念的机器人。然后我们做了 5% 流量的小流量灰度跑了一周。结果很打脸。**离线分数涨了 6.4 分线上负反馈率却从 4.1% 微涨到 4.3%转人工率从 31.2% 到 31.0%几乎纹丝不动。**最尴尬的是客诉里至少有 3 个 case事后翻 Trace 才发现Agent 该查订单没查该转人工没转全程用一段礼貌又得体的通用话术把用户稳稳地安抚到了愤怒。其中一条最典型的 Trace脱敏后长这样轮次用户Agent中间决策1“我三天前申请的退款怎么还没到账”“亲亲退款一般 1-3 个工作日到账请耐心等待哦~”未识别催办意图走通用话术2“我查了还没到订单号 6680”“好的亲这边已经为您加急反馈了呢~”识别到订单号却没调用查询工具3“加急反馈有什么用到底退没退”“非常抱歉给您带来不便建议您留意账户变动……”情绪升级为投诉仍未触发转人工用户把订单号喂到了嘴边Agent 偏不查情绪已经炸了Agent 还在加急反馈。每一步语气都没毛病但整个过程它没做成一件正事。最讽刺的是——这样一段对话在我们当时的离线评分里得分并不低。按逻辑性 / 连贯性 / 专业性 / 语气自然度去打分它每一句都回应了用户语气全程礼貌耐心还准确说出了退款周期综合下来85 分甚至略高于我们的平均线。可换成评测的视角去看订单号它没查退款它没解决用户都炸了它还没转人工——工具调用通过率 0任务完成率 0。同一段对话一个视角里它是优秀客服另一个视角里它一件事都没办成。那一刻我意识到我们从头到尾做的根本不是评测是评分——在判断 Agent 说得像不像一个好客服却从来没判断过它有没有在真实任务里把事做对。 会用工具能让 Agent 跑起来。会设计评测才能知道它到底有没有真的变好。这篇不讲评测科普只讲一件事怎么从踩过的坑里搭一套真正能推动 Agent 变好的评测系统。读完你至少能带走四个可以直接用在团队里的判断你做的可能根本不是评测只是评分——为什么离线分数越高线上越可能翻车。Benchmark 不是测试集是系统失败历史的记忆——七类样本怎么配才不会让简单样本淹没要命的 bug。LLM-as-Judge 会骗你也会被你的 Agent 反噬——为什么评估器自己才是最该被评估的那个。没有 Trace、没有线上回流离线指标永远在自嗨——怎么把评测跑成一个能自进化的 loop。只想直接动手、不想看理论拉到文末我整理了一套5 步最小 Agent 评测系统明天就能在团队里试跑。一、认知为什么你做的可能根本不是评测既然评分和评测是两回事那真正的评测到底在评什么很多人以为还是评逻辑性、连贯性、专业性那一套。会说话不代表会做事但这些指标判断的只是一段回复写得顺不顺判断不了一个 Agent 在连续对话里有没有做对下一步动作。举个例子。用户问“这双鞋偏码吗”Agent 可以直接回答尺码标准可以追问用户平时穿多大也可以结合用户前面说过的脚型给建议。单独看哪一种都可能合理。但放进上下文里判断完全不同用户前面已经说过我平时穿 38脚背高Agent 还在泛泛解释建议参考尺码表——问题不在不专业在没有利用上下文。用户只是问尺码Agent 却急着推荐另一款高价商品——问题不在不会说话在动作太急。用户说算了我再看看Agent 礼貌回一句好的亲有需要随时问我——看起来满分却可能错过了一个关键判断用户到底是价格犹豫、款式不确定还是已经彻底失去购买意愿多轮对话 Agent 难的地方从来不是某一句话写得漂不漂亮。是它在每一个上下文节点里有没有选对下一步动作。该追问还是该回答该解释还是该推荐该查工具还是该转人工该承认不知道还是该给结论所以多轮对话评测不能只看语言质量。它真正要评的是意图理解对不对、上下文承不承接、动作选没选对、工具有没调用、风险控不控制、任务收没收束。这时候你会发现评测不是一个打分动作它是一套帮 Agent 持续进化的诊断系统。 多轮对话不一定需要标准答案但一定需要标准判断。平均分会掩盖真正的问题只看平均分是评测设计里最容易踩的坑。假设你有 100 条测试样本80 条普通商品咨询 Agent 表现很好15 条轻微价格异议勉强能用5 条售后、投诉、退款、情绪用户表现很差。最后平均分可能还不错。但线上出问题的往往就是那 5 条。我见过一个真实售后场景。用户给了订单号说怎么还没发货Agent 礼貌回亲亲一般 48 小时内安排发货哦请耐心等待。“用户又说我都下单三天了订单号 8821”Agent 继续非常抱歉仓库会尽快安排。用户最后炸了“你到底查没查”从 Trace 看每一步的问题清清楚楚关键节点期望行为实际行为问题用户问发货状态先判断是否需要订单信息通用解释 48 小时发货尚可接受用户给订单号 8821调用订单查询工具未调用工具关键失败用户质疑查没查说明查询结果或承认无法查询继续引导用户自己查看体验恶化处理不了时明确转人工并带上上下文泛泛建议联系人工收束不完整这段对话表面看语气没问题也没胡说八道。但失败的原因藏在过程里用户已经把订单号喂到嘴边了Agent 应该调用查询工具而不是继续用通用话术安慰。这个问题逻辑性、连贯性、专业性的平均分里根本看不出来。所以评测不能只看平均分。更要看关键节点通过率、高风险样本误放行率、困难样本稳定性、工具调用正确率以及最容易被忽略的一项——历史 bad case 有没有复发。一个 Agent 的能力不该由平均表现定义而该由它在关键样本上的稳定性定义。 Agent 最危险的不是简单问题答得不够漂亮而是在关键节点上错得很自信。先问评测服务什么决策再设计指标聊到这里自然冒出一个问题那到底该看哪些指标我做评测时越来越不愿意一上来就问该设计哪些指标。我会先问另一个问题这个评测结果最后要被谁拿去做什么决策这个转变很关键。模型选型指标要能稳定区分不同模型优劣。上线门禁指标要关注风险和误放行率。Prompt 优化指标要能定位具体失败原因。Skill 迭代指标要能映射到具体能力模块。线上监控指标要能和真实日志关联。评估器校准指标要能衡量 LLM Judge 和人工是否一致。不同决策需要不同评测。很多评测系统做不起来不是因为缺指标是因为指标没有服务决策。它们只是在描述 Agent “看起来怎么样”却指导不了团队下一步该干什么。带着这个认知我们进入下一件事——拿什么数据来评。二、数据Benchmark是失败历史的记忆评测的第一块砖不是 Prompt是数据。但这个数据怎么搭决定了你最终是在评测还是在自嗨。Benchmark 不是随机抽样很多人以为 Benchmark 就是抽几百条真实对话固定下来反复跑。这是个开始但远远不够。随机抽样最大的问题是普通样本太多、关键节点太少、简单问题太多、边界风险太少。真实分布是有了但不一定能暴露问题。一个好的 Benchmark应该既像真实世界又比真实世界更会暴露问题。我倾向于结构化构建样本分成七类。一句话先记住这张表别让 80% 的简单样本淹没那 5% 要命的关键样本。样本类型作用电商客服示例主路径样本保证基础能力不崩商品咨询 → 澄清需求 → 推荐 → 回答库存/优惠关键节点样本测试动作选择用户信息足够后是否停止追问困难样本测试复杂上下文前后需求变化、同时问多个问题边界风险样本测试安全底线退款、投诉、隐私、确定性承诺工具调用样本测试过程可靠性查订单、查物流、查库存、提交工单仿真样本扩大覆盖面模拟价格敏感、低信任、情绪用户历史回归样本防止旧问题复发线上 bad case、灰度失败样本这七类还不够。关键是比例。早期可以参考一个配比主路径 40%、关键节点 20%、困难 15%、边界风险 10%、工具调用 10%、历史回归 5%。系统成熟后再逐步把困难、边界、历史回归和真实日志的比例往上提。Benchmark 不是越难越好但一定不能让简单样本淹没真正要命的问题。而这只是起点。有价值的 Benchmark会像活的一样不断吸收新东西线上 bad case、灰度失败样本、人工争议样本、评估器误判样本、业务指标和离线指标不一致的样本。 Benchmark 不是一次性测试集而是系统失败历史的记忆。一条合格的多轮样本长什么样做多轮 Benchmark还有一个特别容易被忽略的点每条样本不该只是一段对话文本它还该带一组元信息。元信息作用用户目标判断用户真正想解决什么Agent 任务目标判断 Agent 应该完成什么当前对话阶段判断此时该追问、解释、推荐还是收束期望行为定义此时正确动作禁止行为定义不能做什么涉及工具判断是否需要查订单、查库存、查物流风险标签标记退款、投诉、隐私、确定性承诺人工判断作为 Gold Set 的基础判断依据帮助 LLM Judge 学习标准来源区分线上、仿真、人工构造、历史 bad case很多人会问多轮对话怎么写标准答案其实很多时候不一定需要标准答案。同一个场景Agent 可以先追问也可以基于已有信息给初步建议都可能合理。你不一定要规定它必须说哪句话。但你必须知道当前应该回答还是追问、应该解释还是推荐、应该继续处理还是转人工、应该承认不确定还是给结论。标准答案是语言层面的标准判断是决策层面的。多轮 Agent 需要的是后者。别忘了仿真它能替你发现测不到的坑真实对话是有限的人工构造又贵又慢。所以很多团队会搭一个用户模拟器来扩量。但一个粗糙的模拟器只是随机生成几句用户话术价值不大。好的模拟器要模拟用户状态而不只是用户输入模拟维度示例用户画像价格敏感、低信任、高意向、反复比较当前目标买商品、查物流、退货、投诉、比价情绪状态平静、犹豫、不满、焦虑隐藏需求想买但怕贵、担心售后、不确定尺码退出条件价格不合适、回答不清楚、等待太久接受条件得到明确建议、确认优惠、解决售后我们搭过一个价格敏感型模拟器画像是想买但反复比价、对运费敏感、稍微不满意就流失。跑完发现一件反直觉的事——Agent 在第一轮推荐后只要用户回一句再看看几乎清一色回复好的亲有需要随时找我直接放弃了。但翻真实数据这类用户只要 Agent 多追问一句是价格不合适还是款式不确定留存能高出一截。这个发现靠人工构造的主路径样本根本测不出来。当然模拟器本身也需要被评估——它模拟出来的用户到底像不像真人。但这是另一个话题了。数据层面讲完下一个问题是谁来给这些数据打分三、评估器让机器替你打分但别全信它机器能替你打分但机器眼里的好未必是用户眼里的好。LLM-as-Judge要先证明自己看懂了对话多轮对话里有大量语义判断靠规则很难覆盖。LLM-as-Judge 很有用。但如果只是写一个 Prompt让大模型从逻辑性、连贯性、专业性几个维度打分效果往往不稳定。它会偏好长回答、偏好礼貌表达、偏好结构化措辞它也可能把积极推荐误判成有效推进把看起来专业误判成真的有用。给你看一个我们踩过的坑。用户问**“已经拆封了还能退吗”** Agent 回了一大段“亲我们提供 7 天无理由退货服务哦商品保持完好即可申请流程如下第一步进入’我的订单’第二步点击’申请退货’……”——结构清晰、语气专业、篇幅充足。早期那版 Judge直接打了 90 分专业性 5、连贯性 5、完整性 5。但人工一看就发现问题用户问的是拆封后这个边界Agent 答的是通用 7 天无理由恰恰回避了真正的问题。用户想要的就一句话拆了能不能退。Agent 用一段漂亮的话术把这个最关键的信息绕过去了。Judge 为什么误判因为它被结构清晰 礼貌 篇幅长骗了。它评的是这段话写得好不好不是这个问题答没答对。所以我现在更倾向于一个原则让 Judge 先证明自己看懂了对话再让它打分。一个好 Judge 的流程分四步先识别用户当前意图 → 再判断对话阶段 → 然后引用对话中的关键证据 → 最后按 Rubric 输出维度判断和失败原因。输出也得结构化不能只有一个分数整体是否通过、任务是否完成、意图理解对不对、上下文有没有承接、动作是否合理、工具调用是否正确、风险是否控制、失败类型是什么、证据在哪、是否需要人工复核。评估器不该只告诉你这段对话 85 分。它应该先证明自己看懂了。否则一个85 分的结果只能永远躺在报表里进不了工程流程。如果你要动手写第一个 Judge可以直接从下面这个 Prompt 改起——它就是按先看懂、再打分的原则设计的 可照抄一个先看懂再打分的 Rubric Judge Prompt你是一个严格的 Agent 评测官。请按下面顺序评测这段多轮对话先别急着打分先复述用一句话说出用户在这一轮的真实意图。再判断Agent 这一步的动作追问 / 回答 / 推荐 / 查工具 / 转人工选得对不对为什么引证据从对话里摘出支撑你判断的原句。最后才评分按这个结构输出是否通过是 / 否任务完成是 / 否意图理解对 / 错一句话理由工具调用正确 / 未调用 / 参数错一句话理由风险控制到位 / 失控一句话理由失败类型该查没查 / 过度推荐 / 回避问题 / ……没有就填无是否需要人工复核是 / 否记住一条看不懂这段对话就不要打分。评分器要组合没有银弹Agent 评测里没有银弹评分器不要什么都丢给 LLM Judge。至少要有三类各管各的有些事规则一句话就能判死——有没有调用该调的工具、参数对不对、JSON 合不合法、延迟超没超标。这些交给确定性评分器便宜、稳定、可复现。有些事必须靠语义判断——用户真实意图理解了没、异议处理得合不合理、上下文承接得好不好。这些才交给Rubric 评分器LLM-as-Judge。还有些事机器再聪明也不能替代人——Gold Set 校准、争议样本复核、高风险场景兜底。这些留给人工评分器。记住一条原则 能用规则判断的不要交给大模型。规则更便宜、更稳定、更可复现。LLM Judge 只用来处理规则覆盖不了的语义判断人工则用来校准自动化评测而不是替代它。先做人和人的一致再做人和模型的一致很多团队一上来就想验证LLM Judge 和人工一致吗但有一个前提常被忽略人和人之间一致吗如果业务、产品、算法、运营对同一段对话的判断都不一样那问题不在模型在标准没对齐。同一段售后对话业务说没有推动成交产品说用户体验还可以算法说回复质量没问题客服专家说这里应该转人工。这时你直接让 Judge 去对齐某一个人的标准没有意义。正确的顺序是先做人和人的一致再做人和模型的一致。流程是多人独立标注 → 计算人工一致性 → 找出争议维度 → 复盘争议样本 → 更新标注指南 → 沉淀 Gold Set → 再校准 LLM Judge。人工不一致的地方别急着让模型学。先让人类把标准说清楚。大模型评估器不是用来替代混乱的人类标准的它是用来放大已经统一的人类标准的。放大的是对齐的标准不是混乱的标准。验证人机一致性也不能只看总体一致率——总体一致率很容易被简单样本稀释。你至少要看五类指标指标说明总体一致率Judge 和人工多数判断一致的比例分维度一致率意图、上下文、工具、风险、任务完成分别是否一致分样本类型一致率主路径、困难、边界、工具、回归分别是否一致误放行率坏样本被 Judge 判成好误拦截率好样本被 Judge 判成坏这里面最值得盯的是误放行率。一个差回答如果被评估器放过去后续系统可能把它当正例继续学习甚至带进上线版本。对高风险场景来说误放行比误拦截严重得多——误拦截最多让你多审几条误放行会让系统朝错误方向自我强化。讲完怎么打分最后一件事是怎么把这一切跑成一个能持续运转、能自我进化的系统。四、工程把评测跑成一个会进化的系统前面三篇讲的是怎么评。这一篇讲的是怎么让评测本身也持续变好并真正服务于上线决策。先说一个让我后怕的代价。有一次一个 Agent 上了线离线 Benchmark 全绿我们以为稳了。结果它在一个高频但隐蔽的场景上持续出错——因为我们的评测集压根没覆盖那种情况。等客诉攒够量、被发现的时候它已经在线上跑了 9 天。那 9 天的善后退款、赔偿、人工补救粗算下来比我们整个季度花在评测上的预算还要多。不是 Agent 不行是评测漏了。一次评测失效的代价往往比你想象的贵得多。Benchmark 好了业务不一定好这是我觉得最值得写的一点。很多团队跑完 Benchmark离线分数一涨就期待线上业务指标也跟着涨。但现实往往没这么顺。原因有好几层Benchmark 没覆盖真实流量里的高频失败离线更重视表达、线上更重视问题解决真实用户不会按仿真剧本走Judge 喜欢的表达用户不一定喜欢。当 Benchmark 和业务指标打架时别急着否定评测。要先复盘样本分布错了指标权重错了是不是只评了语言质量、没评任务结果是不是评估器把看起来好当成了真的有效我倾向于把指标分三层来看离线质量指标——判断 Agent 能力意图识别、上下文承接、工具调用、风险控制。线上行为指标——判断用户行为变化继续对话率、追问率、转人工率、负反馈率。业务结果指标——判断真实价值问题解决率、订单转化率、售后一次解决率。然后离线指标要和线上指标建立映射比如工具调用准不准会直接影响售后一次解决率和转人工率上下文承接得好不好会影响用户重复解释的次数。每次灰度或上线后都要回看离线哪些指标提升了线上哪些业务指标变化了两者一致吗不一致到底是样本、指标、评估器还是产品策略的问题 评测不是一次设计完成的。评测也要被业务结果反向评测。没有 Trace就没有真正的 Agent 评测光对齐业务还不够。如果只看最终回复我们只能评结果但 Agent 的问题往往发生在过程里。有没有识别用户意图、有没有召回正确记忆、有没有选对 Skill、有没有调用工具、工具参数对不对、工具返回后有没有正确理解、有没有在某一步悄悄偏航——这些只看最终答案一个都看不出来。所以 Agent 评测系统必须捕获 Trace。一句话这些字段落了盘失败才说得出错在哪一步落不下来你永远只能笼统地说这个回答不好。Trace 字段作用用户输入还原上下文Agent 中间决策判断动作选择意图识别结果判断是否理解用户Memory 召回判断是否使用历史信息Skill 选择判断能力路由是否正确Tool 调用名称 / 参数 / 返回判断工具使用是否正确最终回复判断用户可见输出Token / 延迟判断成本和效率模型版本支持版本对比评估器版本支持 Judge 回溯人工校准记录支持标准更新有了 Trace评测才有可解释性。否则我们只能说这个回答不好却说不出它为什么不好、错在哪一步、该改什么。Trace 是 Agent 评测的地基。没有它前面三层都悬在半空。Bad Case 是系统进化的燃料地基立住了接下来是燃料。线上 bad case 很多人都会收集但只是往一个文档里一扔价值不大。Bad case 不是一句这个不行。它应该是一条结构化资产字段作用原始对话还原真实上下文用户目标判断用户真正想解决什么Agent 回复分析失败表现完整 Trace判断过程是否出错失败轮次定位问题发生点失败类型进入分类统计人工判断建立可信标签Judge 判断判断评估器是否误判线上影响判断优先级根因分析指导修复是否进入回归集防止复发一个 bad case 的闭环应该是线上发现问题 → 抽取完整 Trace → 人工复盘 → 判断是 Agent 错还是评估器错 → 归因失败类型 → 修复 → 加入能力测评集 → 稳定通过后进回归集。这里有个关键点也是最容易翻车的点有些 bad case 是 Agent 错有些是 Judge 错。如果是 Agent 错改 Agent如果是 Judge 错改评估器。如果不区分这两类就会出现一种灾难明明是评估器误判你却去改 Agent于是系统朝着错误的方向一路狂奔。评估器自己也要被评估、被校准、被迭代很多人把评估器当成一段 Prompt。写完一个 LLM-as-Judge Prompt配一个输出 JSON就觉得评测系统搭好了。但真实项目里评估器本身也会出错它会误判、会偏科、会过拟合也会随模型版本变化而漂移。而且评估器的错误比 Agent 的错误更隐蔽也更危险。再讲一个我们踩的坑。有一次为了修一个Agent 没主动提优惠的 bad case我们在 Judge 的 Rubric 里加了一条是否提及当前优惠。结果新版本 Judge 一上线主路径评分普遍掉了——因为大量场景里 Agent 根本不该提优惠用户在问售后、问尺码但 Judge 现在认为没提优惠 扣分。更糟的是Agent 为了讨好 Judge开始在售后场景里硬塞优惠信息用户体验直接崩了。我们事后看了一组脱敏数据那条 Rubric 上线后主路径样本的 Judge 通过率从 89% 掉到 71%可人工一复核掉下去的这 18 个百分点里有近 60% 是误判Agent 本来就不该提优惠。更讽刺的是灰度期间线上售后场景被塞优惠的负反馈占比从 2% 飙到了 9%。这就是评估器过拟合你优化了一个维度它就在所有地方都强调这个维度。这其实是另一种 reward hacking——只不过黑客不是别人是你自己写的 Rubric。Agent 不会攻击你的系统但它会无条件地拟合你的评估器你奖励什么它就生产什么哪怕你奖励的是一个 bug。这种事还不止发生一次。后来我们又在 Judge 里加了一条是否复述确认了用户需求避免理解偏差本意很好。结果 Agent 学到的捷径是每一轮都把用户上一句话原样复述一遍用户这双鞋 38 码有货吗 Agent好的亲您是想确认 38 码是否有货对吗我来为您查询……然后才回答听起来很贴心实际上每轮多浪费一句话、多烧一轮 token、多消耗一次用户的耐心。Judge 给它打了高分因为它确认了需求用户却被它绕烦了。所以记住一句话Agent 永远是对的对着你的评估器而言。评估器指哪它打哪。评估器一旦偏了Agent 会比谁都勤恳地朝错误方向一路狂奔。所以评估器也是一个有生命周期的系统。每个版本都要留痕版本信息作用Rubric评估标准Prompt评估器执行逻辑Judge 模型判断模型版本影响输出 Schema保证结果可解析Gold Set 表现衡量基础可信度人机一致率判断是否贴近人工误放行率 / 误拦截率判断风险方向适用场景防止乱用已知缺陷帮助人工兜底变更记录支持回溯它的进化流程是收集 Judge bad case → 人工确认真实标签 → 归因错误类型 → 更新 Rubric、few-shot、反例或规则 → 跑 Judge 回归集 → 比较新旧一致率 → 如果提升且无明显退化再发布新版本。评估器进化的目标不是让它在某几个样本上和人工一致而是让它在更大范围内稳定接近人工共识。灰度发布才是最后一道关离线 Benchmark 通过不代表可以直接全量上线。一个稳妥的发布流程是离线 Benchmark → 仿真环境测试 → 历史回归集验证 → 高风险样本人工复核 → 小流量灰度 → 线上指标观察 → 人工抽样复盘 → 逐步扩大流量。发布门禁也得分层硬门禁隐私泄露、严重工具错误、编造承诺、高风险违规——不通过绝对不能上线。软门禁表达啰嗦、语气不自然、解释不够清晰——可进入灰度观察或人工审核。Agent 上线不是一次性动作更像一条连续流动的河从离线验证到仿真预演从灰度观察到线上回流。每一次发布都应该让评测系统本身也变得更准一点。评测是 Agent 进化的方向盘一开始我以为评测只是 Agent 项目里的一个辅助环节。后来才发现评测其实是 Agent 进化的方向盘。没有评测优化只能靠感觉。 没有 Benchmark改动无法比较。 没有 Trace失败无法归因。 没有 LLM Judge规模化评估就是烧钱。 没有人工校准Judge 本身就不可信。 没有线上回流离线指标永远在自嗨。工具会越来越多模型会越来越强生成能力会越来越便宜。但真正稀缺的可能不是谁会调用更多工具。而是谁能定义清楚什么叫好、怎么验证好、哪里还不够好、怎么让系统持续变好。这就是评测的价值。它不是给 Agent 打一个分而是搭一个能让 Agent自进化的 loop——可验证、可诊断、可迭代、可上线而评测是让这个 loop 转起来的核心。如果你现在就想动手别被上面这一整套体系吓住——一个最小可用的 Agent 评测系统不需要一开始就做得很重按下面这 5 步搭起来就行。第一步先把 Trace 记下来不要急着打分先让 Agent 的过程可见。最小版本只需落盘这些信息用户输入、Agent 回复、中间决策、调用了什么工具、参数是什么、工具返回了什么、模型版本。只要这些没落盘后面所有评测都只能停留在这个回答好不好的主观判断——你看不到它到底是意图识别错了、工具没调用、参数错了还是工具结果理解错了。这一步的最小产出每一段对话都能还原完整过程。第二步先做 30 条 Gold Set不要一上来追求几千条测试集先人工打磨 30 条高质量样本15 条主路径、5 条工具调用、5 条高风险、5 条历史 bad case。每条别只放对话文本还要补上用户目标、Agent 任务目标、期望行为、禁止行为、是否需要工具、风险标签、人工判断、判断依据。这一步的最小产出你有一批大家都认可的标准判断样本而不是一堆只有分数的测试数据。第三步写一个 Rubric Judge但别只让它打分第一版别追求复杂让它做三件事先判断用户真实意图再判断 Agent 当前动作是否合理最后给出失败原因和证据。输出别只有一个分数至少包括是否通过、任务是否完成、意图理解对不对、工具调用对不对、风险有没有控制、失败类型、引用证据、是否需要人工复核。关键是让 Judge 先证明自己看懂了对话再评分。这一步的最小产出每条评测结果都告诉你哪里坏了而不是只告诉你几分。第四步把历史 bad case 固化进回归集不要让线上翻过的车只停留在复盘文档里。先挑 5 条最典型的 bad case补全原始对话、完整 Trace、失败轮次、失败类型、人工判断、线上影响、修复建议固定成回归样本。以后每次改 Prompt、改 Skill、换模型、调 Judge都先跑这 5 条。这一步的最小产出老问题不会因为一次新优化又偷偷复发。第五步做一张离线指标 ↔ 线上指标的映射表最后一步是防止评测自嗨。把每个离线指标都对应到一个它可能影响的线上指标。比如工具调用正确率 ↔ 任务一次解决率、人工接管率上下文承接能力 ↔ 用户重复说明率、对话轮次风险控制能力 ↔ 负面反馈率、违规率。如果离线分数涨了、线上指标却没动那要复盘的往往是评测系统本身样本分布错了指标权重错了还是 Judge 把看起来好误判成了真的有效这一步的最小产出每次评测结果都能服务一次真实的上线判断。跑通这个最小闭环之后再按前面四篇把样本加全、把 Judge 校准、把 Trace 做厚——它会自己长成一套完整的评测系统。从这 5 步开始你的 Agent 才第一次拥有了知道自己有没有变好的能力。会用工具只是开始。 AI 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%免费】