AI端侧应用、氛围编程
OpenClaw关键升级：Jev决策模型通过共享API接入插件体系
#OpenClaw
#Jev分类模型
#AI智能体Agent
2026-09-23
6K
banq
OpenClaw给AI智能体装上了决策模型，结果发现让机器人变聪明的秘诀居然是让它少思考！
OpenClaw关键升级：Jev决策模型通过共享API接入插件体系。
--91likeyou---
OpenClaw正在用CEO的工资干前台的活
你平时用的OpenClaw跟普通的聊天机器人完全不是一回事，聊天机器人只会你问一句它答一句，而OpenClaw是一个能自主干活的程序，它能调用外部工具、读写文件、搜索网页、管理日程，甚至能自己决定下一步该做什么。
但自主干活是有代价的，OpenClaw在真正动手之前必须先做一堆小判断，比如用户发的这句话到底是不是在跟我说话；比如我手头有二十个工具该挑哪一个出来用；比如对话历史太长了哪些旧消息该扔掉哪些该留着。
这些判断每一个看起来都很小，但OpenClaw做判断的方式就是调用一次大语言模型，调用一次就要花时间和花钱，当这些杂活越堆越多的时候，你真正想让OpenClaw干的那件正事反而被拖慢了，这就好比一家公司的CEO每天花三个小时审批员工的打车报销单，审批得确实很认真，但公司的战略会议因此推迟了，打车报销单真的需要CEO级别的判断力吗！
Josh Lehman踩过的第一个坑
OpenClaw的维护者Josh Lehman一开始也走了弯路，他的第一个实验非常直觉，就是给OpenClaw加了一个工具，让OpenClaw在需要做判断的时候去调用TypeSafe团队开发的Jev。
Jev是一个专门为快速判断设计的模型，由Diogo Almeida和TypeSafe团队开发，它的特长就是接收一组条件然后瞬间给出一个结论，Josh Lehman觉得把它当成工具交给OpenClaw调用应该能解决问题。
这个方案确实跑通了，但Josh Lehman很快发现一个荒谬的现象，他的系统变成了一个慢模型在认真思考"要不要去调用一个快模型"，OpenClaw先要用对话模型理解当前情况，然后对话模型决定要不要调用Jev，然后Jev给出判断，然后对话模型再根据判断做下一步，一个本来应该瞬间完成的小判断被硬塞进了三轮模型对话里！
Josh Lehman是OpenClaw的维护者，他做的第一个实验就是给Agent挂一个决策工具，让Agent自己决定什么时候调用决策模型。结果呢？他发现问题了——你还是让一个慢吞吞的大语言模型去思考"我该不该叫那个快的来帮忙"！
这就好比你请了一个博士后帮你决定要不要用计算器算一加一！
决策模型跟聊天模型根本不是一回事
要理解Josh Lehman后来怎么翻盘的，你得先搞清楚决策模型（decision model）跟平时用的聊天模型有什么本质区别，聊天模型的工作方式是接收一段话然后输出一大段话，你得自己从那段话里猜它到底想表达什么结论。
决策模型的工作方式完全不同，它接收一组证据和一组评判标准，然后直接返回一个结构化的答案，这个答案可以是一个选项、一个分数、或者一个概率值，你的程序拿到这个答案就能直接用在下一步逻辑里，不需要再做任何文本解析。
打个比方你就明白了，聊天模型就像一个滔滔不绝的顾问，你问它今天该不该带伞，它会给你讲一段关于气压变化和季风走向的长篇分析，而决策模型就像一个天气预报App，直接告诉你降雨概率百分之八十，你拿着这个数字就能决定出门带不带伞，判断本身没有变得更准确，但你的程序终于能直接用上这个结论了！
一行代码让所有插件共享决策模型
搞清楚了决策模型是什么之后，下一个问题是把它塞进AI智能体框架的哪个位置，OpenClaw的做法是让决策模型跟聊天模型一样成为一个独立配置的组件，用户配好一个决策模型之后，所有插件都能通过Plugin SDK的共享接口直接调用。
这个共享接口的具体调用方式是一行代码：api.runtime.decisions.evaluate，任何一个插件开发者写插件的时候，只要调用这行代码，就能用上用户已经配置好的决策模型，不需要自己再去对接TypeSafe的Jev或者Jared Palmer的本地Kev服务器。
这种插件优先的架构解决了一个非常实际的集成难题，如果每个插件都要自己写一套模型对接代码，用户就得在每个插件的设置里重复配置同一个模型，而OpenClaw把这个配置收拢到了一个地方，插件只管调用，用户只管配置一次，Josh Lehman最初的实验并没有白费，他只是把决策模型放错了位置，真正该做的不是让AI智能体把决策模型当工具调用，而是让应用代码直接调用决策模型做判断！
不配置决策模型也不会影响任何功能
OpenClaw团队在这件事上非常克制，决策模型目前是完全可选的配置，用户不启用它，OpenClaw就按原来的方式运行，启用了它也只是让支持的功能和插件多了一个可用的判断通道，框架不会自动把决策模型塞进每一个环节。
这种设计背后有一个很清醒的判断，Jev刚刚上线不久，替代方案还在增长，社区还在摸索哪些环节真正适合用决策模型来处理，如果OpenClaw一上来就把决策模型绑定到核心流程里，一旦判断出错就会影响所有用户的基础体验。
OpenClaw同时把评估工具移进了核心代码库，命名为decision_evaluate，这个工具不绑定TypeSafe也不绑定Jev，任何符合接口的决策模型都能接入，用户配好了就能用，不配也不耽误事！
这里有一个关键区分必须说清楚！
给应用程序代码直接调用决策模型，和给Agent一个工具去调用决策模型，完全是两回事！
前者是插件作者在代码里调api.runtime.decisions.evaluate，用来优化插件的内部逻辑；后者是把评估工具交给Agent自己用，让Agent在运行过程中主动发起判断请求！
OpenClaw正在把评估工具移入核心，命名为decision_evaluate，这样它就不绑定TypeSafe或者Jev了，任何配置了决策模型的Agent都能用！
这个细节说明OpenClaw在架构上做了一个有意识的取舍：提供商负责翻译和传输，核心负责验证、取消、截止时间、准入和生命周期管理！
插件提交结构化的问题，决策运行时选择已配置的提供商，限制请求边界，验证回答，提供商报告的概率和分数在结构和范围验证之后保持原样！
消费者自己决定拿到答案之后怎么做，运行时不做决策策略！
这就怪了，为什么OpenClaw不直接替开发者决定什么时候该用决策模型？
因为维护者不知道所有有用的场景！
从Discord群聊到工具过滤的真实场景
理论讲完了来看一个让所有AI智能体开发者都头疼的真实场景，Peter的OpenClaw智能体Molty住在一个团队Discord频道里，Molty有一个非常烦人的习惯，就是别人在群里聊天根本没叫它，它也要跳出来插嘴，团队成员不得不反复告诉Molty闭嘴，然后过一会儿同样的事情又发生了。
传统的解决办法是在Molty回复之前再加一次模型调用，让另一个模型判断Molty该不该说话，但这就回到了Josh Lehman踩过的坑，在一个已经很慢的模型调用前面再加一个模型调用，频道里每刷一条消息就要多等一轮判断，整个体验变得更差，而一个足够快的决策模型可以在极短时间内给出说或不说的结论，Molty终于能学会在适当的时候闭嘴了！
除了Discord群聊，社区开发者还在探索更多场景：用决策模型过滤工具定义让主模型不用花时间筛选无关工具；用决策模型在上下文压缩时快速判断哪些消息值得保留；用决策模型根据任务类型自动选择最合适的聊天模型；用决策模型更频繁地审查和整合AI智能体学到的新技能。
不替你做决定，只给你做决定的能力
开放决策模型API这件事，本质上跟OpenClaw一直以来的做法一致！
OpenClaw早就让用户自己选对话模型了，它不绑定任何一家提供商，你想用OpenAI就用OpenAI，想用Anthropic就用Anthropic，想用本地模型也行！
决策模型走的是同一条路！
在配置里选一个决策模型，它就对支持的插件和功能生效；不选的话，OpenClaw继续照常工作，什么都不变！
决策模型是选择性启用的，不是新要求！
Josh Lehman原话是这么说的：“如果你不启用它，那也没关系，它就跟以前一样照常工作。”
这句话看起来很平淡，但它背后的设计哲学很有意思——能力开放给开发者，但不用逼着所有人马上用！
这就像给了一把你可能永远用不上的钥匙，但钥匙就挂在那里，你什么时候需要了，拿起来就能用！
然而，社区的热情显然超出了预期！
决策模型不会让Agent变聪明，但会让它变快
一个必须承认的事实是：决策模型不会让Agent的判断变得更准！
Jev在Bryo AI的独立测试中，准确率略低于Gemini，但成本低了十到二十倍！
这是一个典型的工程取舍：用一点点准确率的下降，换取巨大的速度和成本优势！
Josh Lehman说得很坦诚：目标是更好的结果、更少的等待、更低的成本、更少的重试，但需要在真实工作流中测试，不能假设每个决策都会因为引入了一个新模型就变好！
这句话值得所有开发者记住——不要因为有一个新工具就到处用它，要看它在具体场景里是不是真的有用！
决策模型的类型化输出确实解决了一个Agent工程里的经典麻烦：工具选择错误！
你想想，当一个Agent要选择调用哪个工具的时候，它其实是在做一道选择题，但传统的大语言模型是在"写答案"——它可能写出一个根本不存在的工具名，可能返回格式完全不对的内容，下游代码根本解析不了！
Jev不会出现这种情况，因为它根本不生成文字，它只从你给它的选项里返回一个，带着概率！
这是"不会产生幻觉"的真实含义——不是"永远选对"，而是"永远不会返回选项之外的东西"！
Jev API支持三种问题类型：Choice是从一组选项里选一个，Score是在有顺序的量表上评分，Boolean是判断某个叙述是否成立，返回零到一的"是"概率！
一次API调用可以放多个彼此独立的问题，Jev用相同的状态并行评估，程序再根据结果决定是直接执行、要求人工确认，还是把案例交给更强的推理模型！
这种架构在业界被称为"快慢分工"——昂贵的大语言模型负责规划和推理这类"慢思考"，高频、原子化的小判断交给轻量决策模型完成"快判断"，负责组装和调度这套分工的工程层就是Harness！
但是，决策模型有它明确的边界！
TypeSafe的文档里写得很清楚：Jev对数字、日期、间接指令、矛盾条件以及对抗性内容不太可靠；状态里塞太多无关信息也会降低准确率！
需要产生文章、代码或自然语言解释的任务，不该硬塞给决策模型；多步骤规划、精确计算、答案无法事先列举的任务，也不适合！
OpenClaw的本地ONNX插件也是一个思路——把分类器跑在本地CPU上，不把状态和问题发给远程服务，模型只在你明确运行下载命令的时候才下载！
这个插件支持七种预置模型，包括DeBERTa和GLiClass系列，跟TypeSafe走的是同一条决策提供商契约！
来自OpenClaw官方文档的信息显示，ONNX插件使用一个独立的持久Node进程来跑推理，宿主保留模型选择、准入、截止时间和生命周期控制权。大模型在慢速机器上冷启动时可能超过五秒的截止时间，建议用maxLoadedModels保持活跃模型的热度，或者选择更小的模型！
这些工程细节说明一件事：决策模型不是什么魔法，它就是一个被精心设计过的工具，用对地方就有效，用错地方就是浪费！
🔥 热词：#OpenClaw关键升级 · #Jev决策模型通过共享API接入插件体系 · #AI端侧应用、氛围编程 · #OpenClaw · #Jev分类模型 · #AI智能体Agent