在 LLM Agent 落地过程中评估环节往往最容易被低估却最容易让项目返工。一个 Agent 能否发布、工具调用链路是否可靠、当前模型是否值得升级这些决策都要以评估结果为依据。可是完整评估成本很高准备基准集、跑多轮对话、逐条人工或模型标注一次全量评估会消耗大量 token 和等待时间。于是出现一个真实问题评估只跑到一半这些部分结果能不能用来支撑决策ParEvalLayer 可以理解为针对这个问题的一类设计思路——在 LLM Agent 评估链路中增加一个分层部分评估层用部分结果先打分、先过滤、先决策只有不确定性高的样本才进入全量评估。本文会把这条思路拆成可落地的方法、代码和排查路径适合正在为 Agent 搭建评测体系、或者想节约评估成本的开发者和算法工程师。1. 先把问题说清LLM Agent 的评估为什么需要分层1.1 Agent 评估的完整链路和真实成本一个 LLM Agent 的完整评估通常不只检查“最终答案对不对”还要检查整个决策过程。以常见的工具调用型 Agent 为例完整评估链路大致是准备评测数据集每个样本包含用户指令、期望行为、环境状态或外部接口 Mock。让 Agent 依次执行任务记录完整轨迹包括模型输出、工具调用参数、执行结果、重试次数。对每条轨迹做多维标注例如最终答案正确性、工具选择合理性、参数是否合法、是否存在幻觉、是否有多余操作。聚合指标得到通过率、失败率、平均轮数、超时率等再决定是否发布或替换模型。这条链路并不复杂但成本非常高。假设评测集有 500 条样本每条 Agent 调用需要 2 分钟串行跑完需要 1000 分钟超过 16 小时即使并行跑token 消耗也相当可观。如果还要用 LLM-as-judge 对每条轨迹做二次标注成本还会翻倍。更麻烦的是评测集不是只跑一次。每次改 Prompt、改工具定义、换模型版本都要重跑回归。于是“全量评估”在发布频率较高的 Agent 项目里往往成为瓶颈。1.2 部分评估不是偷懒是决策时延和成本之间的取舍现实中的决策并不总是需要全部证据。如果一个样本在浅层检查里已经暴露出严重的工具调用格式错误那就没有必要再花成本跑完整对话树如果一个样本的浅层结果非常明确地通过也没有必要为了“形式上的完整”再跑一遍深度验证。这就是 ParEvalLayer 的核心动机把评估拆成多个层级每一层只花上一层的成本得到一部分信号当这部分信号足以支撑“通过”或“拒绝”时就提前做出决策只有当信号不足、结论不确定时才继续进入下一层直到全量评估。可以把这套机制类比 CI/CD 流水线。提交代码后先跑快速编译检查再跑单元测试最后才跑集成测试。大多数提交在早期阶段就会被拦截只有少数进入昂贵阶段。Agent 评估也需要同样的节奏。1.3 ParEvalLayer 的定义边界ParEvalLayer 不是某个固定指标也不是一个官方工具而是一类“评估编排层”的设计模式。它负责按顺序调度多个评估器。把每一层的部分结果汇总成置信度。根据置信度和决策规则输出 pass、reject 或 defer。它不负责替代全量评估。发布前的最终验收、高风险场景的完整评审仍然需要深度评估。ParEvalLayer 的目标是在“整体发布决策”和“单样本决策”之间找到一个成本可控的中间层让大多数样本提前收敛只把真正不确定的样本送到昂贵评估环节。注意部分评估的价值在于“用可控成本排除多数确定性样本”而不是让所有样本都跳过完整评估。设计时先明确哪些决策可以接受部分证据哪些决策必须全量证据。2. 设计一个最小 ParEvalLayer评估信号、置信度和决策规则2.1 把评估拆成三层在设计上可以把评估拆成三层每层对应不同成本和不同信号强度。第一层是浅层规则检查成本最低。它通常不调用大模型或用极小的模型只检查硬性条件输出是否符合 JSON 格式、工具名是否存在、参数类型是否合法、是否出现明显的空输出或超长输出。这一层跑的很快适合对所有样本无条件执行。第二层是语义核对成本中等。用一个 LLM-as-judge 对单轮或短轨迹做关键维度打分例如答案是否相关、是否覆盖用户意图、工具调用是否合理。它不要求完整轨迹只需要关键片段。第三层是深度验证成本最高。它需要完整轨迹、外部 Ground Truth、甚至人工复核。只有前两层无法给出确定结论的样本才会进入这一层。层级典型检查内容单样本成本延迟典型信号L1 浅层规则输出格式、工具名、参数类型、空输出极低毫秒到秒格式是否合法、是否有硬性错误L2 语义核对答案相关性、意图覆盖、单轮工具合理性中秒到分钟语义得分、是否出现明显偏差L3 深度验证完整轨迹、Ground Truth、多轮一致性高分钟到小时最终正确性、完整通过率2.2 评估信号与置信度打分每一层评估器输出的不是一个笼统的“好坏”而是一组结构化信号。每个信号至少包含名字、是否通过、分值、是否关键、补充说明。汇聚这些信号后需要计算两个值置信度和覆盖率。置信度表示当前证据对“样本质量”的判断强度覆盖率表示已经检查的信号占完整信号集合的比例。一个简单但可用的置信度计算公式是confidence (通过信号占比) * 0.6 (信号平均分) * 0.4 coverage 已检查信号数 / 预期信号总数这个公式不是唯一选择但它体现了两个重要原则信号越多、越一致置信度越高覆盖率低时即使当前信号全通过也不能轻易判定为 pass因为还有很多失败模式没有检查到。实际项目中可以换成加权求和但不要丢掉覆盖率这个维度。2.3 决策规则有了置信度和覆盖率就可以定义三层决策当存在任一关键信号失败时直接拒绝不需要再评估因为关键信号失败意味着无论其他维度多好样本都无法接受。当置信度高于接受阈值且覆盖率满足最低要求时判定通过。当置信度低于拒绝阈值时判定拒绝。其余情况进入下一层。如果所有层都跑完仍然不确定最终结果应该偏向拒绝或者转人工复核不能默认通过。这个“不确定即不通过”的收口原则是防止部分评估放走坏样本的关键。3. 用 Python 实现一个可运行的原型3.1 项目结构这里给出一个最小可运行的项目结构用于说明 ParEvalLayer 的编排逻辑。实际项目需要根据自己的模型、评估器和数据格式调整。parevallayer/ ├── config.yaml ├── evaluators/ │ ├── __init__.py │ ├── base.py │ ├── l1_rule.py │ ├── l2_semantic.py │ └── l3_full.py ├── decision.py └── run_eval.py其中base.py定义信号和评估器基类decision.py实现置信度计算和决策规则run_eval.py是入口脚本。3.2 核心代码先定义评估信号结构# evaluators/base.py from dataclasses import dataclass, field dataclass class EvalSignal: name: str passed: bool score: float 0.0 critical: bool False detail: str dataclass class EvalResult: layer_name: str signals: list field(default_factorylist) property def any_critical_failed(self) - bool: return any(not s.passed and s.critical for s in self.signals) property def passed_ratio(self) - float: if not self.signals: return 0.0 return sum(1 for s in self.signals if s.passed) / len(self.signals) property def avg_score(self) - float: if not self.signals: return 0.0 return sum(s.score for s in self.signals) / len(self.signals)然后实现置信度计算和决策函数# decision.py from evaluators.base import EvalResult EXPECTED_SIGNALS 6 # 实际项目按完整信号集合定义 def compute_confidence(result: EvalResult): coverage len(result.signals) / EXPECTED_SIGNALS confidence result.passed_ratio * 0.6 result.avg_score * 0.4 return min(confidence, 1.0), min(coverage, 1.0) def decide(result: EvalResult, cfg): if result.any_critical_failed: return reject, critical_signal_failed confidence, coverage compute_confidence(result) if coverage cfg[require_coverage]: return defer, coverage_too_low if confidence cfg[accept_threshold]: return pass, confidence_high if confidence cfg[reject_threshold]: return reject, confidence_low return defer, need_deeper_check接着是编排层让样本在多个评估器之间流转# run_eval.py from evaluators.base import EvalSignal, EvalResult from decision import decide class ParEvalLayer: def __init__(self, layers, cfg): self.layers layers self.cfg cfg def evaluate(self, sample): for layer in self.layers: result layer.run(sample) action, reason decide(result, self.cfg) if action in (pass, reject): return action, reason, result return reject, all_layers_exhausted, None # 省略各层 evaluator 的细节这里只展示 L1 的示意 class L1RuleEvaluator: def __init__(self): self.layer_name L1 def run(self, sample): signals [] output sample.get(output, ) if not output: signals.append(EvalSignal(has_output, False, 0.0, True, empty output)) else: signals.append(EvalSignal(has_output, True, 1.0, True, )) has_format_error output.startswith(ERROR:) signals.append( EvalSignal(format_error, not has_format_error, 0.0 if has_format_error else 1.0, True, output if has_format_error else ) ) return EvalResult(self.layer_name, signals)这段代码的关键在于每个评估器只负责产出信号不负责决策决策逻辑统一收口在decide函数里。这样新增一个评估器时不需要修改其他层只需要把它加入layers列表。3.3 参数说明config.yaml中的参数会直接决定部分评估的激进程度accept_threshold: 0.8 reject_threshold: 0.4 require_coverage: 0.6 max_layers: 3参数含义典型值调大的影响调小的影响accept_threshold判定通过的置信度下限0.8更保守通过样本更少全量评估比例更高更激进通过样本更多但漏过坏样本风险上升reject_threshold判定拒绝的置信度上限0.4更多样本提前拒绝节省成本但误杀好样本风险上升更少提前拒绝误杀减少成本上升require_coverage允许决策的最低信号覆盖率0.6要求更多信号减少盲目决策允许早期决策速度更快但可靠性下降max_layers最多评估层数3可容纳更复杂评估链路提前收口成本低但可能漏判这里的常见错误是把 accept_threshold 设置过低比如 0.6。表面上看通过率提高了实际上很多“表面上合格”的坏样本被放过了。阈值必须根据历史全量评估结果校准不能凭感觉拍。4. 运行验证怎样判断部分评估的结果可不可信4.1 构造最小评测场景假设要评估一个会调用天气工具和日历工具的 Agent。评测集有 30 条样本每条样本包含用户指令、Agent 输出、以及人工标注的结果标签pass 表示可用fail 表示不可用。运行 ParEvalLayer 后理想输出如下sample_001: pass reasonconfidence_high layers_usedL1,L2 sample_002: reject reasoncritical_signal_failed layers_usedL1 sample_003: defer reasonneed_deeper_check layers_usedL1,L2 - L3其中sample_002在 L1 就因工具名不存在被拒绝省掉了后续所有成本sample_003信号不充分进入 L3 全量评估。这组输出可以直接看到每个样本被哪个层级提前拦截成本节省在哪一段。4.2 用混淆矩阵评估评估器本身ParEvalLayer 本质上是一个分类器它的输出是决策动作。要验证它可不可信不能只跑一次看流程通不通而是要把它的决策和全量评估的“真值”做对比。from collections import Counter stats Counter() for sample in dataset: # dataset 含人工标注 full_label action, reason, _ parevallayer.evaluate(sample) stats[(action, sample[full_label])] 1 print(stats)四类结果最值得关注pass 且真值为 pass正常通过。reject 且真值为 fail正常拒绝。pass 但真值为 fail这是最危险的误放行表示部分评估漏过了坏样本。reject 但真值为 pass误杀表示部分评估过于保守浪费了好样本。决策结果真值 pass真值 failpass正常通过误放行必须压到最低reject误杀影响吞吐正常拒绝defer进入全量评估可接受进入全量评估可接受误放行率应该成为这个评估层最重要的监控指标。只要它在可接受范围内提前拒绝和提前通过就都是划算的。4.3 成本收益对比在阈值为 0.8 和 0.4 的典型配置下30 条样本可能只需要 10 条进入全量评估其余 20 条在 L1 或 L2 阶段就收敛。假设 L1 成本接近 0L2 单条成本是 L3 的十分之一那么整体评估成本可以降到全量评估的 40% 左右。方案单样本平均成本总延迟适用场景全量评估高数小时发布前最终验收只做浅层检查极低分钟级快速冒烟测试不适合做质量结论ParEvalLayer 分层中低分钟到小时日常回归、单样本决策、批量筛选收益不是免费的。部分评估节约的成本需要用误放行率来换。建议每轮跑完都统计一次成本节省和误放行率出现明显偏离时重新校准阈值。5. 常见问题与排查路径5.1 部分评估和全量评估结论不一致现象ParEvalLayer 判为 pass 的样本全量评估发现是坏的或者判为 reject 的样本人工复核后发现其实可用。排查顺序检查这层评估器的信号项是否覆盖了失败模式。很多不一致来自“该查的信号没查”比如只查了输出格式没查工具参数合法性。检查置信度公式是否过于乐观。如果信号平均分虚高confidence 很容易越过阈值。检查是否漏配 critical 标记。一个真正关键信号如果没标记为 critical失败后也不会触发提前拒绝。检查覆盖率要求是否太低。当覆盖率不足时决策依据不完整结论天然不稳定。问题现象常见原因检查方式处理建议误放行坏样本关键失败模式没有对应信号对比全量评估失败原因补充信号项并标记 critical误杀好样本reject_threshold 过高或信号过严统计 reject 样本的人工标签调低 reject_threshold 或放宽信号结论来回抖动覆盖率过低、只跑了部分信号检查 coverage 日志提高 require_coverage5.2 阈值怎么定不要直接用 0.8 和 0.4 上线。阈值应该从一批已经做过全量评估的样本上反向标定。具体做法先收集 200 到 500 条带全量结论的样本用 ParEvalLayer 跑出每条的置信度画出置信度分布。然后观察坏样本集中在哪个置信度区间好样本集中在哪个区间。坏样本置信度普遍高于 accept_threshold说明阈值太高需要上调。好样本置信度普遍低于 reject_threshold说明阈值太低需要下调。两类样本在中间区间重叠严重时说明这一层信号本身区分度不够应该增加信号项而不是继续调阈值。注意当 Agent 的 Prompt、工具定义或底层模型发生变化时置信度分布会随之变化。每次 Agent 版本升级后都要重新校准阈值不能沿用旧配置。5.3 评估结果不稳定、抖动大如果同一批样本连跑两次决策结果差异很大先检查 LLM-as-judge 的温度参数。语义核对层使用 Judge 模型时建议把温度固定为 0并冻结系统提示词。另一个抖动来源是信号的边界情况。某个信号得分在 0.49 和 0.51 之间波动时会把样本从 reject 推向 defer进而触发更昂贵的评估。解决方式是给边界区间加一个“未知区间”落在区间内一律 defer不参与初步决策。还可以对 L2 层使用多 Judge 投票。两个 Judge 结论一致才允许 pass 或 reject结论分歧则进入下一层。这个方案会增加一点成本但能显著降低抖动。6. 生产环境落地建议与扩展方向6.1 从单条决策到批量评估流水线ParEvalLayer 在单条样本上工作但生产环境中更常见的是批量场景。建议把分层逻辑接入两条流水线。一条是 CI/CD 回归流水线每次提交都跑 L1 规则检查只要几分钟Pull Request 阶段跑 L2 语义核对合并或发布前跑 L3 全量评估。这样既保证了每次提交都有快速反馈又不会让每次提交都承担全量评估成本。另一条是每日巡检流水线对线上采集的用户请求样本用 ParEvalLayer 做抽样评估。通过率异常下降时自动告警再由人工介入。这里的重点是“变化检测”不是追求每条的绝对准确。6.2 日志、监控和可追溯性每个决策都要留下完整记录否则无法复盘误放行。建议每条评估记录至少包含样本 ID 和 Agent 版本号。各层信号明细包括通过状态、分值、关键标记。最终决策动作和触发原因。使用到的阈值配置和置信度、覆盖率数值。时间戳和 Judge 模型版本。监控指标至少包括pass 比例、reject 比例、defer 比例、进入全量评估的比例、平均评估成本、误放行率。前四项决定成本结构最后一项决定这个评估层是否可信。日志不要只记录最终结果。没有信号明细的话误放行发生时你根本不知道是哪一层放走的只能重新跑一遍成本更高。6.3 扩展方向部分评估层的设计本身是一个很好的扩展底座。当前用固定阈值做决策后续可以改成基于历史数据动态调整阈值当前是单条样本独立决策后续可以加入批内分布校准避免某批样本整体偏难或偏易。主动学习是另一个有价值的扩展点。所有被 defer 的样本都会进入全量评估这本身就构成了一组高质量标注数据。定期用这些数据反哺阈值校准和信号设计可以让评估层越用越准。多 Agent 协作场景也可以接入这套思路。先对单个 Agent 的局部轨迹做浅层检查再对协作链路做整体语义核对最后才做完整多轮验证。这和单 Agent 的分层思路完全一致只是每一层的评估对象从“一个 Agent 的输出”扩展成了“一段协作轨迹”。接入 ParEvalLayer 前可以按这份清单自检是否已经有一批带全量结论的历史样本用于阈值校准。是否明确哪些信号是 criticalcritical 信号是否有稳定、低成本的检查方式。是否设计了覆盖率下限避免低覆盖率的盲目决策。是否有日志记录每次决策的信号明细而不是只记最终结果。是否监控误放行率而不是只关注成本节省。是否把阈值配置外置化方便 Agent 版本升级后重新校准。这套方法的核心判断是评估的目标不是“把每条都评完”而是“用最低成本做出可靠决策”。把确定性样本快速收敛把不确定样本交给全量评估是成本和质量之间最实用的平衡点。对于正在搭建 Agent 评测体系的团队先从 L1 和 L2 两层跑起来积累一段真实数据后再逐步加入更重的验证层会比一开始就追求全量评估更容易落地。 LLM Agent评估成本高？ParEvalLayer分层部分评估实现高效决策
在 LLM Agent 落地过程中评估环节往往最容易被低估却最容易让项目返工。一个 Agent 能否发布、工具调用链路是否可靠、当前模型是否值得升级这些决策都要以评估结果为依据。可是完整评估成本很高准备基准集、跑多轮对话、逐条人工或模型标注一次全量评估会消耗大量 token 和等待时间。于是出现一个真实问题评估只跑到一半这些部分结果能不能用来支撑决策ParEvalLayer 可以理解为针对这个问题的一类设计思路——在 LLM Agent 评估链路中增加一个分层部分评估层用部分结果先打分、先过滤、先决策只有不确定性高的样本才进入全量评估。本文会把这条思路拆成可落地的方法、代码和排查路径适合正在为 Agent 搭建评测体系、或者想节约评估成本的开发者和算法工程师。1. 先把问题说清LLM Agent 的评估为什么需要分层1.1 Agent 评估的完整链路和真实成本一个 LLM Agent 的完整评估通常不只检查“最终答案对不对”还要检查整个决策过程。以常见的工具调用型 Agent 为例完整评估链路大致是准备评测数据集每个样本包含用户指令、期望行为、环境状态或外部接口 Mock。让 Agent 依次执行任务记录完整轨迹包括模型输出、工具调用参数、执行结果、重试次数。对每条轨迹做多维标注例如最终答案正确性、工具选择合理性、参数是否合法、是否存在幻觉、是否有多余操作。聚合指标得到通过率、失败率、平均轮数、超时率等再决定是否发布或替换模型。这条链路并不复杂但成本非常高。假设评测集有 500 条样本每条 Agent 调用需要 2 分钟串行跑完需要 1000 分钟超过 16 小时即使并行跑token 消耗也相当可观。如果还要用 LLM-as-judge 对每条轨迹做二次标注成本还会翻倍。更麻烦的是评测集不是只跑一次。每次改 Prompt、改工具定义、换模型版本都要重跑回归。于是“全量评估”在发布频率较高的 Agent 项目里往往成为瓶颈。1.2 部分评估不是偷懒是决策时延和成本之间的取舍现实中的决策并不总是需要全部证据。如果一个样本在浅层检查里已经暴露出严重的工具调用格式错误那就没有必要再花成本跑完整对话树如果一个样本的浅层结果非常明确地通过也没有必要为了“形式上的完整”再跑一遍深度验证。这就是 ParEvalLayer 的核心动机把评估拆成多个层级每一层只花上一层的成本得到一部分信号当这部分信号足以支撑“通过”或“拒绝”时就提前做出决策只有当信号不足、结论不确定时才继续进入下一层直到全量评估。可以把这套机制类比 CI/CD 流水线。提交代码后先跑快速编译检查再跑单元测试最后才跑集成测试。大多数提交在早期阶段就会被拦截只有少数进入昂贵阶段。Agent 评估也需要同样的节奏。1.3 ParEvalLayer 的定义边界ParEvalLayer 不是某个固定指标也不是一个官方工具而是一类“评估编排层”的设计模式。它负责按顺序调度多个评估器。把每一层的部分结果汇总成置信度。根据置信度和决策规则输出 pass、reject 或 defer。它不负责替代全量评估。发布前的最终验收、高风险场景的完整评审仍然需要深度评估。ParEvalLayer 的目标是在“整体发布决策”和“单样本决策”之间找到一个成本可控的中间层让大多数样本提前收敛只把真正不确定的样本送到昂贵评估环节。注意部分评估的价值在于“用可控成本排除多数确定性样本”而不是让所有样本都跳过完整评估。设计时先明确哪些决策可以接受部分证据哪些决策必须全量证据。2. 设计一个最小 ParEvalLayer评估信号、置信度和决策规则2.1 把评估拆成三层在设计上可以把评估拆成三层每层对应不同成本和不同信号强度。第一层是浅层规则检查成本最低。它通常不调用大模型或用极小的模型只检查硬性条件输出是否符合 JSON 格式、工具名是否存在、参数类型是否合法、是否出现明显的空输出或超长输出。这一层跑的很快适合对所有样本无条件执行。第二层是语义核对成本中等。用一个 LLM-as-judge 对单轮或短轨迹做关键维度打分例如答案是否相关、是否覆盖用户意图、工具调用是否合理。它不要求完整轨迹只需要关键片段。第三层是深度验证成本最高。它需要完整轨迹、外部 Ground Truth、甚至人工复核。只有前两层无法给出确定结论的样本才会进入这一层。层级典型检查内容单样本成本延迟典型信号L1 浅层规则输出格式、工具名、参数类型、空输出极低毫秒到秒格式是否合法、是否有硬性错误L2 语义核对答案相关性、意图覆盖、单轮工具合理性中秒到分钟语义得分、是否出现明显偏差L3 深度验证完整轨迹、Ground Truth、多轮一致性高分钟到小时最终正确性、完整通过率2.2 评估信号与置信度打分每一层评估器输出的不是一个笼统的“好坏”而是一组结构化信号。每个信号至少包含名字、是否通过、分值、是否关键、补充说明。汇聚这些信号后需要计算两个值置信度和覆盖率。置信度表示当前证据对“样本质量”的判断强度覆盖率表示已经检查的信号占完整信号集合的比例。一个简单但可用的置信度计算公式是confidence (通过信号占比) * 0.6 (信号平均分) * 0.4 coverage 已检查信号数 / 预期信号总数这个公式不是唯一选择但它体现了两个重要原则信号越多、越一致置信度越高覆盖率低时即使当前信号全通过也不能轻易判定为 pass因为还有很多失败模式没有检查到。实际项目中可以换成加权求和但不要丢掉覆盖率这个维度。2.3 决策规则有了置信度和覆盖率就可以定义三层决策当存在任一关键信号失败时直接拒绝不需要再评估因为关键信号失败意味着无论其他维度多好样本都无法接受。当置信度高于接受阈值且覆盖率满足最低要求时判定通过。当置信度低于拒绝阈值时判定拒绝。其余情况进入下一层。如果所有层都跑完仍然不确定最终结果应该偏向拒绝或者转人工复核不能默认通过。这个“不确定即不通过”的收口原则是防止部分评估放走坏样本的关键。3. 用 Python 实现一个可运行的原型3.1 项目结构这里给出一个最小可运行的项目结构用于说明 ParEvalLayer 的编排逻辑。实际项目需要根据自己的模型、评估器和数据格式调整。parevallayer/ ├── config.yaml ├── evaluators/ │ ├── __init__.py │ ├── base.py │ ├── l1_rule.py │ ├── l2_semantic.py │ └── l3_full.py ├── decision.py └── run_eval.py其中base.py定义信号和评估器基类decision.py实现置信度计算和决策规则run_eval.py是入口脚本。3.2 核心代码先定义评估信号结构# evaluators/base.py from dataclasses import dataclass, field dataclass class EvalSignal: name: str passed: bool score: float 0.0 critical: bool False detail: str dataclass class EvalResult: layer_name: str signals: list field(default_factorylist) property def any_critical_failed(self) - bool: return any(not s.passed and s.critical for s in self.signals) property def passed_ratio(self) - float: if not self.signals: return 0.0 return sum(1 for s in self.signals if s.passed) / len(self.signals) property def avg_score(self) - float: if not self.signals: return 0.0 return sum(s.score for s in self.signals) / len(self.signals)然后实现置信度计算和决策函数# decision.py from evaluators.base import EvalResult EXPECTED_SIGNALS 6 # 实际项目按完整信号集合定义 def compute_confidence(result: EvalResult): coverage len(result.signals) / EXPECTED_SIGNALS confidence result.passed_ratio * 0.6 result.avg_score * 0.4 return min(confidence, 1.0), min(coverage, 1.0) def decide(result: EvalResult, cfg): if result.any_critical_failed: return reject, critical_signal_failed confidence, coverage compute_confidence(result) if coverage cfg[require_coverage]: return defer, coverage_too_low if confidence cfg[accept_threshold]: return pass, confidence_high if confidence cfg[reject_threshold]: return reject, confidence_low return defer, need_deeper_check接着是编排层让样本在多个评估器之间流转# run_eval.py from evaluators.base import EvalSignal, EvalResult from decision import decide class ParEvalLayer: def __init__(self, layers, cfg): self.layers layers self.cfg cfg def evaluate(self, sample): for layer in self.layers: result layer.run(sample) action, reason decide(result, self.cfg) if action in (pass, reject): return action, reason, result return reject, all_layers_exhausted, None # 省略各层 evaluator 的细节这里只展示 L1 的示意 class L1RuleEvaluator: def __init__(self): self.layer_name L1 def run(self, sample): signals [] output sample.get(output, ) if not output: signals.append(EvalSignal(has_output, False, 0.0, True, empty output)) else: signals.append(EvalSignal(has_output, True, 1.0, True, )) has_format_error output.startswith(ERROR:) signals.append( EvalSignal(format_error, not has_format_error, 0.0 if has_format_error else 1.0, True, output if has_format_error else ) ) return EvalResult(self.layer_name, signals)这段代码的关键在于每个评估器只负责产出信号不负责决策决策逻辑统一收口在decide函数里。这样新增一个评估器时不需要修改其他层只需要把它加入layers列表。3.3 参数说明config.yaml中的参数会直接决定部分评估的激进程度accept_threshold: 0.8 reject_threshold: 0.4 require_coverage: 0.6 max_layers: 3参数含义典型值调大的影响调小的影响accept_threshold判定通过的置信度下限0.8更保守通过样本更少全量评估比例更高更激进通过样本更多但漏过坏样本风险上升reject_threshold判定拒绝的置信度上限0.4更多样本提前拒绝节省成本但误杀好样本风险上升更少提前拒绝误杀减少成本上升require_coverage允许决策的最低信号覆盖率0.6要求更多信号减少盲目决策允许早期决策速度更快但可靠性下降max_layers最多评估层数3可容纳更复杂评估链路提前收口成本低但可能漏判这里的常见错误是把 accept_threshold 设置过低比如 0.6。表面上看通过率提高了实际上很多“表面上合格”的坏样本被放过了。阈值必须根据历史全量评估结果校准不能凭感觉拍。4. 运行验证怎样判断部分评估的结果可不可信4.1 构造最小评测场景假设要评估一个会调用天气工具和日历工具的 Agent。评测集有 30 条样本每条样本包含用户指令、Agent 输出、以及人工标注的结果标签pass 表示可用fail 表示不可用。运行 ParEvalLayer 后理想输出如下sample_001: pass reasonconfidence_high layers_usedL1,L2 sample_002: reject reasoncritical_signal_failed layers_usedL1 sample_003: defer reasonneed_deeper_check layers_usedL1,L2 - L3其中sample_002在 L1 就因工具名不存在被拒绝省掉了后续所有成本sample_003信号不充分进入 L3 全量评估。这组输出可以直接看到每个样本被哪个层级提前拦截成本节省在哪一段。4.2 用混淆矩阵评估评估器本身ParEvalLayer 本质上是一个分类器它的输出是决策动作。要验证它可不可信不能只跑一次看流程通不通而是要把它的决策和全量评估的“真值”做对比。from collections import Counter stats Counter() for sample in dataset: # dataset 含人工标注 full_label action, reason, _ parevallayer.evaluate(sample) stats[(action, sample[full_label])] 1 print(stats)四类结果最值得关注pass 且真值为 pass正常通过。reject 且真值为 fail正常拒绝。pass 但真值为 fail这是最危险的误放行表示部分评估漏过了坏样本。reject 但真值为 pass误杀表示部分评估过于保守浪费了好样本。决策结果真值 pass真值 failpass正常通过误放行必须压到最低reject误杀影响吞吐正常拒绝defer进入全量评估可接受进入全量评估可接受误放行率应该成为这个评估层最重要的监控指标。只要它在可接受范围内提前拒绝和提前通过就都是划算的。4.3 成本收益对比在阈值为 0.8 和 0.4 的典型配置下30 条样本可能只需要 10 条进入全量评估其余 20 条在 L1 或 L2 阶段就收敛。假设 L1 成本接近 0L2 单条成本是 L3 的十分之一那么整体评估成本可以降到全量评估的 40% 左右。方案单样本平均成本总延迟适用场景全量评估高数小时发布前最终验收只做浅层检查极低分钟级快速冒烟测试不适合做质量结论ParEvalLayer 分层中低分钟到小时日常回归、单样本决策、批量筛选收益不是免费的。部分评估节约的成本需要用误放行率来换。建议每轮跑完都统计一次成本节省和误放行率出现明显偏离时重新校准阈值。5. 常见问题与排查路径5.1 部分评估和全量评估结论不一致现象ParEvalLayer 判为 pass 的样本全量评估发现是坏的或者判为 reject 的样本人工复核后发现其实可用。排查顺序检查这层评估器的信号项是否覆盖了失败模式。很多不一致来自“该查的信号没查”比如只查了输出格式没查工具参数合法性。检查置信度公式是否过于乐观。如果信号平均分虚高confidence 很容易越过阈值。检查是否漏配 critical 标记。一个真正关键信号如果没标记为 critical失败后也不会触发提前拒绝。检查覆盖率要求是否太低。当覆盖率不足时决策依据不完整结论天然不稳定。问题现象常见原因检查方式处理建议误放行坏样本关键失败模式没有对应信号对比全量评估失败原因补充信号项并标记 critical误杀好样本reject_threshold 过高或信号过严统计 reject 样本的人工标签调低 reject_threshold 或放宽信号结论来回抖动覆盖率过低、只跑了部分信号检查 coverage 日志提高 require_coverage5.2 阈值怎么定不要直接用 0.8 和 0.4 上线。阈值应该从一批已经做过全量评估的样本上反向标定。具体做法先收集 200 到 500 条带全量结论的样本用 ParEvalLayer 跑出每条的置信度画出置信度分布。然后观察坏样本集中在哪个置信度区间好样本集中在哪个区间。坏样本置信度普遍高于 accept_threshold说明阈值太高需要上调。好样本置信度普遍低于 reject_threshold说明阈值太低需要下调。两类样本在中间区间重叠严重时说明这一层信号本身区分度不够应该增加信号项而不是继续调阈值。注意当 Agent 的 Prompt、工具定义或底层模型发生变化时置信度分布会随之变化。每次 Agent 版本升级后都要重新校准阈值不能沿用旧配置。5.3 评估结果不稳定、抖动大如果同一批样本连跑两次决策结果差异很大先检查 LLM-as-judge 的温度参数。语义核对层使用 Judge 模型时建议把温度固定为 0并冻结系统提示词。另一个抖动来源是信号的边界情况。某个信号得分在 0.49 和 0.51 之间波动时会把样本从 reject 推向 defer进而触发更昂贵的评估。解决方式是给边界区间加一个“未知区间”落在区间内一律 defer不参与初步决策。还可以对 L2 层使用多 Judge 投票。两个 Judge 结论一致才允许 pass 或 reject结论分歧则进入下一层。这个方案会增加一点成本但能显著降低抖动。6. 生产环境落地建议与扩展方向6.1 从单条决策到批量评估流水线ParEvalLayer 在单条样本上工作但生产环境中更常见的是批量场景。建议把分层逻辑接入两条流水线。一条是 CI/CD 回归流水线每次提交都跑 L1 规则检查只要几分钟Pull Request 阶段跑 L2 语义核对合并或发布前跑 L3 全量评估。这样既保证了每次提交都有快速反馈又不会让每次提交都承担全量评估成本。另一条是每日巡检流水线对线上采集的用户请求样本用 ParEvalLayer 做抽样评估。通过率异常下降时自动告警再由人工介入。这里的重点是“变化检测”不是追求每条的绝对准确。6.2 日志、监控和可追溯性每个决策都要留下完整记录否则无法复盘误放行。建议每条评估记录至少包含样本 ID 和 Agent 版本号。各层信号明细包括通过状态、分值、关键标记。最终决策动作和触发原因。使用到的阈值配置和置信度、覆盖率数值。时间戳和 Judge 模型版本。监控指标至少包括pass 比例、reject 比例、defer 比例、进入全量评估的比例、平均评估成本、误放行率。前四项决定成本结构最后一项决定这个评估层是否可信。日志不要只记录最终结果。没有信号明细的话误放行发生时你根本不知道是哪一层放走的只能重新跑一遍成本更高。6.3 扩展方向部分评估层的设计本身是一个很好的扩展底座。当前用固定阈值做决策后续可以改成基于历史数据动态调整阈值当前是单条样本独立决策后续可以加入批内分布校准避免某批样本整体偏难或偏易。主动学习是另一个有价值的扩展点。所有被 defer 的样本都会进入全量评估这本身就构成了一组高质量标注数据。定期用这些数据反哺阈值校准和信号设计可以让评估层越用越准。多 Agent 协作场景也可以接入这套思路。先对单个 Agent 的局部轨迹做浅层检查再对协作链路做整体语义核对最后才做完整多轮验证。这和单 Agent 的分层思路完全一致只是每一层的评估对象从“一个 Agent 的输出”扩展成了“一段协作轨迹”。接入 ParEvalLayer 前可以按这份清单自检是否已经有一批带全量结论的历史样本用于阈值校准。是否明确哪些信号是 criticalcritical 信号是否有稳定、低成本的检查方式。是否设计了覆盖率下限避免低覆盖率的盲目决策。是否有日志记录每次决策的信号明细而不是只记最终结果。是否监控误放行率而不是只关注成本节省。是否把阈值配置外置化方便 Agent 版本升级后重新校准。这套方法的核心判断是评估的目标不是“把每条都评完”而是“用最低成本做出可靠决策”。把确定性样本快速收敛把不确定样本交给全量评估是成本和质量之间最实用的平衡点。对于正在搭建 Agent 评测体系的团队先从 L1 和 L2 两层跑起来积累一段真实数据后再逐步加入更重的验证层会比一开始就追求全量评估更容易落地。