Jev 如何用决策模型替代高频 LLM 调用，降低 Agent 成本

Agent 开发这两年有个很明显的现象：大家把越来越多的精力花在“怎么让 LLM 多调几次工具”上，而不是“怎么把这件事真正做完”。一个任务拆成七八轮对话，每轮都要把上下文重新塞一遍，token 烧得飞快，延迟一层层叠加，最后还未必稳定。Jev 这波突然被讨论起来，本质上就是冲着这个痛点去的——它想做的事情很直接：把 Agent 里那些高频、重复、模式固定的 LLM 调用，尽量从“每次都要问模型”变成“用决策模型直接判”。

我第一次看到 Jev 相关的讨论时，第一反应不是“又一个 Agent 框架”，而是“终于有人认真对待调用成本这件事了”。因为只要你真正在生产环境跑过 Agent，就会知道最贵的从来不是那一次两次的复杂推理，而是那些每天都在重复发生的琐碎判断：这一步该不该调工具、调哪个、参数怎么填、要不要重试、要不要终止。这些判断单个看起来简单，但量大到一定程度，LLM 调用就成了整个系统里最不划算的一环。Jev 想干的，就是把这些判断交给一个更轻、更快、更可控的决策层。

1. Jev 到底想解决 Agent 里的什么问题

1.1 先搞清楚 Agent 里 LLM 调用为什么“过量”

要理解 Jev 的价值，得先看清楚一个典型 Agent 的调用结构。假设你做一个“自动整理资料并生成报告”的 Agent，流程大概是：理解用户意图、规划步骤、选择工具、执行工具、判断结果是否可用、决定下一步、生成最终输出。这里面真正需要“大模型深度思考”的，其实只有意图理解和最终生成这两步。中间那一大串“选哪个工具”“参数对不对”“要不要再来一次”，本质上都是分类和决策问题，而不是生成问题。

但现实里很多 Agent 框架是怎么做的？全部丢给 LLM。每一步都发一次请求，每次都把系统提示、历史对话、工具列表、当前状态重新打包。结果就是：一个本来三步能完成的任务，硬生生走了十几轮 LLM 调用。我实测过一个中等复杂度的任务，光是“判断工具返回结果是否有效”这一项，就占了总调用次数的四成以上。这些调用里，绝大多数答案其实是高度重复的——同样的输入模式，模型给出的判断几乎一模一样。

注意：调用次数多不只是钱的问题。每一次 LLM 调用都引入一次网络往返和一次不确定性，调用链越长，整体失败率和延迟抖动就越难控制。

1.2 Jev 的核心思路：用决策模型替代高频 LLM 判断

Jev 的思路可以概括成一句话：把 Agent 执行过程中那些“模式固定、答案收敛”的判断，从 LLM 手里拿走，交给一个专门的决策模型（Decision Model）来处理。这个决策模型不负责生成自然语言，它只负责做选择——选工具、选分支、选是否继续。因为任务变窄了，模型就可以做得非常小、非常快，而且输出是结构化的，不需要解析自由文本。

这里有个关键概念叫 RLCD，也就是把决策过程拆成可复用、可组合的规则化组件。你可以把它理解成给 Agent 装了一套“条件反射”：遇到某种状态，直接触发对应动作，不用每次都回到大脑皮层重新思考。LLM 只在真正需要创造力和开放推理的时候才被唤醒。这样一来，Agent 的调用结构就从“每步都问大模型”变成了“大部分步骤走决策层，少数步骤走 LLM”。

我个人的判断是，这个方向之所以现在火，是因为大家终于算明白了账。早期 Agent 拼的是“能不能跑通”，现在拼的是“跑得划不划算”。当一个 Agent 每天要处理上万次任务时，哪怕每次省下几百毫秒和几千 token，累积起来都是非常可观的数字。

1.3 它适合谁，不适合谁

Jev 这套东西不是万能药。它最适合的是那些流程相对稳定、判断模式可枚举的 Agent 场景，比如客服工单流转、数据采集清洗、固定业务流程的自动化。这些场景里，大部分决策是可以提前定义清楚的，LLM 只需要处理边界情况。

