1. 一个不写字的模型凭什么让 Agent 圈集体刷屏第一次看到 Jev 这个名字是在几个 Agent 开发群里同时被刷屏。点进去之前我以为是又一个套壳聊天产品点进去之后发现完全不是那么回事——它压根不生成文本它只做一件事判断。这个定位在当下这个万物皆可生成的时间点显得特别反常识。我们习惯了让模型写代码、写文案、写总结突然冒出来一个模型你给它一段上下文它不给你续写而是给你一个判断结果这个动作该不该执行、这个工具调用是否安全、这段代码有没有类型漏洞、这个浏览器操作会不会越界。它输出的不是内容是决策。Jev 解决的核心问题是 AI Agent 在真实执行链路里最要命的一环判断。Agent 的架构通常是规划-执行-观察的循环规划靠大语言模型执行靠工具调用但中间那个这个动作到底能不能做的判断环节长期是靠提示词硬扛的。提示词判断的问题在于不稳定、不可控、不可审计而且每次都要消耗大量 token 去让模型想清楚。Jev 把这一层单独抽出来做成一个专用模型用极低的延迟和极高的确定性来回答是/否/风险等级这类问题。适合谁来了解这个东西如果你正在搭 Agent、正在被工具调用的安全性折磨、正在为 Codex 这类编码 Agent 的越权操作头疼、或者你只是想知道 2026 年 Agent 基础设施会往哪个方向走那 Jev 这个案例值得拆开看。它不代表某个具体产品的胜利它代表一种架构思路的转向把判断从生成里剥离出来。我下面会从它为什么这么设计、核心判断逻辑怎么落地、怎么接入到 Codex 和 BrowserUse 这类实际场景、以及踩坑排查几个角度把这个东西讲透。不是官方文档的复述是我自己拆解和实测之后的整理。2. 为什么判断要从生成里拆出来2.1 生成模型做判断的三个致命伤先说清楚为什么大家之前不用专用判断模型。因为大语言模型看起来什么都能干判断这种小事顺手就做了。但真到生产环境问题全暴露出来。第一个是不确定性。你问 GPT 类模型这个 shell 命令能不能执行同样的输入温度调成 0 它也可能给你不同的措辞有时候说可以但要小心有时候说不建议有时候直接给你改写一版。对于 Agent 来说它需要的是一个明确的信号不是一段模棱两可的建议。判断模型的价值就在于输出空间被压缩到极小基本就是布尔值加风险等级没有解释性废话。第二个是延迟和成本。Agent 的执行循环里判断是高频动作。每一步工具调用前都要判断一次任务下来可能几十上百次判断。如果每次都走一遍大模型推理延迟叠加起来非常可观token 成本也会失控。Jev 这类判断模型通常参数量小、推理路径短单次判断的延迟可以压到生成模型的零头。第三个是不可审计。生成模型的判断藏在自然语言里你很难做结构化日志很难做规则回溯出了问题只能翻聊天记录。判断模型输出的是结构化结果可以打点、可以统计、可以做阈值告警。这在企业级 Agent 里是刚需。提示判断和生成分离本质上是把决策和表达这两件事解耦。Agent 里凡是需要确定性决策的地方都值得考虑用专用判断模型替代提示词。2.2 判断模型的输出空间设计Jev 这类模型最值得研究的是它的输出设计。它不输出文本输出的是一个受限的决策空间。常见的几种形态二分类allow / deny最简形态适合安全闸门场景多级风险safe / low / medium / high / critical适合需要分级处理的场景动作选择在给定候选工具里选一个最合适的适合路由场景置信度打分0 到 1 的连续值适合需要阈值调节的场景为什么输出空间要受限因为受限意味着可枚举、可测试、可回归。你可以为判断模型写单元测试给定输入断言输出这在生成模型上几乎做不到。这也是 TypeSafe 这个概念在 Agent 领域火起来的原因——判断结果本身要有类型要有约束不能是自由文本。2.3 和 Codex、BrowserUse 的关系Codex 这类编码 Agent 和 BrowserUse 这类浏览器 Agent是判断模型最典型的两个落地场景。Codex 在执行任务时会生成 shell 命令、文件操作、代码补丁。这些动作里有些是安全的有些是破坏性的比如rm -rf、覆盖配置文件、往生产环境推代码。传统做法是在提示词里写一堆不要做危险操作但模型该犯还是会犯。Jev 在 Codex 里的角色就是在命令真正执行前插一道判断闸门把危险动作拦下来。BrowserUse 的场景更微妙。浏览器 Agent 会点击、输入、跳转它面对的是真实网页可能触发支付、可能提交表单、可能泄露信息。判断模型在这里要做的是识别这个点击是不是用户真正想要的防止 Agent 被页面上的诱导性元素带偏。这两个场景的共同点是动作不可逆判断必须前置。这也是判断模型存在的根本理由。3. Jev 的核心判断逻辑与实操接入3.1 判断模型的输入构造判断模型不是凭空判断的它的输入构造直接决定判断质量。一个合格的判断输入通常包含四部分任务上下文当前 Agent 正在做什么目标是什么候选动作即将执行的具体动作越结构化越好环境状态当前所处的环境比如工作目录、权限级别、是否生产环境历史轨迹之前已经执行了哪些动作避免重复或矛盾我实测下来输入构造里最容易出问题的是候选动作的粒度。太粗判断模型抓不住重点太细判断模型会陷入细节。经验做法是把动作归一化成动词对象参数的三元组比如write_file(path/etc/hosts, content...)这样判断模型能快速定位风险点。3.2 接入 Codex 的实操步骤把 Jev 接进 Codex 的判断链路核心是在工具调用前插一个 hook。下面是我整理的一套可复现流程。第一步确认 Codex 的调用入口。Codex 通常以 CLI 或本地服务的形式运行工具调用会经过一个统一的执行函数。你要做的是在这个执行函数里真正执行动作之前把动作信息发给 Jev 判断。第二步构造判断请求。以 shell 命令为例import requests def judge_command(command: str, cwd: str, env: str) - dict: payload { context: { task: code_agent_execution, cwd: cwd, environment: env # dev / staging / prod }, action: { type: shell, command: command } } resp requests.post(http://localhost:PORT/judge, jsonpayload, timeout2) return resp.json()第三步根据判断结果决定放行还是拦截。判断结果里通常有decision和risk_level两个字段。我的做法是safe直接放行low记录日志放行medium以上弹确认或直接拦截。result judge_command(cmd, cwd, env) if result[decision] deny: raise PermissionError(fBlocked by Jev: {result[reason]}) if result[risk_level] in (medium, high): log_warning(cmd, result) if env prod: raise PermissionError(High risk action in production)第四步做超时和降级处理。判断模型本身也可能挂这时候不能让整个 Agent 卡死。我的策略是判断超时默认拒绝高风险动作、放行低风险动作同时打点告警。注意判断模型的超时阈值不要设太大Agent 循环里判断是高频动作单次超过 500ms 就会明显拖慢整体体验。我一般设 300ms 到 500ms。3.3 接入 BrowserUse 的判断点BrowserUse 的判断点和 Codex 不太一样它的动作更软但后果可能更严重。我梳理了几个必须插判断的位置点击前尤其是按钮、链接、提交类元素判断这个点击是否符合当前任务目标输入前往表单里填内容判断是否涉及敏感字段跳转前导航到新页面判断目标域名是否在允许列表内提交前任何 form submit这是最后一道闸门BrowserUse 的判断输入要带上页面上下文比如当前 URL、页面标题、目标元素的文本和属性。判断模型据此判断这个动作是不是任务相关的。def judge_browser_action(action, page_url, element_info, task_goal): payload { context: {url: page_url, goal: task_goal}, action: action, element: element_info } return requests.post(JUDGE_ENDPOINT, jsonpayload).json()实测下来BrowserUse 场景里判断模型最容易被诱导性元素骗到比如页面上有个巨大的立即领取按钮但任务目标其实是查订单。这时候判断模型要能识别出动作和目标的不一致。3.4 TypeSafe 思路在判断结果上的应用TypeSafe 这个词在 Agent 圈火核心诉求是让 Agent 的每一步都有类型约束。判断模型的输出天然适合做类型化。我习惯把判断结果定义成枚举类型而不是字符串from enum import Enum class Decision(Enum): ALLOW allow DENY deny CONFIRM confirm class RiskLevel(Enum): SAFE safe LOW low MEDIUM medium HIGH high CRITICAL critical这样做的好处是下游处理逻辑可以用模式匹配编译器能帮你检查分支覆盖不会出现判断模型返回了一个你没处理的值这种运行时惊喜。这也是判断模型相比提示词判断的一大优势——它的输出可以被类型系统接住。4. 判断模型的参数调优与效果验证4.1 阈值怎么定判断模型通常会给一个置信度或风险分阈值定在哪里直接决定误杀率和漏放率。这个没有标准答案要看场景。我的经验做法是分环境定阈值环境放行阈值拦截阈值说明开发0.50.9宽松鼓励尝试预发0.70.85平衡观察行为生产0.850.7严格宁可误杀生产环境的放行阈值高于拦截阈值意味着中间有一段灰区会走人工确认。这个设计是为了避免判断模型在边界情况下自作主张。4.2 怎么验证判断模型的效果判断模型的效果验证和生成模型完全不同。生成模型看输出质量判断模型看的是混淆矩阵。你需要构造一批标注好的动作样本每个样本标注应该放行还是应该拦截然后跑判断模型统计四个指标真阳性该拦的拦住了假阳性不该拦的拦了误杀真阴性该放的放了假阴性不该放的放了漏放Agent 场景里假阴性的代价通常远大于假阳性。漏放一个危险命令可能删库误杀一个安全命令只是多一次确认。所以调优方向应该是压低假阴性容忍一定的假阳性。4.3 判断模型的持续迭代判断模型不是一劳永逸的。Agent 的任务分布会变新的危险模式会冒出来。我的做法是把所有判断结果落库包括输入、输出、最终是否被人工推翻定期 review 被推翻的样本这些是判断模型的盲区把盲区样本加入训练或规则库做增量迭代这套闭环跑起来之后判断模型的准确率会随着使用逐步提升而不是原地踏步。提示判断模型的日志一定要存原始输入不要只存判断结果。否则出了问题你根本不知道当时判断模型看到了什么。5. 常见问题与排查实录5.1 判断模型接入后 Agent 变慢这是最常见的反馈。原因通常有三个判断请求是同步阻塞的、判断模型本身推理慢、判断被调用了太多次。排查顺序先看单次判断延迟如果超过 500ms说明判断模型本身有问题考虑换更小的模型或做量化。如果单次延迟正常但整体变慢看调用次数可能是判断点插得太密把一些明显安全的动作也送去判断了。我的做法是对高频低风险动作做本地缓存同样的动作在短时间内重复出现直接复用上次判断结果。5.2 判断结果不稳定同一个动作判断模型时而放行时而拦截。这通常是输入构造不稳定导致的比如上下文里带了随机的时间戳、带了会变化的会话 ID。判断模型的输入要尽量归一化把不影响判断的字段剔除掉。另一个可能是判断模型本身有随机性。如果它支持温度参数判断场景一律设成 0。5.3 判断模型误杀正常操作误杀率高的时候先别急着调阈值先看误杀的样本有没有共性。我遇到过一类情况判断模型对某个路径特别敏感因为训练数据里这个路径出现过危险操作。这时候要么在输入里补充更多上下文让判断模型区分要么对这个路径做白名单。5.4 判断服务不可用怎么办判断服务挂了Agent 不能跟着挂。降级策略要提前设计好。我的方案是判断服务不可用时高风险动作一律拒绝低风险动作放行但打点告警同时触发判断服务健康检查恢复后自动切回这个策略的核心是故障时保守宁可让 Agent 停下来也不要让它带着不确定的判断继续跑。5.5 常见问题速查表现象可能原因排查方向Agent 整体变慢判断同步阻塞 / 调用过密看单次延迟和调用次数判断结果抖动输入含随机字段 / 温度非 0归一化输入温度设 0误杀率高阈值过严 / 训练盲区看误杀样本共性漏放危险动作阈值过松 / 输入缺上下文补充环境信息收紧阈值判断服务超时模型推理慢 / 网络问题看服务端延迟加超时降级判断结果无法解析输出格式不稳定强制结构化输出加校验6. 判断模型这条路会怎么走我自己搭过几套 Agent从最早全靠提示词硬扛到后来加规则引擎再到用判断模型最大的体会是Agent 的可靠性不取决于它多能生成而取决于它多会判断。生成能力再强一个越权操作就能把整个系统的信任度打没。Jev 这类判断模型的出现本质上是把 Agent 的刹车系统专业化。以前刹车是拿提示词凑合的现在有了专用件。这个方向我觉得会继续分化未来可能会出现针对不同场景的判断模型代码判断、浏览器判断、数据库操作判断、支付判断每个都有自己的风险模型和阈值体系。对开发者来说现在值得做的事是把判断层从业务逻辑里抽出来做成可替换的模块。今天用 Jev明天可能有更适合你场景的判断模型接口一致的话切换成本很低。判断层的接口设计我建议就三件事输入动作和上下文输出决策和风险等级附带一个可选的解释字段用于排查。最后分享一个我踩过的坑一开始我把判断模型当成万能闸门什么动作都送进去判断结果判断服务成了瓶颈而且很多判断其实是重复的。后来我做了分层明显安全的动作走本地规则直接放行只有规则覆盖不到或者风险不确定的才送判断模型。这样判断调用量降了一个数量级整体延迟也下来了。判断模型是好东西但别把它当唯一防线规则、白名单、判断模型三层配合才是稳的架构。