1. 从 Token 到决策Jev 到底在解决什么问题第一次看到“Jev当 AI 不再生成 Token而是直接做决策”这个标题我脑子里蹦出来的第一个画面是过去两年我们跟大模型打交道本质上都在做一件事——猜下一个 Token。你问它“今天天气怎么样”它一个字一个字往外蹦你让它写代码它也是一行一行往外吐。整个过程里模型是个“文本生成器”决策权始终在人手里它给建议你来拍板。Jev 想干的事情不太一样。它把“生成 Token”这个动作往后放把“做决策”提到前面来。换句话说模型不再只是输出一段看起来合理的文字而是直接给出一个可执行的动作、一个明确的选择、一个带状态的判断。这个转变听起来只是措辞上的差别但落到工程实现上是两套完全不同的架构。我拿一个实际场景来说明。假设你有一个客服工单系统用户提交了一条“我的订单三天没发货我要退款”。传统 LLM 方案是把工单内容塞进 prompt让模型生成一段回复文本比如“非常抱歉给您带来不便我帮您查询一下……”。这段文本再交给人工或者规则引擎去判断下一步。而 Jev 这类决策型 Agent 的思路是模型直接输出一个结构化决策比如{action: query_order, order_id: 12345, next_step: check_logistics}系统拿到这个决策直接执行不需要再经过“文本→解析→判断”的中间层。这个差别为什么重要因为Token 生成是有成本的而且成本不低。你让模型生成 500 个 Token 的客套话这 500 个 Token 里可能只有 20 个 Token 是有用的决策信息剩下 480 个都是“语言润滑剂”。Jev 的核心主张就是把这层润滑剂砍掉让模型直接输出决策信号。对于高频调用的 Agent 场景这个优化带来的延迟下降和成本下降是实打实的。那 Jev 适合谁我觉得三类人最应该关注一是正在做 Agent 开发的工程师你们肯定被“模型输出格式不稳定”折磨过二是做 LLM 应用落地的产品和技术负责人你们关心的是怎么把 Token 成本压下来三是对 AI 决策机制好奇的开发者想搞清楚“不生成 Token 的模型”到底怎么工作。下面我按自己的理解把这个事情拆开讲。2. 核心机制拆解Jev 是怎么绕过 Token 生成的2.1 传统 LLM 的 Token 生成链路回顾要理解 Jev 的改动得先看清楚传统 LLM 在 Agent 场景里是怎么跑的。我画不了图就用文字描述这条链路用户输入 → Prompt 拼接 → 模型前向计算 → 输出概率分布 → 采样得到 Token → 重复直到结束符 → 得到完整文本 → 后处理解析 → 提取决策 → 执行动作。这条链路里最耗时的环节是“重复直到结束符”。每生成一个 Token模型都要做一次完整的前向计算。生成 200 个 Token 就是 200 次前向计算。虽然现在有 KV Cache 优化但延迟依然跟输出长度成正比。更麻烦的是Agent 场景往往需要多轮决策每一轮都要走一遍这个链路延迟叠加起来很可观。还有一个隐藏问题Token 生成是概率性的。模型输出“我建议您先查询订单状态”和“建议先查订单”是两个不同的 Token 序列但语义几乎一样。你的后处理解析器得同时兼容这两种写法否则就会解析失败。这就是为什么很多 Agent 项目里Prompt 里要写一大堆“请严格按照 JSON 格式输出”但模型还是时不时给你加个“好的以下是 JSON”。2.2 Jev 的决策输出机制Jev 的思路是既然 Agent 最终只需要一个决策那为什么还要让模型把决策“翻译”成自然语言再解析回来直接在模型输出层做约束让模型输出一个决策向量或者决策 ID 不就行了。我理解的具体做法是这样的模型在预训练或者微调阶段除了学习 Token 预测还学习一个“决策头”。这个决策头不输出词表上的概率分布而是输出一个动作空间上的概率分布。动作空间是预先定义好的比如[查询订单, 发起退款, 转人工, 结束会话]。模型看完输入后直接在这个动作空间上做分类选出概率最高的动作。这跟传统 LLM 的区别在于传统 LLM 的输出空间是词表几万到几十万个 TokenJev 的决策输出空间是动作集合可能只有几十到几百个动作。输出空间小了计算量自然就小了。而且输出是结构化的不需要后处理解析直接就能用。我打个比方。传统 LLM 像是一个翻译官你把中文需求给它它先翻译成英文你再找人把英文翻译回中文执行。Jev 像是一个直接听懂中文的助理你说什么它直接做不需要中间翻译环节。翻译环节少了出错概率就低了速度也快了。2.3 决策空间的设计与约束这里有个关键问题决策空间怎么定如果动作集合太小模型能做的事情就有限如果动作集合太大又退化成 Token 生成了。我看了下 Jev 相关的讨论常见的做法是分层决策空间。第一层是粗粒度动作比如“查询类”“修改类”“交互类”“结束类”。第二层是细粒度参数比如查询类下面有“查订单”“查物流”“查账户”。模型先选粗粒度动作再选细粒度参数。这样每一层的输出空间都可控组合起来又能覆盖足够多的场景。这种分层设计还有个好处可以针对每一层单独做约束。比如查询类动作不允许修改数据修改类动作必须带确认参数。这些约束可以在解码阶段直接屏蔽掉不合法的动作而不是等模型输出文本后再用规则去拦。这就从“事后检查”变成了“事前约束”可靠性高了一个档次。注意决策空间的设计不是一劳永逸的。业务变化了动作集合要跟着变。所以 Jev 这类方案通常需要配套一个动作注册机制让开发者能动态增删动作而不是每次改动作都要重新训练模型。3. 实操落地怎么在现有项目里接入 Jev 思路3.1 环境准备与依赖梳理假设你现在有一个基于 LLM 的 Agent 项目想试试 Jev 这种决策型方案。我的建议是不要一上来就推翻现有架构而是先做一个“决策层替换”的试点。你需要准备的东西不多一个能跑推理的模型服务可以是本地部署的也可以是 API 调用的一个动作注册表用 JSON 或者 YAML 定义都行一个决策执行器根据模型输出的动作 ID 调用对应的业务函数。如果你用的是 Python我习惯用 Pydantic 来定义动作 schema这样类型检查和序列化都省事了。from pydantic import BaseModel from enum import Enum class ActionType(str, Enum): QUERY_ORDER query_order QUERY_LOGISTICS query_logistics INITIATE_REFUND initiate_refund TRANSFER_HUMAN transfer_human END_SESSION end_session class Decision(BaseModel): action: ActionType order_id: str | None None reason: str | None None这个Decision模型就是 Jev 思路的落地形式。模型不需要生成一段话只需要填这个结构。填完之后你的执行器直接match decision.action就能分发。3.2 动作注册表的定义与维护动作注册表是 Jev 方案的核心配置文件。我一般会把它设计成三层结构动作 ID、动作描述、参数 schema。动作描述是给模型看的参数 schema 是给执行器用的。actions: - id: query_order description: 根据订单号查询订单状态和基本信息 params: - name: order_id type: string required: true description: 订单编号通常是数字或字母组合 - id: initiate_refund description: 对指定订单发起退款流程 params: - name: order_id type: string required: true - name: reason type: string required: false description: 退款原因用于记录维护这个表的时候有个经验动作描述要写得像给新人看的操作手册不要写得太抽象。比如“查询订单”不如“根据订单号查询订单状态和基本信息”来得清楚。模型对描述的理解越准确选错动作的概率就越低。3.3 决策解码与执行流程接入 Jev 之后你的 Agent 主循环会变成这样接收用户输入拼接上下文。调用模型模型输出一个决策 ID 和参数。校验参数是否完整、是否合法。执行对应动作拿到执行结果。把执行结果作为新的上下文进入下一轮决策。直到模型输出end_session或者达到最大轮次。这个循环里第 3 步的校验很关键。我踩过的坑是模型有时候会输出一个不存在的动作 ID或者参数类型不对。所以校验层要严格不合法就直接打回让模型重新决策而不是硬着头皮执行。def execute_decision(decision: Decision, registry: dict): if decision.action not in registry: raise ValueError(f未知动作: {decision.action}) action_def registry[decision.action] for param in action_def[params]: if param[required] and not getattr(decision, param[name], None): raise ValueError(f缺少必填参数: {param[name]}) return registry[decision.action][handler](decision)这段代码看起来简单但它是整个决策链路的守门员。守门员不靠谱后面全乱套。3.4 与传统 Token 方案的混合使用完全抛弃 Token 生成也不现实。有些场景需要模型解释决策理由或者需要生成一段面向用户的自然语言回复。我的做法是混合使用决策走 Jev 通道回复生成走传统 Token 通道。比如用户问“为什么我的订单还没发货”模型先输出决策query_logistics执行器查到物流信息后再把物流信息喂给模型让模型生成一段自然语言解释。这样决策是结构化的回复是自然的两边的好处都占了。提示混合模式下要控制好两个通道的调用顺序。先决策后生成不要反过来。反过来会让模型先编一段话再根据话去猜决策那就本末倒置了。4. 常见问题与排查技巧实录4.1 模型选错动作怎么办这是最常见的问题。模型选错动作通常有三个原因动作描述有歧义、上下文信息不足、模型本身能力不够。排查顺序我一般是这样的先看动作描述把容易混淆的动作描述拿出来对比看是不是描述太接近了。比如“查询订单”和“查询物流”如果描述都写“查询相关信息”模型肯定懵。把描述改清楚大部分选错问题都能解决。如果描述没问题再看上下文。模型做决策需要足够的信息如果用户说“帮我处理一下”模型根本不知道处理什么。这时候要么让模型先输出一个“澄清”动作要么在 Prompt 里补充更多上下文。最后才考虑换模型。动作选择本质是个分类任务分类任务对模型规模的要求没有生成任务那么高。一个小模型如果微调得当在固定动作空间上的表现可能比大模型还好。4.2 参数提取不完整怎么处理模型选了正确的动作但参数没填全比如选了query_order但没给order_id。这种情况我一般分两步处理先尝试从上下文里补全补不全再让模型重新决策。从上下文补全的逻辑可以写得很简单如果用户上一句提到了订单号就用正则提取出来填进去。如果上下文里没有就返回一个“需要补充信息”的状态让模型生成一个追问动作。def fill_missing_params(decision, context): if decision.action query_order and not decision.order_id: match re.search(r\b\d{6,}\b, context) if match: decision.order_id match.group() return decision这个正则不一定通用但思路是通用的能自动补的就自动补不能自动补的就追问不要硬猜。硬猜的后果是执行了一个错误的动作比不执行还糟糕。4.3 决策循环陷入死胡同怎么跳出Agent 决策循环有个经典问题模型反复选同一个动作或者两个动作来回跳。比如先查订单发现没发货又查订单又发现没发货无限循环。我的解法是加一个状态指纹机制。每执行一个动作就把动作 ID 和关键参数拼成一个字符串存到一个集合里。如果下一轮决策生成的指纹已经在集合里就强制中断循环转人工或者返回兜底回复。visited set() def step(decision): fingerprint f{decision.action}:{decision.order_id} if fingerprint in visited: return fallback_response() visited.add(fingerprint) return execute_decision(decision)这个机制简单但有效。我实测下来加了状态指纹之后死循环的概率从大概百分之几降到了几乎为零。4.4 常见问题速查表问题现象可能原因排查方向解决建议模型输出未知动作 ID动作注册表未同步检查注册表版本重新加载注册表增加兜底动作参数类型不匹配模型输出格式漂移检查 schema 定义在解码层加类型强制转换决策延迟高动作空间过大统计动作分布分层决策先粗后细多轮对话后决策质量下降上下文过长检查上下文窗口做上下文摘要只保留关键信息同一动作重复执行缺少状态跟踪检查循环控制逻辑引入状态指纹机制这张表是我在实际项目里慢慢攒出来的基本上覆盖了八成以上的常见问题。遇到新问题的时候先往表里对对不上再单独排查。5. 决策型 Agent 的边界与我的个人体会Jev 这种“不生成 Token 直接做决策”的思路听起来很美好但也不是万能药。我自己的体会是它最适合动作空间有限、决策频率高、对延迟敏感的场景。比如客服工单路由、游戏 NPC 行为选择、自动化运维的故障响应。这些场景里动作就那么几十个模型不需要发挥创造力只需要选对动作。反过来如果场景需要大量自然语言生成比如写文章、做翻译、生成代码那 Token 生成还是绕不开的。你不可能让模型直接输出一个“写文章”的决策 ID然后指望执行器把文章写出来。执行器没那个能力。还有一个边界是动作空间的维护成本。动作越多注册表越复杂模型选错的概率也越高。我见过一个项目动作空间膨胀到三百多个模型选动作的准确率直接掉到六成以下。后来砍到八十个准确率回到九成。所以动作空间不是越大越好该合并的合并该拆分的拆分保持在一个模型能 hold 住的范围内。最后分享一个我在实际接入时的小技巧先用传统 Token 方案跑一遍全流程把模型实际输出的决策文本收集起来做聚类分析。你会发现虽然模型每次输出的文本不一样但语义上其实就那几类。这几类就是你动作空间的雏形。用真实数据反推动作空间比拍脑袋定动作要靠谱得多。这个思路后续还可以扩展。比如把决策日志存下来定期做动作分布的漂移检测。如果某个动作的调用频率突然暴涨可能是业务变了也可能是模型出问题了。早发现早处理比等用户投诉再排查要主动得多。