Agent亟需新决策层：JEV为何值得关注
当前的智能代理（Agent）已经集成了越来越多的工具，包括浏览器、代码执行环境、数据库、搜索工具、邮件接口、支付系统、云资源甚至真实交易接口。但随着工具生态的丰富，行业面临的核心问题也发生了变化：过去我们担忧模型无法正确调用工具，如今更需要关注的是——它为什么选择这个工具？置信度是否足够？遇到高风险动作时是否应该主动拦截？当存在上百个候选工具时，继续让通用大模型输出自由文本再由应用猜测真实意图的模式，显然存在诸多隐患。
JEV之所以值得关注，正是因为它将Agent流程中最容易被忽略的中间环节单独抽离了出来：在规划与执行之间，增加一层可解析、带概率、受应用代码约束的决策层。它的核心并非让模型变得更聪明，而是让整个流程更可控。JEV接收序列化的系统状态和类型化问题，返回choice、score或yes/no判断及对应概率，而是否执行工具、调用哪个具体工具、风险阈值如何设定，完全由应用代码自主决定。
JEV的核心定位与工作流
根据官方文档，JEV是一款旗舰级模型，也是首个System One模型。它并非完整的Agent，也不会直接执行打开浏览器、删除文件或交易下单这类操作，更像是一个精准的快速判断器：基于当前系统状态和有限的问题，判断哪个选项最合适、风险处于哪个层级、某个条件成立的概率有多高。
一个稳定的JEV工作流通常包含三个核心角色： 1. 规划器：负责理解目标、收集上下文、生成候选动作； 2. JEV决策层：负责对有限候选进行选择、评分或判断； 3. 应用执行器：负责验证返回结果、套用预设阈值、执行工具并记录审计信息。
这条边界至关重要，相关项目文档反复强调：JEV仅负责选择、评分、路由或过滤，应用代码始终掌握最终执行权。
四种核心应用模式
1. Choice：从有限候选中选择最优项
Choice是最直观的原语模式。应用将候选标签和各自的判断标准明确传递给JEV，返回结果包含被选中的标签、各标签的概率以及置信度。
举几个常见的例子：客服Agent可以设置账单咨询、技术支持、其他问题三个类别；浏览器Agent可以设置点击指定按钮、下滑页面、返回上一页等离散动作；模型网关可以设置低成本、均衡、高性能三个模型档位。
这种模式比“让模型直接输出JSON告知工具选择”更加稳定，原因有三点：候选集合由代码定义，模型无法凭空生成不存在的工具名；返回值是固定类型，应用可以直接校验，无需从自然语言中提取意图；不仅返回最优选项，还会给出所有候选的概率，应用可以判断领先优势是否足够。Vercel AI SDK的TypeSafe适配器公开支持Choice模式，并对候选数量做约束，当前实现最多接受255个选项。这个数字是适配器的边界，不意味着一次塞入越多工具越好，真正的工程重点仍是先缩小候选集，再做决策。
2. Score：将模糊风险转化为概率分布
Score用于有序等级判断，开发者提供从低到高的评分标准，JEV返回期望分数、各等级的概率、图例和置信度，当前适配器最多支持10个评分等级。
它适合处理非简单对错的问题，比如内容风险分级、工具危险度评估、证据质量判断和结果质量评分。与直接输出一个固定分数相比，概率分布更有参考价值：比如两个任务的期望分数都是2.0，但一个高度集中在“中等”区间，另一个在“安全”和“严重”之间摇摆，后者显然需要人工复核。
3. Route：基于Choice的系统路由用法
很多项目将JEV用作路由工具，这本质上是一种系统级应用模式：先将模型、Agent、技能或工作流转化为有限候选，再通过Choice判断应该将任务交给哪个对象。
LiteLLM的复杂度路由就是典型案例：它将请求和可选的模型档位构造成JEV问题，要求选择能完整回答请求的最便宜档位，同时明确请求中要求使用特定模型的文字仅作为分类内容，不能控制路由逻辑。返回结果不仅包含选中的档位，还会给出每个档位的概率和置信度，应用可以据此实施多层策略：高置信度时直接路由，候选接近时选择更安全或更强的模型，低置信度时回退到默认模型，高价值任务则触发人工确认。
收录的路由案例还包括Agent Router、OpenChamber、Firstmate，以及Claude Code模板中的模型路由插件，它们路由的对象可以是模型，也可以是专业Agent、Skill或工作流。
4. Filter：前置判断减少后续负载
Filter是一种组合模式，应用可以通过yes/no、Choice或Score对大量候选进行第一轮过滤，只将通过阈值的少量对象交给后续Agent处理。
常见场景包括新闻线索筛选、工具输出裁剪、代码扫描结果复核、交易入口证据检查、垃圾内容和密钥泄露判断等。比如NewsJack会先过滤实时新闻，再让Agent处理入选机会；JEV Pruner和Save Token JEV Clean用于裁剪工具输出或历史上下文；QuantDinger则在部分真实交易入口前增加证据与风险门禁。过滤的价值不仅是节省token，还能形成明确的流程漏斗：原始候选、决策结果、阈值、保留项和拒绝原因都可以被记录，后续可以复盘“为什么这条内容没有进入Agent流程”。
安全门禁：概率只是信号，协议才是保障
概率只是决策的参考信号，一个系统即使拿到了0.92的置信度，如果没有定义阈值、回退机制、审计规则和执行边界，仍然不安全。一个完整的Agent安全门禁至少需要六个步骤：候选白名单、状态最小化、类型校验、分级阈值、拒绝与弃权、执行隔离。
比如Composio的TypeSafe Provider就展示了这类分层阈值设计：路由、动作门禁和参数判断分别设置不同阈值，对于破坏性工具，路由阈值最低需要达到0.9。这一设计的核心思想值得复用：风险越高，对决策证据和置信度的要求也就越高。
为什么Agent需要专门的决策层
1. 大模型不必承担所有认知工作：规划、写作、代码生成需要开放式推理，而分类、排序、评分和门禁通常是有限问题。将所有步骤都交给同一个大模型，会让延迟、成本、解析和安全边界纠缠在一起。 2. 决策结果可以被测试：结构化输入和概率输出更容易形成测试集，给定相同状态，预期选择什么、风险分数是否越过阈值、低置信度是否正确回退，Agent的“判断”由此可以进入单元测试、回归测试和线上监控。 3. 应用代码重新拿回主权：工具调用最危险的模式，是模型同时定义候选、选择候选并直接执行。JEV模式将候选和执行保留在代码侧，模型仅参与中间判断，让权限边界更容易审计。 4. 决策可以并行回答：一个JEV请求可以同时提交多个命名问题，比如工具类别、风险等级、是否需要人工确认，系统得到的是一组相互独立、可解析的答案，而非一段混合了理由、动作和自我辩护的自然语言。
开源生态与接入方法
有一个开源的源码审阅目录，收录了相关的JEV实践项目，最新快照包含171个项目、48个星标过千的仓库和10类实践方向：浏览器与电脑操作、SDK集成、路由优化、开放模型、搜索与数据、安全审查、Agent工作流、界面自动化、开发工具和垂直工具。该目录的价值在于每条项目说明都尽量链接到固定提交的源码证据，而非仅根据README宣传语归类，同时提供JSON目录格式，适合继续做生态分析或自动筛选。需要注意的是，目录中所有项目的runtimeVerified均为false，也就是仅完成了源码层审阅，并未独立运行和验证每个项目，星标数也只是抓取时的快照，不应作为质量排名的依据。
如果想要将JEV接入自己的Agent系统，可以从一个非常小的决策点开始，无需重写整个Agent流程，具体步骤如下： 1. 找到当前最不稳定的自由文本判断环节，比如“该调用哪个工具” 2. 通过代码生成有限候选，并为每个候选明确标注判断标准 3. 将当前请求和必要上下文放入可序列化的state中 4. 使用Choice、Score或yes/no格式向JEV提问 5. 验证返回的类型、概率和候选标签是否符合预期 6. 通过显式阈值决定执行、回退、拒绝或触发人工复核 7. 记录请求ID、候选、概率、阈值和最终动作，持续进行回归评估
最适合先落地的场景通常是模型路由、工具白名单选择、内容安全预分类和长输出裁剪，因为这些任务候选明确、结果容易核验，且不会一开始就触碰不可逆操作。
结语
随着Agent工具数量持续增长，真正稀缺的能力不再是“能不能调用工具”，而是“是否应该调用、该调用哪个、证据是否足够、失败时如何停下”。JEV带来的启发不一定是要求所有系统都使用同一个模型，更重要的是承认：规划和执行之间需要一个明确的决策协议，候选由代码限定，判断返回概率，策略使用阈值，低置信度允许弃权，执行继续受权限系统控制。当这层决策边界被建立起来，Agent才会从“会调用工具的模型”，走向“能够被测试、被审计、被治理的自动化系统”。
