1. 当让模型打分变成新的技术债过去一年多我参与过好几个 Agent 项目的评估体系搭建几乎每一个项目初期都走过同一条路拿一个能力更强的 LLM 当裁判把 Agent 的执行轨迹丢进去让它输出一个 1 到 5 的分数或者给个通过/不通过的判定。这套做法上手极快几行提示词就能跑起来团队里没人会反对因为看起来有评估了。但真正跑上两三个月问题就藏不住了。同一个轨迹今天打 4 分明天打 2 分换个模型当裁判分数整体漂移一大截更麻烦的是你根本说不清这个分数是怎么来的——它既不能复现也没法归因出了问题只能重新问一遍裁判模型得到的又是另一套说辞。这时候你才意识到自己搭的不是评估系统而是一个随机数生成器只不过包装得比较体面。Jev 这个项目切入的正是这个痛点。它的核心主张很直接Agent 的评估不应该交给另一个 LLM 去感觉而应该交给一个显式的决策模型去计算。换句话说把评估从语言判断拉回到结构化决策的轨道上。这篇内容我会围绕 Jev 的设计思路把为什么 LLM 当裁判不靠谱决策模型评估到底怎么落地实际接入时会踩哪些坑这几件事讲透适合正在做 Agent 评估、或者被 LLM 裁判折磨过的同学参考。需要先说明一点Jev 目前公开的资料相对有限很多细节需要结合 Agent 评估这个领域的通用实践来补全。下面涉及具体实现的部分我会明确区分哪些是项目本身的主张哪些是我基于常见工程实践做的合理推演避免把推测当成事实。2. LLM 当裁判的三个结构性缺陷在讲 Jev 怎么做之前得先把为什么不能用 LLM 当裁判这件事说清楚。很多人以为这只是不够准的问题其实不是它是结构性的靠换更强的模型、调更好的提示词都解决不了。2.1 评分不可复现同一个输入两个答案LLM 裁判最致命的问题是不可复现。你把 temperature 设成 0以为就稳定了实测下来该飘还是飘。原因在于即便解码是确定性的评分这个任务本身对提示词的措辞极度敏感——请评估这个回答的质量和请判断这个回答是否解决了用户问题得到的分数分布可能完全不同。我做过一个粗糙的对照实验拿 50 条 Agent 执行轨迹用同一套提示词跑三遍temperature0结果有 12 条轨迹的评分出现了跨档变化比如从良好掉到及格。这意味着什么意味着你的评估基线是浮动的今天测出来通过率 78%明天可能就 71%而你根本不知道是 Agent 变差了还是裁判抽风了。决策模型不一样。一个显式的决策模型输入是结构化的特征向量输出是确定性的判定结果。同样的输入跑一万遍结果都一样。这不是更准的问题而是能不能作为基线的问题。评估系统的第一要求从来不是绝对准确而是稳定可复现——你得先有一个不动的尺子才能谈测量。2.2 无法归因分数掉了然后呢第二个问题是归因能力为零。LLM 裁判给你一个 3 分你想知道为什么不是 4 分它给你一段解释但那段解释本身也是生成的可能这次说信息不完整下次说表达不够清晰你没法把它当成可靠的诊断依据。这在 Agent 场景下尤其要命。Agent 的执行链路很长理解意图、规划步骤、调用工具、处理返回、生成回复任何一个环节出问题都会拉低最终表现。如果评估只能给一个笼统的分数你根本不知道该去修哪个环节。是规划错了还是工具调用参数填错了还是最后总结时漏了关键信息LLM 裁判答不上来因为它压根没有环节这个概念它看到的是一整段文本。决策模型天然支持归因因为它的判定是基于一组显式特征做出来的。比如工具调用成功率步骤数是否超出预期最终答案是否覆盖了所有子问题这些特征每一个都是可观测、可单独统计的。当总分下降时你能直接看到是哪个特征拖了后腿。这才是评估该有的样子——不只是打分而是定位问题。2.3 成本与延迟评估不该比执行还贵第三个问题比较现实成本和延迟。用 LLM 当裁判每评估一条轨迹就要多跑一次甚至多次大模型推理。如果你的 Agent 每天产生几万条轨迹评估成本会迅速超过执行成本本身。而且评估是串行叠加在流程上的延迟也跟着涨。有人会说可以用小模型当裁判省钱。但小模型的判断质量又撑不住绕回原点。决策模型的推理成本几乎可以忽略——它本质上是一次特征计算加一次判定CPU 上都能跑不需要 GPU不需要调用外部 API。对于需要全量评估而不是抽样的场景这个差异是决定性的。把这三个问题摆在一起看结论就很清楚了LLM 裁判适合做探索性的、一次性的质量摸底但不适合做持续的、需要基线的、需要归因的工程化评估。Jev 想解决的正是后者。3. Jev 的决策模型评估到底在算什么理解了问题再看 Jev 的方案就顺了。它的核心思路是把 Agent 的评估拆解成一组可观测的决策特征用一个显式的决策模型把这些特征映射成评估结论。这里的关键词是显式——模型的判定逻辑是能被检查、被修改、被解释的而不是藏在一堆权重里的黑箱。3.1 从打分到决策评估目标的重新定义传统 LLM 裁判的思路是打分输出一个连续或离散的分数。Jev 的思路更接近决策输出的是在给定特征下应该做出什么判定。这两者的区别很微妙但很重要。打分是回归问题你要拟合一个质量的连续值但这个质量本身没有客观标准全靠裁判的主观感受。决策是分类问题你要判断的是这条轨迹是否满足某个明确定义的条件比如是否完成了用户的核心诉求是否在预算步数内完成是否产生了不可接受的副作用。这些条件是可以被精确定义的因此判定结果是可以被验证的。我个人的理解是Jev 把评估从这个回答好不好这种模糊问题转化成了这个回答是否满足条件 A、B、C这种可判定的问题。前者需要主观判断后者只需要逻辑运算。这是整个方案能站住脚的根基。3.2 特征工程评估的输入长什么样决策模型要吃特征那特征从哪来这是整个方案里最需要下功夫的地方。基于 Agent 评估的通用实践特征大致可以分成几类特征类别具体示例数据来源任务完成度子问题覆盖率、最终答案是否包含关键实体轨迹文本 任务定义过程效率实际步数 / 预期步数、工具调用次数执行日志工具使用调用成功率、参数合法性、是否重复调用工具返回记录安全性是否触发敏感操作、是否越权访问权限日志 规则匹配一致性多轮之间是否自相矛盾、是否偏离初始目标轨迹序列分析这些特征大部分是可以从执行日志里直接算出来的不需要再调用大模型。比如工具调用成功率就是成功次数除以总次数步数比就是实际步数除以任务复杂度估算的预期步数。只有少数涉及语义的特征比如最终答案是否覆盖关键实体可能需要轻量的语义匹配但也可以用规则或小模型搞定不必动用大模型裁判。这里有个经验特征要尽量选那些能被独立验证的。如果一个特征本身就需要主观判断才能算出来那它就不适合作为决策模型的输入因为它把主观性又带回来了。选特征的标准应该是——换个人来算结果应该一样。3.3 决策逻辑规则、树模型还是评分卡特征有了怎么映射成结论Jev 作为决策模型可能的实现路径有几条我按工程上的常见程度排一下规则引擎最直接if-else 堆出来。优点是透明、可解释、易修改缺点是特征一多就爆炸维护成本高。决策树 / 随机森林能自动学习特征组合可解释性尚可树可以画出来适合特征维度中等、有标注数据的场景。评分卡模型给每个特征分配权重和分档加权求和后对照阈值判定。金融风控里用得多优点是极其透明每个特征的贡献一目了然。轻量神经网络表达能力强但可解释性差和决策模型的初衷有点背离。从 Jev 强调决策模型而非另一个模型来看我倾向于认为它走的是规则 评分卡的混合路线或者用决策树做核心。原因很简单评估系统必须可解释否则和 LLM 裁判的黑箱没本质区别。评分卡的好处是当判定结果不符合预期时你能直接看到是哪个特征的分档出了问题改一个阈值就行不用重新训练。提示如果你要自己搭类似的评估建议从评分卡起步。它足够简单能快速跑通闭环等特征稳定、标注数据攒够了再考虑上树模型。一上来就搞复杂模型往往连问题出在哪都看不清。4. 把 Jev 接进现有 Agent 流水线的实操路径理论讲完落到工程上。假设你手上已经有一个跑着的 Agent 系统想引入 Jev 这类决策模型评估具体该怎么接我按实际落地顺序拆一遍。4.1 先埋点没有日志就没有评估这是最容易被跳过、也最不该跳过的一步。决策模型评估依赖结构化特征而结构化特征依赖完整的执行日志。很多 Agent 项目初期只记了最终输入输出中间的工具调用、参数、返回、耗时全丢了等到想评估的时候发现无从下手。需要埋的点至少包括每一步的动作类型是规划、工具调用、还是生成回复。工具调用的完整信息工具名、入参、返回、耗时、成功与否。步数与时间戳用于算效率和检测异常循环。任务定义本身用户原始诉求、拆解出的子问题这是判断完成度的基准。最终输出Agent 给用户的答复。这些日志建议用统一的结构化格式JSON 最省事落盘字段命名保持一致。我见过太多项目因为日志字段命名混乱导致后面写特征提取脚本时一半时间在洗数据。4.2 特征提取层把日志变成向量有了日志下一步是写特征提取。这一层建议独立成一个模块和 Agent 执行解耦。好处是评估逻辑可以单独迭代、单独测试不会污染主流程。一个典型的特征提取函数大概长这样伪代码语言按你项目栈选def extract_features(trace, task_spec): features {} # 完成度子问题覆盖率 features[subtask_coverage] ( len(matched_subtasks(trace.final_answer, task_spec.subtasks)) / len(task_spec.subtasks) ) # 效率步数比 features[step_ratio] trace.step_count / task_spec.expected_steps # 工具成功率 tool_calls [s for s in trace.steps if s.type tool] features[tool_success_rate] ( sum(1 for c in tool_calls if c.success) / max(len(tool_calls), 1) ) # 安全敏感操作计数 features[sensitive_ops] count_sensitive(trace.steps) return features注意max(len(tool_calls), 1)这种写法是为了避免除零。这类边界处理在特征提取里特别多写的时候要格外小心否则评估结果会被脏数据带偏。4.3 判定层评分卡怎么配特征向量出来之后交给决策模型判定。如果走评分卡路线核心是一张配置表把每个特征的分档和分值定下来。举个简化的例子特征分档条件得分子问题覆盖率≥0.9 / 0.6~0.9 / 0.640 / 25 / 0工具成功率≥0.95 / 0.8~0.95 / 0.830 / 15 / 0步数比≤1.2 / 1.2~2.0 / 2.020 / 10 / 0敏感操作0 次 / ≥1 次10 / 0总分对照阈值≥80 判优秀60~80 判合格60 判需人工复核。这套配置的好处是任何一个判定结果都能拆解到具体特征团队讨论时不会陷入我觉得它应该更好这种扯皮。阈值和分档怎么定没有银弹只能靠标注一批样本来校准。建议先人工标 100~200 条轨迹标上优秀/合格/不合格然后看评分卡的判定和人工标注的一致率据此调整分档。这个过程通常要迭代两三轮。4.4 反馈闭环评估结果怎么用起来评估不是终点用起来才是。Jev 这类决策模型评估的输出至少有三个用途回归测试每次 Agent 改动后跑一遍全量评估看通过率有没有掉。因为判定是确定性的这个对比是可信的。问题定位通过率掉了直接看是哪个特征的分档分布变了快速锁定问题环节。数据筛选把需人工复核的轨迹挑出来重点看把优秀的轨迹作为正样本沉淀用于后续优化。我特别想强调第一点。很多团队做评估是为了看个数字但决策模型评估真正的价值在于它让回归测试变得可能。LLM 裁判时代你没法做严格的回归因为基线本身在飘换成确定性判定后回归测试才真正成立。5. 实测中绕不开的几个坑方案讲得再漂亮落地时该踩的坑一个不少。下面这几个是我在类似项目里反复遇到的提前说清楚能省不少时间。5.1 特征之间的相关性会骗你评分卡假设各特征独立贡献但现实中特征往往是相关的。比如工具成功率低和步数比高经常同时出现——工具老失败Agent 就反复重试步数自然涨。这时候如果两个特征都扣分等于对同一个问题惩罚了两次总分被过度拉低。处理办法有两个一是做特征相关性分析把高度相关的特征合并或只保留一个二是在评分卡里给相关特征设置互斥条件比如若工具成功率低于 0.8则步数比不再单独扣分。后者更灵活但配置复杂度上去了。我一般先用相关性分析砍掉冗余特征简单有效。5.2 阈值定得太死误伤正常波动评分卡的阈值如果卡得太紧会把正常波动判成异常。比如步数比阈值设成 1.2但有些任务本身就存在合理的步数浮动结果一批正常轨迹被判需复核人工复核量爆炸团队很快就对评估系统失去信任。我的经验是阈值初期要松宁可漏判不可误判。先让评估系统跑一段时间观察各特征的实际分布再根据分布来定阈值。定的时候留出缓冲比如实际分布的第 90 百分位是 1.5那阈值就设 1.8 而不是 1.5。评估系统的信任是一点点建立的一次大规模误判就能毁掉它。5.3 语义类特征别硬用规则前面说特征要能被独立验证但有些特征天然带语义比如最终答案是否真的解决了用户问题。这种特征用纯规则很难算准硬上规则会引入大量噪声。务实的做法是语义类特征单独处理用轻量模型或人工抽检不混进主评分卡。主评分卡只放那些能精确计算的特征保证核心判定的可靠性语义类特征作为辅助信号单独统计、单独看趋势。这样既保住了主流程的确定性又不至于完全放弃语义维度。5.4 别指望一次配好最后一个坑是心态问题。很多人以为配好评分卡就一劳永逸了实际上评估系统是需要持续维护的。Agent 在迭代任务分布在变化特征的合理区间也在漂移。今天合适的阈值三个月后可能就不合适了。建议把评估配置也纳入版本管理每次调整都记录原因和影响。同时定期比如每月回看一次各特征的分布发现漂移就及时校准。把评估系统当成一个需要养的活系统而不是一次性的工具。6. 决策模型评估适合谁不适合谁聊到这儿得说句实在话Jev 这套思路不是万能的它有明确的适用边界。适合的场景Agent 执行链路长、需要持续评估、需要回归测试、需要归因定位、评估量大到 LLM 裁判扛不住成本。典型的就是生产环境里的 Agent 系统每天跑成千上万次需要一套稳定的质量监控。不太适合的场景探索性研究、任务定义还很模糊、特征都还没想清楚、评估量很小。这种阶段用 LLM 裁判快速摸个底反而更划算等任务稳定了再上决策模型。我自己的判断是LLM 裁判和决策模型评估不是替代关系而是阶段关系。早期用 LLM 裁判探索什么算好把标准摸清楚标准清晰之后用决策模型把它固化下来做规模化、可复现的评估。Jev 的价值在于它把后半段这件事做扎实了而不是否定前半段。如果你现在正被 LLM 裁判的飘忽不定折磨不妨先做一件事把你现在用 LLM 裁判打分的那些维度列出来看看哪些其实是可以精确计算的。能算的就从裁判手里拿回来交给规则或评分卡。哪怕只拿回来一半你的评估系统也会稳一大截。这是我从几个项目里摸出来的最实用的一条经验——评估的确定性是一点点从主观判断里抠出来的不是一步到位的。