今天想聊一个我给 Agent 做改造时反复用到的东西判断器。先看一张经常出现的“事故现场”Agent 在一个任务里跑得很欢工具调用一个接一个但突然在某一步做出了明显不合理的操作比如把不该删的配置删了、在错误的环境里执行了命令、或者在一个问题上反复重试同一个方案。你会发现模型本身没有变笨问题出在它的执行链路里缺了一个“把关的人”。我最近在多个 Agent 项目里实践了一种做法在 Agent 的决策和执行之间插入一个独立的判断模块把“要不要做”“选哪个方案”“现在的结果靠不靠谱”这类问题交给一个专门的模型去回答。这个模块就是标题里说的“判断器”。围绕这个思路我重点对比了 Laya 和 Jev 两个模型一个偏向快速决策一个偏向深度评估配合不同的部署方式几乎能覆盖从轻量工具型 Agent 到重型编码 Agent 的全部场景。这篇文章会把整个思路、选型逻辑、部署细节和踩坑记录都写出来。适合谁看正在给 Agent 加自我校验能力的开发者、想把决策模型接到自己项目里的同学、以及被“Agent 乱跑”问题折磨的一线工程师。我会把能直接抄作业的配置、代码和排查表放在后面几节。1. Agent 为什么需要“判断器”1.1 执行失控的典型症状先说说我观察到的 Agent 执行失控的几种典型表现你可以对照自己的项目看看有没有中招。第一种是“多头并进式失控”。模型为了“高效”一次性生成了多个可并行的操作但其中某一两个操作的前提条件并没有满足。比如先删旧表再建新表但删表的时候还有另一个流程在写入或者同时修改同一个配置文件的多个字段结果互相覆盖。没有判断器的话这种问题要等到错误日志出现才被发现而那时候上下文里已经混入了大量无效信息Agent 后续的每一步都在一个被污染的状态上继续。第二种是“固执重试式失控”。Agent 调用某个接口失败后它会基于同样的入参换一种措辞再试一次甚至连续重试五六次。这不是模型蠢而是它的训练目标里没有“及时止损”这个维度。如果你不主动给它一个“判断器”去评估“当前的重试是否有意义”它就会一直坚持到上下文耗尽或者触发超时。第三种是“局部最优式失控”。在长任务里Agent 每一步都选择了当前看起来最优的动作但由于它看不到全局这些局部动作组合起来往往会导致最终结果偏离目标。比如让它写一个数据清洗脚本它依次处理了缺失值、异常值、格式统一但每个步骤都做得过度最后整个数据集的结构都被改得不可用了。当时的场景是我在跑一个偏向数据处理的 Agent 项目连续几个晚上都在看日志里那些“看似正确但实际有害”的中间结果。我一开始想靠写更详细的 prompt 来约束模型但很快发现 prompt 只能约束“话术”约束不了“行为”。真正有效的方案是在行为发生之前或者发生之后增加一个独立的判断环节让另一个模型去审视“这个动作该不该做”。1.2 判断器的定位从“单线程执行力”到“review 制”把判断器加入 Agent 的架构本质上是在模仿软件工程里的 Code Review 机制。你写代码的时候不会让一个程序一边写一边自己合并到主干总得有一个 reviewer 看一遍。Agent 也是一样大模型天生擅长生成内容但它对自己生成内容的“质量”并没有稳定的感知因为它缺少一个外部视角。判断器要解决的核心问题可以拆成三层行动审查在执行一个关键动作之前判断“这个动作在当前状态下是否合理”。方案优选当模型产生了多个候选方案时判断“哪个方案更符合用户的真实意图”。结果验收在完成一步之后判断“这个结果是否真的达到了预期的中间目标”。为了实现这三层能力我最后选择了两个模型来搭配使用Laya 和 Jev。你可能会问为什么不用一个模型解决所有问题原因有两个一个是我下面要说的成本和延迟问题另一个是单一模型做判断时容易产生“自我偏好”——LLM 倾向于认可自己刚生成的内容这都快成常识了。用另一个独立的、不同定位的模型来担任判断者可以有效避开这种盲区。2. Laya 和 Jev两类判断模型的定位与选择2.1 Laya轻量决策跑在最前面Laya 的定位是轻量级决策模型它擅长处理的是“从多个选项里快速选一个”以及“判断一个动作是否应该立刻执行”这两类任务。它的核心优势是速度快、资源占用低适合放在 Agent 执行链路的最前端对每一次工具调用做快速预筛。我个人的理解是Laya 在做决策时更像一个“经验丰富的值班同事”。你给它当前的状态摘要和几个候选动作它不需要做长时间的推演就能告诉你现在 B 选项比 A 选项更合适或者这个动作再等一下执行更好。它不是那种会把每个方案翻来覆去分析三遍的模型它的设计目标就是快。举一个具体场景。我在做一个自动化运维类的 Agent它会根据监控指标执行扩容、重启、清理日志等操作。没有判断器之前有一次监控数据出现抖动Agent 做出一个扩容动作但实际业务量并没有增长。后来我把 Laya 接在动作执行前让它看一眼“当前指标数据 最近三次动作 候选动作”只花了几百毫秒就给出了“不建议执行扩容”的判断理由是当前指标波动幅度在正常范围内。从那次以后这一类误操作基本被堵住了。从部署角度看Laya 的参数量不大量化之后可以轻松跑在边缘设备上。在 Jetson Orin 这类带 GPU 的板子上推理延迟可以控制在百毫秒级别就算是在普通的 CPU 服务器上配合 INT8 量化也能做到可用的程度。所以它的定位非常适合作为 Agent 的高频前置判断器不会给主流程增加太多开销。2.2 Jev深度评估拦在关键节点Jev 跟 Laya 不是同类模型它的定位是深度评估主要处理那些需要“想清楚再动手”的关键节点。比如一段完整的代码改动提交给仓库之前它是否真的解决了问题一个多步骤的复杂方案中间哪个环节最可能失败一个数据管道在运行完之后输出结果是否满足下游的使用要求我最初接触 Jev是看到有人用它在 Codex 里做代码评审。当时的第一反应是这不就是拿一个模型去给另一个模型挑错吗后来实际跑了几次才发现Jev 的价值不在于“挑错”而在于“把评估标准结构化”。它会把一个方案拆解成多个评估维度然后针对每个维度给出结论和依据最后才汇总成整体判断。这里就体现出 Laya 和 Jev 的本质区别Laya 回答的是“哪个选项”Jev 回答的是“这个选项为什么行、为什么不行、要改成什么样才行”。一个是选择题模型一个是判断题证明题模型。我实践中比较喜欢用 Jev 做“合入前门禁”。比如在编码类 Agent 里Agent 完成一个 commit 之后不直接 push而是先丢给 Jev 做一轮 review要求它输出是否存在逻辑漏洞、是否处理了边界条件、是否符合任务描述中的验收标准。只有 Jev 给出的结论是“通过”这个 commit 才允许进入下一步。有人用 Jev 构建数据系统也是类似的思路在数据清洗管道的关键环节设置评估节点让 Jev 判断当前清洗后的数据分布是否合理如果分布异常就触发回滚或者人工介入。Jev 的代价是推理时间长参数量大直接部署到边缘设备并不现实。它更适合跑在云端或者性能较强的本地服务器上而且由于推理成本高你不能让它在每个动作上都跑一遍。它会作为“低频高价值”的判断器只出现在 Agent 流程的关键节点上。2.3 选择策略四种组合方式把两个模型放在一起我发现实际项目里的选择基本可以总结成四种组合方式。我直接画个表给你对比一下组合方式适用场景典型配置成本特征只用 Laya高频工具调用型 Agent如运维、爬虫、自动化操作每次动作前判断是否执行或从候选动作里选最优延迟极低单次成本可忽略只用 Jev低频重型任务如代码评审、方案评估、数据管道验收在关键里程碑做深度评估单次成本高但调用次数少Laya Jev 串联完整的长任务链路Laya 做动作级预筛Jev 做阶段级门禁中和前两者推荐大多数 Agent 使用Laya Jev 并联需要从多个维度同时保障质量的场景两个判断器并行跑任一判负即中断延迟和成本最高但质量保障最强大多数情况下我建议你的第一版先走“只用 Laya”或“Laya Jev 串联”的组合。原因是并联方案对系统要求较高而且两个判断器同时卡在关键路径上对 Agent 主流程的可用性影响太大。先把串联跑顺再考虑要不要加并联冗余。3. 部署方案与推理优化3.1 快速起步API 外挂让 Agent 框架先跑起来先把最快的方案说清楚直接把 Laya 和 Jev 作为 API 服务接到你的 Agent 框架里。这也是我最推荐的第一阶段做法因为它能让你在几个小时之内验证“判断器到底能不能解决我的问题”而不是先在部署上耗掉三天。具体来说现在的模型供应商基本都会提供 OpenAI 兼容的接口格式。我的做法是统一封装一层判断器客户端底层指向不同的模型端点上层暴露统一的调用接口。一个最小可用的判断器客户端大概长这样import json from openai import OpenAI class Judger: def __init__(self, base_url, api_key, model_name): self.client OpenAI(base_urlbase_url, api_keyapi_key) self.model model_name def decide(self, system_prompt, decision_context, timeout10): try: resp self.client.chat.completions.create( modelself.model, messages[ {role: system, content: system_prompt}, {role: user, content: decision_context} ], temperature0.2, timeouttimeout ) return resp.choices[0].message.content except Exception as e: return fERROR: {e}这里有几个关键点。第一点是 temperature 要设置得比较低。判断器不是生成模型它需要的是可重复、一致的结论而不是有创造力的回答。我一般设置在 0.2 以下。这个参数的意义在于如果你对同一个状态连续问两次判断器得到的结论应该是一样的否则你根本无法判断 Agent 的行为是模型问题还是判断器本身不稳定。第二点是超时一定要设置。判断器挂在 Agent 主流程上如果它卡住了整个 Agent 就停了。我的做法是超时设置在 10 秒以内并准备一个 fallback 策略判断器超时或者报错时默认放行当前动作同时记录一条 warning。你可以根据自己的安全要求来决定“超时默认放行”还是“超时默认阻断”但我的经验是默认放行更符合实际情况因为 Agent 本身是一个容错系统一次漏判可以通过后续环节补救但一次误阻断会让整个任务卡死在半路上。第三点是输出格式。如果你只是把判断器的输出当成一段文本看那它的作用就大打折扣。我在实际项目中要求判断器必须输出结构化 JSON固定字段为{ decision: approve | reject | revise, reason: 简要说明判断依据, confidence: 0.0, suggestion: 如果 decision 为 reject 或 revise给出修正建议 }这样 Agent 框架可以直接解析结果不需要再让主模型去“理解”判断器的回复。3.2 本地部署边缘设备与低配服务器的取舍API 外挂跑通之后你就会面临一个问题要不要把判断器部署到本地常见的动机有几个比如数据安全要求不能把数据发出去、API 按量计费成本太高、或者网络不稳定想降低对外部服务的依赖。但本地部署的判断器对硬件有要求尤其你如果还想跑 Jev 这种大模型就需要认真考虑硬件条件和推理框架。我把部署选择分成三个档次你可以对号入座。第一档在研究板或工控机上跑 Laya。比如 RK3588或者 Jetson Orin Nano 这类带 NPU 的设备。这类硬件跑 Laya 没什么压力重点是模型格式要转换成对应平台能高效执行的格式。以 RK3588 为例rknn-toolkit2 工具链可以把模型转换成 RKNN 格式跑在 NPU 上非常快。如果你做的 Agent 是边缘侧的比如车端、工控、机器人那判断器放本地的价值很大因为你要判断的动作本来就发生在本地的硬件上数据就没有必要传出去。第二档在普通 GPU 服务器上同时部署 Laya 和量化后的 Jev。比如一张 16GB 显存的显卡用 INT8 量化后大多数评估模型都可以塞进去。推理服务我用的是 vLLM它对连续批处理的支持很好多个请求并发进来时吞吐量比朴素的推理方式高得多。部署的命令大致是这样的vllm serve /path/to/jev-model \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --port 8001这里--max-model-len要根据你的实际输入长度来定。判断器的输入通常不会太长如果你把 Agent 的整个历史上下文都塞进去反而会稀释判断依据也会让显存占用快速上升。我一般把输入限制在 4K 到 8K tokens 之间。第三档纯 CPU 环境。只建议跑量化后的 Laya不建议用 CPU 跑 Jev除非你接受一个推理要等几十秒甚至几分钟。在 CPU 上跑判断器的体验会很差因为它被设计成高频率调用一旦延迟上去了Agent 就相当于每一步都在“卡顿思考”整个流程的可用性会大打折扣。3.3 让判断器变快的几个实用优化规模做大之后判断器的响应速度会成为 Agent 实际体验的瓶颈。我总结几个经得起实践验证的优化手段。第一个优化是输入裁剪。判断器不需要看 Agent 的全部上下文。你只需要把“当前任务目标摘要、当前状态摘要、候选动作描述、约束条件”这四部分组合起来给它。我在项目里写了一个 reducer 函数它会把长上下文压缩成结构化的短摘要。实测下来判断器的单次输入从 3000 tokens 降到了 600 tokens 左右响应时间缩短了将近一半而判断质量几乎没有下降。第二个优化是恒速缓存。在很多场景下Agent 会在短时间内多次请求判断器判断的内容很多时候是重复或高度相似的。比如它反复尝试同一个失败的 API每重试一次都会带同样的状态去问判断器“该不该继续”。这种情况下加一个带相似度检测的缓存把相同的决策上下文直接命中之前的判断结果效果非常明显。我用的是简单的向量相似度匹配超过 0.95 就直接返回缓存结果。第三个优化是本地小模型预筛。如果 Jev 太贵太慢你可以在 Jev 前面加一个更高频的小模型做预筛只有小模型无法确定时才升级到 Jev。比如 Laya 本身就是很好的预筛器遇到明显该通过的请求直接放行遇到明显该拒绝的请求直接拦下只有遇到模糊地带才把完整上下文发到 Jev 做深度评估。这个方案虽然没有“纯 Laya”方案快但是显著节省了 Jev 的调用次数成本能降一个数量级。4. 集成实操把一个判断器加进 Agent 主循环4.1 判断协议的结构设计给 Agent 加判断器最忌讳的就是随手在某个函数里加个 if 调用。那样做前期能用后期代码一复杂判断器的触发点、超时行为、告警逻辑全部纠缠在一起根本没法维护。我花了较多时间在协议设计上。判断器和 Agent 主循环之间需要有一个稳定的“判断协议”不管底层模型是 Laya、Jev 还是未来的什么新模型协议不应该变。我定义了一个最小化的协议结构分为三层输入层提供 task goal任务目标、state summary当前状态摘要、candidate actions候选动作列表、constraints约束条件。输出层统一为 decisionapprove / reject / revise、reason、confidence、suggestion 四个字段。控制层定义超时策略、重试策略、阻断策略、日志策略。在实际代码里我把它实现成一个基类具体模型只是基类的不同实现。这样做的好处是如果你想从 Laya 切换到别的决策模型只需要换一个实现类主循环的其余代码完全不用动。class ActionFilter: def __init__(self, judger: Judger, default_policyreject): self.judger judger self.default_policy default_policy def check(self, context: dict) - dict: try: result self.judger.decide( system_promptDELEGATION_PROMPT, decision_contextbuild_context(context) ) parsed json.loads(result) return parsed except Exception as e: # 判断器异常时的兜底策略 return { decision: self.default_policy, reason: fjudger error: {e}, confidence: 0.0, suggestion: }这个协议层在项目里的价值我多说一句它让你可以在不同阶段随时替换判断器。比如你前期用某个 API 验证效果后期想切换到本地模型整个切换的成本只是写一个新的 Judger 实现类。4.2 自主型 Agent把 Laya 插进动作选取现在展示一个实际可跑的集成流程。场景是带工具调用的自主型 Agent执行效果比较接近早期的 ReAct 模式。Agent 主循环的核心逻辑大概是这样的while not task_done: state observe_environment() candidate_actions propose_actions(state, task_goal) # 使用 Laya 作为动作选择器 decision laya_filter.check({ task_goal: task_goal, state_summary: state.summary(), candidate_actions: [a.describe() for a in candidate_actions], constraints: [不要重复执行失败超过3次的操作, 注意操作执行顺序] }) if decision[decision] approve: action select_action_by_confidence(candidate_actions, decision) result execute_action(action) elif decision[decision] revise: action revise_action(candidate_actions, decision[suggestion]) result execute_action(action) else: # reject不执行动作先收集更多信息 state gather_more_info()这里最有意思的是 Laya 会参与到“动作选择”而不是“动作拦截”。什么意思呢就是在提出候选动作的阶段Agent 可能生成了三四个候选Laya 会给出“哪个候选最值得执行”以及“是否每个候选都需要执行”。这样做比“拦截非法动作”更主动它是把判断器当成一个决策中枢而不是一个保安。我在项目里实际观察到的一个效果是加了这个选择器之后Agent 调用工具的“无意义动作”数量下降非常明显。比如以前它会在查询失败后马上再查询一次现在每一次查询都经过了判断器的筛选重复的、低价值的调用自然被过滤掉了。4.3 编码 Agent用 Jev 做合入前的门禁编码 Agent 是另一种很常见的使用场景这类的 Agent 特点是动作频率低但单个动作的价值和风险都很高。比如让 Agent 完成一个任务后生成一个 commit diff然后推送代码。这个场景里我最喜欢用的组合是“Laya 做过程拦截 Jev 做结果评审”。Laya 在编码 Agent 里负责的是一些轻量的判断比如“当前修改涉及的文件是否都在允许范围内”“是否在测试通过前就生成提交请求”。这些判断消耗低、实时性强可以在 Agent 生成动作的瞬间就做出反应。Jev 则在关键节点出场。我的做法是设置一个“合入前门禁”Agent 完成修改后把生成的 patch、需求描述、当前仓库里的相关代码片段打包发给 Jev让它做一轮完整评审。给 Jev 的评审 prompt 大致长这样你是一个代码评审专家。请基于以下维度评估这段代码修改 1. 是否解决了需求描述中的核心问题 2. 是否存在明显的逻辑漏洞或边界条件遗漏 3. 是否引入了不必要的变更 4. 是否有明显安全风险 需求描述{} 代码变更{} 相关上下文{} 请输出 JSON 格式{{decision: pass|fail|revise, reason: ..., suggestion: ...}}Jev 输出的结果会直接决定这个变更能不能进入提交队列。如果是 failAgent 会拿到 Jev 给的 suggestion基于它重新修改代码然后再次提交给 Jev 评审。这个循环通常两三轮以内就会收敛。有人问过我这个流程会不会拖慢开发效率。我的实际体会是短期看确实会因为每次提交都要多等一次 Jev 的评审但如果算上返工成本整体效率不降反升。没有这个门禁的时候一个看似完成的任务常常要到联调阶段才暴露问题那个返工成本比多等三十秒评审可怕得多。4.4 参数与阈值先跑通再调优判断器的参数配置我遇到过不少人在一开始就把自己困住了。比如有同学在第一天就纠结“confidence 阈值到底设 0.7 还是 0.8”为此调了一整天参数。我的建议是前期不要花太多时间在阈值调优上先把所有阈值设成“宽松模式”目标是让流程跑通积累足够多的真实判断日志。我的习惯是先跑一周左右把判断器的结果和 Agent 的最终结果都记录下来。等数据积累到一定程度再来分析哪些 reject 才是真正必要的、哪些 approve 是放过了问题。基于这些真实样本去调阈值才算是有依据。另外几个参数也值得注意revision 上限如果一个动作或一份代码被判断器连续打回 3 次就要把 Agent 拉停转人工介入否则会在判断器和 Agent 之间死循环。置信度阈值低于阈值的判断结果不直接阻断而是记录为待确认推给用户或中转给更高层级的判断器。上下文窗口我自己用 Jev 的默认窗口是 8192够了。输入裁剪比盲目扩窗口更重要。注意判断器给 Agent 返回“revise”时携带的 suggestion 一定要具体。如果你只返回“代码有问题”Agent 大概率会原封不动再提交一次。而如果你返回“第三行 assert 条件取反了请检查边界输入处理”Agent 的下一轮修改就有很高的概率一次性通过。5. 常见问题与排查实录5.1 模型申请与密钥校验先说一个很容易让人卡住的事情Laya 和 Jev 的获取渠道。这里的“申请”不只是拿一个 API key 那么简单很多模型为了控制滥用风险会限制申请者必须有真实业务场景。我第一次申请 Jev 的时候就提交了两轮信息第一轮只写了“开发 Agent 项目”被驳回第二轮把具体的 Agent 类型、判断器用途、预估调用量都写清楚之后才通过。所以如果你准备申请这类模型建议提前准备一段完整描述包括项目是什么、判断器放在哪个环节、每小时的调用量预期、是否需要批量推理支持。好的申请描述基本就是一段规范的使用场景说明。密钥拿到之后第一步是做一个连通性自检。不要直接把密钥往正式代码里塞先用一个最小脚本验证模型服务是否可用、限流条件是怎样的、单次调用的平均延迟是多少。这些信息能帮你在正式集成前就分清“模型问题”和“集成问题”。一个常见坑是某些模型的密钥有不同的作用范围比如某个 key 只能访问特定模型、特定并发数或者只能从特定 IP 段访问。一旦你的 Agent 是通过代理服务或容器化环境往外发请求就很容易遇到“本地 curl 通、服务里跑不通”的诡异现象。排查思路是先确定密钥是否绑定 IP再检查服务的出口 IP 是否在授权范围内。提示千万不要把密钥直接硬编码在 Docker 镜像或者前端代码里。你的 Agent 项目迟早要交给别人运行或者部署到服务器上密钥泄露一次后续就很麻烦。5.2 上下文超长被截断判断器部署后最常见的 bug 之一就是上下文超长。我遇到过一种情况是 Agent 把一次对话里的所有历史消息全部塞给 Jev结果超过了模型的窗口限制报错信息看起来像是“输入长度无效”或者“max context length exceeded”。解决方案有两个方向。第一个方向是主动裁剪输入只提取对判断真正有用的部分。这个我在前面已经说过了判断器的输入不是一个“对话记录”而是一个“决策摘要”。第二个方向是调整服务端参数。用 vLLM 部署时如果你的输入长度超过某个阈值即使不超过硬限制推理速度也会显著变慢。我建议针对判断器服务单独设置--max-model-len不要希望它跟 Agent 主模型共用同一个配置。两个模型在同一个服务上运行时窗口一长显存分分钟告急。5.3 判断结果时好时坏这可能是判断器落地过程中最让人头疼的问题。上个月我在一个项目里用 Jev 做代码评审门禁第一周效果非常好能挡住不少问题提交但到了第二周模型对同类问题的判断开始出现摇摆有时同样的问题会被打回有时又会直接通过。排查之后我发现原因出在输入里“上下文内容”的差异。Agent 的主模型是会学习和记忆上下文的它生成的代码风格前后有变化而我的 Jev prompt 还停留在第一周那个模板上它对“当前代码库的规范”没有感知自然会导致判断标准漂移。解决方法是在给 Jev 的输入里加入“当前仓库的代码规范摘要”比如“本项目规定所有外部输入必须经过类型校验”“数据库操作必须使用事务”。把这个约束写进判断器的 system prompt它的评估就会重新变得稳定。另外还有一个技巧是给判断器加 few-shot 示例。不是说让它去模仿而是用 2 到 3 个“正确判断 错误判断”的示例来校准它的输出标准。我把几组真实案例整理进 prompt 之后Jev 的误判率下降得很明显。5.4 延迟与显存瓶颈最后说两个性能问题。一个是本地部署 Jev 时显存不足导致的 OOM。这种情况在并发多个 Agent 实例时特别容易出现。排查思路很简单第一步看 vLLM 日志里面的 GPU 显存占用如果长时间保持 95% 以上基本可以确定是显存瓶颈第二步看判断器的输入长度有没有异常上涨如果很多请求都接近窗口上限那就说明裁剪逻辑失效了。解决办法无非三条量化等级从 INT8 改成 INT4、削减--max-model-len、或者限制并发请求数量。我的排序是先削减窗口长度再限制并发最后才考虑换更低精度的量化。因为窗口太长不仅慢还会稀释判断依据这本身就是一个质量问题不只是性能问题。另一个性能问题是延迟波动。如果你用 API 外挂方式延迟波动会来自服务端的负载均衡和限流策略。我的做法是在判断器客户端里加一个滑动窗口统计实时记录最近 100 次调用的平均延迟和 P99 延迟。当 P99 超过 5 秒时自动触发告警并临时切换到一个更快但可能更弱的小模型作为降级方案。class JudgerWithStats(Judger): def __init__(self, base_url, api_key, model_name): super().__init__(base_url, api_key, model_name) self.latency_history [] def decide(self, system_prompt, decision_context, timeout10): import time start time.time() result super().decide(system_prompt, decision_context, timeout) elapsed time.time() - start self.latency_history.append(elapsed) if len(self.latency_history) 100: self.latency_history.pop(0) return result加上这个统计之后你的判断器就不再是一个黑盒你会知道它当前的响应品质究竟如何也就能放心让 Agent 主流程依赖它。写在最后我实际跑过两套方案之后最大的感受是判断器的价值不在于“把 Agent 变成永不犯错的系统”而在于“让 Agent 的错误变得可控、可观察、可回滚”。你不需要追求判断准确率百分百只需要保证错误的成本足够低Agent 的整体可用性就会上一个台阶。还有一个很实用的经验想分享给你。刚开始给 Agent 加判断器时不要试图一次性接入所有环节。先选一个最痛的点比如“动作执行前拦截”或者“提交前评审”跑通之后再逐步扩展。我见过不少同学因为一下子给 Agent 接了太多判断逻辑最后 Agent 每走一步都要经过五六个模型的评审和重写整个任务从十分钟变成了一小时完全没法用。判断器是给 Agent 增加约束的但它自己不产生业务价值它的价值全都在“关键位置拦一下”这件事上。最后再补充一个小建议判断器的输出日志一定要记全包括输入上下文摘要、输出 decision、置信度、Agent 最终实际执行结果。这批数据是你后续优化判断器的核心资产。我之前一度以为只是常规日志后来用这些数据总结规律、调整模型阈值时才意识到它们的价值有多大。希望这篇文章能帮你在自己的 Agent 项目里少走几步弯路。