拆解Jev：不生成文本的AI决策模型如何实现毫秒级动作输出

最近在整理手头的智能体项目正好把 Jev 这一类“不生成文本的 AI”拆了拆。很多人第一次听到这个概念时第一反应都是困惑AI 不做文本生成那还能做什么在过去的认知里AI 好像天然和“输出一段话”绑定在一起GPT、对话助手、代码补全全都在做文本生成。但实际接触下来你会发现自动驾驶、机器人控制、运维告警响应、编程工具决策这类场景真正需要的并不是一段流畅优美的自然语言而是一个可以直接交给执行系统的动作参数。Jev 的核心定位就在于这种“状态进来、动作出去”的决策式模型。如果只看热词大家最关心的问题集中在几个点上Jev 是开源的吗决策延迟 32.8 毫秒够不够用能不能支持自动驾驶怎么接入 Codex 这样的编程环境怎么申请和配置密钥这篇文章不打算做产品说明书式的介绍而是从“拆解”的视角把这套东西讲清楚它到底为什么不做文本生成决策又是怎么做出来的延迟里面藏着哪些工程细节以及落到自动驾驶、Agent 编程这些具体场景时应该怎么用、会遇到哪些坑。文中我会把 Jev 当作一个“面向直接决策的模型实例”来拆解你可以把它视作这类非生成式决策模型的代表。就算你手上没有官方渠道的访问权限理解它的运行逻辑之后也可以迁移到自己的模型选型和技术方案里。1. 直接决策与文本生成两种技术路线的边界1.1 从“预测下一个 token”到“预测下一个动作”生成式模型的基本工作方式是最大化条件概率给定上下文预测下一个 token然后一个 token 一个 token 地把完整序列拼出来。你可以把这个过程理解成“先写作文再做判断”。写作文本身是个不错的推理过程但它不是实时的也不保证每一步输出都是可执行的指令。Jev 走的是另一条路。它直接计算状态到动作的映射用数学表达就是[ a_t f(s_t) ]这里 (s_t) 不是一段自然语言而是一个结构化的状态编码——车速、相对位置、障碍物类型、路况信息、任务目标全部压缩成固定维度的向量输出 (a_t) 也不是一段解释性文字而是动作空间里的具体数值比如方向盘转角、纵向加速度、决策编号。没有 token 级采样没有生成文本的中间环节模型的每一毫秒都花在“理解状态、输出动作”这件事上。这个差别在实时系统里是致命的。文本生成模型哪怕用流式输出也有采样随机性同一个状态可能生成不同的句子而你指望它稳定地把“向左变道注意左后方来车”翻译成执行指令那还得再经过一层语义解析。解析出错怎么办解析时间过长怎么办没人能保证。Jev 这类模型直接把“解析”这个环节从系统里删掉了。1.2 文本生成器的隐性成本很多团队在初期规划里会下意识地把决策也交给大模型认为“反正大模型什么都会”。这句话在一轮对话、一个文档摘要的场景里成立在决策链路里却很容易翻车。文本生成的隐性成本至少有三个第一是时间成本。一次决策若依赖完整文本输出延迟往往在几百毫秒到几秒之间而且长度越长越不稳定。对自动驾驶、高频交易、工业控制这类系统来说这就是不可接受的抖动源。第二是随机性成本。大模型推理时温度参数一调同一次输入可能产出概率分布不同的结果。决策系统最怕的恰恰是“同样路况、不同决策”因为下游执行机构没法解释这种随机性来自哪里。第三是解析成本。自然语言输出之后必须做实体抽取、意图识别、格式校验。你等于把决策拆成了“模型推理 规则解析”两段任何一个环节出错都会造成整体决策失效。Jev 把输出定义成结构化动作参数解析层直接消失后端拿到的就是标准 JSON 或张量。1.3 决策快照就是 Jev 的“眼前世界”我拆 Jev 的时候最关注的一个概念是“动态决策快照”。快照不是截图不是把摄像头画面存下来而是把这一时刻系统关心的全部要素压缩成一个固定结构的表示。打个比方你开车时并不需要记住路边每一棵树长什么样你只需要知道自己当前的速度和方向、前面有没有车、距离多近、旁边车道是否允许变道。这些信息组合在一起就是你的“驾驶快照”。Jev 也这样它会从感知模块拿到底层信息经过筛选只把和当前任务相关的特征放进快照。快照的内容按模块大致可以分为四类自车状态纵向车速、横摆角速度、横向偏移量、当前加速度环境目标障碍物类别、相对位置、相对速度、置信度道路结构车道曲率、航向偏差、可行驶区域掩码任务指令目标车道、规划意图、任务优先级。这套结构的意义在于它让模型不用去看完整的多维传感器数据而是直接在一个低维、高信息密度的世界里做判断。这也是为什么 Jev 可以保持很低的决策延迟——它处理的不是“世界”而是“世界的决策关键摘要”。2. Jev 的核心机制快照、动作空间与 32.8 毫秒延迟2.1 动态决策快照是怎么生成的快照的生成过程决定了 Jev 的上限。如果前面的感知模块没有把环境信息抽象好模型拿到再完整的数据也做不出高质量决策。实际项目里快照生成一般分三步第一步时间对齐。传感器数据来自不同频率摄像头可能是 30Hz毫米波雷达可能是 20HzIMU 可能是 100Hz。Jev 内部会维护一个时间窗把所有数据对齐到同一个时间戳上避免“用上一帧的图像去配当前帧的速度”。第二步特征筛选。不是所有感知结果都值得进快照。距离 200 米以外、置信度为 0.3 的疑似目标在很多场景里根本没有决策价值。筛选规则通常包括距离阈值、置信度阈值、目标类别白名单、动态性判断。第三步向量化。把结构化数据转成固定维度的浮点张量。这里要特别注意维度一致性如果快照张量维度是动态的后面推理时的延迟和显存开销都会变得不可控。我在项目中遇到过最隐蔽的问题是时间戳不同步导致快照里出现“未来数据”。传感器的数据包偶发乱序如果不对齐就直接塞给模型模型等于看到了还没发生的事情决策自然就变得飘忽不定。所以不论用什么模型快照模块一定要做时间戳校验和同步。2.2 动作空间怎么设计动作空间是决策模型能输出的所有合法动作的集合。Jev 的动作空间设计可以分为两种模式离散模式适合行动选择类任务。比如一个运维 Agent可能的动作就是“重启服务”“回滚版本”“拉取日志”“发起告警”模型输出的是一个动作编号和对应置信度。离散空间的好处是实现简单但边界情况往往会落在两个动作之间因此我会给每个动作都配一个“拒绝执行”的置信度下限防止模型在一个低置信度动作上硬跳。连续模式适合运动控制类任务。自动驾驶里的输出通常包括转向角、目标加速度、目标横摆角速度。连续动作虽然更灵活但需要在输出之后加一层执行约束比如加速度不能超过舒适区间、转向角变化率不能超过物理上限。比较好的实践是混合空间先用一个小型分类头决定宏观策略比如“跟随慢车”“换道超车”“减速让行”再用连续回归头输出具体数值。宏观策略负责解释性连续数值负责可执行性两套输出都来自同一个快照但经过不同的输出头。2.3 32.8 毫秒延迟是怎么来的决策延迟 32.8 毫秒是不少人在选型时最关心的一项。这个数字能不能支持自动驾驶先给结论大多数场景下足够。自动驾驶的底盘控制周期常见为 20 到 50 毫秒也就是说决策模型在 30 到 40 毫秒内给出一条控制指令已经可以满足很多 L2 和部分 L3 场景的需求。重点不是“绝对数值越低越好”而是“延迟要稳定”偶尔一次 32.8 毫秒、下一次 150 毫秒这样对控制系统才是灾难。拆开来看32.8 毫秒的典型预算大概是这样的感知输出到状态快照生成10 到 12 毫秒快照特征标准化和编码4 到 6 毫秒模型推理10 到 15 毫秒动作后处理和约束校验3 到 5 毫秒。你注意最后一项动作后处理经常被忽略但它实打实地会占用时间。模型输出的动作不能直接发给执行器首先要做单位换算、置信度过滤、物理约束检查。如果一个系统说自己延迟 32.8 毫秒但实际后处理逻辑里挂了一个字符串匹配或者规则引擎这个数字迟早会被打破。提示如果你在压测中发现延迟高于预期先别急着优化模型推理优先检查后处理链路里有没有“不小心”把文本解析加回来。决策系统最怕的就是嘴上说不用文本工程实现里又搞了一个 JSON 解析的循环等待。2.4 Jev 和语言模型是怎么协作的有人会问Jev 如果能自己决策那大模型还有用吗我的理解是两者不是替代关系而是分工关系。Agent 系统通常分层次。高层大模型负责理解复杂任务、拆分目标、判断优先级这个过程适合用文本因为任务本身是模糊的、需要推理的。低层执行决策却应该交给 Jev 这样的决策式模型因为执行需要的是低延迟、高稳定性、可回溯。举个例子你让一个编程 Agent 修改某个模块大模型先判断“这个模块和另外三个文件有依赖关系应该先跑测试”这是高层推理。但“要不要立刻执行 git commit”“commit 之前要不要先构建”“遇到测试失败是回滚还是继续修复”这些逐帧变化的执行决策就适合 Jev 直接输出动作编号而不是让大模型每次重新生成一段完整解释。Jev 和语言模型协作时我一般会用一条规则语言模型只负责给出意图不直接生产执行参数Jev 只负责执行参数不负责解释意图。中间通过一个轻量的协议层做转换这样两边都不越界系统也不会因为“大模型说了一句模糊的话”而卡住。3. 落地实操自动驾驶、编程助手与接入配置3.1 自动驾驶决策为什么不能等一句自然语言自动驾驶场景是验证“不做文本生成的 AI”最好的试金石。车辆以 100 公里/小时行驶时每秒前进约 28 米100 毫秒就是 2.8 米。如果决策链路里出现任何文本生成、语义解析、远程调用的环节这个延迟就会立刻转化为实际距离误差。用车道保持为例。感知模块输出本车与车道线的距离偏移量Jev 接收后直接输出转向修正角。整个过程是纯数值计算。一旦在中途加入“根据车道偏移量生成一句警告再解析这句话判断怎么转向”系统就完全不可用了因为你不确定模型会生成多长的句子、用什么措辞、解析器是否能理解。我在实车数据回放中做过对比同一个场景下文本中间层的方案平均延迟 420 毫秒Jev 的直接映射方案平均 33 毫秒。前者在高速场景里已经足够让车跨过一个完整车道边界后者还留有余量给执行器滤波。3.2 状态输入与动作输出范例这里给出一个简化版的快照和输出示例方便你理解 Jev 的输入输出接口长什么样。假设场景是高速公路单车道跟车。输入快照JSON 示意{ snapshot_id: 20240911_082130_4712, timestamp_ms: 824617, ego: { speed_mps: 29.5, yaw_rate: -0.08, acceleration_mpss: 0.4 }, objects: [ { id: 17, class: truck, rel_x_m: 42.1, rel_y_m: -1.8, rel_vx_mps: -2.6, confidence: 0.96 } ], lane: { curvature_1pm: 0.0031, heading_error_rad: 0.02 } }动作输出JSON 示意{ action: { steer_angle_rad: 0.012, target_acceleration_mpss: -1.2, confidence: 0.91 }, decision_time_ms: 32.8, snapshot_id: 20240911_082130_4712 }注意输出里带上了snapshot_id这是一个让系统具备可回溯性的细节。每次决策都能定位到输入快照出问题的时候可以直接回放该帧状态而不是只能靠滴滴自己的日志猜测。我在项目里把所有决策和快照都做了关联存储排查问题的效率至少提高一倍。3.3 在编程 Agent 场景里的用法把 Jev 和 Codex 这类编程工具放在一起用是最近比较热的方向。核心思路很简单编程 Agent 的“决策”部分也应该直接输出动作而不是每次都靠大模型重新生成步骤描述。比如一个修复测试失败的 Agent它的状态快照可以包含当前分支名、最近 5 次构建状态、测试失败列表、改动文件列表、是否处于 CI 等待状态。Jev 根据这份快照选择一个动作修复失败测试、跳过 CI 直接提交、回滚上次提交、申请人工介入。实际接入时我建议把 Jev 设计成编程 Agent 的一个“策略层”。大模型负责写代码Jev 负责回答“接下来该不该执行这个动作”。这样大模型不需要为每个动作做一次长文本推理token 消耗明显下降Agent 的执行节奏也更稳定。在 Codex 这类工具中使用时最常见的实现方式是做一个工具调用的前置拦截器。监听到大模型打算调用某个工具时先把这个工具信息和当前项目状态转成快照交给 Jev 判断。如果 Jev 给出的动作是“拒绝执行”或者“延迟执行”拦截器就阻止这次调用。这里的延迟预算可以放宽到几十毫秒但对于并发场景来说几十毫秒的优化依然非常有价值。3.4 接入配置与密钥管理的经验接入 Jev 这类模型事务里开发者最常接触的实际问题其实是密钥和端点配置。不管你是不是自己部署模型都要养成规范的密钥管理习惯因为密钥一旦泄露任何模型本身的安全性讨论都没有意义了。我一般的做法是新建一个.env文件集中管理配置JEV_ENDPOINThttps://api.example.internal/v1 JEV_API_KEYsk-xxx JEV_REQUEST_TIMEOUT_MS50然后在代码里用环境变量读取不把密钥写死在源码里。如果你用 Python可以直接用python-dotenv加载如果你用 Gogodotenv也是类似用法。这里有几个从实操中总结出来的重点第一密钥要做最小权限授权。如果是云端服务只申请能支持当前任务的角色权限不要一上来就申请管理员级密钥。团队合作时申请独立密钥而不是共用一把出问题才知道找谁。第二定期轮换。即使密钥没有泄露也建议按周期轮换尤其是当项目进入对外发布阶段之后。我会在日历里设置密钥轮换提醒踩过一次“密钥过期导致生产环境不可用”的坑之后你就知道提前轮换有多重要。第三请求要设置超时控制。决策模型如果在 50 毫秒内没有返回不如直接触发降级策略。我在代码里会写一个超时配置宁可走保守规则也不要让主线程一直等待。4. 常见问题、排错与避坑经验实录4.1 延迟不稳定从哪些环节开始查延迟如果是单次 32.8 毫秒看起来挺好看但一压测就飘到 100 毫秒以上问题往往不出在模型本身。我建议按照下面的链路逐层排查。先看数据输入。如果快照张量里出现动态维度比如目标数量不固定很多推理框架会触发动态图重建这个开销一次就能吃掉几十毫秒。解决办法是固定最大目标数量不够的位置补零或空间掩码。再看后处理。某些团队为了兼容旧系统会在敏捷迭代 Jev 输出的 JSON 之后再做一次“语义映射”这等于把文本解析那一层又加回来了。后处理应该是纯数值运算一旦出字符串循环或正则匹配延迟立刻会不可控。最后看批处理。在线部署时如果多个请求合批慢请求会被快请求一起拖住。针对耗时敏感场景不要开大 batch 来做推理宁可单车单请求也不要积压排队。延迟稳定优先于吞吐量。4.2 文本模型和决策模型意见不一致怎么办混合架构里最容易出的不对齐问题是大模型说“向左变道”Jev 却输出“保持当前车道”。这种冲突会让系统没头绪也会让调试的人懵掉。我的处理原则是分层仲裁。高层模型可以提出意图但最终执行动作必须经过低层决策模型的通道。如果两者冲突默认采用低层决策模型结果同时把高层意图和实际动作一起记录到日志里。后续迭代时用这批冲突样本去判断到底是高层理解错了还是低层模型视野太窄、没看到大模型已经推理出的全局信息。基础共识是牺牲一部分“最佳方案”也要保证系统的确定性。自动驾驶里宁可不换道也绝对不能因为两个模型各自抢方向盘导致执行器震荡。4.3 快照特征质量太差导致的决策失误决策模型对快照质量极度敏感。你给它的快照里如果少了关键目标它很可能决策出一个在真实世界里完全错误的动作。我踩到过一次典型的坑快照里只保存了感知模块中置信度排名前一的目标结果旁边车道有一辆高速接近的车辆因为置信度在帧内低了一点被直接过滤掉模型就给出了“平稳向左并线”的错误决策。后来改成按距离、速度、类别分别保留 Top-K 目标缺陷才解决。建议在快照生成环节加一个“强制保留清单”某些条件下即便目标置信度不足也要以低权重放进快照。比如正前方突然出现静态障碍物、旁边车道高速接近的车辆这类目标往往是最危险的不能因为一次低置信度就被丢掉。快照宁可多给模型一些信息也不要让模型在两个平行世界里猜来猜去。4.4 排查速查表我整理了下面这张速查表遇到问题可以直接对照排查。现象可能原因首选排查方法决策延迟从 33ms 升到 200ms动态维度触发推理图重建固定快照维度补齐零值决策抖动频繁动作跳跃连续动作输出缺少滤波加入一阶低通滤波系数 0.2 起步大模型与决策模型结果冲突没有分层权限边界设置仲裁规则默认低层优先同输入不同输出模型未锁随机种子或部署多副本版本不一致固定推理 config逐副本比对版本号快照误判严重漏检高风险目标特征筛选阈值过严设置“强制保留清单”降低关键类别过滤阈值频频超时请求队列被长任务阻塞关闭大 batch单独部署实时实例密钥校验失败密钥权限过期或跨环境使用检查环境变量轮换新密钥这张表不一定覆盖所有情况但能帮你省下不少“排查到一半发现是在浪费时间”的无谓消耗。我现在做任何决策模型集成都会把这张表先贴在项目文档第一页团队新同学上手也能直接照着查。4.5 部署时容易被忽略的三个细节最后再单独聊三个细节都是实际部署中很容易踩中的。一个是版本管理。决策模型的迭代必须是显式的不能只更新权重文件而不更新对应的配置文件。我在服务端启动时会打印模型签名的 SHA 值每次上线都核对签名确保线上确实是我验过的那一版。一个是日志结构化。决策日志建议输出 JSON 格式包含snapshot_id、模型输出、后处理结果、决策延迟。人眼读日志的时候会很痛苦但回放工具只需要读 JSON 就能还原现场值得一开始就坚持。还有一个是“快速失败”策略。比如请求超时、输出非法、置信度过低都应该走降级路径而不是重试。决策系统的重试逻辑很危险我见过一个项目因为超时重试导致模型连发三条指令执行机构差点做出反向动作。宁可这一帧不做也绝对不要做错一帧。个人体会如果你问我 Jev 这类不生成文本的 AI最终的价值在哪里我的体会是它把“AI 决策”从一种修辞变成了一种工程纪律。文本生成很好用但它描述世界的方式是离散、缓慢、带随机性的而控制机械、执行动作、响应状态变化需要的是另一个量级的速度和稳定。拆完 Jev 之后我对自己手头 Agent 项目的重构思路也变得清晰起来——凡是既定的、可重复的、要求低延迟的决策坚决从大模型身上剥下来交给决策模型去完成大模型只留给它真正擅长的事理解复杂意图、生成灵活的表达、规划高层的路径。最后再分享一个日常调试的小技巧给每次决策都留下可回放的快照不要只记录模型输出。很多模型问题看起来是模型错了其实是输入帧里的某个字段传输变形或时间戳错位。有了快照你才能区分是“模型判断错了”还是“模型看到的世界就是错的”。这一点对任何直接决策的 AI 系统都适用。