Jev 决策模型：砍掉 Agent 中 70% 的 LLM 调用

Agent 开发这两年有个很明显的趋势大家把越来越多的决策权塞给了 LLM。一个请求进来先让模型判断意图再让模型选工具工具返回结果后再让模型决定下一步循环往复直到任务完成。这套模式跑 demo 的时候很惊艳一旦上生产、并发上来、任务链路拉长账单和延迟就开始教做人了。最近圈子里讨论度很高的 Jev切入的正是这个痛点——它想做的事情很直接把 Agent 执行链路里那些本不该由 LLM 来做的调用砍掉换成一个专门的决策模型来接管。这篇文章我就围绕 Jev 这个方向把它的核心思路、为什么现在火、和现有 Agent 框架怎么配合、实际接入要注意什么完整拆一遍。不管你是刚接触 Agent 开发还是已经在线上跑着 LLM 驱动的智能体应该都能从中拿到一些能直接用的东西。1. Agent 里那些被浪费掉的 LLM 调用1.1 一个典型 Agent 循环到底在烧什么先把账算清楚。一个标准的 ReAct 风格 Agent处理一次用户请求大致是这样的系统提示词 历史对话 可用工具列表拼成一个巨大的 prompt发给 LLM模型返回一段文本里面包含我要调用哪个工具、参数是什么框架解析出来执行工具把工具结果再拼回上下文再次调用 LLM如此循环直到模型输出最终答案。问题在于这个循环里真正需要大模型级别智能的环节其实很少。大部分调用干的是这些活判断用户这句话属于哪一类意图、从一堆工具里挑一个、把自然语言参数格式化成 JSON、判断上一步的结果算不算成功、决定是继续还是收尾。这些任务有个共同特点——它们是分类、路由、格式化、状态判断而不是开放域推理。用参数量几十亿甚至上百亿的通用大模型来做这些就像请一个博士去前台做访客登记能力严重过剩成本却实打实地按 token 计费。我实测过一个中等复杂度的客服 Agent单次会话平均触发 7 到 9 次 LLM 调用其中只有 1 到 2 次是真正需要模型做复杂推理的比如理解模糊需求、生成有温度的回答剩下 6 到 7 次全是路由和判断。这意味着超过 70% 的调用成本花在了本可以用更轻量方案解决的事情上。延迟同理每次调用哪怕只花 800 毫秒累积起来就是好几秒用户体感就是这 AI 怎么这么慢。1.2 为什么大家一直没动手砍不是没人想到这个问题而是砍起来有顾虑。最直接的顾虑是准确性。用规则或者小模型做路由一旦判断错了整个任务链路就跑偏而且错误会沿着循环放大。相比之下让大模型每次都重新判断一遍虽然贵但容错性看起来更好——它每次都能看到完整上下文理论上不会记错。第二个顾虑是维护成本。写规则路由意味着每加一个工具、每改一次业务逻辑都要同步改规则规则一多就变成意大利面。而纯 LLM 方案的好处是改提示词就行灵活。第三个顾虑是工程复杂度引入一个额外的决策模型意味着多一套模型部署、多一套版本管理、多一套监控很多团队觉得不划算。Jev 这类方案的价值恰恰在于它试图同时解决这三个顾虑用一个专门训练的决策模型把准确性做到接近甚至超过通用大模型的路由水平同时把部署和接入做得足够轻让多引入一套东西的成本降到可接受。这就是它为什么在这个时间点被讨论——不是概念新而是工程上终于变得划算了。1.3 决策模型和通用 LLM 的分工边界这里要澄清一个容易混淆的点Jev 不是要干掉 LLM而是要重新划分 LLM 和决策模型的职责边界。通用 LLM 擅长的是开放域理解、生成、复杂推理决策模型擅长的是在有限、明确、结构化的动作空间里做选择。前者是什么都懂一点的通才后者是只干一件事但干得很准的专才。一个健康的 Agent 架构应该是这样的用户输入进来先由决策模型判断意图和下一步动作要不要调工具、调哪个、参数大概是什么需要真正生成内容或者处理模糊语义的时候才把控制权交给通用 LLM。工具执行完结果回给决策模型判断是否达成目标达成则收尾没达成则继续决策。LLM 从每一步都要参与变成只在关键节点被召唤调用次数能砍掉一大半。这个分工听起来简单但落地时的关键问题是决策模型的动作空间怎么定义它怎么知道当前有哪些工具可用它怎么处理多轮状态这些正是 Jev 这类方案需要回答的核心工程问题也是后面几节要展开的重点。2. Jev 把决策从 LLM 手里拿走的底层逻辑2.1 决策模型到底在决策什么要理解 Jev先得把决策这个词拆开。在 Agent 语境下一次决策通常包含四个子问题当前处于什么状态用户想干嘛、任务进行到哪一步、有哪些可选动作可用工具集合、每个工具的前置条件、选哪个动作在候选里挑最优、动作参数是什么把意图转成结构化输入。通用 LLM 是把这四个子问题揉在一个 prompt 里一次性回答靠的是它庞大的参数里隐含的世界知识和指令遵循能力。决策模型的做法是把这个问题形式化状态用特征向量表示动作空间用结构化 schema 描述选择过程变成一个分类或者排序问题参数生成变成一个受约束的序列生成问题。一旦形式化就可以用更小的模型、更针对性的训练数据来专门优化。打个比方通用 LLM 像一个经验丰富但什么都管的项目经理每次开会都要他把所有事重新捋一遍决策模型像一个专职的调度员手里有一张实时更新的任务看板只看下一步该谁上反应快、不啰嗦。Jev 想做的就是把调度员这个角色独立出来让项目经理只在真正需要拍板大事的时候出场。2.2 为什么是现在火三个条件同时成熟一个技术方向突然被讨论通常不是因为它新而是因为它需要的几个前置条件刚好都到位了。Jev 这个方向我觉得是三个条件同时成熟。第一是成本压力到了临界点。前两年大家做 Agent 还在探索阶段跑通比省钱重要。现在很多团队已经把 Agent 推到了真实业务里token 账单从研发成本变成了运营成本每个月真金白银地出优化动力完全不一样了。当单次会话的 LLM 调用从 3 次涨到 10 次成本曲线是陡的这时候任何能砍调用的方案都会被认真评估。第二是小模型和专用模型的能力上来了。以前用一个小模型做路由准确率惨不忍睹大家只能捏着鼻子用大模型。现在经过指令微调和针对性训练的小模型在受限动作空间里的表现已经相当能打尤其是分类和结构化输出这类任务小模型和大模型的差距远没有开放域生成那么大。第三是Agent 框架的编排能力成熟了。以前 Agent 逻辑是写死在代码里的想插一个决策层很别扭。现在主流框架都支持自定义节点、支持把执行流程拆成可编排的步骤决策模型作为一个独立节点插进去变得很自然。这三个条件叠加才让把决策独立出来从想法变成了可落地的工程实践。2.3 和 RLCD、Decision Model 这些概念的关系热词里出现了 RLCD 和 Decision Model这里顺带理一下它们和 Jev 的关系。Decision Model 是这类方案的统称指专门用于做决策的模型Jev 可以理解为这个方向下的一个具体实现或者一套方法论。RLCD 通常指用强化学习或者对比学习的方式来训练决策能力——核心思路是让模型在大量状态-动作-结果的样本里学习什么样的决策能带来好结果而不是单纯模仿人类标注的下一步动作。这个训练范式的意义在于决策质量是可以被结果反馈优化的。传统做法是人工标注这种情况下应该调工具 A但人工标注覆盖不了所有情况而且标注标准本身可能不一致。用结果反馈来训练模型能学到一些人类没显式标注但确实有效的决策模式。当然这也带来新的工程挑战——怎么定义奖励、怎么构造训练环境、怎么避免模型学到投机取巧的策略这些是真正落地时要啃的硬骨头。3. 把 Jev 接进现有 Agent 框架的实操路径3.1 接入前先想清楚哪些调用该交给决策模型不是所有 LLM 调用都值得替换。我的经验是先用一个简单的判断标准过一遍这个调用如果换成从 N 个固定选项里选一个准确率能接受吗如果能就适合交给决策模型如果这个调用需要生成自由文本、需要理解高度模糊的语义、需要跨领域知识推理那就留给通用 LLM。具体到常见的 Agent 环节我整理了一张对照表可以直接拿来评估自己的项目Agent 环节是否适合决策模型原因意图分类非常适合本质是有限类别分类工具选择非常适合动作空间明确可枚举参数抽取与格式化适合结构化输出约束明确多轮状态判断适合状态机式判断结果成功/失败判定适合二分类或小范围分类最终答案生成不适合需要开放域生成模糊需求澄清不适合需要理解隐含语义复杂多步规划谨慎取决于动作空间是否封闭这张表不是绝对的但能帮你快速定位优化点。一般来说一个 Agent 里 60% 到 80% 的调用都属于适合这一档这就是可优化的空间。3.2 动作空间的定义决策模型能不能用好的关键决策模型的效果八成取决于动作空间定义得好不好。动作空间就是决策模型可以选的所有动作的集合包括工具名、参数 schema、前置条件、后置效果。定义得越清晰、越结构化决策模型越容易学准。我踩过的一个坑是一开始把动作空间定义得太粗一个工具叫处理订单参数是一个自由文本。结果决策模型根本学不会因为它不知道这个自由文本里该填什么。后来拆成查询订单状态取消订单修改收货地址三个独立动作每个动作的参数都是明确字段准确率立刻上来了。动作空间要拆到每个动作的语义单一、参数可枚举的程度这是硬要求。另一个要点是给每个动作写清楚前置条件和后置效果。比如取消订单的前置条件是订单状态为待发货后置效果是订单状态变为已取消。这些信息喂给决策模型它才能判断当前状态下这个动作是否可执行。很多团队只给工具名和参数不给条件和效果决策模型就只能靠猜效果自然差。3.3 一个可复用的接入骨架下面给一个接入骨架用伪代码表示你可以按自己用的框架翻译过去。核心思路是把 Agent 循环拆成决策节点和执行节点两类决策节点走决策模型执行节点走工具只有需要生成内容时才调通用 LLM。# 决策节点调用决策模型返回下一步动作 def decide(state, action_space): # state 包含用户输入、历史动作、当前工具返回结果 # action_space 是结构化描述的可选动作集合 decision decision_model.predict( statestate, actionsaction_space, constraintsstate.get(preconditions) ) # decision 形如 {action: query_order, params: {...}, done: False} return decision # 执行节点执行工具返回结果 def execute(decision, tools): if decision[done]: return {finished: True, result: decision.get(answer)} tool tools[decision[action]] return {finished: False, result: tool.run(**decision[params])} # 主循环 def run_agent(user_input, tools, action_space, max_steps10): state {input: user_input, history: []} for _ in range(max_steps): decision decide(state, action_space) outcome execute(decision, tools) state[history].append({decision: decision, outcome: outcome}) if outcome[finished]: # 只有需要生成自然语言回答时才调通用 LLM return generate_final_answer(state) return generate_final_answer(state) # 超步数兜底这个骨架的关键在于decide函数里没有通用 LLM 的参与generate_final_answer才是唯一需要大模型的地方。实际项目里decide内部可能还要处理多轮状态压缩、动作空间动态裁剪等细节但整体结构就是这样。3.4 灰度上线别一上来就全量替换接入决策模型最忌讳的是一刀切全量替换。我的建议是灰度分三步走。第一步影子模式决策模型和原 LLM 路由并行跑只记录决策模型的输出不真正执行对比两者的选择差异。这一步能帮你发现决策模型在哪些场景下判断和 LLM 不一致评估风险。第二步低风险场景切换挑那些判断错了也不会有严重后果的环节先切比如意图分类、结果成功判定。这些环节即使判错后面还有兜底逻辑。观察一段时间确认准确率和延迟都达标。第三步核心环节切换工具选择、参数抽取这些直接影响任务走向的环节在低风险场景验证充分后再切。切换时保留一个开关出问题能快速回滚到 LLM 路由。灰度期间一定要埋点记录决策模型的置信度低置信度的决策可以回退给 LLM 处理这样既省了大部分调用又保住了边界情况的准确性。4. 实测中绕不开的几个坑4.1 决策模型过度自信导致的错误放大决策模型有个比通用 LLM 更危险的问题它往往更自信。通用 LLM 在不确定的时候会输出模棱两可的话框架还能识别出来决策模型输出的是一个明确的动作选择哪怕它其实没把握也会给出一个确定答案。如果这个错误发生在任务早期后面所有步骤都会沿着错误方向走错误被放大。解决办法是强制决策模型输出置信度并设置回退阈值。置信度低于阈值时把决策权交回给通用 LLM。这个阈值需要根据业务容忍度调我一般从 0.7 开始试观察误判率和回退率的平衡点。另外可以在决策模型训练时加入不确定样本让它学会在信息不足时主动输出需要更多信息而不是硬猜。4.2 动作空间膨胀后的性能衰减刚开始动作空间只有十几个动作时决策模型又快又准。随着业务扩展动作涨到上百个问题就来了准确率下降、推理变慢、维护困难。这不是决策模型独有的问题但因为它承担了核心决策影响更直接。应对策略有两个方向。一是动作空间分层先让决策模型判断大类比如是查询类还是操作类再在类内选具体动作。这样每层的候选数量都可控。二是动态裁剪动作空间根据当前状态只把可能可执行的动作喂给决策模型。比如订单已经取消了那取消订单这个动作就不该出现在候选里。动态裁剪既提升准确率又降低推理开销是必做的优化。4.3 和 LLM 网关、监控体系的配合引入决策模型后你的调用链路变成了决策模型 通用 LLM混合监控体系要相应调整。原来只看 LLM 的调用量、延迟、错误率现在要分开看决策模型的调用量、决策准确率需要人工抽检或者用结果反馈、回退到 LLM 的比例、端到端任务成功率。如果团队已经有 LLM 网关决策模型的调用最好也走网关统一做限流、鉴权、日志。这样出问题时能在一个地方看到全链路。我见过一些团队把决策模型单独部署、单独监控结果排查问题时要在两套系统之间来回切效率很低。统一入口、统一监控这个原则在混合架构下更重要。4.4 密钥管理和接入安全热词里出现了jev密钥jev怎么接入这类问题说明很多人在关心接入细节。这里给几条通用原则不针对具体产品。第一密钥绝不硬编码在代码里用环境变量或者密钥管理服务这是底线。第二决策模型的调用要有独立的鉴权和配额不要和通用 LLM 共用一个密钥否则一个出问题会互相影响。第三决策日志要脱敏决策过程里可能包含用户敏感信息记录时要过滤。第四接入前确认数据流向决策模型是本地部署还是远程调用数据会不会出你的边界这直接关系到合规。5. 这套思路适合什么样的团队和场景5.1 什么时候值得引入决策模型不是所有 Agent 项目都需要 Jev 这类方案。判断标准很简单算一下你的 LLM 调用成本里有多大比例花在了路由和判断上。如果这个比例低于 30%引入决策模型的收益可能覆盖不了工程成本先别折腾。如果超过 50%而且调用量还在涨那就值得认真评估。另一个维度是任务链路的长度。单轮问答型 Agent本来就没几次调用优化空间有限。多轮、多工具、长链路的 Agent每次会话动辄七八次调用优化收益才明显。还有延迟敏感度如果用户对响应速度很敏感砍掉几次 LLM 调用带来的延迟下降体验提升是立竿见影的。5.2 小团队怎么低成本试水小团队资源有限不可能一上来就训一个决策模型。我的建议是先用规则 小模型混合的方式试水。把最高频、最明确的决策场景用规则覆盖比如关键词命中直接路由剩下的用一个小参数量的模型做分类。这样不需要训练先跑起来积累决策日志。跑一段时间后你手里就有了一批状态-动作-结果的真实数据这时候再考虑用这些数据去微调一个决策模型效果会比凭空训练好得多。数据是决策模型的核心资产先跑起来攒数据比一开始就追求完美方案更实际。5.3 决策模型和 RAG、知识库怎么共存热词里还有 llm wiki、知识库、RAG 这些概念它们和决策模型不冲突是互补的。决策模型负责下一步做什么RAG 负责做这件事需要什么知识。一个典型配合是决策模型判断需要查询知识库触发 RAG 检索检索结果作为工具返回再交给决策模型判断是否足够、要不要继续检索。要注意的是别让决策模型去处理知识检索的细节。它的职责是决定要不要查、查什么方向具体检索、排序、拼接交给 RAG 模块。职责清晰两边都好维护。如果让决策模型直接生成检索 query 并处理返回结果它又变成了一个通用 LLM 的角色失去了独立决策层的意义。6. 我对这个方向的一点判断Jev 火起来本质上反映的是 Agent 开发从能跑就行进入要算账的阶段。前两年大家拼的是谁的 Agent 更聪明、能处理更复杂的任务现在拼的是谁的 Agent 更便宜、更快、更稳。这个转变是必然的任何技术从实验室走向生产都会经历这一步。决策模型这个方向我觉得会持续演进但形态可能会变。现在大家讨论的是独立一个决策模型未来更可能是决策能力被内化到 Agent 框架里变成框架的一个标准组件开发者不用关心底层是规则、小模型还是别的什么只配置动作空间和策略就行。到那时候Jev可能不再是一个具体的产品名而是变成一种默认的架构模式。对开发者来说现在值得做的不是急着选某个具体方案而是先把自己的 Agent 调用链路拆清楚搞清楚哪些调用是必要的、哪些是可以优化的。这个认知比用哪个工具重要得多。工具会变但把决策和生成分开这个思路我觉得会长期成立。我自己在项目里已经开始按这个思路重构哪怕暂时不用专门的决策模型光是理清职责边界代码的可维护性和成本表现就已经有改善了。