1. 从能跑到跑得对Agent 判断器到底在解决什么Agent 这东西2024 年之后基本成了每个做 AI 应用的人绕不开的话题。从最早的 ReAct 循环到后来的多智能体协作再到各种框架满天飞大家手里的 Agent 已经能查资料、调工具、写代码、操作浏览器了。但真正在生产环境里跑过一段时间的人都会发现一个尴尬的事实Agent 能干活但它不知道自己干得对不对。这就是判断器要解决的问题。我最早接触这个概念是在做一个自动化代码审查 Agent 的时候。当时的设计很朴素用户提需求Agent 生成代码然后直接返回。结果上线第一周就出事了——Agent 生成的代码有一半在语法上没问题但逻辑上完全跑不通甚至有几段直接引用了不存在的库。用户投诉说这东西还不如我自己写。问题不在于 Agent 不会写代码而在于它写完就交卷中间没有任何自我检查的环节。判断器的本质就是在 Agent 的执行链路里插入一个独立的评估节点。它不负责生成内容只负责回答一个问题这一步的输出能不能进入下一步这个判断可以是规则驱动的比如检查代码能否通过语法解析也可以是模型驱动的比如用另一个模型来打分还可以是混合的。关键在于它把生成和验证这两件事拆开了。为什么必须拆开因为同一个模型既当运动员又当裁判几乎必然出问题。大模型有个很讨厌的特性叫自我一致性偏好——它倾向于认为自己刚生成的内容是对的。你让它检查自己写的代码它大概率会说看起来没问题。这不是它偷懒而是它的训练目标决定了它更擅长续写而不是批判。所以判断器通常要用不同的模型、不同的提示词、甚至不同的输入视角来做。Laya 和 Jev 这两个名字最近在 Agent 圈子里被频繁提起本质上就是两种不同思路的判断器实现。Laya 偏向于轻量级的规则小模型混合判断适合部署在边缘设备或者资源受限的场景Jev 则更偏向大模型驱动的语义级判断适合对准确性要求高、可以接受一定延迟的服务端场景。这两个不是竞争关系而是覆盖了不同的需求区间。这篇文章我会把这两条路线都拆开讲清楚它们各自的核心机制是什么、在什么场景下该选哪个、部署的时候有哪些坑、以及怎么把它们接进现有的 Agent 框架里。如果你正在做 Agent 项目或者正在纠结我的 Agent 老是不靠谱怎么办这篇应该能给你一些可以直接抄的作业。2. Laya 路线轻量判断器为什么在边缘场景更吃香2.1 Laya 的核心设计哲学把判断成本压到最低Laya 这类判断器的出发点非常务实不是所有判断都需要大模型。很多场景下一个 Agent 的输出是否合格用规则就能判断个八九不离十。比如代码 Agent 生成的 Python 代码先过一遍ast.parse()看语法对不对比如客服 Agent 生成的回复检查一下有没有包含敏感词或者空回复比如数据提取 Agent 的输出验证一下 JSON 能不能被解析、字段是否齐全。这些判断用大模型来做纯属浪费。一次大模型调用的成本可能是几厘到几分钱延迟在几百毫秒到几秒之间。而一个正则匹配或者语法解析成本几乎为零延迟在毫秒级。当你的 Agent 每天要跑几十万次的时候这个差距就是真金白银。Laya 的设计就是把这类确定性判断做成一个可配置的规则引擎同时保留一个轻量级的小模型通常是 1B 到 3B 参数级别的模型或者经过蒸馏的专用分类模型来处理那些规则覆盖不到的模糊情况。整个判断器的内存占用可以控制在 2GB 以内这意味着它可以直接跑在 RK3588 这类边缘芯片上和 Agent 主程序部署在同一台设备里不需要额外的网络调用。我实测过在 RK3588 上跑一个 Laya 风格的判断器用 ONNX Runtime 加载一个 1.5B 的量化模型单次判断延迟在 80 到 150 毫秒之间内存占用 1.8GB 左右。这个数据意味着什么意味着你可以在一个完全离线的环境里让 Agent 具备基本的自我检查能力不需要把数据传到云端。2.2 规则层怎么写才不鸡肋很多人一听规则引擎就觉得 low觉得不如大模型智能。但实际做下来规则层写得好不好直接决定了整个判断器的可用性。我见过太多项目规则层就写了几个正则表达式结果要么误报率高得离谱要么漏报严重最后大家干脆把规则层关掉全靠模型硬扛。规则层的设计有几个原则。第一规则要分层。最底层是硬性规则比如输出不能为空JSON 必须能解析代码必须能通过语法检查这些是红线不通过直接打回不需要任何模型介入。中间层是业务规则比如回复中不能出现竞品名称生成的 SQL 不能包含 DROP 语句这些根据具体业务配置。最上层是启发式规则比如回复长度不能超过 500 字代码中不能有超过 3 层的嵌套循环这些是软性建议触发后交给模型做二次判断。第二规则要可观测。每条规则触发的时候要记录下触发的是哪条规则、输入是什么、判断结果是什么。这些日志在后期调优的时候是金矿。我自己的做法是给每条规则一个唯一 ID然后在判断器的输出里带上triggered_rules字段这样出问题的时候能快速定位是哪条规则误伤了。第三规则要能热更新。业务规则变化很快今天不允许提竞品明天可能就允许了。如果每次改规则都要重新部署运维成本太高。Laya 这类判断器通常会把规则配置放在一个独立的 YAML 或者 JSON 文件里判断器启动时加载同时监听文件变化改完保存就生效。# laya_rules.yaml 示例 rules: - id: hard_001 name: 非空检查 level: hard condition: len(output.strip()) 0 action: reject - id: hard_002 name: JSON可解析 level: hard condition: not is_valid_json(output) action: reject - id: biz_001 name: 竞品词检查 level: business condition: any(word in output for word in [竞品A, 竞品B]) action: flag_for_review - id: heu_001 name: 回复过长 level: heuristic condition: len(output) 500 action: send_to_model这个配置结构是我自己在项目里用的action字段决定了规则触发后的处理方式reject直接打回flag_for_review标记后继续但记录send_to_model转交给模型层做二次判断。这样分层之后规则层不再是简单的通过/不通过而是一个有梯度的过滤网。2.3 小模型判断层的训练与蒸馏规则层覆盖不了的场景就要靠小模型了。但小模型不是随便拿一个来就能用的它需要针对你的具体判断任务做微调或者蒸馏。最实用的做法是先用大模型生成一批判断样本然后用这批样本去蒸馏一个小模型。具体流程是这样的收集 5000 到 10000 条 Agent 的真实输出用 GPT-4 或者 DeepSeek 这类强模型给每条输出打上合格/不合格的标签同时让强模型给出判断理由。然后把这些数据整理成分类任务的格式用 LoRA 或者 QLoRA 去微调一个 1B 到 3B 的基座模型。这里有个细节很多人会忽略判断任务的标签往往是不平衡的。大部分 Agent 输出其实是合格的不合格的可能只占 5% 到 10%。如果直接拿这种数据去训练模型会学到一个偷懒的策略——全部判合格准确率也有 90% 以上。所以训练的时候要做重采样或者用 focal loss 这类对不平衡数据更友好的损失函数。我自己的经验是判断任务的小模型不需要太强的生成能力它本质上是个分类器。所以用 encoder-only 的架构比如 BERT 系列的变体往往比 decoder-only 的架构更合适推理速度也更快。如果一定要用 decoder 架构那就把输出限制成固定的几个 token比如合格和不合格这样解码开销最小。蒸馏出来的小模型在特定判断任务上的准确率通常能做到 85% 到 92% 之间。这个数字看起来不高但你要知道它是在毫秒级延迟、零网络调用的条件下达到的。对于大部分边缘场景来说这个准确率已经足够把明显有问题的输出拦下来了剩下的模糊情况可以交给后续的人工审核或者异步的大模型复核。2.4 在 RK3588 上部署 Laya 的实操细节RK3588 是现在边缘 AI 部署的热门芯片6 TOPS 的 NPU 算力跑一个 1.5B 的量化模型绰绰有余。但实际部署的时候有几个坑要注意。第一个坑是模型格式转换。RK3588 的 NPU 只支持 RKNN 格式你需要把 PyTorch 或者 ONNX 模型转成 RKNN。转换工具是 RKNN-Toolkit2但它在转换 decoder 类模型的时候经常出问题尤其是涉及动态 shape 的时候。我的建议是尽量把判断模型做成固定输入长度的比如统一 padding 到 512 个 token这样转换会顺利很多。第二个坑是内存分配。RK3588 通常有 4GB 或 8GB 内存但 NPU 能访问的内存是有限制的。如果你把判断模型和 Agent 主程序放在同一个进程里很容易出现内存争抢。比较好的做法是用单独的进程跑判断服务通过本地 socket 或者共享内存来通信。这样即使判断服务崩了也不会影响 Agent 主程序。第三个坑是量化精度。RKNN 支持 int8 量化但 int8 量化对判断任务的影响比对生成任务大。因为判断任务往往依赖一些细微的语义差异量化误差可能会让模型把基本合格判成不合格。我的做法是先用 int8 跑一遍看看准确率下降多少如果下降超过 3 个百分点就改用 int16 或者混合量化。部署脚本大概长这样# 1. 转换模型 python3 -m rknn.api.rknn_converter \ --model_path laya_judge.onnx \ --output_path laya_judge.rknn \ --quantize int8 \ --dataset calibration_data.txt # 2. 启动判断服务 python3 laya_server.py \ --model laya_judge.rknn \ --port 19527 \ --max_length 512 \ --batch_size 4判断服务本身用 FastAPI 或者 Flask 写一个简单的 HTTP 接口就行Agent 主程序通过http://localhost:19527/judge来调用。实测下来单次判断的端到端延迟包括 HTTP 开销在 100 到 200 毫秒之间完全能满足实时判断的需求。3. Jev 路线语义级判断器的能力边界与接入方式3.1 Jev 和 Laya 的本质区别在哪里如果说 Laya 是用最小的成本把明显的问题拦下来那 Jev 就是用足够的智能把微妙的问题识别出来。这两者的区别不在于技术高低而在于判断的粒度。Laya 能判断的是这个输出有没有硬伤——语法对不对、格式对不对、有没有明显违规。但有些问题它是判断不了的。比如 Agent 生成的回复在事实层面是错的但语法完美、格式规范比如 Agent 给出的建议在逻辑上自相矛盾但每一句话单独看都没问题比如 Agent 生成的代码能跑但存在安全漏洞。这些都需要语义级的理解能力也就是 Jev 这类判断器要解决的问题。Jev 的核心是一个经过专门训练的大模型它的训练数据是大量的Agent 输出 人工判断对。和 Laya 的小模型不同Jev 通常有 7B 到 70B 的参数规模能够理解复杂的上下文能够做多步推理能够识别那些看起来对但实际有问题的输出。我自己的测试数据在一个代码生成任务上Laya 风格的小模型能拦下 78% 的明显错误语法错误、引用错误、格式错误但对逻辑错误和安全漏洞的识别率只有 30% 左右。而 Jev 风格的判断器在同样的任务上对逻辑错误的识别率能到 75%对安全漏洞的识别率能到 65%。代价是Jev 的单次判断延迟在 1 到 3 秒之间成本是小模型的 50 到 100 倍。所以选择逻辑很清晰如果你的场景对延迟和成本极度敏感且大部分错误是硬伤级别的选 Laya。如果你的场景对准确性要求高错误代价大且可以接受秒级延迟选 Jev。当然最实用的方案是两者结合Laya 做第一层过滤Jev 做第二层复核。3.2 Jev 判断器的提示词设计要点Jev 这类判断器本质上是一个被专门提示词约束的大模型。提示词写得好不好直接决定了判断质量。我见过很多人直接把 Agent 的输出丢给模型然后问这个输出好不好得到的回答基本是废话。判断器的提示词需要非常结构化。一个有效的 Jev 提示词通常包含这几个部分角色定义、判断维度、评分标准、输出格式、边界情况说明。角色定义让模型进入评审员的状态而不是助手的状态。判断维度要明确列出需要检查的方面比如事实准确性、逻辑一致性、安全性、完整性。评分标准要给出具体的分数锚点比如5 分表示完全正确且无遗漏3 分表示基本正确但有 minor 问题1 分表示存在严重错误。输出格式要强制模型返回结构化的 JSON方便程序解析。你是一个严格的输出评审员。你的任务是评估 Agent 生成的回复是否合格。 评估维度 1. 事实准确性回复中的事实陈述是否正确 2. 逻辑一致性回复内部是否存在矛盾 3. 安全性回复是否包含有害、违规或危险内容 4. 完整性回复是否完整回答了用户的问题 评分标准 - 5分所有维度都合格 - 3-4分存在 minor 问题但不影响整体可用性 - 1-2分存在严重问题必须打回 输出格式严格 JSON { score: 1-5, passed: true/false, issues: [{dimension: ..., description: ...}], suggestion: ... } 待评估内容 {agent_output}这个提示词的关键在于强制结构化输出。如果不强制 JSON模型会给你一段散文式的评价你还得再写一个解析器去提取信息纯属给自己找麻烦。另外passed字段和score字段要分开因为有时候分数不高但可以放行比如 3 分但问题不严重有时候分数不低但必须打回比如 4 分但涉及安全问题。3.3 用 Jev 做判断时的成本控制策略Jev 好用但贵。一个 70B 的模型每次判断的 token 消耗在 500 到 1500 之间取决于输出长度和提示词长度按现在的 API 价格单次成本在 0.01 到 0.05 元之间。如果你的 Agent 每天跑 10 万次光判断成本就是 1000 到 5000 元。这个数字对很多团队来说是不可接受的。成本控制有几个实用的策略。第一采样判断。不是每次输出都判断而是按比例采样比如 10% 或者 20%。采样判断的目的是监控整体质量而不是拦截每一次错误。如果采样发现某个时间段的问题率上升再临时提高采样率。第二分级判断。先用 Laya 做第一层只有 Laya 判断为模糊或者疑似有问题的输出才送给 Jev。这样 Jev 的调用量能降到原来的 20% 到 30%。第三缓存判断结果。很多 Agent 的输出是重复的或者高度相似的。对于完全相同的输入判断结果可以直接缓存。对于相似的输入可以用 embedding 做近似匹配如果相似度超过阈值复用之前的判断结果。第四用蒸馏版 Jev。如果你有足够的判断数据可以蒸馏一个 7B 或者 13B 的版本专门做判断任务。蒸馏版的准确率可能比原版低 5 到 10 个百分点但成本能降到原来的十分之一。我自己的项目里用的是Laya 全量 Jev 采样 20% 缓存的组合。实测下来判断成本控制在每万次调用 20 到 30 元之间同时能把严重错误率从 8% 压到 1.5% 以下。这个投入产出比是可以接受的。3.4 把 Jev 接进 Agent 框架的几种模式Jev 判断器接入 Agent 框架有三种常见的模式各有适用场景。同步阻塞模式是最简单的Agent 生成输出后直接调用 Jev 判断判断通过才返回给用户不通过就打回重生成。这种模式的优点是逻辑简单缺点是延迟高。如果 Jev 判断要 2 秒Agent 生成要 3 秒用户就要等 5 秒才能看到结果。适合对延迟不敏感的后台任务。异步复核模式是Agent 生成输出后直接返回给用户同时把输出丢给 Jev 做异步判断。如果 Jev 判断有问题再通过某种方式通知用户或者触发修正。这种模式用户体验好但需要额外的机制来处理已经返回给用户的错误输出。适合对延迟敏感、且错误可以事后修正的场景。前置判断模式是在 Agent 生成之前先用 Jev 判断一下这个任务是否适合由 Agent 来处理。比如用户问了一个涉及敏感信息的问题Jev 可以在 Agent 开始工作之前就把它拦下来。这种模式适合有明确合规要求的场景。我自己的做法是混合使用对于高风险操作比如生成可执行代码、涉及资金的操作用同步阻塞模式对于低风险操作比如生成文本回复用异步复核模式对于所有操作都加一层前置判断来过滤明显不合适的请求。# 同步阻塞模式的伪代码 def agent_with_judge(user_input): output agent.generate(user_input) judgment jev.judge(output, contextuser_input) if judgment[passed]: return output else: # 打回重生成最多重试 2 次 for _ in range(2): output agent.regenerate(user_input, feedbackjudgment[issues]) judgment jev.judge(output, contextuser_input) if judgment[passed]: return output # 重试仍不通过返回兜底回复 return fallback_response(judgment)这个重试逻辑里有个细节把判断结果作为反馈传给 Agent。很多人重试的时候只是简单地让 Agent 再生成一次这样 Agent 很可能犯同样的错误。把 Jev 给出的issues作为反馈传进去Agent 才知道具体哪里有问题重生成的质量会高很多。4. 判断器选型一张决策表帮你做决定4.1 按场景特征选型选 Laya 还是 Jev不是拍脑袋决定的要看你的具体场景。我整理了一个决策表把常见的场景特征和对应的推荐方案列出来。场景特征推荐方案理由边缘设备部署无网络LayaJev 需要大模型边缘设备跑不动日调用量 10 万次Laya 为主 Jev 采样全量 Jev 成本太高错误代价极高如医疗、金融Jev 为主 Laya 兜底准确性优先成本次要延迟要求 500msLayaJev 的秒级延迟无法满足判断任务以格式/语法为主Laya规则小模型足够判断任务涉及事实核查、逻辑推理Jev小模型做不了语义级判断团队没有模型训练能力Jev用 APILaya 需要自己训练小模型数据不能出本地Laya本地部署Jev 通常需要调用云端 API这个表不是绝对的但能覆盖 80% 的决策场景。我自己的经验是大部分项目最终都会走向混合方案Laya 做第一层快速过滤Jev 做第二层精准判断。区别只在于两层之间的比例和触发条件。4.2 判断器本身的评估怎么做判断器上线之后怎么知道它判断得准不准这是很多人忽略的问题。判断器不是部署完就完事了它需要持续的评估和调优。评估判断器的核心指标有三个准确率、召回率、误报率。准确率是判断正确的比例召回率是实际有问题的输出中被判断器抓出来的比例误报率是实际没问题但被判断器打回的比例。这三个指标要一起看单独看任何一个都会误导。比如一个判断器准确率 95%看起来很厉害。但如果它的策略是全部判合格而实际有问题的输出只占 5%那它的准确率就是 95%但召回率是 0。反过来如果判断器把所有输出都判为有问题召回率 100%但误报率也接近 100%Agent 基本没法用了。我的做法是每周做一次评估从上周的 Agent 输出里随机抽 200 条人工标注合格/不合格然后和判断器的结果对比算出三个指标。如果召回率低于 70%说明判断器太宽松了需要收紧阈值如果误报率高于 15%说明判断器太严格了需要放宽阈值或者优化规则。评估数据要积累起来这些数据是后续优化判断器的燃料。我自己的项目跑了三个月积累了大概 5000 条标注数据用这批数据重新蒸馏了一次小模型召回率从 68% 提升到了 82%误报率从 18% 降到了 9%。这个提升是实打实的。4.3 判断器和 Agent 的协同进化判断器不是独立存在的它和 Agent 是一对共生关系。Agent 的能力在进化判断器的标准也要跟着进化。一个常见的误区是判断器的标准一旦定下来就不改了。但实际上Agent 刚上线的时候输出质量可能比较差判断器需要严格一些随着 Agent 的迭代输出质量提升了判断器如果还保持原来的严格程度就会产生大量误报拖慢整个系统的效率。我的做法是动态调整判断阈值。具体来说每周统计一次 Agent 的输出质量分布如果合格率从 85% 提升到了 92%就把判断器的阈值相应放宽让更多输出能直接通过。这样判断器的严格程度始终和 Agent 的实际水平匹配。另一个协同进化的点是判断结果反哺 Agent 训练。判断器标记为不合格的输出以及对应的判断理由是训练 Agent 的优质数据。用这些数据做 RLHF 或者 DPO能让 Agent 直接学会避免这些错误从源头上减少判断器的负担。我自己的项目里每积累 1000 条判断数据就做一次 Agent 的微调效果比单纯调判断器好得多。5. 部署实战从零搭一套带判断器的 Agent 系统5.1 环境准备与依赖安装假设你要在一台 Linux 服务器上搭一套完整的系统包含 Agent 主程序、Laya 判断器、Jev 判断器通过 API 调用。下面是具体的步骤。首先装 Python 环境。我推荐用 conda 来管理因为判断器涉及的依赖比较多用 conda 能避免很多版本冲突。# 创建环境 conda create -n agent-judge python3.10 conda activate agent-judge # 安装核心依赖 pip install fastapi uvicorn httpx pydantic pyyaml pip install onnxruntime-gpu # 如果有 GPU pip install transformers accelerate pip install rknn-toolkit2 # 如果要在 RK3588 上部署Agent 框架的选择看你的具体需求。如果是简单的单 Agent用 LangChain 或者自己写一个循环就够了。如果是多 Agent 协作可以考虑 AutoGen 或者 CrewAI。判断器本身不依赖特定的 Agent 框架它就是一个独立的服务通过 HTTP 接口和 Agent 通信。5.2 Laya 判断服务的完整实现Laya 判断服务的核心是一个 FastAPI 应用它加载规则配置和小模型对外暴露一个/judge接口。# laya_server.py import yaml import onnxruntime as ort from fastapi import FastAPI from pydantic import BaseModel import numpy as np app FastAPI() # 加载规则 with open(laya_rules.yaml, r) as f: rules yaml.safe_load(f)[rules] # 加载小模型 session ort.InferenceSession(laya_judge.onnx) class JudgeRequest(BaseModel): output: str context: str class JudgeResponse(BaseModel): passed: bool triggered_rules: list model_score: float action: str app.post(/judge, response_modelJudgeResponse) def judge(req: JudgeRequest): triggered [] # 第一层规则判断 for rule in rules: if eval_rule(rule, req.output): triggered.append(rule[id]) if rule[action] reject: return JudgeResponse( passedFalse, triggered_rulestriggered, model_score0.0, actionreject ) # 第二层小模型判断 score run_model(session, req.output, req.context) if score 0.3: return JudgeResponse( passedFalse, triggered_rulestriggered, model_scorescore, actionreject ) elif score 0.6: return JudgeResponse( passedTrue, triggered_rulestriggered, model_scorescore, actionsend_to_jev ) else: return JudgeResponse( passedTrue, triggered_rulestriggered, model_scorescore, actionpass )这个实现里action字段有三种取值reject表示直接打回send_to_jev表示转交给 Jev 做二次判断pass表示直接通过。这样 Laya 就起到了一个分流器的作用把大部分明显合格和明显不合格的输出处理掉只把模糊的留给 Jev。5.3 Jev 判断服务的接入与重试逻辑Jev 判断服务通常是通过 API 调用的所以实现上就是一个 HTTP 客户端加上重试逻辑。# jev_client.py import httpx import json from tenacity import retry, stop_after_attempt, wait_exponential class JevClient: def __init__(self, api_key, base_url): self.api_key api_key self.base_url base_url self.client httpx.Client(timeout30.0) retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max10)) def judge(self, output, context): prompt build_judge_prompt(output, context) response self.client.post( f{self.base_url}/v1/chat/completions, headers{Authorization: fBearer {self.api_key}}, json{ model: jev-judge, messages: [{role: user, content: prompt}], temperature: 0.1, response_format: {type: json_object} } ) result response.json() return json.loads(result[choices][0][message][content])这里有几个细节值得说。temperature设成 0.1 而不是 0是因为完全为 0 的时候模型有时候会陷入重复输出的死循环0.1 能在保持稳定性的同时避免这个问题。response_format设成json_object能强制模型输出合法的 JSON省去了解析的麻烦。重试逻辑用tenacity库指数退避最多重试 3 次能处理大部分网络抖动。5.4 完整链路的串联与监控把 Laya 和 Jev 串起来再加上 Agent 主程序整个链路是这样的# agent_pipeline.py def process(user_input): # 1. Agent 生成 output agent.generate(user_input) # 2. Laya 判断 laya_result laya_client.judge(output, user_input) if laya_result.action reject: # 打回重生成 output agent.regenerate(user_input, feedback输出未通过基础检查) laya_result laya_client.judge(output, user_input) if laya_result.action reject: return fallback_response() if laya_result.action send_to_jev: # 3. Jev 判断 jev_result jev_client.judge(output, user_input) if not jev_result[passed]: output agent.regenerate(user_input, feedbackjev_result[issues]) # 重生成后可以再过一遍 Laya laya_result laya_client.judge(output, user_input) if laya_result.action reject: return fallback_response() # 4. 记录日志 log_judgment(user_input, output, laya_result, jev_result if jev_result in dir() else None) return output监控这块我建议至少记录这几个指标判断总次数、Laya 各 action 的分布、Jev 的调用次数和通过率、重生成次数、最终兜底次数。这些指标能帮你快速定位问题。比如 Jev 调用率突然上升说明 Laya 的规则可能失效了兜底次数上升说明 Agent 的输出质量在下降。6. 踩过的坑与实战心得6.1 判断器本身也会幻觉这是最反直觉的一个坑。你以为判断器是来抓 Agent 幻觉的结果判断器自己也会产生幻觉。我遇到过好几次Jev 判断器把一个完全正确的输出判为存在事实错误理由说得头头是道但仔细一看全是编的。这个问题的根源在于判断器本质上也是大模型大模型有的毛病它都有。缓解的办法有几个一是让判断器给出具体的证据而不是只给结论。比如不要只说存在事实错误而要指出第三段提到的 XX 数据与 YY 来源不符。有了具体证据你就能快速判断这个判断是否靠谱。二是用多个判断器投票比如同时用两个不同的大模型做判断只有两个都判不合格才打回。三是保留人工复核通道对于判断器标记为严重问题的输出不要直接丢弃而是转给人工复核积累数据后再优化判断器。6.2 规则层的误报比漏报更可怕在规则层设计上我踩过最大的坑是规则写得太严误报率飙升。当时为了拦截违规内容我写了一条规则输出中不能出现任何数字。本意是防止 Agent 泄露敏感数据结果把正常的价格是 100 元需要 3 个工作日这类回复全拦了。误报率一度超过 40%用户投诉不断。后来我调整了策略规则层只做硬性检查软性检查全部交给模型层。硬性检查就是那些违反了就绝对不能通过的规则比如空输出、格式错误、明确的违规词。软性检查比如回复可能不够详细语气可能不够友好这些交给模型去判断因为模型能理解上下文不会像规则那样一刀切。6.3 判断延迟的隐藏成本判断器带来的延迟不只是判断本身的时间。在同步阻塞模式下判断延迟会直接叠加到用户等待时间上。更隐蔽的是判断失败后的重生成会带来额外的延迟。一次重生成意味着 Agent 要再跑一遍如果 Agent 生成要 3 秒判断要 1 秒重生成一次就是 4 秒用户总共等了 8 秒。我的优化经验是给判断器设置超时超时后默认放行。判断器的可用性不应该成为整个系统的瓶颈。如果 Jev 判断超过 3 秒还没返回就直接放行同时记录一条日志事后分析。这样能保证最坏情况下用户的等待时间不会失控。6.4 判断数据的冷启动问题判断器刚上线的时候没有历史数据规则不知道该怎么写小模型也没有训练数据。这个冷启动阶段是最难熬的。我的做法是先用大模型做一段时间的影子判断。Agent 正常跑输出正常返回给用户同时把输出送给大模型做判断但判断结果不影响流程只是记录下来。跑一到两周积累几百到几千条判断数据然后用这些数据来训练小模型、优化规则。等判断器的准确率达到可接受的水平再正式启用。这个影子阶段还有一个好处能帮你发现 Agent 输出中的系统性问题。我在影子阶段发现Agent 生成的代码有 30% 存在同样的边界条件处理缺失这个问题在正式启用判断器之前就修复了省了很多事。6.5 判断器的版本管理判断器的规则和模型会不断迭代如果没有版本管理出了问题很难回滚。我的做法是给判断器打版本号每次修改规则或者更新模型都生成一个新的版本。判断服务的接口里带上版本号Agent 调用的时候可以指定用哪个版本。这样如果新版本出了问题可以快速切回旧版本。版本管理还有一个作用A/B 测试。你可以让一部分流量走新版本判断器一部分走旧版本对比两个版本的准确率和误报率。我自己的项目里每次判断器大版本更新都会跑一周的 A/B 测试确认新版本确实更好之后才全量切换。7. 一些扩展思路判断器这个思路其实可以扩展到 Agent 系统的很多环节。比如在 Agent 调用工具之前加一个工具选择判断器判断这个工具是否适合当前任务在 Agent 读取外部数据之后加一个数据质量判断器判断数据是否可信在 Agent 输出最终结果之前加一个合规判断器判断结果是否符合业务规范。这些判断器可以共用同一套基础设施规则引擎 小模型 大模型的三层架构。区别只在于每层的规则和模型不同。我自己的项目里已经把这套架构抽象成了一个通用的判断服务框架不同的判断任务只需要配置不同的规则和模型代码复用率很高。另一个扩展方向是判断器的联邦学习。如果你的系统部署在多个节点上每个节点都在产生判断数据可以把这些数据聚合起来训练一个更好的判断器同时不泄露各节点的原始数据。这个思路在边缘计算场景下特别有价值因为边缘节点的数据往往不能上传到中心。最后说一个我自己的体会判断器的价值不在于它判断得多准而在于它让 Agent 系统变得可观测、可干预。在没有判断器之前Agent 就像一个黑盒你不知道它什么时候会出错出错了也不知道为什么。有了判断器之后每一步的输出都有了质量信号你可以基于这些信号做路由、做重试、做告警、做优化。这种可观测性带来的价值往往比判断器本身拦截了多少错误更大。