★ FEATURED ARTICLE 1. 为什么要在 Agent 里塞一个“判断器”做 Agent 开发的人早晚都会撞上同一堵墙模型能说会道但一到“该不该动手、动哪只手、动完算不算完”这种决策环节就开始飘。你让它查个数据它给你写首诗你让它改个配置它把整个文件重写了。这不是模型笨而是我们把“生成”和“决策”这两件事混在了一个黑盒里。所谓给 Agent 加一个“判断器”本质是在生成链路之外单独挂一个负责“拍板”的模块。它不负责写漂亮话只负责回答几个很硬的问题当前这一步要不要执行、走哪条分支、结果是否达标、要不要重试、什么时候该停。Laya 和 Jev 这两个名字最近在 Agent 圈子里被反复提起就是因为它俩分别代表了判断器的两种典型思路——一个偏“决策路由”一个偏“执行裁决”。把这两个概念理清楚再谈部署和选型才不会一上来就陷进“哪个模型更强”的口水战。这篇文章面向的是已经动手写过 Agent、或者正准备把 Agent 从 Demo 推向可用状态的人。我会把判断器的定位、Laya 与 Jev 的分工、Python 环境下的落地方式、本地部署的取舍以及选型时真正该看的指标一条条拆开讲。中间会穿插我自己踩过的坑比如判断器返回格式不稳定导致整个循环卡死、本地部署时显存估算失误、以及“判断器比主模型还贵”这种反直觉的情况。看完你至少能判断自己的项目到底需不需要判断器需要的话该往哪个方向搭。先说一个结论性的认知判断器不是让 Agent 变聪明的它是让 Agent 变“可控”的。聪明靠主模型可控靠判断器。这两件事分开之后你会发现很多之前觉得是“模型能力问题”的 bug其实是架构问题。2. Laya 与 Jev 到底在判断什么2.1 Laya 的定位决策路由管“往哪走”Laya 在 Agent 体系里扮演的角色更接近一个“路由决策层”。它接收的是当前上下文、可用工具列表、以及历史执行轨迹输出的是“下一步该调用哪个工具、带什么参数、或者直接给出最终答复”。你可以把它理解成 Agent 的十字路口交警。它关心的核心问题是分支选择。比如用户问“帮我看看服务器上那个服务还活着吗”Agent 面前可能摆着三条路直接查进程、发个健康检查请求、或者读日志。Laya 要做的不是执行而是判断哪条路当前最合理并且给出理由。这个“理由”很重要因为它是后续可解释性和调试的抓手。Laya 的决策通常依赖几个输入维度任务类型、当前已尝试过的动作、失败次数、以及工具的前置条件是否满足。我实测下来Laya 这类判断器最怕的是“工具描述写得含糊”。如果你给工具的描述是“查询数据”它大概率会乱选写成“根据用户 ID 查询订单表返回订单状态字段仅在该用户已登录时可用”路由准确率会明显上升。这不是 Laya 挑剔而是路由决策天然依赖清晰的选项边界。2.2 Jev 的定位执行裁决管“行不行”Jev 管的是另一件事某个动作执行完之后结果到底算不算成功、要不要继续、要不要回滚。它更像一个质检员加裁判。Laya 决定“去做”Jev 决定“做完之后算不算数”。这个分工在长链路 Agent 里特别关键。举个真实场景Agent 要完成“把配置文件里的超时时间从 30 改成 60”。Laya 决定调用文件编辑工具Jev 则在编辑完成后判断——文件是否真的被改了、改的值对不对、有没有引入语法错误、是否需要重新加载服务。如果 Jev 判定失败它会触发重试或回退而不是让 Agent 傻乎乎地宣布“任务完成”。Jev 的裁决逻辑通常包含三类检查格式校验返回是否符合预期结构、语义校验内容是否满足任务目标、以及副作用校验有没有产生意料之外的变更。第三类最容易被忽略但恰恰是生产环境里最要命的。我见过 Agent 为了改一个字段顺手把整个配置文件的注释全删了主模型觉得“任务完成”Jev 如果只看目标字段就会放行只有加上副作用检查才能拦住。2.3 两者协作时的数据流把 Laya 和 Jev 串起来一个典型的 Agent 循环是这样的上下文进入 LayaLaya 输出动作决策动作被执行执行结果进入 JevJev 输出裁决结论裁决结论再回到上下文进入下一轮 Laya。这个闭环里Laya 和 Jev 是两次独立的模型调用或规则调用它们不共享“想当然”的状态只通过结构化的数据传递。这里有个设计要点Laya 和 Jev 的输出必须是强结构化的最好是 JSON字段固定。我早期图省事让它们返回自然语言结果解析层天天崩一个“好的我认为应该……”就能让整个循环挂掉。后来改成强制 schema稳定性立刻上来了。判断器的价值建立在“可解析”之上不可解析的判断等于没判断。维度Laya决策路由Jev执行裁决输入上下文、工具列表、历史轨迹动作、执行结果、任务目标输出下一步动作及参数成功/失败/重试/回滚核心问题往哪走行不行失败代价走错路浪费轮次误判成功污染状态关键依赖工具描述清晰度校验规则完备度3. 用 Python 把判断器接进 Agent 主循环3.1 环境准备里最容易被忽略的两件事Python 环境本身没什么好说的装个 3.10 以上版本建个虚拟环境就行。但有两件事我要单独拎出来讲因为它们在判断器场景下特别容易出问题。第一件是依赖版本锁定。判断器往往要调用模型接口、做 JSON 解析、可能还要跑本地推理这几类库的版本冲突非常常见。我建议用requirements.txt把版本钉死尤其是模型客户端库和 Pydantic 这类做 schema 校验的库。Pydantic 大版本升级会改校验行为判断器的 schema 一旦校验逻辑变了可能从“严格拒绝”变成“宽松放行”这是灾难性的。第二件是超时和重试策略。判断器是循环里的关键路径它一卡整个 Agent 就停。我踩过的坑是Laya 调用超时设了 30 秒结果一个复杂任务里 Laya 被调了十几次光等待就花了几分钟。后来把判断器的超时压到 8 秒以内并且给它配了降级策略——超时就返回“保守决策”比如“不执行新动作请求人工确认”。判断器可以慢但不能把主循环拖死。# requirements.txt 关键片段 pydantic2.7.1 httpx0.27.0 tenacity8.3.03.2 判断器的输入输出契约设计判断器能不能用八成取决于契约设计。我的做法是给 Laya 和 Jev 各定义一个 Pydantic 模型输入输出都走这个模型任何不符合契约的返回直接判为无效并触发重试。Laya 的输出契约大概长这样一个action字段枚举只能是工具名或final_answer、一个params字段字典、一个reason字段字符串用于日志。Jev 的输出契约则是一个verdict字段枚举pass、retry、rollback、abort、一个detail字段、以及可选的suggestion字段。from enum import Enum from pydantic import BaseModel, Field class LayaAction(str, Enum): call_tool call_tool final_answer final_answer class LayaDecision(BaseModel): action: LayaAction tool_name: str | None None params: dict Field(default_factorydict) reason: str class JevVerdict(str, Enum): pass_ pass retry retry rollback rollback abort abort class JevDecision(BaseModel): verdict: JevVerdict detail: str suggestion: str | None None这套契约的好处是解析失败就是失败不会出现“模型说了句模棱两可的话代码猜半天”的情况。判断器的可靠性从契约的严格程度就定了一半。3.3 主循环里 Laya 和 Jev 的插入位置主循环的结构其实很朴素准备上下文、调 Laya、执行动作、调 Jev、根据 Jev 结果决定下一步。关键在于插入位置不能乱。Laya 必须在动作执行之前Jev 必须在动作执行之后、下一轮 Laya 之前。我见过有人把 Jev 放在循环末尾统一裁决结果一个任务跑了五步才发现第一步就错了前面四步全是无效功。Jev 要尽量贴近动作动作一完成就裁决错了立刻止损。这跟流水线上的质检是一个道理质检点越靠前浪费越少。def run_agent(task, max_turns15): context build_initial_context(task) for turn in range(max_turns): laya_decision call_laya(context) if laya_decision.action LayaAction.final_answer: return laya_decision.reason result execute_tool(laya_decision.tool_name, laya_decision.params) jev_decision call_jev(laya_decision, result, task) if jev_decision.verdict JevVerdict.abort: return f任务中止{jev_decision.detail} if jev_decision.verdict JevVerdict.rollback: rollback_last_action() context update_context(context, laya_decision, result, jev_decision) return 达到最大轮次未完成这段代码里max_turns是必须的。判断器再聪明也可能陷入“重试—失败—重试”的死循环硬性轮次上限是最后一道保险。我一般设 10 到 15 轮复杂任务可以放宽但绝不能没有。3.4 让判断器“说人话”的日志设计判断器的 reason 和 detail 字段千万别浪费。它们是你排查问题的第一手材料。我的做法是把每一轮的 Laya 决策和 Jev 裁决都写进结构化日志带上轮次、耗时、token 消耗。出问题的时候直接看日志就能还原 Agent 的“心路历程”。有个细节日志里要记录判断器的原始返回和解析后的结果。因为很多时候问题出在解析环节原始返回是好的解析错了。把两者都存下来对比一眼就能定位。这个习惯帮我省了大量调试时间。4. 部署这件事本地跑还是走接口4.1 判断器的部署形态选择判断器可以是一个独立服务也可以是一个进程内的函数调用。选哪种取决于你的判断器是“模型驱动”还是“规则驱动”。规则驱动的判断器比如纯 if-else 的校验逻辑直接进程内调用最省事。模型驱动的判断器比如 Laya 和 Jev 这种需要推理的就得考虑部署形态。走远程接口的好处是解耦判断器可以独立升级、独立扩容主 Agent 不用跟着重启。坏处是网络延迟和稳定性风险判断器接口一抖整个 Agent 就卡。本地部署的好处是延迟低、数据不出本地坏处是资源占用和运维成本。我的经验是开发调试阶段走远程接口快速迭代生产环境如果对延迟敏感、或者数据敏感就本地部署。两者可以共存用配置切换。4.2 本地部署时的显存与算力估算本地部署判断器最容易翻车的地方是显存估算。很多人拿主模型的显存需求直接套判断器结果要么浪费要么爆显存。判断器的输入输出通常比主模型短但调用频率高所以它的瓶颈往往不在单次推理的显存峰值而在并发时的显存占用。估算方法很简单先测单次推理的显存占用再乘以你预期的并发数留 30% 余量。比如单次推理占 4GB你预期同时处理 3 个判断请求那就需要 4×3×1.3 约 15.6GB。如果显存不够优先考虑量化版本判断器对精度没那么敏感4bit 量化通常够用。另外判断器的模型规模不必和主模型对齐。一个 7B 的判断器配一个更大的主模型是很常见的组合。判断器要的是“判断准”不是“知识多”。我实测过用 3B 模型做 Jev 的格式校验和语义校验效果和 7B 差距不大但延迟和显存省了一大截。4.3 判断器服务的健康检查与降级判断器作为关键路径上的组件必须有健康检查和降级方案。健康检查不用太复杂一个轻量的探针接口返回判断器是否可用即可。降级方案则要提前想好判断器不可用时Agent 是暂停、还是走保守规则、还是直接失败。我倾向于“保守规则降级”。比如 Laya 不可用时默认不执行新动作返回“需要人工确认”Jev 不可用时默认对动作结果做基础格式校验通过则放行不通过则中止。这样即使判断器挂了Agent 也不会做出危险动作只是效率降低。提示降级逻辑一定要在判断器上线前就写好并测试过。等判断器真挂了再临时加往往来不及而且容易引入新 bug。4.4 部署后的可观测性建设判断器部署完不是终点可观测性才是。你需要能看到判断器的调用量、成功率、平均延迟、解析失败率、以及各类裁决结果的分布。这些指标能告诉你判断器是不是在正常工作。特别要盯的是“解析失败率”和“裁决分布”。解析失败率高说明契约或模型输出有问题裁决分布如果长期偏向某一类比如 90% 都是 pass说明 Jev 可能太宽松形同虚设。我见过一个 Jev 上线两周裁决结果全是 pass一查发现校验规则写错了等于没校验。可观测性就是用来抓这种问题的。5. 选型时真正该看的几个指标5.1 判断准确率怎么测才靠谱判断准确率不能靠感觉得有一批标注好的测试用例。做法是收集一批真实的任务轨迹人工标注每一步“正确的 Laya 决策”和“正确的 Jev 裁决”然后让判断器跑一遍算准确率。这里有个坑测试集要覆盖“边界情况”不能全是简单样本。比如 Laya 的测试集里要有“多个工具都可用时选哪个”“工具前置条件不满足时怎么办”Jev 的测试集里要有“结果格式对但语义错”“结果语义对但有副作用”。这些边界样本才是判断器价值的试金石。我一般要求 Laya 的路由准确率在 85% 以上Jev 的裁决准确率在 90% 以上才考虑上线。低于这个数判断器带来的收益可能抵不过它引入的延迟和复杂度。5.2 延迟与成本的权衡判断器是额外开销这个开销值不值要看它省下了什么。Laya 多花 200ms 做路由可能省下主模型走错路浪费的几秒Jev 多花 300ms 做裁决可能避免一次错误操作导致的回滚成本。算账要算总账不能只盯着判断器本身的耗时。成本上判断器的 token 消耗通常比主模型低但调用次数多。一个 15 轮的 Agent 任务Laya 和 Jev 各调 15 次加起来 30 次判断调用。如果判断器走的是按 token 计费的接口这笔账要提前算。本地部署的话主要是算力成本相对可控。指标建议阈值说明Laya 路由准确率≥85%低于此值收益不明显Jev 裁决准确率≥90%误判成功代价高判断器单次延迟≤500ms超过会拖慢主循环解析失败率≤2%高于此值需检查契约判断器成本占比≤主模型 30%超过需重新评估必要性5.3 判断器与主模型的能力边界选型时最容易犯的错是让判断器去干主模型的活。判断器不该负责生成内容、不该负责复杂推理它只负责在有限选项里做选择、在明确标准下做裁决。一旦你发现判断器的 prompt 越写越长、要考虑的情况越来越多说明它的职责边界模糊了该拆分了。反过来主模型也不该干判断器的活。让主模型自己判断“我这一步做得对不对”等于让考生自己批卷可靠性天然打折。判断器独立出来就是为了引入一个“外部视角”。5.4 开源与闭源判断器的取舍开源判断器的好处是可本地部署、可微调、数据可控坏处是需要自己维护、效果依赖调优。闭源接口的好处是开箱即用、效果稳定坏处是数据要出本地、长期成本可能更高、且受制于服务方。我的建议是如果判断逻辑相对固定、数据敏感优先考虑开源本地部署如果判断逻辑复杂多变、团队没有调优精力先用闭源接口跑通再评估是否迁移。不要一上来就追求“全本地”那往往会让项目卡在部署环节迟迟出不了效果。6. 那些让我熬夜的判断器坑6.1 判断器返回格式不稳定导致循环卡死这是我踩过最狠的一个坑。早期 Laya 返回自然语言我在代码里用正则去抠工具名。大部分时候没问题但模型偶尔会换个说法正则匹配不到代码就抛异常整个 Agent 循环直接挂。更麻烦的是这种失败是间歇性的测试环境复现不了生产环境偶发。后来改成强制 JSON schema并且在调用层加了“解析失败就重试一次再失败就降级”的逻辑才算稳住。教训是判断器的输出契约必须强约束解析层必须容错两者缺一不可。6.2 Jev 太宽松等于没装有段时间我发现 Agent 的“任务完成率”特别高但用户投诉也多。一查发现 Jev 的裁决几乎全是 pass。原因是我的校验规则只检查了“动作是否执行”没检查“执行结果是否符合目标”。比如改配置只要文件被写过就算 pass至于改的值对不对根本没看。修正方法是给 Jev 加了三层校验格式、语义、副作用。语义校验里明确要求“结果必须包含目标字段且值符合预期”。改完之后pass 率降下来了但任务真实完成率上去了。判断器严格一点短期看是“误报”长期看是“保命”。6.3 判断器比主模型还贵这个坑比较隐蔽。有一次我为了追求判断准确率给 Laya 配了一个和主模型同级别的模型结果一算账判断器的 token 消耗占了总成本的 40%。判断器调用次数多单次虽然短但架不住量大。后来换成小模型加规则混合的方案简单路由用规则复杂路由才调模型。成本立刻降下来准确率只掉了两三个点。判断器不是越强越好够用就行。6.4 本地部署时忽略了并发下的显存抖动本地部署判断器单次测试一切正常一上并发就爆显存。原因是判断器的输入长度波动大短请求和长请求混在一起显存占用峰值比单次测试高不少。解决办法是给判断器设输入长度上限超长的先截断或走另一条路径同时按峰值而非均值估算显存。6.5 判断器的“重试”逻辑引发雪崩Jev 判定 retry 时如果重试的还是同一个动作、同样的参数大概率还是失败。更糟的是如果重试逻辑没有退避会瞬间打满判断器和工具接口。我的做法是retry 必须带“修正建议”下一次 Laya 决策时要参考这个建议调整参数同时 retry 次数设上限超过就 abort。7. 判断器上线前我会做的几件事判断器这东西写出来容易用得住难。我在每次上线前都会做几件事算是给自己上的保险。第一件是跑一遍“对抗测试”。故意给 Laya 一些模糊的工具描述、给 Jev 一些“看起来对但其实错”的结果看它们会不会被带偏。判断器的鲁棒性比它在正常样本上的表现更重要。第二件是压测判断器的并发。判断器是循环里的高频组件并发能力不行整个 Agent 的吞吐就上不去。压测时重点看延迟的 P99而不是平均值因为长尾延迟才是拖垮体验的元凶。第三件是准备好“一键关闭判断器”的开关。判断器出问题时能快速切回无判断器的裸奔模式虽然效果差但至少服务不挂。这个开关在紧急情况下能救命。第四件是给判断器配一套独立的监控告警。判断器的失败不应该淹没在主服务的日志里它需要自己的仪表盘和告警规则。判断器静默失败比它报错更可怕。最后分享一个我自己的体会判断器的价值不在于它多聪明而在于它让 Agent 的行为变得“可预期”。一个可预期的、偶尔笨一点的 Agent比一个聪明但不可控的 Agent在生产环境里活得久得多。Laya 和 Jev 只是两种实现思路真正重要的是你愿不愿意把“决策”和“执行”这两件事分开对待。分开之后你会发现 Agent 的调试、优化、上线都变得有章可循了。
阅读完成 · 觉得有帮助？
