上篇我们认识了 JEV一个专注于快速判断与决策的“协处理”模型 —给它当前状态再问“选哪个”“程度多少”“是不是”它返回结果和概率。它精准的针对当前 Agent 系统中普遍存在的“大炮打蚊子”的问题 — 用复杂的推理来完成大量需要高速甚至实时的判断。因此把“JEV 们”放入 Agent比较合适的位置就是这类决策环节要不要继续任务、点哪个控件、工具是否安全等并和 LLM 、确定性程序实现分工合作本篇对 Agent 系统中 JEV 包括其他类似模型的典型应用场景做拆解。01ReAct 行动循环常见的 ReAct Agent 是一种推理与行动交替进行、自主完成任务的系统。其核心的 Agent Loop 会不断的做出类似的判断与决策目标任务是否已经完成我是否应该重试刚才的工具调用我是否需要进入HITL的环节把控制交给人类下一步应该调用哪个工具这些都是代表性的 Choice 或者 Noul 类型的问题。通常这些决定都交给擅长推理的 LLM很多调用只是在有限”菜单“里选一项。现在这正是 JEV 可以尝试的地方Agent 保存任务目标、每轮输出和更新状态JEV 负责从当前可选动作如结束任务、询问用户、调用某个工具等中判断下一步动作当然 JEV 的答案只是动作建议完成与否仍然由程序验证循环上限也由 Agent 代码控制而遇到要分析复杂状态、生成解决方案的情况仍需要 LLM。你可以用一个简单的自定义 Agent Loop 来验证可行性给 Agent 设定一个任务以及一些可用的工具然后让 Agent 根据当前状态包括目标、 配置、历史消息等、候选工具来判断下一步动作直到完成。模拟如下def agent_run(client): ... try: for_in range(8): state env.observe() action client.choose(state, env.instructions, env.criteria) env.step(action) if env.done: ...在这里 “choose”的动作就是交给 JEV 模型来完成的判断。实际测试中如果发现在延时上并没有体现出 JEV 的优势很可能是网络延迟导致解决方法是使用本地的开源平替比如 Laya。在这个场景中JEV 的主要价值是用毫秒级的决策模型来让 Agent Loop 控制成本更低速度更快也因此可以引入更多的检查环节。02Computer UseWeb 自动化Web/GUI Agent 已经成为 AI 应用的重要形态。但常见的问题是消耗资源且延时较大特别是使用视觉模型辅助的这类 Agent。这类 Agent 的传统做法都是让 LLM 反复读取页面DOM 或者截图、生成下一步操作长页面和多步任务会不断消耗时间与上下文。那么是否可以这样改进把当前页面能做的 UI 操作先整理成一个“菜单”Choices用 JEV 这类高速决策模型来回答“操作哪个元素、做什么动作”以指导 Agent 下一步的动作。著名的开源项目 Browser Use 已经提供了这样一个开发库jev-ultrafast。让你可以借助 JEV 来使用 Browser Use 框架实现 Web Agentfrom jev_ultrafast import Agent with Agent( ...web agent 任务“ ) as agent: for state in agent.run(): print(state[elapsed_ms], state[status])小编用 jev-ultrafast 做了一个简单演示完成一个酒店搜索的任务GOAL (Search for hotels in Hangzhou. Set the nightly budget filter to CNY 500 or less and enable the breakfast-included-only filter, then apply the filters. Open the matching hotels details and verify that its city is Hangzhou, its nightly price is at most CNY 500, and breakfast is included. Stop on that details page. Do not make any booking.)这里使用 jev-ultrafast 的 Agent 等相关 API 来完成任务对其每一步的选择choose进行了跟踪并输出最后的停留页面当然这种方案目前并不完美遇到未暴露为可选元素的控件、需复杂视觉识别的场景或开放文本等仍需要浏览器能力和多模态的 LLM 配合。不过这也让我们更加期待多模态的“JEV”们的出现。03工具与技能路由工具Tool和技能Skill体系是 Agent Harness 最重要的组成之一。传统 Agent 把每个工具的描述和技能都塞进模型上下文然后让模型判断并生成工具调用工具目录越大描述越长相近工具越容易混淆且 Token 消耗越大。借助 JEV 这样的决策模型Agent 可以把“需要哪些工具”变成一个 Choice 问题基于“分层路由”Hierarchical routing的模式实现像医院分诊一样的工具选择路径 — 尤其当工具集稳定、用途清晰时。先选医院工具大类再选科室激活工具集再找医生本轮工具。这对于平台级的 Agent 来说工具目录经常动态变化可以让模型看到一个更小、更相关的工具范围减少干扰提高推理准确性。比如第一层让 JEV 从“公共、财务、编程、检索、管理”等类别做选择。选中“财务”后程序再加载这个分支让第二个 Choice 从“查询余额、开发票、退款、对账”中再选一个。当然在具体实现时需要做更精细化的控制和评估结合confidence置信度拿不准就保留多个候选继续比较或让用户澄清每层也要有“不匹配”的出口避免第一步选错就一路错到底。分层能缩小选择范围但代价是增加误选或遗漏使用决策模型后是否真的更快、更准需要在上线前做批量评估。JEV 的 Choice 单题最多支持 255 个选项并非有几十个工具就必须分层。04工具安全守卫随着各种通用 Agent 的盛行给这些 Agent 的工具执行设置安全“门禁”至关重要。常见的方法有给工具设置安全级别严重的要求人工审核但容易被“忽视“关键词拦截根据工具、参数等识别关键词但容易“误伤”交给 LLM 判断频繁审查增加延迟和成本而且同一模型审查意义不大更稳妥的架构是在工具执行之前设一道语义守卫根据本次调用和对话状态判断工具风险据此放行或拦截当风险不确定或后果严重时也可以转入人工环节。这个工作就很适合 JEV 这样的快速模型。比如提出 Noul 类型且有明确标准的问题“是否包含提示注入”、“是否泄露敏感信息”、“输出是否违反约定”等然后返回概率再由程序决定放行、拦截或交人类复核LangChain 已经把这个模式用中间件一种类似钩子的机制进行了封装AutoModeMiddleware。它在工具执行前调用 JEV风险达到阈值就返回拦截消息guard AutoModeMiddleware(toolstools) agent create_agent(planner, toolstools, middleware[guard]) result agent.invoke({messages: [HumanMessage(contenttask)]})你也可以自定义一个工具门禁实现一个 Middleware然后在 wrap_tool_call 中借助 JEV/Laya 做判断处理。比如class LLMAutoMode(AgentMiddleware): ...... defwrap_tool_call(self, request, handler): answer self.judge.invoke(...); if answer.risk_estimate 0.5: return ToolMessage( content(fThe tool call {request.tool_call[name]} was blocked because fit was classified as risky (LLM estimate: {answer.risk_estimate:.2f}). The tool was not executed.), tool_call_idrequest.tool_call[id], namerequest.tool_call[name], statuserror) return handler(request)在这里借助决策模型的优势是 —你可以在一次任务中做很多这样细小的风险检查而不用担心延迟与成本。但正如我们之前强调的JEV 们宣传的“无幻觉”不代表不会决策错误所以结合使用其他的一些风控机制仍然是必要的。05Agent 任务评估与观测当 Agent 报告任务已经完成大部分时候我们会选择“信任”它 — 再通过人工审查、代码测试等方法来评估其完成度。还有一个常见做法是请另一个 LLM 当“评委”读取 Agent 的执行轨迹并给出评估结果。不过这种评估大多缓慢且结果非结构化。现在借助 JEV 这类模型可以把评估拆分成更具体的问题用 Noul 检查任务是否完成、是否违规、是否需要人工复核用 Score 评估任务完整程度、问题紧急程度用 Choice 告诉你是完成、重试、放弃还是人工复核。这种方案可以很好的用于监控 Agent 任务完成情况与质量并指导后续改进。比如分析客服 Agent 中的详细跟踪日志 — 如果你对每天成千上万次 Agent 的运行生成这样的分析结果就可以用来监控服务质量、做A/B对比、失败分析、甚至做自己的训练样本筛选。考虑到 JEV 这类模型的性能与成本你可以让这种评估真正的融入到 Agent 的日常监控与观测而无需担心 Token 爆表。06模型与 Agent 路由在 Agent 任务中让 LLM 写一封邮件与在多约束条件下进行一次规划需要的能力并不相同。但大部分时候特别是单 Agent 系统我们会倾向于使用统一的模型。问题是如果全用强模型则造成浪费而全用小模型则任务质量下降甚至返工。一种方法是让 LLM 先做模型分流但这个动作本身又是开销。而 JEV 就更适合回答这种边界清楚的路由题给定请求、候选模型以及判断标准各模型擅长的任务让 JEV 帮你选择合适的处理者给出建议与概率。你还可以结合任务难度、风险与不确定性等制定分流标准。当然如果把候选从 LLM 换成“研究、编程、数据分析”等专业 Agent同样可以用于 Agent 任务的分派与交接意图识别。在具体的实现中结合 Confidence 置信度进行一些保护也是必要的而不是简单的选取概率最高者 — 路由错误导致的返工或质量的代价要远大于一次路由的代价。LangChain 官方也实现了这样一个 MiddlewareModelRouterMiddleware可以很方便的让 Agent 具有根据复杂度选择合适模型的能力router ModelRouterMiddleware(choices{ fast: ModelChoice(modelfast, criteria单笔查询), powerful: ModelChoice(modelpowerful, criteria多约束规划), }, instructions选择能完成任务且成本最低的模型) agent create_agent(fast, toolstools, middleware[router])这里的 criteria 参数告诉路由器各模型适合的任务也就是分流的判断标准。其目前的机制是在一次 Agent Loop 运行开始时根据最新的用户消息选择模型后续则复用。07RAG 与上下文管理RAG 管道的价值大部分时候并不取决于模型而是数据或知识的质量以及检索的相关性与完备性。而基于向量相似性的语义检索并不足以解决这个问题这也是出现众多高级 RAG 方法C-RAGSelf-RAG等的根本原因。一种常见的优化思路是用 LLM 对语义检索的结果进行相关性判断并根据结果进行必要的知识筛选、补充比如 Web 搜索或 Query Rewrite。现在你可以借助 JEV 等决策模型让它充当检索知识进入上下文前的“筛选员”对知识相关度进行评估与过滤。很显然JEV 模型非常适合回答这类问题Noul这段知识是否能够支持回答输入问题Score这段知识与输入问题的相关程度如何Noul 这些知识是否足够回答用户的输入问题根据这些问题的答案你可以选择废弃不相关知识或补充更多知识大致的程序处理逻辑如下... def rag(question, retrieve, llm_answer, client): # jev判断是否相关 def judge(instructions, **state): return client.system_one( statestate, questions{ok: Noul(instructionsinstructions)}, ).nouls[ok].noul kept, seen [], set() for _ in range(3): # 最多三轮检索 for chunk in retrieve(question, excludeseen): seen.add(chunk.id) if judge(片段包含回答问题所需的信息吗, questionquestion, chunkchunk.text) 0.5: kept.append(chunk) # jev判断知识是否足够 if kept and judge(这些知识足够回答问题的所有要点吗, questionquestion, evidence[c.text for c in kept]) 0.8: return llm_answer(question, kept) return资料仍不足需要补充信息所以现在你可以构建一个两阶段的检索策略先做更宽泛的检索比如 Top_k10然后借助决策模型做低成本的筛选最后将选中的知识用来生成答案。另外你可以使用决策模型输出的概率来实现类似排序模型Rerank的能力这里的评分可以使用 Noul 输出的概率也可以使用 Score 评分并结合置信度。这套思路也能用于 Agent 的上下文管理。方法很简单让 JEV 判断旧的对话记录是否仍有用再由程序来执行保留或废弃而不是直接让 LLM 去做历史对话的摘要 — 容易带来上下文丢失。GitHub 上有一个 Claude Code 插件fast-jev-compaction 其通过评分来废弃无用的工具调用及结果只保留重要内容从而达到精简上下文的目的。08实时动态决策最后是一个收益最大的场景实时决策。在游戏、仿真、机器人等环境里的 AI 需要极其快速的反应毫秒级下一步应该怎么做因为每走完一步下一步的“路”可能就变了。如果让 LLM 每轮从头推理则性能无法满足要求想象下游戏里的 NPC 每次要思考 5 秒才有反应而使用固定规则又不够智能。现在你可以让 JEV 们和 LLM 们来配合LLM 负责长期的目标规划 。比如完成任务的主要步骤JEV 负责在每一步骤中根据环境状态做出可能需要的快速判断举一个例子一个仓库配送机器人要完成“把某个包裹送到打包台”。LLM 可以拆解并规划出路径确认包裹 → 前往货架 → 取件 → 运到打包台。但是执行到一半通道被货物挡住此时则由 JEV 来根据当前环境、位置、可选动作来判断下一步怎么做。这里的状态State可以来自游戏引擎、环境传感器或 API 接口等而程序的执行通常由专用的控制系统负责。不过由于当前的决策模型还不支持视觉理解这也在很大程度限制了其应用相信随着未来多模态能力的解锁将带来这类快速反应系统能力上的突破。总结以上是我们为大家拆解的 JEV 包括其他类似的开源模型在 Agent 系统中的一些典型应用场景。总结来说JEV 很适合 Agent 里高频、高性能、答案有限的判断与决策。更多应用层面的场景如意图识别、邮件分类、工单分流、内容打标等都能沿用这套思路 — LLM 做规划生成JEV 做高速判断程序则负责确定性执行以减少不必要的 Token 开销提高决策速度并由此产生更多收益。