给Agent装上判断器：Laya轻量决策与Jev深度评估的实践指南

今天想聊一个我给 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”或“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_url=base_url, api_key=api_key) self.model = model_name def decide(self, system_prompt, decision_context, timeout=10): try: resp = self.client.chat.completions.create( model=self.model, messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": decision_context} ], temperature=0.2, timeout=timeout ) return resp.choices[0].message.content except Exception as e: return f"ERROR: {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（约束条件）。
• 输出层：统一为 decision（approve / reject / revise）、reason、confidence、suggestion 四个字段。
• 控制层：定义超时策略、重试策略、阻断策略、日志策略。

在实际代码里，我把它实现成一个基类，具体模型只是基类的不同实现。这样做的好处是，如果你想从 Laya 切换到别的决策模型，只需要换一个实现类，主循环的其余代码完全不用动。

class ActionFilter: def __init__(self, judger: Judger, default_policy="reject"): self.judger = judger self.default_policy = default_policy def check(self, context: dict) -> dict: try: result = self.judger.decide( system_prompt=DELEGATION_PROMPT, decision_context=build_context(context) ) parsed = json.loads(result) return parsed except Exception as e: # 判断器异常时的兜底策略 return { "decision": self.default_policy, "reason": f"judger 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 输出的结果会直接决定这个变更能不能进入提交队列。如果是 fail，Agent 会拿到 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, timeout=10): 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 项目里少走几步弯路。