反过来，如果你的 Agent 本身就是高度开放、每次任务都完全不同的探索型应用，那 Jev 能帮你的地方就有限。因为决策模型的前提是“模式可复用”，如果根本没有稳定模式，那还是得靠 LLM 现场推理。所以别一上来就想着全盘替换，先分析你的调用日志，看看哪些调用是重复的、可预测的，那才是 Jev 的用武之地。

2. 拆解 Jev 的核心机制与关键概念

2.1 Decision Model 和 LLM 的分工边界

Jev 最核心的设计，是把 Agent 的执行拆成两层：决策层和执行层。决策层由 Decision Model 负责，处理的是“下一步做什么”；执行层由 LLM 和工具负责，处理的是“具体怎么做”。这个分工听起来简单，但边界划在哪里非常讲究。

划得太宽，决策模型扛不住复杂情况，还是得频繁回退到 LLM；划得太窄，LLM 调用没减下来多少，等于白做。我的经验是，判断一个决策能不能交给 Decision Model，看三个条件：第一，输入状态是否可以用有限字段描述；第二，输出是否是有限选项之一；第三，同样的输入是否应该得到稳定的输出。三条都满足，就可以下沉到决策层。

举个例子，“用户这句话是咨询还是投诉”可以交给决策模型，因为它是分类问题；“根据用户投诉内容写一封安抚邮件”就得交给 LLM，因为它是生成问题。把这两类混在一起处理，就是很多 Agent 又慢又贵的根源。

2.2 RLCD 是怎么把决策变成可复用组件的

RLCD 这套机制的价值在于“复用”。传统 Agent 里，每个判断都是临时拼 prompt，判断逻辑散落在各个节点里，改一处要动全身。RLCD 把这些判断抽象成独立的决策组件，每个组件有明确的输入输出契约，可以单独测试、单独替换、单独优化。

这有点像后端的微服务拆分：以前是一个大单体，所有逻辑搅在一起；现在拆成一个个小服务，各管一摊。好处是显而易见的——某个决策组件表现不好，你可以单独调它，不用重跑整个 Agent。而且因为组件是结构化的，你可以给它们写单元测试，这在纯 LLM 的 Agent 里几乎做不到。

提示：拆分决策组件时，建议按“决策类型”而不是“业务步骤”来分。比如“工具选择”“结果校验”“重试判断”各成一个组件，这样跨业务也能复用。

2.3 为什么决策模型能做到又小又快

决策模型之所以能小，是因为它不需要理解语言的细微含义，只需要在给定特征下做分类。输入被压缩成结构化字段，输出是枚举值，整个模型的参数量可以比通用 LLM 小好几个数量级。小带来的直接好处就是快——本地推理甚至能在毫秒级完成，完全不需要网络往返。

这里有个容易被忽略的点：决策模型的稳定性远高于 LLM。LLM 有个毛病，同样的输入稍微变个措辞，输出就可能飘。而决策模型因为输入是结构化的，只要字段值一样，输出就一样。对于需要严格可控的生产系统来说，这种确定性比“偶尔更聪明”重要得多。

3. 把 Jev 接进现有 Agent 的实操路径

3.1 第一步：先摸清你的调用分布

别急着改代码。第一步应该是把你现有 Agent 的 LLM 调用日志拉出来，做一次统计。重点看三个维度：调用类型分布、重复率、单次调用的平均 token 消耗。我一般会按“决策类”和“生成类”给每次调用打标签，然后看决策类占比多少。

实测下来，很多 Agent 的决策类调用占比能到六成以上，其中又有相当一部分是高度重复的。这部分就是 Jev 的切入点。你可以先挑重复率最高、逻辑最简单的那一类决策做试点，跑通了再逐步扩大范围。

3.2 第二步：定义决策组件的输入输出契约

确定要下沉哪类决策后，接下来是定义契约。这一步是整个接入过程中最关键的，因为契约定得不好，后面全是坑。输入字段要尽量精简，只保留真正影响决策的字段，多余的字段只会增加噪声。输出必须是有限枚举，不能是自由文本。

