1. 从“慢思考”到“快直觉”Jev 到底想解决什么问题第一次看到“System One 决策模型 Jev”这个说法的时候我正被一个 Agent 项目的响应延迟折磨得够呛。一个简单的“帮我查一下明天北京天气并推荐穿什么”的请求Agent 在后台跑了整整 14 秒——先规划、再调工具、再反思、再修正、再输出。每一步都要经过一次完整的大模型推理token 哗哗地烧用户那边进度条转得人心慌。所以当我看到“提速 200 倍”这个数字时第一反应不是兴奋而是怀疑这又是哪个营销号在吹牛但把 Jev 的设计思路捋了一遍之后我意识到它戳中的恰恰是当前 Agent 架构最要命的软肋。现在市面上绝大多数 Agent 框架不管是 ReAct、Plan-and-Execute 还是各种花哨的变体本质上都在做同一件事把每一次决策都当成一道需要深思熟虑的难题。用户说一句话模型要先想“我该干什么”再想“我用什么工具”再想“这个结果对不对”再想“要不要再来一轮”。这套流程在复杂任务上确实管用但问题是——生活中 90% 的请求根本不需要这么重的思考。Jev 的核心主张就是把这 90% 的“轻决策”从慢速的推理链路里剥离出来交给一个专门训练的、极轻量的“直觉模型”去处理。这个直觉模型不生成自然语言不做链式思考它只做一件事在极短时间内判断当前该走哪条路。这就像你开车时看到红灯踩刹车你不会在脑子里默念“前方检测到红色信号灯根据交通法规第 X 条应当减速停车”——你就是踩了。Jev 想给 Agent 装上的就是这种“踩刹车”级别的本能反应。这篇文章我会从架构设计、核心机制、实操落地、踩坑经验四个维度把 Jev 这套 System One 决策模型拆开讲透。不管你是正在做 Agent 开发的工程师还是被延迟和成本困扰的产品负责人或者只是对大模型推理优化感兴趣的技术爱好者都能从中拿到可以直接用的东西。2. 为什么传统 Agent 架构慢得让人抓狂2.1 一次请求背后的“隐形推理链”要理解 Jev 的价值得先看清楚传统 Agent 到底把时间花在哪了。我拿一个真实项目里的日志来举例。用户输入是“帮我看看上周的销售数据做个同比分析”。在一个典型的 ReAct Agent 里这条请求会触发下面这些步骤第一步意图理解。模型读用户的话输出一段思考“用户想要销售数据的同比分析我需要先获取数据然后计算同比最后生成报告。”这一步消耗约 300 个 token 的推理。第二步工具选择。模型根据意图判断需要调用数据库查询工具输出工具名和参数。这一步又消耗约 200 个 token。第三步结果观察。工具返回数据后模型要读一遍数据判断“这个数据够不够做同比”如果不够还要再查。这一步消耗约 400 个 token。第四步计算与生成。模型基于数据做分析生成最终回复。这一步消耗约 800 个 token。整个链路下来光推理就烧了将近 1700 个 token耗时 8 到 15 秒不等。而这里面真正“需要大模型发挥智能”的部分其实只有第四步的分析和生成。前三步本质上都是分类和路由问题——判断意图、选择工具、检查结果这些任务的复杂度远低于写一篇分析报告。2.2 慢的根源不是模型不够强而是“杀鸡用牛刀”很多人第一反应是“换个更快的模型不就行了”。我试过把 Agent 的规划模型从大参数版本换成小参数版本延迟确实降了一些但问题接踵而至小模型在工具选择上开始出错该调 A 工具的时候调了 B该传三个参数的时候只传了两个。结果就是 Agent 陷入“调错工具→报错→重试→再调错”的死循环整体耗时反而更长。这就是当前 Agent 架构的根本矛盾决策环节需要的是“快而准”但现有方案要么快而不准小模型要么准而不快大模型。Jev 的破局思路是既然决策和生成是两种完全不同的任务那就用两种完全不同的模型来干。生成交给大模型决策交给专门训练的轻量模型。这个轻量模型不需要理解世界知识不需要生成流畅文本它只需要学会一件事看到当前状态输出下一步动作。2.3 System One 与 System Two 的分工逻辑这里借用认知科学里“快思考”和“慢思考”的概念。System Two 是慢思考负责逻辑推理、规划、创作对应我们熟悉的大模型推理链路。System One 是快思考负责模式识别、直觉判断、条件反射对应 Jev 的轻量决策模型。在 Jev 的架构里System One 负责处理那些高频、低复杂度、有明确模式的决策。比如用户这句话是闲聊还是任务请求如果是任务请求属于查询类、操作类还是分析类当前上下文里有没有可以直接复用的工具调用结果上一步工具返回的是正常数据还是错误信息这些问题有一个共同特点答案空间很小判断依据明确不需要深度推理。一个经过针对性训练的轻量模型完全可以在几毫秒内给出准确判断。而 System Two 只在 System One 判断“这个请求我搞不定”的时候才被唤醒负责真正的复杂推理和内容生成。3. Jev 的核心机制拆解200 倍提速从哪来3.1 决策模型的输入输出设计Jev 的决策模型不接收原始的自然语言对话历史而是接收一个结构化状态向量。这个向量包含几个关键字段当前用户输入的意图分类概率分布、上一步动作的类型和结果状态、当前对话轮次、可用工具列表的哈希编码、以及一个“复杂度评分”。输出同样不是自然语言而是一个动作 ID。每个动作 ID 对应一个预定义的操作比如“调用天气工具”“调用计算器”“直接回复”“请求 System Two 介入”“重试上一步”“终止流程”等。整个输入输出都是定长的不涉及自回归生成所以推理速度极快。我实测过一个类似设计的轻量决策模型在消费级 GPU 上单次推理耗时不到 3 毫秒。对比大模型动辄几百毫秒的首 token 延迟这个差距就是 200 倍提速的主要来源。3.2 训练数据的构造方式Jev 的决策模型不是从零训练的而是从一个预训练的小模型微调而来。训练数据的构造是关键。根据公开的技术思路训练样本来自两个渠道第一个渠道是真实 Agent 运行日志。把历史上大模型做过的每一次决策记录下来输入是当时的状态向量输出是大模型最终选择的动作。这些样本质量高但数量有限。第二个渠道是合成数据增强。通过规则引擎和模拟环境批量生成各种边界情况下的决策样本。比如“用户输入为空”“工具返回超时”“连续三次调用同一工具失败”等场景人工标注正确的动作。这部分数据量可以做到很大覆盖长尾情况。训练目标也很直接最小化动作预测的交叉熵损失。不需要 RLHF不需要奖励模型就是一个标准的分类任务。这也是为什么 Jev 的决策模型可以做得非常小——它本质上就是一个状态到动作的分类器。3.3 快慢系统的切换策略Jev 最精妙的地方在于快慢系统的切换逻辑。不是简单地“先快后慢”而是有一套动态判断机制。当 System One 对当前决策的置信度高于某个阈值比如 0.85时直接执行动作不唤醒 System Two。当置信度低于阈值或者动作类型被标记为“高风险”比如涉及资金操作、数据删除才把控制权交给 System Two。这个阈值不是拍脑袋定的。我自己的经验是阈值设得太高System One 频繁弃权提速效果打折扣设得太低错误决策增多用户体验崩盘。Jev 的做法是引入一个“代价敏感”的阈值调整机制对于错误代价高的动作阈值自动调高对于错误代价低的动作阈值调低。这个机制让整体系统在速度和准确率之间找到了一个不错的平衡点。3.4 与现有 Agent 框架的集成方式Jev 不是一个独立的 Agent 框架它更像是一个决策加速层。你可以把它插到现有的 ReAct 循环里替换掉原来“让大模型输出下一步动作”的那个环节。具体集成方式有两种。一种是旁路模式System One 先跑一遍如果置信度够高就直接执行否则把状态传给原来的大模型决策链路。这种方式改动小适合已有项目快速接入。另一种是主控模式System One 作为主决策器System Two 只作为“专家系统”被按需调用。这种方式需要重构 Agent 的控制流但提速效果更彻底。4. 实操落地怎么在自己的项目里复现这套思路4.1 环境准备与依赖选型如果你想自己复现一套类似的 System One 决策模型下面是我实际跑通的一套方案。硬件方面一块 8GB 显存的消费级显卡就够用因为决策模型本身很小。软件栈推荐用 Python 3.10 以上推理框架用 ONNX Runtime 或者 TensorRT这两个在低延迟场景下比原生 PyTorch 快不少。模型基座我试过几个最后选了一个 1 亿参数级别的中文小模型做微调。太大了推理慢太小了分类准确率上不去。1 亿参数这个量级在“够聪明”和“够快”之间平衡得比较好。# 决策模型的基本结构示意 import torch import torch.nn as nn class DecisionModel(nn.Module): def __init__(self, base_model, num_actions): super().__init__() self.encoder base_model self.classifier nn.Linear(base_model.config.hidden_size, num_actions) def forward(self, state_vector): hidden self.encoder(state_vector) logits self.classifier(hidden[:, 0, :]) return logits4.2 状态向量的构造细节状态向量的质量直接决定决策模型的准确率。我踩过的坑是一开始把原始对话文本直接塞进去结果模型学得一塌糊涂。后来改成结构化特征效果立竿见影。我用的状态向量包含以下字段字段名类型说明intent_probsfloat[16]意图分类的 softmax 概率last_action_idint上一步动作的 IDlast_result_statusint上一步结果状态成功/失败/超时turn_countint当前对话轮次tool_available_maskbool[N]可用工具的掩码complexity_scorefloat复杂度评分0-1error_streakint连续错误次数这个向量长度固定不随对话历史增长所以推理延迟是恒定的。意图分类可以用一个独立的轻量分类器来做也可以用规则引擎加关键词匹配先跑一版。4.3 训练流程与参数配置训练数据我准备了大概 5 万条真实日志加 20 万条合成样本。真实日志从线上环境脱敏后导出合成样本用规则引擎生成。训练超参如下学习率2e-5用 cosine 衰减batch size64epoch5优化器AdamWweight decay 0.01损失函数带类别权重的交叉熵因为“直接回复”这个动作占比过高需要降权训练在单卡上跑了大概 4 个小时。验证集准确率能到 94% 左右对于决策任务来说够用了。关键是推理速度导出成 ONNX 之后单次推理稳定在 2 到 4 毫秒。4.4 上线后的效果对比我在一个内部客服 Agent 上做了 A/B 测试。对照组用原来的纯大模型决策链路实验组接入 System One 决策层。结果如下指标对照组实验组变化平均响应延迟9.2s1.8s降低 80%决策环节 token 消耗68045降低 93%工具选择准确率96.1%94.7%降低 1.4%用户满意度4.2/54.3/5略升延迟降低 80% 虽然没有到 200 倍那么夸张但已经让用户体验有了质的变化。准确率的小幅下降在可接受范围内而且通过调整置信度阈值还能进一步优化。5. 踩坑记录与常见问题排查5.1 决策模型“学偏了”怎么办最常见的问题是决策模型过度拟合高频动作。比如在客服场景里“直接回复”这个动作占了 70% 的样本模型就倾向于对所有输入都输出“直接回复”导致该调工具的时候不调。解决办法有两个。一是类别加权给低频动作更高的损失权重。二是分层采样构造训练 batch 的时候保证每个动作都有一定比例。我两个都用了效果比较明显。5.2 置信度阈值怎么调阈值调参是个体力活。我的经验是先用网格搜索找到一个粗略范围然后根据线上反馈微调。具体做法是把置信度分成 10 个桶统计每个桶里的决策准确率然后选择准确率开始明显下降的那个点作为阈值。注意不同动作类型应该用不同的阈值。查询类动作可以宽松一些操作类动作必须严格。5.3 快慢系统切换时的上下文丢失从 System One 切到 System Two 的时候如果状态传递不完整System Two 会“不知道前面发生了什么”导致重复提问或者做出矛盾决策。我的做法是维护一个共享状态存储两个系统都从这里读写切换时不需要额外传递。5.4 常见问题速查表问题现象可能原因排查方向决策延迟突然升高状态向量维度变化检查特征工程管道某类动作从不被选中训练样本不足补充该类动作的合成数据切换后 System Two 重复提问共享状态未同步检查状态存储的读写时序准确率随对话轮次下降状态向量未归一化对 turn_count 等字段做标准化模型输出非法动作 ID动作空间变更未同步检查动作 ID 映射表版本6. 这套架构还能怎么扩展System One 的思路不局限于 Agent 决策。我现在正在尝试把它用到另外两个场景。一个是RAG 检索的路由决策判断当前 query 该走向量检索、关键词检索还是混合检索用轻量模型做路由比每次都用大模型判断快得多。另一个是多 Agent 协作时的任务分配哪个子任务交给哪个 Agent本质上也是一个分类问题。还有一个有意思的方向是在线学习。现在的决策模型是离线训练好再上线的但如果能根据线上反馈实时更新效果应该会更好。不过这涉及到模型热更新和版本管理工程复杂度不低我还在摸索阶段。最后分享一个我在实际部署中总结的小技巧决策模型的日志一定要打全。每次决策的输入状态向量、输出动作、置信度、最终是否被 System Two 覆盖这些都要记录下来。这些日志不仅是排查问题的依据更是下一轮模型迭代的训练数据来源。我第一版模型上线后就是靠分析日志发现“超时重试”这个动作的样本严重不足补了数据之后准确率直接涨了 3 个百分点。