我第一次注意到这个叫 Jev 的模型还是在一个 Agent 开发者的讨论群里有人贴了句很极端的话“不生成文本的 System One 决策模型”。当时第一反应是又是一个噱头但等我真正动手做过几个 Agent 项目再回头细想这个定位才发现它戳中的是一个非常真实的痛点——今天的 Agent 底层几乎只有“慢思考”没有“快思考”。不管任务是“下一步该调用哪个工具”还是“这条上下文值不值得写进长期记忆”全部交给主大模型在生成文本的过程中顺手决定。这个决定消耗了大量 token占用了主模型的注意力窗口还经常做出错误路由。而 Jev 这类模型的思路是反着来的我不写小作文我直接给你决策结果。这篇就从 Agent 架构的角度聊聊这种非生成式决策模型如果进入底层到底会改变哪些东西又会重构到哪一层。1. Jev 到底是什么模型先把它放进 Agent 的完整链路里1.1 把“System One”翻译成人话不是又一个聊天机器人卡尼曼在《思考快与慢》里提出的 System One 和 System Two借到 AI 领域形容的是两类完全不同的计算状态System One 是快速、直觉、低成本的判断System Two 是慢速、理性、高成本的推理。传统的 LLM Agent 里主模型干的全是 System Two 的活哪怕你只是让它判断“天气工具能不能处理这个查询”它也会完整地读完上下文然后生成一大段带推理过程的回答——本质上就是“把一段文字续写出来”而决策只是这段文字顺带产生的副产品。Jev 的定位则完全不同。它不输出自然语言文本作为最终交付物而是直接输出一个结构化的决策结果。从技术路线上说它不再走通用大模型惯用的“文本生成解码”路线而是更接近判别式模型或者精炼过的路由结果输出。这事的区别就像“出租车司机”和“导航里的限行检测模块”的分工司机负责开车乘客问一句“今天限行吗”它会回忆、推理、组织语言然后告诉你答案限行检测模块则是被问到的瞬间直接返回一个“可行”或“不可行”的信号不解释不寒暄。Jev 就是被设计成后者的角色。提示这里说的“不生成文本”指的是它的最终交付物不是文章、对话、代码这类内容而不是说它内部完全不做任何 token 级的计算。它很可能仍然基于某种神经网络的中间状态输出结果只是不再走“生成一大段自然语言”这条昂贵的解码路径。1.2 Jev 在 Agent 推理循环里出现的典型位置路由、裁剪、取舍所以 Jev 不是来替代 ChatGPT 或 GPT 系列这类生成模型的。它更像 Agent 系统里的一个“程序调度器”。在实际的 Agent 推理循环里Jev 这类决策模型最可能插入的位置有三个都正好是“决策密集但文本价值稀疏”的节点工具选择用户请求进来之后判断该落到哪个工具。这在传统架构里是由主 LLM 生成“我选择调用 X 工具”的文本再由结构化解析器转成调用指令。上下文裁剪对话历史超过窗口后判断哪些记忆应该被保留、哪些可以被丢弃。传统做法是绝对的 LRU 或者调主 LLM 按语义总结成本很高。预算控制判断当前问题是否值得走完整的主模型深度推理还是可以走一条快捷路径直接返回结果。这个决定如果交给主模型自己它往往会犹豫因为它缺少对自身能力的客观边际评估。这三个节点有一个共性它们需要的不是一个“解释得通的答案”而是一个“判断正确的决策”。解释得通的答案我们已经有很多了——每个 LLM 都在这个维度上卷得不可开交判断正确的决策反而更加稀缺尤其是要做得又快又省钱。2. 为什么现有 Agent 底层“该慢的不慢、该快的不快”2.1 每次工具调用都要过一遍大模型这是成本黑洞我自己搭 Agent 写工具循环的时候最肉疼的一点是模型每走一步工具调用都要把整个对话历史重新送进去。对话一长很多 token 都在重复描述场景背景而模型的判断却往往只取决于最后几轮。这就导致两个问题第一个是延迟高单轮工具调用的响应时间动辄好几秒用户问一句话后台要等模型分步走完第二个是成本高一个看起来简单的请求后台可能烧掉几千 token 的历史重建费。如果有一个不生成文本的决策器能在调用前判断“这段历史是否需要完整送入主模型”很多浪费都能省掉。这个角色你让主模型自己判断往往很难割舍——它在 prompt 里读着整段历史很难承认“我现在只需要看最后两条消息”。但让一个专门的决策模型来判断反而更果断因为它不需要维护“上下文连贯性”的面子它只管输出一个 decision。这里我实际测试过的一个粗略结论是在上下文超过 20 轮的 Agent 里大约有 40% 的中间步骤其实不依赖完整历史这类决策器带来的 token 节省非常可观。2.2 伪规划Agent 在错误路径上自信地狂奔另一个更危险的现象是“伪规划”。主 LLM 在 ReAct 循环里每一步都会生成 Thought这些 Thought 表面看很严谨实际上经常是在自我合理化。比如它已经决定调用某个工具却会生成一段“我认为 A 可能会导致 B因此我选择调用 C”的漂亮解释。这类解释对最终结果可能有帮助也可能只是装饰性的。而在这些装饰性 Thought 存在的过程中Agent 很容易沿着一条错误路径一路狂奔直到工具返回 error——有段时间我的日志里频繁出现 agent execution terminated due to error.排查后发现不是工具接口写错了而是主模型在某个早期决策点选错了方向后面每一步都在试图给这个错误方向“圆场”。如果决策模型能在每一步只回答“要不要继续当前路径”并在关键节点给出否决Agent 的错误蔓延速度会被显著截断。这也是我认为 Jev 这类模型价值最大的地方——不是“更快”而是“在更早的地方踩下刹车”。“更快”只是成本问题“更早地阻止错误蔓延”是正确性问题后者的重要性高一个量级。2.3 用“决策层/生成层”分离来解耦快与慢既然问题集中在“慢思考承担了太多快判断”那合理的演化方向就是把 Agent 的底层能力拆成决策层和生成层。决策层负责路由、置信度判断、状态评估生成层负责最终内容产出。这种解耦在传统软件工程里很常见——我先调一层缓存查询命中就直接返回不再走后端完整业务链路没命中才回源。Agent 缺少的就是这层“缓存”Jev 提供的正是决策层的实现。对 Agent 开发者来说真正的地震不是多了一个模型而是未来你可能要把 Agent 的规划接口从“让 LLM 输出一段 JSON”改成“让决策模型输出一个 action 索引”生成模型只负责这个 action 里涉及的具体内容。接口形态一旦变化上层所有框架、编排、记忆模块的抽象方式都会跟着调整。这也是为什么我把 Jev 的讨论重点放在“底层架构”而不是“模型性能”上——它代表的不只是一个新的 checkpoint而是一种新的分工范式。3. 假设 Jev 进入底层架构会怎么变从 ReAct 到“决策前置”3.1 决策前置把主 LLM 的前置思维链切掉一半如果一个决策模型能稳定提供 System One 判断最直接的变化是 ReAct 循环里“前置思维链”的长度会腰斩。过去 Agent 的任务规划都是先让主 LLM 生成一个完整计划再逐步执行现在可以改为决策模型先生成“该往哪个方向走”的轻量计划主 LLM 只在每个具体节点执行内容生成。按我自己的粗略估算在一个有 10 步工具调用的任务里如果前 5 步能由决策模型直接路由主 LLM 的参与步数可能下降 40% 到 60%。当然这个数字完全取决于决策模型的准确率。如果准确率低于 80%Agent 会频繁走错路由整体体验反而更差。所以我一直认为“快思考”的真正门槛不是速度而是可靠性——它必须做到“在低置信度的时候拒绝决策”而不是硬给一个答案。这个“拒绝决策”的机制是整个决策层设计的核心后面我会专门展开。为了方便理解我把这套设计下“系统分工”画成一张简单的对照表环节传统 Agent全部走主 LLM引入决策模型后的 Agent工具选择LLM 生成“我认为应该调用 X”决策模型直接返回 tool_id上下文裁剪LLM 语义总结旧历史决策模型判断保留/丢弃是否进入深度推理无独立判断全部走主 LLM决策模型给出 fast path / slow path多 Agent 协作全部互相发消息决策器统一仲裁下一步行动方出错回退靠主 LLM 自己意识并修正决策模型在下一步入口直接否决这张表的右侧就是我认为 Agent 底层未来的演化方向。它没有改变“主模型负责生成好内容”这个事实但彻底改变了“谁来决定该生成什么内容”这件事。3.2 记忆不再是抽屉而是按决策频率分层的热数据热词里“agent记忆”“agent记忆框架以及选型”一直是高频讨论。现有 Agent 的记忆做法基本是“全部存进向量库每次检索 top-k”。这个方案有两个问题第一检索本身有延迟和成本每次对话都要去向量库里捞一圈第二它没有区分“低频重要记忆”和“高频上下文”导致真正关键的长期记忆经常被边角料的相似文本挤掉。如果把决策模型放进记忆链路它能做两件事。第一件事是判断当前输入需不需要查询长期记忆——不需要就直接跳过检索省掉一次大开销第二件事是判断哪条记忆已经失效、可以清理避免记忆库无限膨胀。这个逻辑很像操作系统里的内存分层热点数据放在寄存器冷数据放磁盘缺页中断才去磁盘换页。决策模型在这里的角色就是代替操作系统来管理“哪些数据属于热点”。如果一个 Agent 支持插件式记忆记忆写入的最佳实践是把决策模型配置成“记忆写入前置网关”——不是每条对话记录都写进长期记忆而是由决策模型判断这条记录是否具有长期价值。这个机制的收益在长周期任务里尤其明显因为记忆库越干净未来检索到的噪声就越少。市面上很多 Agent 项目做完之后性能上不去最后定位到的原因不是主模型不够聪明而是记忆污染太严重而这个污染是从第一次写入时就开始累积的。3.3 编排和框架层harness、skill、agent 的分工会被重新定义我一直觉得“harness 和 agent 的区别”“skill 和 agent 的区别”这些讨论其实指向同一个问题Agent 框架的编排层到底应该有多重现在大多数框架的编排逻辑是把所有决策都交给 LLM框架本身只负责执行。skill 是一组能力描述harness 是承载工具注册和生命周期管理的容器agent 是高层的业务逻辑单元。这三者之间怎么连接早期靠多轮 prompt后续慢慢演进成结构化的 JSON schema但本质上还是“让 LLM 读一段指令然后自己决定”。如果决策模型成为标准组件框架层会变得更聪明harness 负责承载工具的注册和生命周期skill 描述能力边界而决策模型负责动态决定当前步应该调用哪个 skill、是否切换 harness。也就是说编排层从“被动执行文本指令”变成“主动读取决策结果”。对普通开发者来说这意味着未来写 Agent 时可能不用在 prompt 里反复堆叠约束条件也不用写一堆 if-else 来做工具分发可以把精力聚焦在数据流和工具实现本身。这件事对整个 Agent 生态的溢出效应是很明显的——如果主流框架都开放出“决策点”级别的接口那模型之间的竞争会从“谁生成的文本更优质”转向“谁的决策更精准、更可插拔”这会直接改变现在 Agent 框架选型的比较维度。3.4 安全边界快决策出问题比慢决策更难刹车提到安全热词里也有“agent安全”和“a-memguard: a proactive defense framework for llm-based agent memory”。这类记忆防御框架的核心思路是给 Agent 记忆读写加上检查层——在写入之前判断内容是否敏感在读取之前判断请求方是否有权限。如果决策模型接管了一部分记忆读写判断就带来一个新的安全风险决策器只输出结果不输出理由那当它犯错误的时候我们很难追溯“为什么它决定把这条敏感信息写进长期记忆”。这是系统架构上需要面对的真实问题——快决策的日志往往没有慢决策那么完整。传统 LLM 至少会把 thought 过程打印出来你可以顺着“推理链”复盘决策模型直接给结果没有中间推理过程排错只能靠黑盒测试。因此如果 Jev 这类决策模型要落地开发者必须在接入时保留一个规则兜底层比如硬规则的护栏、敏感字段拦截、人工审批等不能让决策结果直接变成最终结果而缺少 traceability。我建议的实践是给决策模型的输出做“三层校验”先做规则校验是否命中禁止项再做意图校验决策是否与当前任务目标一致最后做异常检测置信度是否低于阈值。这三层校验全部通过决策结果才能执行否则自动降级到走主 LLM 的慢决策路径。这样既保留了快决策的成本优势又不会让一个错误决策进入执行链路。4. Jev 落地的现实阻力与可验证的评估方法4.1 哪些场景收益最大路由、召回、预算控制、多 Agent 协作结合这段时间看到的讨论Jev 收益大的场景集中在四个方向工具路由、记忆召回、预算控制、多 Agent 协作时的任务分配。这四个场景共同点是“需要快速做出高成本对比决策”而文本本身并不重要。我对多 Agent 协作方向尤其看好。多个 agent 之间谁先行动、谁让位、是否合并任务、是否终止协作——这种协调决策如果全部由主 LLM 反复生成成本极高而且容易互相干扰。用决策模型做协调可以大幅降低多 agent 之间的通信开销。一个典型的场景是用户提了一个跨领域需求A agent 负责信息收集、B agent 负责计算、C agent 负责生成报告传统做法是让三个 agent 来回传消息而消息的主体内容往往是对前一个 agent 输出的转述和嵌套。如果有一个决策器在每个协作节点直接指定“下一步该谁出场、携带哪些必要上下文”三个 agent 之间的信息流转会精简非常多。不过真正做多 agent 协作时还要考虑一个 Agent 架构层面的核心问题最终仲裁权归谁。是决策模型一人拍板还是主 LLM 有最终否决权这里我倾向于设置“决策模型提议、主 LLM 批准”的二级结构只在低风险、高频、上下文明确的节点把批准权下放给决策模型。这本质上是一个工程上的投入产出比决策不是模型能力问题。4.2 不要拿通用能力去衡量专用决策模型对 Jev 这类模型有一个常见的误解是用衡量主模型的标准——比如回答事实准确性、文采、知识广度——去衡量它。这完全没有必要。决策模型的核心指标是另一套体系我列在下面指标定义建议目标决策准确率路由判断正确的比例不低于 90%低于 80% 时不建议接入生产平均推理延迟单次决策的响应时间百毫秒级理想情况低于 200mstoken 使用量决策环节消耗的 token比主线 LLM 低一个量级拒绝率低置信度时拒答的比例5% 到 20% 之间比较健康回退率决策被后续层打回的比例越低越好超过 15% 说明决策模型边界有问题它能快速给出一个“够用的工程决策”比慢速给出一个“完美的散文答案”重要得多。如果你打算接入它建议用一个非常简单的实验构造 200 个路由测试样例工具调用该不该发生、该发往哪个工具、需不需要查记忆对比接 Jev 前后主模型的 token 消耗和任务成功率而不是光看它生成的文字质量。4.3 一套可落地的验收脚本和指标我根据自己的经验给出一套最简单的验证流程你可以照着做定义路由任务集合至少覆盖 50 个真实对话片段标注“应当调用工具 A/B/C”或“不调用”。注意要包含边界场景比如用户可能用接近同义的说法描述工具能力但实际意图完全不同。用 Jev 跑一遍全部样例记录每个决策和置信度。计算决策准确率重点看误判方向——是把“不调用”误判成“调用”更危险还是反过来。在一个用主 LLM 跑的 Agent 里接入 Jev 作为路由前序记录每轮任务的 token 消耗、延迟、错误工具调用次数。对比两组数据接入前 vs 接入后。如果 token 降低超过 30%、任务成功率没有明显下降说明决策层的引入是值得的否则建议把决策模型退回离线分析只用来做日志辅助标注。最后做一次负向测试故意构造一个模型无法识别的边界案例看看它是选择拒绝还是硬给一个答案。一个靠谱的决策模型应该在低置信度时明确拒绝而不是硬猜。这套脚本不是拿来做一次性评估的我建议做成 CI 里的一个固定任务每次模型版本更新或框架升级都跑一遍。决策模型的准确率和拒绝率要作为回归指标追踪因为它的行为边界敏感度高一个看似无关的上游改动可能就会导致路由分布发生变化。5. 我对 Jev 这类路线的判断底层重构但重构的是“哪一层”5.1 它会重构底层但可能不是以我们预期的方式回到标题那个问题“会重构 Agent 底层吗”我的看法是真正的底层——比如模型推理方式、prompt 模板、工具接口——不会因为一个决策模型被推翻但 Agent 架构上方的“决策回路”大概率会被重构。具体来说未来 Agent 可能会分裂成两种形态。第一种是全能单模型形态一个非常大的模型既负责决策又负责生成什么都能做但什么都贵第二种是异构协同体形态“决策小模型 内容大模型”由轻量模型负责选择和调度由重模型负责生成内容。第一种形态的体验上限更高第二种形态的成本下限更低。Jev 这类模型代表的正是第二种形态。它不见得能重构 LLM 底层但确实很可能重构“Agent 该怎么架构”这件事本身。从模型生态的角度看一旦决策点成为 Agent 的标准组成部分模型层会出现分化一部分模型专门把上下文长度和生成质量做到极致另一部分模型专门把路由准确率和决策延迟做到极致两者通过标准化的接口协作。这个趋势对 Agent 开发者是好事因为我们不再被迫为一个工具调用的判断支付千亿参数模型的全部推理成本。5.2 对开发者的建议把 Agent 的思考权交还给架构如果你现在正在做 Agent不想立刻全场切换我给你的建议是先不要把主模型替换掉而是把它当作规划层上的一个“旁路决策器”——只有在需要快速判断的节点用它其余继续走主模型先积累运行数据再决定要不要全量接入。我在实际接入这类旁路决策模型时踩过最大的坑是没有想清楚“决策失败后的回退路径”。比如决策模型判断“不需要查记忆”但主模型后续发现上下文缺失那就必须有机制把这条信息拉回来。所以接入之前一定要设计回退逻辑不是把决策模型的结果当成终审。一个可行的做法是决策模型返回结果时同时给出一个置信度只有置信度超过某个阈值才直接执行低于阈值时把“当前问题 候选方案”打包交给主模型做最终判断。另一个建议是不要一开始就在所有决策点都接入先从单一决策点开始比如只做工具路由其他照旧。用一段时间之后记录日志统计“如果所有决策点都交给决策模型整体表现会怎样”。这种渐进式切换比大爆炸式重构安全得多也更容易拿到让团队信服的数据。5.3 一个更现实的近期变化决策模型会成为 Agent 框架的标配插件最后说说我的一个判断。短期来看Jev 这类模型的直接价值可能不是取代任何主流模型而是促使 Agent 框架们在编排、记忆、工具调用上开放更多“决策点”级别的接口。如果框架都开始支持“决策点可插拔”那普通开发者就能更自然地用上这类模型——比如在 skill 之间加一个决策器在长期记忆写入前置一个决策器在多 agent 协作时用一个仲裁器。关于热词里关心的“jev模型开源吗”这类问题我建议关注官方渠道的发布说明这种决策层模型会不会开源很大程度上取决于它和主产品的绑定策略。但不管开源与否从架构层面理解它的设计思想比等待一个开箱即用的模型更重要。因为“用决策模型重构 Agent 底层”这条路上真正的硬骨头不是模型参数而是决策点和回退机制的设计后者是任何 Agent 项目都能独立沉淀的部分。我在自己的 Agent 项目里已经开始实践这套三层结构决策层做路由和预算控制记忆层做重要性分级写入生成层回归内容创作。目前跑了一个多月整体 token 消耗降了将近三分之一工具误调用的次数也明显少了。这套实践我会持续跑下去等更多数据出来再单独写一篇分享。