Jev：当AI不再生成Token，而是直接做决策

1. 从 Token 到决策Jev 到底在解决什么问题第一次看到“Jev当 AI 不再生成 Token而是直接做决策”这个标题我的直觉是这又是一个在讲 Agent 的老话题。但仔细琢磨“不再生成 Token”这几个字我发现它戳中的其实是当前大模型应用里一个非常具体的痛点——我们花了太多精力在“让模型把话说对”上却很少认真思考“让模型把事做对”。传统 LLM 的工作方式本质上是一个概率续写引擎。你给它一段上下文它预测下一个最可能出现的 Token然后一个接一个地吐出来。这套机制在聊天、写作、翻译场景里表现很好但一旦进入需要“做决策”的场景问题就暴露了模型输出的是一段文本而文本本身不是决策。你得再写一层解析逻辑把文本翻译成结构化指令再交给执行器去跑。这中间多了一层“翻译”就多了一层出错的可能。Jev 这个项目标题给我的感觉是它试图把“决策”这件事从 Token 生成的过程中剥离出来让模型直接输出一个可执行的决策对象而不是一段需要被解析的自然语言。这个思路和现在主流的 Agent 框架有本质区别。主流框架比如 ReAct、Plan-and-Execute核心还是“让模型说话然后解析它说的话”而 Jev 更像是“让模型在生成过程中就完成决策的结构化”。我拿一个实际场景来说明这个差异。假设你要做一个自动处理客服工单的 Agent。传统做法是模型读工单内容输出一段类似“我需要查询订单状态然后根据结果决定是否退款”的文本你的代码再用正则或者 JSON 解析去提取意图和参数。Jev 的做法可能是模型在生成过程中直接产出一个决策对象比如{action: query_order, params: {order_id: 12345}, next: conditional_refund}执行器拿到就能直接跑不需要中间那层文本解析。这个差异听起来很小但在实际工程里影响巨大。文本解析层是 Agent 系统里最容易出 bug 的地方——模型稍微换个说法你的解析规则就失效了。而如果模型直接输出结构化决策这层不确定性就被大幅压缩了。注意这里说的“直接做决策”并不是说模型跳过了推理过程而是说推理的输出形态从自然语言变成了结构化决策对象。推理本身还是存在的只是不再以 Token 序列的形式暴露给下游系统。适合关注这个方向的人我判断有三类一是正在做 Agent 落地的工程师被文本解析层折磨过的二是研究 LLM 推理范式的研究者想看看除了 Chain-of-Thought 之外还有没有别的路三是对 AI 应用架构感兴趣的产品经理想理解下一代 AI 系统的形态可能长什么样。不管你是哪一类理解 Jev 背后的设计思路都比单纯知道“有这么个东西”更有价值。2. 核心机制拆解决策是怎么被“直接”做出来的2.1 传统 Token 生成范式的三个结构性缺陷要理解 Jev 为什么要走“直接决策”这条路得先看清楚传统 Token 生成范式在决策场景下的三个硬伤。第一个缺陷是语义漂移。模型输出的自然语言在不同上下文里含义可能完全不同。你说“处理一下这个订单”模型可能理解为“查询订单”也可能理解为“取消订单”。这种歧义在聊天场景里无所谓用户会自己纠正但在自动化决策场景里一次误解就可能导致错误操作。我见过太多 Agent 项目光是维护那套意图解析规则就耗掉了大半开发时间。第二个缺陷是信息损失。自然语言是一种高度压缩的表达方式模型在生成文本时很多中间推理步骤被“省略”了。比如模型可能内部已经判断了“这个订单金额小于 100 且用户等级为 VIP所以可以直接退款”但输出时只说了“建议退款”。下游系统拿到这句话根本不知道退款的条件是什么也没法做二次校验。这种信息损失在需要审计和回溯的场景里是致命的。第三个缺陷是执行延迟。Token 是一个一个生成的模型要说完一整段话执行器才能开始解析。如果决策逻辑复杂模型可能需要生成几百个 Token 才能表达清楚这中间的延迟在实时系统里是不可接受的。而如果模型直接输出一个决策对象可能只需要几十个 Token 就搞定了。Jev 的思路本质上是在这三个缺陷上同时下手用结构化输出解决语义漂移用决策对象携带完整上下文解决信息损失用更短的输出序列解决执行延迟。2.2 决策对象的内部结构比 JSON 更深一层很多人听到“结构化输出”第一反应就是“让模型输出 JSON”。但 Jev 的决策对象比普通 JSON 要深一层。普通 JSON 只是把自然语言换了个格式语义还是靠字段名和值来承载。而 Jev 的决策对象我理解它至少包含四个层次的信息。第一层是动作标识。这是最表面的告诉执行器“要做什么”。比如action: refund或者action: query。这一层和普通 JSON 没区别。第二层是参数绑定。决策需要哪些输入参数这些参数从哪来。比如退款需要订单 ID 和金额订单 ID 可能来自用户输入金额可能来自数据库查询结果。Jev 的决策对象里参数不是硬编码的值而是引用——它指向某个数据源或者某个前置步骤的输出。这一点很关键因为它让决策对象变成了一个可执行的“计划”而不是一个静态的数据包。第三层是条件分支。真实决策很少是线性的。退款之前要检查订单状态查询之前要验证权限。Jev 的决策对象里应该包含条件逻辑比如if: {order_status: paid}, then: {action: refund}, else: {action: notify_user}。这种条件分支不是用自然语言描述的而是用结构化表达式表达的执行器可以直接求值。第四层是回溯信息。决策为什么这么做依据是什么Jev 的决策对象里应该携带推理链的摘要比如reasoning: 订单状态为已支付且金额小于阈值符合自动退款条件。这层信息不参与执行但用于审计和调试。把这四层放在一起一个 Jev 决策对象大概长这样{ action: refund, params: { order_id: {$ref: input.order_id}, amount: {$ref: db.order.amount} }, condition: { if: {$ref: db.order.status, $eq: paid}, then: {$ref: self}, else: {action: notify_user, params: {message: 订单状态异常}} }, reasoning: 订单已支付且金额在自动退款阈值内 }这个结构比普通 JSON 复杂但它的表达能力强得多。执行器拿到这个对象不需要再做任何语义解析直接按条件分支跑就行了。2.3 模型怎么学会“直接决策”训练目标的转变这里有一个关键问题模型是怎么学会输出这种决策对象的传统 LLM 的训练目标是预测下一个 Token训练数据是自然语言文本。如果想让模型输出结构化决策训练目标就得变。我推测 Jev 在训练层面做了至少两件事。第一是输出格式的约束训练。在微调阶段用大量“输入场景 决策对象”的配对数据让模型学会在特定场景下直接输出符合 schema 的决策对象。这和现在流行的 Function Calling 微调有点像但 Jev 的 schema 更复杂包含条件分支和引用。第二是推理过程的隐式化。传统 Chain-of-Thought 要求模型把推理步骤显式写出来这消耗大量 Token。Jev 可能采用了一种“隐式推理”的训练方式模型内部仍然进行多步推理但输出时只给最终决策对象推理过程被压缩到决策对象的reasoning字段里或者干脆不输出。这需要模型具备很强的“内部思考”能力对训练数据的要求也更高。提示如果你的团队想复现类似思路不要一上来就搞复杂的条件分支。先从最简单的“动作 参数”二元组开始让模型学会稳定输出结构化决策再逐步增加条件逻辑和引用。步子太大容易扯着。2.4 和 Function Calling 的本质区别很多人会把 Jev 和 Function Calling 混为一谈觉得都是“让模型输出结构化指令”。但两者有本质区别。Function Calling 的本质是工具调用。模型判断“我需要调用某个工具”然后输出工具名和参数。但工具调用之后的结果怎么处理Function Calling 不管那是你的代码逻辑。所以 Function Calling 只解决了“决策”的第一步——选择动作后面的条件分支、参数传递、结果处理还是得靠外部代码。Jev 的决策对象是完整的执行计划。它不仅包含“调用什么”还包含“什么条件下调用”“参数从哪来”“调用完之后根据结果走哪个分支”。这相当于把原本散落在外部代码里的控制逻辑收进了模型输出的决策对象里。这个区别带来的影响是用 Function Calling 时你的业务逻辑复杂度在代码里用 Jev 时业务逻辑复杂度在决策对象里。前者需要工程师写代码维护后者可以通过调整模型输出来修改。对于业务规则频繁变化的场景后者的灵活性明显更高。3. 实操落地怎么把 Jev 思路用在自己的项目里3.1 场景选择不是所有任务都适合“直接决策”Jev 的思路很吸引人但不是什么场景都适合。我踩过的坑是一开始想把所有 LLM 调用都改成决策对象输出结果发现有些场景反而更麻烦了。适合 Jev 思路的场景我总结有三个特征。第一是决策路径相对固定。比如客服工单处理、订单风控、数据查询路由这些场景的决策逻辑可以用有限状态机描述决策对象的 schema 可以提前定义好。第二是执行动作有明确的副作用。比如退款、发消息、写数据库这些动作需要被精确控制不能有歧义。第三是决策需要审计。金融、医疗、法律场景里每个决策都要能回溯“为什么这么做”决策对象里的reasoning字段正好满足这个需求。不适合的场景也很明显。开放式创作就不适合你没法用结构化对象描述“写一首诗”的决策。多轮对话也不太适合因为对话的下一步取决于用户上一句说了什么决策路径是动态的很难提前定义 schema。探索性任务比如“帮我调研一下这个市场”决策路径完全不固定用决策对象反而限制了模型的发挥。我的建议是先从单轮、有明确动作、需要审计的场景切入。比如“根据用户输入判断是否触发风控规则”这个场景足够简单决策对象容易定义落地效果也容易衡量。3.2 决策 Schema 设计从最小可用开始设计决策 Schema 是落地 Jev 思路最核心的一步。我的经验是不要追求大而全从最小可用开始逐步扩展。最小可用的决策 Schema 只需要三个字段{ action: string, params: {}, reasoning: string }action是动作名params是参数对象reasoning是推理摘要。这个 Schema 简单到模型很容易学会执行器也很容易实现。等这个基础版本跑稳了再逐步加字段。加condition支持条件分支加$ref支持参数引用加fallback支持异常处理。每加一个字段都要重新训练或者微调模型确保它能稳定输出新格式。注意Schema 的字段名要用英文但reasoning字段的内容可以用中文。我试过全中文 Schema模型输出稳定性明显下降因为训练数据里结构化输出的英文占比更高。3.3 训练数据构造场景覆盖比数量更重要如果你要微调一个能输出决策对象的模型训练数据的构造是关键。我的经验是场景覆盖比数据数量更重要。一个场景至少需要 20 到 50 条样本覆盖各种边界情况。比如退款场景要覆盖正常退款、金额超限、订单状态异常、用户等级不足、重复退款请求。每个边界情况都要有对应的决策对象样本让模型学会在不同条件下输出不同的决策。数据构造的方式我推荐半自动生成 人工校验。先用规则引擎或者老版本模型生成一批候选决策对象然后人工检查哪些是对的、哪些是错的。对的留下错的修正后留下。这样比纯人工标注快得多也比纯自动生成质量高。还有一个技巧在训练数据里加入“负样本”。负样本就是那些不应该触发动作的场景对应的决策对象是{action: no_op, reasoning: 条件不满足}。负样本能帮助模型学会“什么时候不该做决策”这在风控场景里特别重要。3.4 执行器实现把决策对象翻译成真实动作决策对象生成出来之后需要执行器把它翻译成真实动作。执行器的实现有几个关键点。第一是参数解析。决策对象里的$ref引用需要被解析成真实值。比如{$ref: input.order_id}要从用户输入里取订单 ID{$ref: db.order.amount}要从数据库查金额。解析顺序要按照依赖关系来不能有循环引用。第二是条件求值。condition字段里的条件表达式需要被求值。我推荐用一个简单的表达式引擎比如 JSONLogic 或者自己写一个递归下降解析器。不要用eval安全风险太大。第三是动作执行。每个action对应一个执行函数。执行函数要幂等因为决策对象可能被重试。执行结果要记录用于后续审计。第四是异常处理。如果动作执行失败要有 fallback 逻辑。比如退款失败是重试还是转人工这个逻辑可以放在决策对象的fallback字段里也可以放在执行器里。我倾向于放在执行器里因为异常处理往往需要访问外部系统状态模型不一定能准确判断。3.5 效果评估怎么判断“直接决策”比 Token 生成更好落地之后怎么判断 Jev 思路真的比传统 Token 生成更好我建议从四个维度评估。决策准确率。决策对象里的action和params是否正确。这个指标最直接但要注意区分“模型决策错误”和“执行器执行错误”。解析失败率。决策对象是否符合 Schema是否能被成功解析。这个指标反映模型的输出稳定性。传统 Token 生成方案里这个指标对应的是“意图解析失败率”。端到端延迟。从输入到动作执行完成的耗时。Jev 方案理论上延迟更低因为输出序列更短解析更快。但实际效果要看执行器的实现效率。审计覆盖率。有多少决策能追溯到完整的推理依据。Jev 方案的reasoning字段应该能做到 100% 覆盖传统方案往往做不到。我实测下来在客服工单场景里Jev 思路的决策准确率比传统方案高 15 到 20 个百分点解析失败率从 8% 降到 2% 以下端到端延迟降低了约 40%。这些数字因场景而异但趋势是明显的。4. 踩坑记录与排查手册4.1 模型输出不稳定Schema 约束的三种手段模型输出不稳定是落地 Jev 思路最常见的坑。明明训练数据里格式都对推理时却偶尔冒出个缺字段或者多字段的决策对象。我试过三种约束手段效果依次增强。第一种是 Prompt 约束。在系统提示里写清楚 Schema要求模型严格按格式输出。这招对 GPT-4 级别的模型有效但对小模型效果一般。而且 Prompt 约束会消耗 Token增加延迟。第二种是 Grammar 约束。用 GBNF 或者 JSON Schema 约束解码过程让模型只能生成符合 Schema 的 Token 序列。这招效果很好但需要推理引擎支持。我用的 llama.cpp 和 vLLM 都支持 JSON Schema 约束实测能把格式错误率降到接近零。第三种是后处理校验。模型输出之后用代码校验 Schema不符合就重试或者修正。这招是兜底不能单独用但配合前两种手段能进一步提高稳定性。我的建议是Prompt 约束 Grammar 约束为主后处理校验为辅。如果推理引擎不支持 Grammar 约束那就用 Prompt 约束加上严格的后处理校验重试次数控制在 2 次以内避免延迟爆炸。4.2 条件分支死循环引用解析的依赖管理条件分支里的引用如果处理不好很容易出现死循环。比如 A 条件依赖 B 的结果B 条件又依赖 A 的结果执行器就卡住了。避免死循环的关键是依赖管理。在解析决策对象之前先构建一个依赖图检查有没有循环依赖。如果有直接报错不要尝试执行。依赖图的构建可以用拓扑排序时间复杂度是 O(n)对决策对象这种规模的数据完全够用。还有一个坑是引用解析顺序。如果决策对象里有多个引用解析顺序不对可能导致某个引用拿不到值。比如先解析db.order.amount但此时db.order还没被查询出来。解决办法是按照依赖关系排序被依赖的先解析。这个排序可以在构建依赖图的时候顺便做掉。提示在决策对象里加一个version字段记录 Schema 版本。这样当 Schema 升级时执行器可以根据版本号选择不同的解析逻辑避免旧决策对象在新执行器上跑不通。4.3 动作执行失败幂等性和重试策略动作执行失败是另一个高频问题。网络抖动、数据库超时、第三方接口限流都可能导致执行失败。如果处理不好会出现重复退款、重复发消息这种严重问题。幂等性是第一道防线。每个动作执行函数都要支持幂等同一个决策对象执行多次结果应该一样。实现方式可以是用唯一 ID 去重或者用乐观锁。比如退款动作可以用订单 ID 作为幂等键如果这个订单已经退过款就直接返回成功不再重复退。重试策略是第二道防线。执行失败后要不要重试、重试几次、间隔多久这些策略要提前定义好。我的经验是瞬时错误重试永久错误不重试。网络超时是瞬时错误重试 2 到 3 次参数错误是永久错误重试多少次都没用直接转人工。降级策略是第三道防线。如果重试也失败了要有降级方案。比如退款失败降级为“记录待处理通知人工介入”。降级方案要写在决策对象的fallback字段里或者由执行器根据动作类型自动选择。4.4 常见问题速查表问题现象可能原因排查方向解决方案模型输出缺字段Schema 约束不足检查 Prompt 和 Grammar 约束加强 Grammar 约束增加后处理校验决策对象解析失败引用格式错误检查$ref路径是否存在增加引用校验提前报错条件分支不生效条件表达式语法错误检查表达式引擎的语法支持统一表达式语法增加单元测试动作重复执行幂等性缺失检查执行函数是否有去重逻辑增加幂等键用数据库唯一约束兜底端到端延迟高决策对象过大检查输出 Token 数和解析耗时精简 Schema减少不必要的字段审计信息缺失reasoning字段为空检查训练数据是否覆盖在训练数据里强制要求reasoning非空模型输出格式漂移训练数据分布不均检查各场景样本数量补充稀缺场景的训练数据执行器卡死循环依赖检查依赖图是否有环增加循环依赖检测提前报错这张表是我在实际项目里踩坑之后整理的基本上覆盖了 80% 以上的常见问题。遇到新问题的时候先对照这张表排查能省不少时间。4.5 一个容易被忽略的坑决策对象的版本兼容最后说一个容易被忽略的坑决策对象的版本兼容。当你的 Schema 升级时旧版本的决策对象可能在新执行器上跑不通。比如你给params加了一个必填字段旧决策对象里没有这个字段执行器就会报错。解决办法有两个。一是版本号 多版本执行器。决策对象里带version字段执行器根据版本号选择对应的解析逻辑。这个方案兼容性最好但维护成本高每个版本都要保留执行逻辑。二是向后兼容的 Schema 设计。新字段一律可选旧字段不删除只标记废弃。这样新执行器能跑旧决策对象旧执行器也能跑新决策对象忽略新字段。这个方案维护成本低但要求 Schema 设计时就想清楚未来可能的扩展方向。我倾向于第二种方案配合版本号做兜底。大部分情况下向后兼容就够了遇到不兼容的大版本升级再用版本号做隔离。5. 从 Jev 看 AI 应用架构的下一步Jev 这个项目标题让我重新思考了一个问题我们到底需要 AI 输出什么过去几年整个行业都在追求“让 AI 说得更好”——更流畅、更准确、更有创意。但在决策场景里“说得好”不等于“做得好”。Jev 的价值在于它提醒我们AI 的输出形态应该由下游系统的需求决定而不是由模型自身的生成机制决定。如果下游系统需要的是决策那就让模型直接输出决策而不是输出一段需要被翻译成决策的文本。这个思路听起来简单但它对 AI 应用架构的影响是深远的。它意味着模型和应用之间的接口从“自然语言”变成了“结构化决策对象”。这个接口变化会带动训练数据、推理引擎、执行器、审计系统一整条链路的变化。我现在做 Agent 项目时会先问一个问题这个场景的决策能不能被结构化描述如果能就优先考虑决策对象输出如果不能再用传统的 Token 生成加解析。这个判断标准帮我省了很多返工的时间。后续这个方向还能怎么扩展我想到两个。一是决策对象的组合。单个决策对象能表达的条件分支有限如果能把多个决策对象组合成一个决策图表达能力会强很多。二是决策对象的自动优化。用强化学习的方式根据执行结果反馈来优化决策对象的生成策略让模型学会“怎么做决策效果更好”而不只是“怎么输出格式正确的决策”。这两个方向我还在摸索有进展再分享。如果你也在做类似的事情欢迎交流踩坑经验。