做 Agent 开发这几年，我越来越觉得：与其把所有任务都塞给一个大模型，不如给 Agent 身边加一个独立的“判断器”。Laya 和 Jev 是我最近这一轮改造里重点对比的两个模型，从部署方式到选型逻辑，踩了不少坑。这篇文章想从“为什么需要判断器”讲起，再聊聊这两个模型分别适合什么场景，最后把本地部署、边缘设备部署和并发压测的实操过程整理成一份可以直接参考的笔记。
很多单模型 Agent 跑一段时间后，问题往往不是“模型不够聪明”，而是“没人把关”：主模型既要生成回答，又要判断下一步动作，职责太多，很容易在一个看似简单的地方翻车。判断器就是把这个“把关”的职责单拆出来，让一个小模型专门回答“该不该调工具、应该调哪个、执行结果靠不靠谱”。如果你正在做 Agent 项目，或者准备把大模型部署到 Jetson Orin、RK3588 这类设备上，这篇文章应该能帮你少走不少弯路。
1. 为什么要在 Agent 里单独拆一个“判断器”
1.1 主模型的“判断”和“生成”其实经常打架
常规单 Agent 架构里，主模型要同时承担两件性质完全不同的任务：生成面向用户的自然语言回答，以及判断下一步该做什么。生成要求模型有创造力、表达流畅、语气自然；判断阶段则要求模型严格跟随指令，输出可解析的结构化结果。这两个目标本身是有冲突的。
我见过最典型的翻车现场是这样的：Agent 调用工具时，模型知道该调用哪个函数，但生成的参数里混进了多余的散文；或者反思阶段确实发现了问题，却在“该重试还是该放弃”上犹豫半天，导致整条任务链路被拖得很长。这不是模型智商不够，而是我们把太多矛盾的职责压到了同一个模型身上。
判断器要解决的就是这个问题。它不负责写回答，也不负责规划完整任务，只负责做决策：是或否、选 A 或选 B、这个结果有没有问题。因为任务单一，它的模型规模可以小很多，输出格式可以限定得很死，延迟也更容易控制。把“判断”从“生成”里拆出来，是我觉得 Agent 工程里性价比最高的架构调整之一。
用个生活化的类比：主模型是冲在一线的业务员，能说会道、随机应变；判断器是签合同前审条款的法务，不负责谈客户，只负责指出风险点。两者分开之后，业务员不用天天记法律条文，法务也不用揣摩客户情绪，各自的效率都更高。
1.2 判断器的三种形态：路由、反思与安全
判断器不是只有一种形态。按我的实践习惯，可以分成三类。
第一类叫路由判断器。用户请求进来后，先由它决定下一步走哪条路：是直接回答，还是调用某个工具，还是去检索知识库。这类判断器的特点是输入短、要求响应快，通常要在几百毫秒内给出结论。它相当于 Agent 的交通指挥。
第二类叫反思判断器。主模型生成完回答、或者工具执行完一轮之后，由它检查结果是否合理、是否满足用户目标、是否需要重写。这类判断器需要读更长的上下文，对指令跟随能力要求更高，但同样要求输出结构化结论。
第三类是安全判断器，负责敏感内容过滤、个人信息遮蔽、恶意指令拦截。它的硬指标是不漏判，宁可多拦截一次也不能放过去。
如果把这个分类和本文的两个主角对应起来，我通常把 Laya 放在路由型判断器这个位置，把 Jev 放在反思型判断器这个位置。安全型判断器一般用两者之一加一段规则来临时实现，还没有完全固定的专用模型。这个对应关系非常重要，后面所有部署和选型讨论都围绕它展开。
2. Laya 和 Jev：两种不同的判断思路
2.1 Laya：轻量、快、适合做前置路由
Laya 是典型的 Agent 前置判断模型。按我拿到的版本来观察，主力档位在数 B 到十几 B 之间，量化之后单张消费级显卡就能带起来，Jetson Orin 这类设备也能想办法塞进去。它的输出风格比较“干”，偏向结构化标签、工具编号、意图分类，而不是长篇大论的分析，这正好符合路由判断器的需求。
我实际使用中主要拿它做两件事。第一件是工具路由：用户说“帮我把这份文档转成 PDF”，我先让 Laya 判断是该调用文档转换工具，还是直接回答。如果候选工具列表里没有匹配项，它会返回“直接回答”，这样主模型就不会硬编一个不存在的工具名。第二件是上下文精简：RAG 场景里召回了 5 段内容，但不是每段都需要传给大模型，让 Laya 做一个“与当前问题是否相关”的过滤，只把高相关片段交给主模型，能明显降 token 消耗，也能减少干扰信息。
下载部署这块，一般从 Hugging Face 或 ModelScope 上找官方量化版本就行。我的建议是优先选 Q4_K_M 或 AWQ 量化版，有两个原因：一是判断器任务对单 token 生成质量要求不高，量化带来的精度损失对“选 A 还是选 B”影响很小；二是显存占用降下来之后，你可以很从容地多开几个实例来扛并发。如果只是本机试验，也可以直接拉到 Ollama 里跑，稳定后再迁移到 vLLM。
2.2 Jev：重判断、适合做反思与质量评审
Jev 和 Laya 的方向不太一样。它不是为了“快”而生，而是为了把“判断”做得更严。我主要拿它做 Agent 执行后的反思校验：工具返回的结果和用户目标是否一致；代码运行输出里有没有报错关键字；主模型生成的长回答有没有遗漏核心要求。这类任务需要读更长的轨迹，所以 Jev 的上下文能力和指令跟随能力要求更高，代价是显存和延迟都会上升。
最近讨论比较多的用法有两个。一个是在 Codex 这类编码工作流里，让 Jev 对几个候选补全方案排序，选一个最像正确解法的结果，相当于把代码评审前置到生成阶段。另一个是用 Jev 搭数据处理管道的质检层，判断清洗结果是否符合规则，不符合就回到上游重跑。这类场景里，判断器输出的是分数或结论，而不是最终用户答案，所以它对准确性的敏感程度远高于流畅性。
需要注意，Jev 的权重在不同渠道下可能有限制，版本之间的差异也比较明显。我拿到的 8B 版本在代码评审场景表现不错，更大的版本扛长轨迹反思更稳，但部署门槛也相应提高了。实际项目里不建议一上来就追求最大版本，先拿小版本把链路跑通，再根据瓶颈决定要不要升级。
2.3 选型：不是越大越强，而是越合适越好
很多朋友会问：Laya 和 Jev 到底该选哪个？我的回答是：先看判断发生的位置。如果判断发生在“行动之前”，选 Laya；如果发生在“行动之后”，选 Jev。
这里给一张选型对照表，是我自己平时参考用的：
| 使用场景 | 优先选择 | 理由 |
|---|---|---|
| 前置工具路由 | Laya | 需要低延迟，模型越小越容易压并发 |
| 输出前快速检查 | Laya | 检查点密集，响应速度优先 |
| 长链路反思 | Jev | 需要读长上下文，判断要更严格 |
| 编码任务候选评审 | Jev | 对代码正确性判断要求高 |
| 边缘设备本地判断 | Laya | 参数量小，量化后更容易塞进边缘设备 |
| 需要严格质量评测 | Jev | 判断粒度细，适合做评审角色 |
两者可以混合用：进入 Agent 主循环前由 Laya 把关，执行完一轮之后由 Jev 复核。很多项目到后期都不是只部署一个判断模型，而是同时部署两个小模型，各干各的活。
这里还必须强调一个选型标准：输出必须稳定结构化。模型再强，如果输出一段带散文的分析，解析环节就会变成新的不稳定源。所以我选判断器模型时特别看重一点——它能不能稳定输出类似{"decision": "tool_call", "tool": "pdf_convert", "confidence": 0.92}这样干干净净的 JSON。
3. 部署与选型实操：从本地到边缘
3.1 先定推理框架：Ollama、vLLM 还是 llama.cpp
部署判断器之前，先要选推理框架。不同框架面向的场景差很多，选错了后面会很别扭。
| 框架 | 定位 | 适合场景 | 并发能力 | 上手难度 |
|---|---|---|---|---|
| Ollama | 单机快速体验 | 本地测试、个人项目 | 一般 | 低 |
| vLLM | 生产级推理服务 | 线上 Agent、高并发 | 强 | 中 |
| llama.cpp | 底层推理引擎 | 边缘设备（Orin、RK3588、CPU） | 单实例较弱 | 中 |
| RKLLM | RK3588 NPU 专用 | 瑞芯微设备部署 | 取决于板子 | 中 |
为什么 Agent 场景里我反复强调判断器要独立成服务？因为判断器是高频调用点。主模型可能一分钟只调一两次，判断器在每个工具调用前后都可能被调用，一次复杂任务甚至要跑几十次。如果把判断器直接塞进主模型的推理进程，两者抢显存、抢调度，很快会互相拖垮。独立成服务之后，可以单独扩容、单独缓存、单独升级，出问题也好定位。
个人试验阶段用 Ollama 完全够，一条命令就能拉模型起服务。但项目一旦要上线、要“扛并发”，vLLM 是更稳的选择。vLLM 自带的 continuous batching 能让大批请求在 GPU 上排得更满，吞吐表现比并发傻开多个进程好很多。如果只想快速包一个内部接口，用 FastAPI 或者 Flask 套一层也行，只是并发上限会比较低。
3.2 本地起一个判断器服务的完整步骤
我这里以部署一个 Laya 前置路由判断器为例，把完整流程走一遍。
第一步，拉取模型。如果走 Ollama，在命令行直接拉取量化版即可，具体 tag 以官方仓库为准：
ollama pull laya:8b-q4_K_M如果走 vLLM，可以用huggingface-cli download或modelscope download把权重先下到本地目录。
第二步，起服务。Ollama 一条命令就能跑起来：
ollama run laya:8b-q4_K_M生产环境建议用 vLLM：
vllm serve laya-judge \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --port 8001这里的--max-model-len不要拉太高。判断器不需要吃很长的上下文，8192 通常就够。上下文设短一点，KV cache 占用的显存就小，同样的显存能塞下更多并发请求。
第三步，用 OpenAI 兼容接口调用。下面这个 Python 示例可以直接搬进你的 Agent 代码里，在工具调用前先跑一次路由判断：
import json from openai import OpenAI client = OpenAI(base_url="http://127.0.0.1:8001/v1", api_key="EMPTY") def route_agent_action(query: str, tools: list[str]): resp = client.chat.completions.create( model="laya-judge", messages=[ {"role": "system", "content": "你是一个 Agent 路由判断器。只输出 JSON，不要任何解释。字段：decision(human/tool/direct)，tool(选中工具名)，confidence(0-1)"}, {"role": "user", "content": json.dumps({"query": query, "tools": tools})} ], temperature=0.1, response_format={"type": "json_object"}, ) return json.loads(resp.choices[0].message.content)返回结果里拿到decision和tool之后，Agent 就可以决定是直接回答、交给用户还是调用某个工具。这一套流程跑通之后，后续换 Jev 做反思判断只是换一个 model 名和换一套 prompt 的事。
3.3 高并发场景：判断器如何扛住 Agent 的海量请求
Agent 项目跑起来之后，“并发”是绕不开的话题。每次工具调用前后都要请求判断器，请求量会很快放大。我的经验是分三步走：并发服务、缓存、限流降级。
第一步是并发服务本身。主链路通过 HTTP 调用判断器，vLLM 端利用 continuous batching 接收请求。如果单卡吞吐不够，就多起几个实例，前面挂一层负载均衡，或者直接用 Kubernetes 的 Deployment 加 Service。判断器模型小，多实例的成本远低于多实例主模型，扩容压力不大。
第二步是缓存。判断器有大量重复请求：同一类工具调用意图、同一批 RAG 片段取舍，在短时间内会反复出现。我习惯用 Redis 对输入 prompt 做哈希缓存，TTL 根据场景设 60 秒到 5 分钟。实测在会话密集场景下，这个缓存能打掉三到五成重复计算，效果非常明显。
第三步是限流降级。给判断器设超时阈值，比如路由判断 800 毫秒、反思判断 3 秒。一旦超时不要无限等，直接降级为“按默认规则处理”，比如默认调用主模型自判。加了这层兜底之后，Agent 的整体失败率反而更低了，因为判断器是辅助组件，不是不可替代的环节。
压测时我最关注的是 p99 首 token 时延和整体吞吐，平均延迟参考意义不大。Agent 场景里，几个慢请求会造成整条任务链路的追赶效应，拖慢后面所有步骤。判断器的 p99 能压到 1 秒以内，才算一个合格的状态。
3.4 边缘设备部署：Jetson Orin 与 RK3588
边缘端部署大模型这两年特别热，“DeepSeek 本地部署 Jetson Orin”“RK3588 部署 YOLOv8”这类话题在社区里经常见。判断器这种小模型，恰恰是边缘设备上最适合跑的 LLM 任务之一。
Jetson Orin 的优势是有完整的 CUDA 环境，部署体验接近桌面端。我试过在 Orin NX 16GB 上跑 7B Q4 量化的 Laya，路由判断的响应速度能接受。部署时先按 JetPack 版本装好 PyTorch/CUDA 容器，再用 llama.cpp 或者支持的 vLLM 版本做推理后端。要注意算力和功耗的平衡，别把 Orin 跑到满负荷，否则散热和功耗都会变成新的麻烦。
RK3588 是另一套玩法。它的 NPU 算力有限，跑视觉模型 YOLOv8 已经很成熟，通常用 RKNN 工具链转换；跑语言模型一般走 RKLLM 工具链。受算力和内存带宽限制，建议只跑 1.5B 到 3B 的量化模型，硬上 7B 会非常吃力。我的实际建议是：在 RK3588 上部署判断器，优先把模型压得足够小，同时把 prompt 压缩到最短，只传工具列表和用户问题的摘要，不要塞完整历史对话。
边缘端一个容易忽略的坑是模型版本管理。设备上部署完之后，模型还会迭代，万一新版本有问题要能回滚。我习惯把权重标签写进配置和 API 响应里，比如model: laya-8b-q4-v2，排查问题时一眼就能看出线上跑的是哪个版本。
3.5 判断器怎么融入现有 Agent 框架
“harness 和 agent 区别”是社区里问得比较多的问题。简单地说：Agent 是干活的智能体，Harness 是套在它外面的控制循环，负责调度工具、管理状态、处理错误。判断器在 Harness 里面是一个可插拔组件，而不是另一个完整的 Agent。
无论用 LangGraph、Dify 还是自研循环，接入思路都差不多。只要判断器暴露 OpenAI 兼容接口，在工具调用节点前插入路由判断，在工具返回后插入反思判断即可。大致的流程是：用户输入先经过 Laya，决定是直接回答还是调用工具；如果调用工具，主模型负责生成具体参数并执行；工具返回结果后，再经过 Jev，判断结果是否满足预期；不满足就带着 Jev 的结论回到主模型重新规划，满足就汇总返回。
这相当于给主模型配了两个裁判，一个管开局，一个管复盘。框架本身不需要大改，只需要在循环的合适位置发出请求、读取结构化结果。
4. 常见问题、避坑与我的选择建议
4.1 判断器部署与使用的常见问题速查
下面这张表是我在实际项目里遇到频率最高的问题和对应解法，可以直接当成排查手册用。
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 判断器经常返回散文而非 JSON | Prompt 没有明确约束 | system 里写明“只输出 JSON”，开启response_format=json_object，温度调到 0.1 以下 |
| 本地显存不足，服务起不来 | 模型太大或上下文设太长 | 换 Q4/AWQ 量化，max-model-len 压缩到 4096 或 8192 |
| 路由判断准确率不高 | 模型与任务不匹配 | 增加 few-shot 示例，加入“无法判断时返回 abstain/direct”的退出选项 |
| RK3588 上模型转换失败 | 算子不支持或工具链版本不匹配 | 查 RKLLM 支持列表，换成官方适配过的底座，或退回 CPU 后端 |
| Agent 在并发高峰频繁超时重试 | 判断器服务排队 | 上 vLLM，多个副本加负载均衡，加 Redis 缓存，设超时降级 |
| Jev 反思太慢拖垮整条任务 | 反思阶段塞了太多历史 | 只截取最近几轮关键轨迹，限制 judge 最大输出 token |
虽然不是标准答案，但覆盖了大多数常见故障。如果你遇到的情况不在表里，优先看日志里判断器的响应时间和返回结构，一般能定位到方向。
4.2 几个我实际踩过的坑
第一个坑是 prompt 混用。早期我把主模型的 system prompt 直接给判断器用，结果它动不动输出一大段“经过分析，我认为……”的分析，解析器每次都要从里面捞 JSON，偶尔捞错字段。后来我给判断器单独设计了一套极简 prompt，并把输出字段用 JSON Schema 写死，问题立刻缓解。判断器的 prompt 和主模型的 prompt 必须是两套，这一点越早想清楚越好。
第二个坑是把判断器结果当绝对真值。判断器模型再准，也只是概率输出。我遇到过 Laya 把“可以调用工具”错判成“直接回答”，导致 Agent 漏掉了一次关键检索。后来我在输出里强制加confidence字段，低于 0.8 就交回主模型自检。这样判断器负责大多数快速决策，主模型只在低置信度时接管，误判率明显下降。
第三个坑是边缘设备上“能跑”和“好用”完全两码事。RK3588 上模型能加载，不代表速度能接受。我试过在它上面用 CPU 后端跑 7B 模型，结论是：能出字，但慢到用户已经放弃等待。边缘端还是得接受“模型更小、任务更专一”的现实，要跑大一点的模型，就应该选 Jetson Orin 这类有 CUDA 的设备。
第四个坑是只优化平均延迟。Agent 项目的用户体感更多由尾延迟决定。某个请求在判断器这边卡了 5 秒，后续所有步骤都会跟着推迟。我现在每次压测都看 p99，低于 1 秒才算合格，平均延迟只作为参考。
4.3 我当前推荐的判断器组合
如果你也想在自己的 Agent 里加判断器，我的建议是别把 Laya 和 Jev 当成二选一的竞品。更实用的组合是“Laya 做路由 + 主模型做执行 + Jev 做反思”。这套组合对硬件要求不算夸张：Laya 用 8B 量化版，Jev 用 8B 或更小版本，两张消费级显卡就能撑起一个小型线上服务。预算不足时，Jev 也可以先用同样大小的通用本地模型顶替，等量化和部署方案摸熟再切换。
团队刚起步时，我甚至建议只上 Laya，先把“该不该调工具”这一关守住；观察一段时间后，再用 Jev 把“结果对不对”这一环补上。不要一上来就搭一整套豪华判断链路，因为多个判断器之间也会互相干扰，出了问题你分不清是路由错了还是反思错了。先跑通，再叠加，这是 Agent 工程里最省心的节奏。
我自己这几个月最大的体会是：Agent 项目提升稳定性，很多时候不是换一个更大的主模型，而是把这些琐碎的判断职责拆出去。Laya 和 Jev 恰好代表了两种不同的拆法：一个快、一个准，一个管事前、一个管事后。如果你手头也有一摊 Agent 任务，不妨先不动主模型，试着在调用工具之前加一个极小的路由判断，再看执行完之后加一个反思校验，多半能看到失败率明显变化。
最后分享一个我一直保留的小技巧：每次迭代判断器的时候，把线上失败的请求攒成一个 jsonl 文件，挑 20 到 50 条塞进 few-shot，比单纯调 prompt 提准确率快得多。这个方法既不挑模型，也不挑框架，简单但非常管用。