我踩过的一个坑是：一开始把太多上下文塞进决策组件，想着“信息多一点判断更准”。结果发现字段一多，决策模型反而容易抓不住重点，准确率还不如精简版。后来我把输入字段从二十多个砍到八个，准确率反而上去了。所以别贪多，先定义最小必要字段集。

3.3 第三步：灰度替换与效果对比

契约定好后，不要一次性全量替换。正确做法是灰度：让决策组件和原来的 LLM 判断并行跑一段时间，对比两者的输出。如果一致率高，就逐步把流量切到决策组件；如果某些场景一致率低，就保留 LLM 兜底。

这个灰度过程还有个额外好处：你能顺便收集到决策组件的边界情况。哪些输入它处理不好，一目了然。这些边界情况要么补充规则，要么明确回退给 LLM。我一般会设一个一致率阈值，比如 95%，低于这个值的场景就不下沉，避免为了省调用而牺牲效果。

4. 实际落地中会遇到的问题与排查

4.1 决策模型“看起来对但实际错”的隐蔽问题

决策模型有个比 LLM 更危险的地方：它错得很安静。LLM 输出错了，你一眼能看出来，因为文本读起来就不对。但决策模型输出的是一个枚举值，错了也不显眼，可能要到下游出问题才暴露。所以对决策组件，监控必须做得更细。

我的做法是给每个决策组件记录输入特征和输出分布，一旦某个输出的占比突然异常，就报警。比如“重试”这个决策平时占比 5%，某天突然涨到 30%，那大概率是上游输入出了问题。这种基于分布的监控，比单纯看准确率更能提前发现问题。

4.2 回退机制没设计好导致的连锁失败

很多人做下沉时只想着“决策模型处理大部分情况”，忘了设计回退。结果遇到决策模型没见过的输入，它硬给一个答案，下游就崩了。回退机制的核心是：决策模型要能表达“我不确定”，然后把控制权交回 LLM。

具体实现上，可以给决策模型加一个置信度输出，低于阈值就走 LLM。或者更简单，定义一组“已知输入模式”，不在模式内的直接回退。别小看这个设计，它决定了你的系统是“优雅降级”还是“直接崩盘”。

4.3 常见问题速查表

注意：回退率是个很重要的指标。如果某个决策组件的回退率长期高于 20%，说明这个决策本身可能就不适合下沉，别硬撑。

5. 关于 Jev 这套思路的一些个人判断

5.1 它代表的是一种工程化回归

Agent 这两年有点被“堆模型能力”带偏了，好像什么问题都能靠更大的模型、更长的上下文解决。但真正做过生产系统的人都知道，能靠工程手段解决的问题，就不该交给模型。Jev 的价值不在于它多聪明，而在于它把该工程化的部分重新工程化了。

这其实是一种成熟度的体现。一个领域早期靠蛮力，中期靠优化，后期靠架构。Agent 现在正处在从蛮力往优化走的阶段，Jev 这类方案的出现是必然的。它提醒我们：不是所有判断都值得动用大模型，很多时候一个清晰的规则、一个轻量的分类器，效果更好还更便宜。

5.2 别把它当成银弹

我也见过一些人把 Jev 当成万能解药，恨不得把所有 LLM 调用都换掉。这就走极端了。决策模型擅长的是收敛性问题，遇到开放性问题它无能为力。而且决策组件的维护本身也是有成本的——你需要持续监控、持续补充样本、持续调整规则。

所以我的建议是：把 Jev 当成工具箱里的一件工具，而不是整套方案。先用它解决那些最痛、最重复、最稳定的判断，把收益拿到手。至于那些复杂的、开放的、变化快的部分，老老实实交给 LLM。两者配合，才是合理的架构。

5.3 后续可以怎么扩展

如果你已经把基础的决策下沉跑通了，接下来可以往两个方向走。一个是决策组件的组合化，把多个小决策串成决策链，处理更复杂的流程；另一个是决策模型的持续学习，用线上数据不断优化决策准确率。这两个方向都需要一定的工程投入，但收益也是实打实的。

我自己的体会是，做这类优化最忌讳一步到位。先小范围验证，拿到数据再决定要不要扩大。Agent 系统的复杂度很高，任何大改动都可能引入意想不到的问题。稳扎稳打，比追求一步到位靠谱得多。