System One 决策模型 Jev：Agent 决策提速 200 倍的架构解析

1. 从“慢思考”到“快直觉”Jev 到底想解决什么问题第一次看到“System One 决策模型 Jev”这个说法我脑子里蹦出来的不是论文而是自己写 Agent 时最头疼的那一幕一个简单的“帮我把这封邮件改得礼貌一点”Agent 在后台跑了七八轮工具调用先规划、再反思、再校验、再重规划最后花了十几秒才吐出一句话。用户早就关掉窗口了。Jev 这个模型被讨论得最多的标签就是“提速 200 倍”和“System One”。这两个词放在一起其实指向的是同一个痛点当前绝大多数 Agent 架构本质上都是“System Two”式的慢思考。它们依赖显式的规划、反思、多轮工具调用每一步都要经过一次完整的大模型推理。这种架构在复杂任务上确实强但代价是延迟高、成本高、并发扛不住。所谓 System One借用的是认知心理学里“快思考”的概念——直觉、快速、几乎无意识。放到 Agent 语境里就是把一部分决策从“每次都要重新推理”变成“一次训练、直接输出”。Jev 的核心主张我理解下来就是不是所有决策都值得动用完整的推理链很多中间步骤完全可以被“压缩”进一个更小的、专门做决策的模型里。这背后的逻辑其实不复杂。你可以把传统 Agent 想象成一个每次出门都要查地图、算路线、比较方案的人而 Jev 想做的是一个已经把城市路网“背下来”的老司机看到目的地就能直接给出走法。前者通用但慢后者专用但快。200 倍的提速大概率就来自这种“把推理变成直觉”的范式转换而不是单纯把模型换小或者加机器。需要说明的是下面关于 Jev 具体实现机制的描述有一部分是基于公开讨论和同类研究的合理推断因为这类模型的完整技术细节往往不会一次性全部公开。我会明确区分哪些是确定的方向哪些是基于常见实践的补全。2. 拆解 Jev 的核心思路为什么“决策”可以被单独拎出来2.1 传统 Agent 的推理开销到底花在哪要理解 Jev 的价值得先算清楚一笔账。一个典型的 ReAct 风格 Agent处理一个中等复杂度任务大致会经历这些环节接收用户输入做意图理解生成一个思考步骤Thought决定调用哪个工具Action等待工具返回结果Observation根据结果决定下一步循环若干轮最后汇总输出问题在于每一个 Thought 和 Action 的生成都是一次完整的大模型前向推理。如果用的是几百 B 参数的模型单次推理在消费级硬件上可能就是几百毫秒到几秒。循环五轮就是好几秒甚至十几秒。这还没算工具本身的执行时间。更麻烦的是并发。假设你要支撑 1000 个用户同时用每个请求平均 5 轮推理那就是 5000 次大模型调用在排队。这时候你会发现瓶颈根本不在工具而在“决策”这个环节本身。2.2 把“决策”从“生成”里剥离出来Jev 的思路我理解是把 Agent 的工作拆成两类环节特点适合的模型语言生成、复杂推理需要强语言能力、开放域知识大模型下一步做什么、调哪个工具状态空间有限、模式相对固定专用决策模型传统架构把这两类都交给同一个大模型等于用杀牛刀切菜。Jev 的做法是训练一个专门的决策模型输入是当前的状态对话历史、已有观察、可用工具列表输出是下一步的动作。这个模型的参数量可以小很多推理速度快很多因为它不需要“会说话”只需要“会选路”。这就是 System One 的精髓决策被训练成了条件反射而不是每次现场推理。2.3 200 倍提速的账怎么算200 倍这个数字听起来夸张但拆开看并不离谱。假设原来每轮决策用 70B 模型单次 800ms换成 1B 级别的专用决策模型单次可能只要 20ms 到 40ms。这本身就是 20 到 40 倍。再叠加两个因素减少推理轮数专用决策模型因为见过大量类似轨迹往往能一步到位不需要“反思再反思”轮数可能从 5 轮降到 2 轮。批处理效率小模型更容易做高并发批处理单位时间吞吐量更高。20 倍乘以轮数减少带来的 3 到 5 倍再乘以批处理带来的额外收益200 倍这个量级就有了合理的解释。当然具体数字取决于任务类型和基线配置不能一概而论。提示看到“提速 N 倍”这类宣传时一定要问清楚基线是什么。是同一个模型换架构还是大模型换小模型是单请求延迟还是整体吞吐不同口径下数字能差一个数量级。3. 核心细节解析Jev 这类决策模型的关键设计点3.1 状态表示决策模型的输入长什么样决策模型要快输入就必须紧凑。传统 Agent 把整段对话历史塞给大模型token 数动辄几千。Jev 这类模型通常会做状态压缩把输入整理成结构化字段当前任务类型分类标签已完成步骤摘要可用工具及其参数 schema关键实体和约束这种结构化输入的好处是 token 数大幅下降推理自然快。代价是需要一个前置的“状态编码”环节把自然语言历史转成结构化状态。这个环节本身也要成本但如果做得轻量总体还是划算的。3.2 动作空间输出为什么可以很简单决策模型的输出通常不是自然语言而是一个离散的动作选择比如调用工具 A参数为 {...}调用工具 B参数为 {...}直接回复用户结束任务动作空间有限意味着可以用分类头或者小型生成头来实现不需要完整的语言建模能力。这是参数量能压下来的关键原因。3.3 训练数据从哪来这是最容易被忽略但最关键的一环。决策模型不是凭空训出来的它需要大量“状态-动作”对。常见来源有几类用大模型 Agent 跑大量任务记录每一步的状态和动作作为蒸馏数据人工标注的高质量轨迹线上真实交互日志脱敏后这里有个经验蒸馏数据的质量比数量重要得多。如果教师模型本身决策就乱学生模型学到的也是乱的。我见过不少团队急着上量结果训出来的决策模型在边界情况上频繁选错工具反而比大模型更不稳定。3.4 与主模型的协作方式Jev 不是要取代大模型而是分工。典型协作模式是决策模型负责“选路”快速决定下一步大模型负责“执行”在需要生成内容或复杂推理时被调用决策模型判断任务完成交回大模型做最终输出这种分工下大模型的调用次数大幅减少只在真正需要语言能力的时候才上场。4. 实操过程如何在自己的 Agent 项目里复现这套思路4.1 第一步先量化你当前的决策开销在动手改架构之前先埋点。你需要知道每个请求平均多少轮决策每轮决策的延迟分布决策环节占总延迟的比例如果决策只占 10%那优化它意义不大如果占 70% 以上那就值得动手。我自己的项目里决策环节一度占到总延迟的 65%这就是典型的可优化场景。4.2 第二步定义你的动作空间把 Agent 所有可能的动作列出来做成一个枚举。比如ACTIONS [ search_web, read_file, write_file, call_api, ask_user, final_answer, ]动作空间越小决策模型越容易训推理越快。如果动作超过几十个考虑做分层决策先选大类再选具体动作。4.3 第三步构造状态-动作数据集用你现有的 Agent 跑一批任务记录每一步的状态和实际动作。这里有个技巧不要只记录成功轨迹失败轨迹同样有价值尤其是那些“选错工具后纠正”的样本能让决策模型学会避坑。数据格式建议做成 JSONL每行一个样本{state: {task_type: email_edit, history: [user wants polite tone], tools: [rewrite, translate]}, action: rewrite}4.4 第四步训练一个轻量决策模型选一个 1B 到 3B 级别的基座模型做监督微调。如果动作空间是离散的也可以直接在上面加分类头。训练时注意学习率不要太大决策任务容易过拟合保留一部分数据做验证重点看边界情况的准确率不要追求 100% 准确决策模型允许偶尔出错后面有大模型兜底4.5 第五步接入主流程并做灰度把决策模型接进 Agent 主循环替换原来的“大模型决策”环节。上线时一定要灰度先放 5% 流量对比成功率和延迟。我踩过的坑是一开始全量切结果某些长尾任务因为决策模型没见过直接卡死。灰度能帮你快速发现这类问题。4.6 第六步持续迭代决策模型不是训一次就完事。线上会不断出现新的任务类型和工具需要定期用新数据做增量训练。建议建立一个“决策错误回流”机制把线上决策错误的样本自动收集起来定期重训。5. 常见问题与排查技巧实录5.1 决策模型总是选同一个工具怎么办这是典型的数据不平衡问题。如果训练数据里某个工具出现频率特别高模型会倾向于一直选它。解决办法对低频动作做上采样在损失函数里给不同动作加权引入“动作多样性”正则项我试过最简单有效的一招是在训练数据里人为增加低频动作的样本比例让分布更均匀。5.2 提速没达到预期先别怀疑模型检查这几个点排查项可能问题解决方向状态编码耗时前置处理太重简化状态表示决策模型本身参数量还是太大换更小基座或量化调用链路网络往返多本地部署或合并调用轮数没降决策质量不够补充训练数据很多时候瓶颈不在决策模型而在它周围的那圈“胶水代码”。5.3 决策模型和大模型输出冲突偶尔会出现决策模型说“结束”但大模型觉得任务没完成。这时候需要一个仲裁机制。我的做法是以决策模型的“结束”信号为准但把大模型的疑虑记录到日志用于后续分析。如果冲突频繁说明决策模型的训练数据需要补充这类边界样本。5.4 并发上去了但错误率也上去了高并发下决策模型可能因为批处理而出现精度损失。检查你的批处理实现确保不同请求的状态没有串味。另外并发高时工具调用可能成为新瓶颈别忘了给工具层也做限流和降级。注意决策模型再快也架不住下游工具慢。做架构优化时一定要端到端看别只盯着一个环节。6. 这套架构适合谁不适合谁Jev 这类 System One 决策模型最适合的场景是任务类型相对固定、工具集明确、对延迟敏感。比如客服自动回复、表单填写、标准化数据处理。这些场景下决策模式高度重复专用模型能发挥最大价值。不太适合的场景是任务高度开放、工具频繁变化、需要大量创造性推理。这种场景下决策空间太大专用模型很难覆盖还是得靠大模型的通用能力。我个人的判断是未来主流 Agent 架构大概率是混合的System One 处理高频、标准化的决策System Two 处理低频、复杂的推理。两者不是替代关系而是分工关系。Jev 的价值在于它把“决策”这个环节单独拎出来做优化给了我们一个明确的工程方向——不是所有事情都要用最大的模型硬扛。最后分享一个我在实际项目里的小体会引入决策模型后最明显的收益其实不是延迟而是成本结构的改变。原来每次决策都在烧大模型的 token现在大部分决策由小模型完成大模型只在关键节点出场整体成本降了一大截。延迟的改善是用户能感知的成本的改善是老板能感知的两个都重要。