1. 从“慢思考”到“快决策”Jev 到底想解决什么问题第一次看到“System One 决策模型 Jev”这个说法我脑子里蹦出来的不是论文而是两年前做客服 Agent 时被延迟折磨的那段经历。当时我们跑一个多轮工具调用的 Agent用户问一句“帮我查下上周的订单为什么还没发货”后台要经历意图识别、槽位填充、工具选择、参数校验、结果整合、话术生成六个环节每个环节都是一次完整的 LLM 推理。一轮下来平均 8 到 12 秒用户早就把 App 关了。后来我们试过缓存、试过小模型兜底、试过并行调用效果都有限因为瓶颈不在工程层而在决策层本身太重了。Jev 这个模型之所以值得单独拿出来聊是因为它切中的正是这个痛点Agent 的“决策”不应该每次都走一遍完整的、昂贵的、慢速的推理链路。它借鉴了认知心理学里“系统一 / 系统二”的划分——系统一是快速、直觉、低耗的系统二是缓慢、审慎、高耗的。传统 Agent 架构几乎把所有决策都压在“系统二”上而 Jev 想做的是把大量高频、模式化、可预测的决策下沉到“系统一”只在真正需要深思的时候才唤起大模型。所以这篇文章不是复述某个发布会的通稿而是想从一个一线做 Agent 的人的视角把 Jev 这类“System One 决策模型”的底层逻辑拆开它为什么能提速提速的代价是什么什么场景适合用什么场景千万别用以及如果你现在手上就有一个 Agent 项目怎么把这套思路落地。适合正在做 Agent 开发、被延迟和成本卡住、想优化推理链路的同学参考也适合刚接触 Agent 架构、想搞明白“决策模型”和“大模型”到底啥关系的朋友。2. 拆解 Jev 的核心设计为什么它能快 200 倍2.1 传统 Agent 的决策链路到底慢在哪要理解 Jev 快在哪得先把传统 Agent 慢在哪说清楚。一个典型的 ReAct 风格 Agent每走一步都要做一次完整的 LLM 调用把系统提示、历史对话、工具描述、当前观察全部塞进上下文让模型输出“思考 动作”。这个过程的耗时由三块构成上下文长度决定的 prefill 时间、输出 token 数决定的 decode 时间、以及工具调用的往返时间。我实测过一个中等复杂度的 Agent系统提示加工具描述大概 3000 token历史对话 2000 token每次决策输出 200 token 左右。在主流模型上单次决策的纯推理时间在 1.5 到 3 秒之间如果碰上工具调用失败要重试一轮任务下来十几次决策几十秒就没了。更麻烦的是这些决策里有大量是重复的、模式化的——比如“用户给了订单号下一步应该调查询接口”“工具返回了错误码下一步应该重试或换工具”这些判断根本不需要动用千亿参数的模型。Jev 的核心洞察就在这里把决策分成两类一类是可以用轻量模型甚至规则引擎搞定的“快决策”一类是必须用大模型才能处理的“慢决策”。快决策走 System One 通道慢决策才走 System Two 通道。这个划分听起来简单但真正难的是怎么判断一个决策该走哪条通道以及快通道的准确率怎么保证。2.2 System One 通道的三种实现路径从我目前了解到的信息和实际工程经验来看System One 通道的实现大致有三条路径Jev 应该是把这三条做了融合。第一条是蒸馏小模型。用一个专门训练的小模型参数量可能在 1B 到 7B 之间来学习大模型在特定决策场景下的输出分布。比如“给定当前状态和可用工具下一步该调哪个工具”这个映射关系其实相当固定小模型完全能学会。蒸馏的好处是推理快、成本低坏处是泛化能力弱遇到训练分布外的状态容易翻车。第二条是检索式决策。把历史决策轨迹做成向量库新状态来了先检索最相似的 K 个历史决策如果相似度足够高直接复用如果不够高才交给大模型。这条路子的关键是状态表示的设计——你得把 Agent 的当前状态对话历史、工具返回、任务进度编码成一个可比较的向量这个编码质量直接决定检索的准确率。第三条是规则 分类器。对于高度结构化的决策比如“工具返回 200 且结果非空则进入结果整合”“工具返回 5xx则重试”直接用规则搞定。对于半结构化的用一个轻量分类器比如 BERT 级别的模型做意图判断。这条路子最快但维护成本高规则会越堆越多。Jev 的聪明之处在于它没有死磕某一条路径而是用一个路由层动态决定当前决策走哪条通道。路由层本身很轻可能就是一个小的分类模型或者一套打分机制判断“这个决策的置信度够不够高够高就走快通道不够高就走慢通道”。这个设计让系统在速度和准确率之间有了一个可调的旋钮。2.3 200 倍提速的数字是怎么来的“提速 200 倍”这个说法我一开始是存疑的因为这种数字往往是拿最优情况对比最差情况。但拆开算一下其实是有道理的。假设传统 Agent 单次决策耗时 2 秒prefill 1.2 秒 decode 0.8 秒而 System One 通道的单次决策耗时 10 毫秒小模型推理 8 毫秒 路由判断 2 毫秒那么单次决策的提速就是 200 倍。这个对比的前提是快通道能覆盖大部分决策。如果快通道只能覆盖 50% 的决策那整体提速就是 2 倍左右如果能覆盖 90%整体提速能到 10 倍以上。所以关键不是“单次快 200 倍”而是快通道的命中率。Jev 的工程价值在于它通过路由层和持续学习机制把命中率做到了一个比较高的水平。我猜测它的做法是每次走慢通道的决策结果都会被记录下来用于更新快通道的模型或检索库这样快通道的覆盖范围会随着使用不断扩张。这是一个越用越快的系统而不是一个静态的加速方案。注意200 倍这个数字一定是特定条件下的测量结果不要直接拿来做容量规划。实际落地时你要先测自己场景下的快通道命中率再算整体收益。3. 落地实操怎么把 System One 思路用在自己的 Agent 上3.1 第一步把决策点显式化很多 Agent 项目的问题在于决策是隐式的——模型在生成文本的过程中“顺便”做了决策你根本不知道它在哪一步做了什么判断。要引入 System One第一步就是把决策点从生成流程里抽出来变成显式的、可枚举的步骤。具体做法是重新设计 Agent 的状态机。不要用“模型自由发挥”的 ReAct 循环而是定义一个明确的状态转移图当前处于哪个阶段意图识别、工具选择、参数填充、结果整合、话术生成每个阶段有哪些可能的动作动作之间的转移条件是什么。这个状态机不需要很复杂五到八个状态通常就够了。我自己的经验是状态机设计得越清晰后面做快通道优化就越容易。因为每个状态下的决策空间是有限的有限空间才适合用小模型或规则来处理。如果状态是无限开放的那快通道根本无从下手。3.2 第二步给每个决策点做“快慢分流”状态机建好之后逐个决策点分析这个决策的输入空间有多大输出空间有多大历史数据里有没有足够的样本。输入输出空间小、样本多的优先做快通道输入输出空间大、样本少的先留在慢通道。举个具体的例子。在“工具选择”这个决策点如果可用工具只有五六个输入是用户意图和当前槽位那这个决策完全可以用一个小分类模型搞定。但在“话术生成”这个决策点输入是完整的对话历史和工具返回结果输出是自然语言这个就必须走大模型。分流的时候有个技巧先做保守分流再逐步放开。一开始只把最确定的那几个决策点放进快通道跑一段时间对比快慢通道的输出一致性一致率超过阈值我一般设 98%再扩大范围。这样能避免一上来就翻车。3.3 第三步搭建快通道的三种实现快通道的实现要按决策点的特点来选。我整理了一个选型对照表是我自己在项目里用过的判断标准决策点特征推荐实现推理耗时量级维护成本输入输出高度结构化规则明确规则引擎微秒级低但规则会膨胀输入半结构化输出是有限类别轻量分类模型毫秒级中需要标注数据输入复杂但有大量历史轨迹检索式决策毫秒级中需要维护向量库输入输出都是自然语言蒸馏小模型十毫秒级高需要训练和迭代规则引擎适合处理“工具返回码判断”“参数格式校验”这类确定性极强的决策。轻量分类模型适合“意图归类”“工具选择”这类有限分类问题。检索式决策适合“相似状态复用”场景比如客服 Agent 里大量重复的问题模式。蒸馏小模型适合“话术生成”这类需要一定语言能力但场景固定的决策。实际项目里这四种往往是混用的。我的建议是先从规则引擎和检索式决策入手因为这两者不需要训练上线快能快速验证快通道的收益。等跑通了再考虑引入模型。3.4 第四步设计路由层和兜底机制路由层是整个 System One 架构的“大脑”它决定每个决策走哪条通道。路由层的设计要点有三个置信度评估、阈值设定、兜底策略。置信度评估可以用多种信号快通道模型输出的概率值、检索时的相似度分数、规则匹配的严格程度。把这些信号归一化之后得到一个 0 到 1 的置信度分数。阈值设定要保守我一般把快通道的阈值设在 0.9 以上低于这个值一律走慢通道。兜底策略是必须的。快通道再准也有出错的时候所以要有机制检测快通道的输出是否合理。最简单的做法是对快通道的输出做一次轻量校验比如检查工具名是否在可用列表里、参数是否符合 schema。校验不通过就回退到慢通道。这个校验的成本很低但能挡掉大部分低级错误。提示路由层的阈值不要一次定死要留一个配置接口方便根据线上表现动态调整。我吃过这个亏阈值定太高导致快通道命中率只有 30%提速效果几乎为零。4. 常见问题与排查技巧实录4.1 快通道准确率上不去怎么办这是落地时最常见的问题。快通道准确率低通常有三个原因训练数据分布不对、状态表示设计不合理、决策点划分太粗。训练数据分布不对指的是你用来训练快通道模型的数据和线上实际遇到的状态分布不一致。比如你用的是历史客服对话训练但线上来了很多新业务的问题模型没见过。解决办法是持续收集线上数据定期重新训练或更新检索库。状态表示设计不合理指的是你把 Agent 状态编码成向量时丢失了关键信息。比如工具返回的错误码、用户的情绪倾向这些如果没编码进去检索就会失准。解决办法是做特征重要性分析看看哪些字段对决策结果影响最大确保它们被编码进去。决策点划分太粗指的是一个决策点里混了多种不同类型的判断。比如“下一步动作”这个决策点既包含工具选择又包含参数填充这两者的决策逻辑完全不同混在一起快通道学不好。解决办法是把决策点拆细一个决策点只做一件事。4.2 快慢通道输出不一致怎么处理不一致是必然的关键是怎么处理。我的做法是记录所有不一致的 case定期分析。分析的时候分三类快通道对慢通道错、快通道错慢通道对、两个都错。快通道对慢通道错的情况说明慢通道在这个场景下反而不如快通道可以考虑把这类状态也纳入快通道。快通道错慢通道对的情况说明快通道的覆盖范围扩得太快了要收缩。两个都错的情况说明这个决策点本身设计有问题要重新审视。这个分析过程要自动化不然人工看不过来。我一般会写一个脚本每天跑一次把不一致的 case 按状态聚类输出 top 10 的高频问题。4.3 快通道的维护成本会不会失控会如果不加控制的话。规则会越堆越多检索库会越来越大小模型会越训越频繁。控制维护成本的关键是设定明确的淘汰机制。规则方面定期统计每条规则的命中次数命中率低于阈值的规则直接删掉。检索库方面设定一个容量上限超过之后按时间或使用频率淘汰旧数据。小模型方面不要频繁重训设定一个固定的重训周期比如两周一次中间只做数据收集。还有一个技巧是把快通道的配置化。规则、阈值、检索参数都做成配置文件改配置不用改代码这样维护成本会低很多。4.4 什么场景不适合用 System One不是所有 Agent 都适合这套架构。任务高度多样化、决策空间开放、样本量少的场景不适合。比如一个通用的研究助手 Agent用户什么问题都可能问决策路径几乎不重复那快通道根本学不到东西强行上只会增加复杂度。判断标准很简单如果你的 Agent 在跑了一千次任务之后决策轨迹的重复率低于 30%那 System One 的收益就很有限。这种情况下优化重点应该放在减少不必要的决策次数上而不是加速单次决策。5. 我对 Jev 这类架构的真实看法说实话System One 这个思路本身不新鲜缓存、蒸馏、规则引擎都是老技术。Jev 的价值在于把这套思路系统化了并且给出了一个可落地的路由框架。它把“什么时候该快、什么时候该慢”这个问题从一个工程直觉变成了一个可度量、可优化的机制。但我还是要泼一盆冷水200 倍提速是特定条件下的数字不要被它带偏。真正决定 Agent 体验的往往不是单次决策的速度而是整个任务链路的顺畅度。我见过太多项目单次决策优化到极致但任务成功率上不去用户照样不满意。System One 能帮你省时间和成本但它解决不了决策质量问题。如果你现在手上有一个 Agent 项目我的建议是先把状态机理清楚再把高频决策点找出来用最简单的规则或检索先跑一版快通道测出实际命中率和准确率再决定要不要投入更多资源。不要一上来就搞小模型蒸馏那个投入产出比在早期往往不划算。最后分享一个我在实际项目里总结的小技巧快通道的日志一定要和慢通道分开打并且给每条日志打上“通道来源”的标签。这样后面做分析和调优的时候你能一眼看出问题出在哪个通道排查效率会高很多。这个细节看起来不起眼但真到了线上出问题的时候能帮你省下大量时间。