最近一直在折腾 Agent 的可控性问题，一个很深的体会是：光有 Laya 这种能干活的主模型还不够，得在任务链路上塞一个会挑刺的“判断器”。社区里讨论比较多的 Laya 和 Jev，正好对应了这两条路线——一个偏生成和决策，一个偏校验和评估。这篇就把我在本地把这两个东西装起来、接进 Agent 流程、以及最后怎么选型的整个过程摊开聊一聊，希望能给正在做 Agent 落地、尤其是给 Agent 加质量闸门的朋友一点参考。
1. 为什么 Agent 需要一个“判断器”
1.1 现在的 Agent 卡在哪：自感知闭环缺失
大多数 Agent 跑起来之后，流程本身并不复杂：模型收到任务，拆解步骤，调用工具，汇总结果。真正让项目变得难控的，是“输出没有校验”这件事。
你让 Agent 帮你查资料写报告，模型生成的初稿可能结构完整，但里面引用的链接已经失效了；你让它改一段代码，它改了 A 处的逻辑，B 处的依赖却忘了同步更新。这种错位在单次生成里很难发现，因为模型本身并没有对自己产物做独立验证的能力。
大模型的自感知闭环其实是缺失的。它生成文本时是逐字预测的，生成完后你让它检查“这段有没有问题”，它往往会顺着刚才的思路再做一遍预测，大概率得出“没问题”的结论。这不是模型故意撒谎，而是它的检查路径被生成路径锁死了。就像写文章的人很难用自己的眼睛抓住自己的错别字，看自己刚写的东西总有滤镜。
所以“给 Agent 加判断器”这件事，本质上是在生成路径之外，再单独拉一条验证路径。判断器不负责想方案，不负责写代码，只做一件事——拿到主模型的输出，按预设标准判断能不能放行。判断器一旦介入，主模型就不再是唯一的“话事人”，Agent 的可靠性也就从“概率正确”往“可验收”的方向挪了一步。
1.2 判断器出现在三个关键位置
实践下来，判断器不是只放在最后验收，而是可以在 Agent 的任务链路上出现三次，每次承担的角色不一样。
第一，工具调用之前。Agent 决定调用一个 API 或者执行一段命令时，参数经常出问题。比如日期格式、单位换算、接口需要的字段名，这些错误一旦发出去，工具会直接报错或返回垃圾数据。判断器在这里做一次“出手前检查”，把明显有问题的调用拦下来，比事后补救省事得多。
第二，中间产物产出之后。多步骤任务里，中间结果的质量决定了后面的走向。比如 Agent 先做数据清洗再做统计分析，清洗出来的数据如果字段丢失，后面的统计再漂亮也是错的。在这个位置放一个判断器，专门评估“当前结果是否满足进入下一步的条件”，不满足就触发重跑或调参。
第三，最终结果交付之前。这是最常规的一层，相当于出厂质检。判断器检查格式、检查内容完整性、检查引用可验证性，甚至给结果打一个可信度分。低分结果回到主模型做二次修订，高分结果直接输出。
这三个位置如果只用一个判断器循环调用，实际上就搭起了一个“生成—判断—重试”的闭环。写成伪代码大概是这样一个结构：
for attempt in range(max_retries): result = main_model.run(task) verdict = judger.evaluate(task, result) if verdict.passed: return result else: task = task + "\n上一版问题：" + verdict.reason + "\n请修订后重试" raise AgentExecutionError("超过最大重试次数")这个循环看着简单，但它是判断器模式的地基。没有这个闭环，判断器就是一个孤立的打分器，对 Agent 的整体可靠性提升非常有限。
1.3 判断器和“人审”的区别
有人会问：我直接让 Agent 跑完后人看一眼不就行了？可以，但人审和判断器解决的是两个不同层面的问题。人审是低频、终局、兜底性质的，不可能在每一步中间产物上都停下来找人来检查。判断器则是一个可嵌入循环里的自动环节，它在毫秒级甚至秒级内就能返回一个结论，而且可以反复触发，不用等人。
判断器的价值更多体现在“过程控制”，人审的价值体现在“最终责任”。两者不是替代关系，是分层关系。自动化流程里用判断器做高频质控，把明显不合格的产物拦截下来；人在最后环节只处理那些有争议、需要业务判断的结果。这样既不增加人力负担，又能明显减少低质量输出。
2. Laya 和 Jev：一对互补的“干活的”和“挑刺的”
2.1 Laya：负责生成与决策的主模型
我接触 Laya 的第一印象是它在复杂推理任务上表现很稳，尤其是那种需要多步推导、最后才能得出结论的问题。拿它当天数据集里的主模型用，最大的感受是“话痨”现象比之前的模型少，生成结果更接近可以直接交付的状态。
Laya 这个定位很好理解——它是团队里的“干活的人”。你给它一个目标，它帮你拆任务、写代码、做分析、调用工具，把想法变成实际的产物。这种模型在 Agent 架构里的位置通常是 orchestrator 或者 worker，承担最主要的生成压力。
但能力强的模型往往也是成本敏感的。Laya 跑一次长任务，消耗的 token 量很大，如果每个环节都让它从头生成，成本会迅速失控。另外，它对 Prompt 的写法也很敏感，同一件事换一种问法，产出的质量可能差很多。这就需要一个轻量的角色在旁边盯着它，防止它跑偏。
2.2 Jev：负责判断与校验的评估模型
Jev 和 Laya 的定位完全相反。Jev 不是用来“干活”的，而是用来“挑刺”的。它的核心能力是评估：给定一段输入和对应的输出，判断输出是否符合输入的要求，质量够不够格，有没有明显的事实性或逻辑性错误。
在实际使用里，Jev 的输出通常被设计成结构化格式，而不是自由文本。我常用的一种格式是返回 JSON 字段，包括整体判断、问题清单、修改建议和置信度评分。这样 Agent 框架可以直接解析结果做分支决策，不需要再让主模型去理解一段自然语言评价。
Jev 走的是轻量路线，推理速度比 Laya 快，单次调用的成本也更低。这意味着它可以在 Agent 的每一步里都被调用，而不需要担心延迟和预算。判断器本来就该是高频组件，如果判断器本身跑一次比让主模型重新生成一次还慢，那整个流程的效率就没有意义了。
2.3 为什么判断器不能直接复用主模型
最大的坑就是“自我评估偏差”。让 Laya 自己生成结果，再让 Laya 自己检查结果，看起来省了一个模型的钱，实际上得到的检查结论基本等于没查。因为模型在检查时会调用与生成时相同的内部知识路径，它对“自己刚生成的内容”有一种天然的倾向性，倾向于认为它是合理的。
拿实际例子来说，我让一个主模型生成一个排序算法，它在边界条件上写错了数组越界。随后让同一个模型检查这段代码，它的结论是“逻辑正确，边界处理合理”。等我把同样的代码交给 Jev 单独检查，Jev 很快就指出了循环终点的 off-by-one 错误。这跟两个模型的能力差距关系不大，核心区别是检查者是否独立于生成者。
另外还有成本和效率的考虑。主模型生成一次要消耗大量计算资源，如果每生成一步都要用主模型自己再评估一次，整个链路的成本会翻倍。判断器做成轻量模型之后，哪怕它把关没那么严格，只要能把明显离谱的结果拦下来，剩下的小问题再靠人审兜底，整个系统的性价比就已经很好了。
3. 给 Agent 加判断器的三种部署方式
3.1 本地部署：用 Ollama 拉起轻量判断器
如果你对数据隐私比较敏感，或者希望用低成本的方式先验证判断器效果，本地部署是最直接的方案。我目前用的是 Ollama 来做本地推理，一方面它对新手友好，另一方面它提供了兼容接口，接入现成的 Agent 框架很方便。
本地部署判断器的基本步骤是：
- 安装 Ollama。官方脚本一条命令装完，Windows、macOS、Linux 都支持。
- 拉取判断器模型镜像。Jev 这类轻量模型通常有几个不同体积的量化版本，先拉适合你显存的那个。
- 启动服务。Ollama 默认监听 11434 端口，启动之后直接用 HTTP 请求调用即可。
- 在 Agent 代码里替换调用地址，把原来指向云端 API 的地址改成
http://localhost:11434。
命令行大概是这样的：
ollama pull jev-judge:7b-q4 ollama serve curl http://localhost:11434/api/generate -d '{"model":"jev-judge:7b-q4","prompt":"请评估以下输出是否符合要求...","stream":false}'本地部署的注意事项有两个。一个是显存必须留够，判断器虽然轻量，但如果你同时跑主模型和判断器在同一张显卡上，很容易出现显存溢出，我建议给两个模型做好显存隔离规划。另一个是注意模型的量化版本，q4 和 q8 在判断准确率上会有细微差别，如果机子跑得动，优先上 q8，判断类任务对精度的敏感度比想象中高。
3.2 服务化接口：用 vLLM 或 FastAPI 包装成 OpenAI 兼容协议
如果本地部署之后要进一步工程化，我建议把判断服务封装成一个统一接口，不要让 Agent 代码里到处散落着裸调用。最常见的方式是用 vLLM 直接拉起模型，vLLM 自带 OpenAI 兼容接口，Agent 框架里把 base_url 指过去就能用。
不想引入太重的推理框架的话，用 FastAPI 包一层也行。判断服务对外只暴露一个 POST 接口，接收任务描述和待判断结果，内部完成推理和结构化输出，返回一个固定格式的 JSON。这样上层 Agent 只跟 FastAPI 交互，底层是什么模型、哪个版本，都可以在服务端随时切换，不用改上层代码。
一个简单的封装例子：
from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class InferRequest(BaseModel): task: str result: str criteria: str = "准确、完整、可执行" class InferResponse(BaseModel): passed: bool score: float reason: str suggestion: str @app.post("/judge", response_model=InferResponse) async def judge(req: InferRequest): prompt = f"任务：{req.task}\n结果：{req.result}\n判断标准：{req.criteria}" raw = await call_local_model(prompt) return parse_verdict(raw)这样做的好处是，判断器的接口一旦标准化，Agent 端的接入成本几乎为零。换成任何其他判断模型都只是服务端的事，Agent 代码完全不用动。
3.3 在 Agent 框架和 IDE 工具中接入
现在很多 Agent 项目已经不满足于“聊天问答”了，更多是在 IDE 和自动化工作流里充当 coding agent。这种场景里加判断器，通常不是再单独开一个服务，而是把判断逻辑嵌入现有的执行链路。
拿代码生成类任务举例。主模型写完一段代码后，判断器立刻作为独立的 reviewer 介入，对代码做一次静态审查，检查单元测试是否覆盖关键分支、是否存在明显安全隐患、有没有硬编码的敏感信息。判断器给的结论如果再带上具体的修改建议，主模型在下一轮修改时就直接有了参照，不需要整段重写。
def build_review_prompt(diff, tests): return f""" 你是一个代码评审员。以下是 AI 生成的代码变更和相关测试。 请判断该变更是否可以合入，输出 JSON 格式： {{"approve": true/false, "blockers": ["..."], "suggestions": ["..."]}} 代码变更：{diff} 测试结果：{tests} """在 IDE 工具链里，这类判断器还可以作为 pre-commit hook 的一环。代码在提交之前先过一遍判断器，有问题就直接把人留在本地修，而不是等 CI 跑完再打回来。整个过程对使用者几乎透明，但它把工程质量的门槛往前移了一大截。
3.4 部署时的资源规划参考
部署判断器时，我一般按并发数反推资源配置。先估一个峰值 QPS，比如有 20 个 Agent 实例同时在跑，每实例每秒可能调用 2 次判断器，那判断服务的并发压力就是 40 QPS。再按单次推理需要的时间估算需要的并发 slot 数。
一个 7B 量级量化模型，在单张 24G 显存的显卡上，单次短文本判断大约耗时 0.5 到 1.5 秒。如果并发需求高，就需要上多卡或者调大批处理。资源规划表大概是这个样子：
| 场景 | 模型规模 | 显存建议 | 并发建议 | 备注 |
|---|---|---|---|---|
| 本地单机实验 | 3B-7B 量化版 | 8G-16G | 低并发 | 优先跑通流程 |
| 内部工具集成 | 7B-14B 量化版 | 24G-48G | 中并发 | 需要服务化封装 |
| 生产环境 | 14B+ 或 API 调用 | 按需扩容 | 高并发 | 考虑自动伸缩 |
如果本地资源确实有限，别硬扛。判断器这种组件完全可以放一台单独的机器上，跟主模型服务分开部署，互不抢占资源。我最初把所有模型塞在同一张卡上，跑起来卡得不行，后来把判断器挪到另一台机器上，整个链路才顺畅起来。
4. Laya 与 Jev 的选型决策：别什么都往 Agent 里塞
4.1 先判断你的任务到底需不需要判断器
判断器不是万能的，也不是所有 Agent 场景都值得加。我个人的判断标准很简单——任务失败后，重新生成一次的成本高不高，以及错误后果严重不严重。如果两个问题的答案都是“高”，那就值得加判断器。
具体来说，我整理了一张决策参考表：
| 任务类型 | 是否需要判断器 | 原因 |
|---|---|---|
| 单步问答，结果宽容 | 不需要 | 重来一次成本低，用户也容易自行纠错 |
| 多步信息整合，引用多 | 强烈需要 | 幻觉引用和过时信息需要独立校验 |
| 代码生成与修改 | 强烈需要 | 编译错误、逻辑错误需要提前拦截 |
| 内容审核与合规检查 | 必须需要 | 判断器承担安全兜底职责 |
| 创意写作 | 可以不用 | 主观性强，判断器标准难定 |
| 数据分析与报表输出 | 强烈需要 | 数字错误会直接误导决策 |
另一种情况是，你的 Agent 已经接入了外部工具返回的结构化数据，且工具本身有强约束（比如 SQL 查询失败直接返回报错），那么判断器的价值会被削弱，因为错误已经被工具层拦截了。判断器真正发力的地方，是那些“输出看起来正常但实际有问题”的场景。
4.2 能力与成本的平衡
选型的时候，最忌讳的就是“越大越好”。主模型 Laya 选大一点的、能力强的，可以理解，因为生成质量直接决定了任务的天花板。但判断器不一样，判断器的核心诉求是“快、够用、不贵”，它不需要生成惊艳的长文，只需要给出可靠的判断结论。
我把 Laya 和 Jev 在选型维度上的差异对比一下：
| 选型维度 | Laya（主模型） | Jev（判断器） |
|---|---|---|
| 核心能力 | 推理、生成、工具调用 | 评估、校验、分类 |
| 速度要求 | 中等，允许长思考 | 高，追求低延迟 |
| 成本敏感度 | 高，单次调用贵 | 低，可高频调用 |
| 开源生态 | 看具体发布情况 | 通常更轻量、更易部署 |
| 上下文要求 | 长上下文优先 | 短上下文足够 |
| 失败代价 | 产物质量差 | 误判导致流程反复 |
实际选型时，判断器够用就好。我用 Jev 的早期版本时，偶尔会出现“该拦的没拦住”的漏判情况。调了几轮阈值和 Prompt 之后，漏判率明显下降。比一味追求更强更大的判断模型，把判断标准和交互格式打磨好，收益要大得多。
4.3 三个可落地的搭配方案
根据资源条件和项目阶段，我把之前试过的组合总结成三套方案，可以直接抄作业。
方案 A 是“全本地部署”，适合数据敏感的团队。Laya 和 Jev 都部署在内网，所有数据不出服务器。这个方案的优点是隐私性强、长期成本稳定，缺点是对硬件要求高，需要专门规划显卡资源。
方案 B 是“本地主模型 + 云端判断器”，适合本地算力有限但希望保留主模型可控性的场景。Jev 走轻量 API 调用，请求里只传判断需要的文本片段，不涉及完整业务数据，隐私风险可控。这样本地主模型继续承担生成，判断压力完全卸载到云端，实测流程速度比本地双模型快不少。
方案 C 是“全云端 API”，适合快速验证和短期项目。Laya 和 Jev 都用服务化 API 接入，开发效率最高，几乎不用关注部署，缺点是长期跑下来成本和数据合规需要仔细核算。
这三个方案不冲突，项目阶段变了完全可以在它们之间切换。判断器的接口设计得规范一点，迁移成本基本就是改一行 base_url 的事。
5. 常见问题与排查技巧实录
5.1 判断器把好结果误判成坏结果
这是我一上来就踩的坑。判断器 Prompt 里写了一句“请严格判断输出是否完美”，结果它把很多质量还不错的结果都打了低分，接着主模型被反复要求重写，整个流程慢了一倍不止。
后来把判断标准从“完美”改成“达到任务要求即可”，并将输出从二元判断改成三段式——直接通过、需要修改、信息不足。信息不足时不是打回重写，而是让主模型补充说明，成本低很多。判断器不是要让结果十全十美，它只需要挡掉明显不合格的产物，过严和过松都会让 Agent 变得不可用。
5.2 判断器接入后 Agent 中途报错
判断器接入过程中，最常见的报错就是 Agent 执行到一半中断，提示执行终止。这类问题大概率不是模型本身的问题，而是判断器的返回结果没有被 Agent 框架正确解析。
排查思路我总结为三步：先看判断器返回的原始结果是否合法，比如 JSON 格式有没有被截断；再看超时设置，判断器推理慢的时候，Agent 默认的请求超时可能不够；最后看重试逻辑，如果判断器连续返回“不通过”，主模型又被同一个 Prompt 重复调用，很容易形成死循环，必须给重试次数设上限。
我踩过最大的坑是忘了解析异常时的降级处理。判断器服务偶尔抖动返回 500，Agent 直接中断。后来在调用层加了降级逻辑，判断服务不可用时默认放行并在日志里标记，让整个链路不至于因为判断器一个环节就白跑一遍。
5.3 串行调用太慢，我要怎么加速
一个自然的想法是判断器每步都跑、每句话都审。但实际操作里完全没有必要，判断器介入的粒度需要控制。结果很长、步骤很多的时候，只抽关键片段做判断就行，不需要对全文逐字检查。比如代码审查只看 diff 和关键函数，报告检查只看摘要和结论部分。
批量判断也是一招。Agent 的多步结果可以攒一批，一次性发给判断器统一打分，减少交互次数。异步处理更彻底——判断耗时和下一步准备并行起来，Agent 在等待判断结果的同时先去做一些不依赖结果的准备工作，整个链路的时间就省出来了。
5.4 判断器提出了建议，但主模型就是不改
这个问题往往不是模型不听话，而是建议根本没进到主模型的下一轮上下文里。很多 Agent 框架在重试时只是简单地把原任务重新发一遍，判断器给的反馈丢失了。主模型甚至都不知道自己上一版哪里有问题，自然不会改。
解决办法是把判断结果显式地拼接到新的 Prompt 里，并且要求主模型先复述判断结论再修改。比如在下一轮任务描述里加上“上一版结果未被通过，原因是：xxx；请先确认你理解该问题，再给出修订版本”。加上这行之后，修改的针对性明显增强，很多问题一轮就能修掉。
5.5 几个调判断器时直接能用的提示词片段
最后分享几个我实测下来效果不错的判断器提示词片段，可以直接复制去改：
你是一个任务质量评估器。请根据以下任务要求和生成结果，判断结果是否达到要求。 任务要求：{task} 生成结果：{result} 输出格式：{"decision": "pass" 或 "revise", "score": 0到100的整数, "reason": "不超过50字的问题摘要", "suggestion": "具体的修改方向，不要说空话"} 注意：只有当结果出现明显错误、缺失关键内容或存在安全风险时，才输出 revise。你是一个代码评审员。以下是代码变更和关联测试摘要。 请找出所有可能导致编译失败、运行异常或安全风险的问题。 不要提风格问题。输出 JSON：{"approved": true/false, "critical_issues": [...], "improvements": [...]}这套模板的关键在于让判断器给出“原因 + 修改方向”，而不是只给一个通过或者不通过。原因让主模型知道问题出在哪，修改方向让主模型知道下一步怎么下手，这两个信息缺一个，重试闭环的效果都会大打折扣。
我个人的体会是，判断器这个组件的原理很简单，真正难的是把判断标准定清楚，并把判断结果转化成主模型能直接执行的反馈。Laya 和 Jev 谁强谁弱，其实并没有标准答案，关键是你希望它们在系统里扮演什么角色——一个负责把事做完，一个负责把事做对。两者接好之后，Agent 的输出质量会有一个肉眼可见的跃升，这个投入非常值得。
