1. 从一次线上事故说起为什么大家都在聊 Jev上个月我们团队的一个 Agent 项目上线第三天就出了状况。用户量不大日活也就两千出头但账单跑得比预期快了将近四倍。排查下来问题很典型一个帮我整理会议纪要并生成待办的任务Agent 在内部循环里调了 17 次 LLM——先判断意图、再决定用哪个工具、工具返回后再判断要不要继续、继续之后又判断格式对不对、格式不对再重试……每一步都是一次完整的模型调用每次调用都带着几千 token 的上下文。单次任务成本被硬生生抬到了几毛钱而用户感知到的只是点了下按钮等了八秒。这不是我们一家的问题。只要你在做 Agent几乎一定会撞上同一堵墙Agent 的智能程度和 LLM 调用次数成正比但成本和延迟也成正比。你想让它更聪明就得多问几次模型你多问几次模型账单和响应时间就一起爆炸。过去一年大家默认接受这个 trade-off直到 Jev 这类东西出现开始有人认真问一句Agent 里那些 LLM 调用是不是大部分根本没必要Jev 最近在 Agent 开发圈子里被反复提起核心主张就一句话——把 Agent 执行流程中大量重复、模式化、可判定的 LLM 调用替换成一个专门的决策模型Decision Model。它不试图干掉 LLM而是把 LLM 从每一步都要问一遍的万能顾问降级成只在真正需要创造力和开放推理时才出手的专家。中间那些该不该调工具参数填什么要不要重试结果合不合格的判断交给一个更小、更快、更便宜的决策层来做。这篇文章我想把 Jev 这件事拆开讲透。它到底解决了什么问题、背后的 RLCD 和 Decision Model 是什么思路、一个 Agent 项目怎么接入、哪些场景适合哪些不适合、踩过哪些坑。如果你正在做 Agent 开发或者被 LLM 调用成本折磨过这篇应该能帮你省下不少试错时间。2. Agent 里 LLM 调用到底浪费在哪2.1 一个典型 Agent 循环的调用解剖先别急着看 Jev我们先把浪费这件事量化。一个标准的 ReAct 风格 Agent处理一个用户请求内部大致是这样的循环接收用户输入拼上系统提示、工具描述、历史记录调一次 LLM让它输出思考 动作。解析动作如果是工具调用执行工具拿到结果。把工具结果塞回上下文再调一次 LLM判断任务完成了吗还要不要继续如果没完成回到第 1 步如果完成再调一次 LLM 生成最终回复。我拿我们那个会议纪要 Agent 实测统计过一个中等复杂度任务LLM 调用次数分布是这样的调用环节平均次数单次平均 token是否真的需要大模型意图识别与路由1800大部分不需要工具选择3.21500部分需要参数抽取与填充3.21200大部分不需要工具结果判定继续/结束4.12000大部分不需要格式校验与重试2.41800不需要最终回复生成12500需要异常兜底判断1.81600部分需要把是否真的需要大模型这一列加一下你会发现真正必须由 LLM 完成的调用占比不到三成。剩下七成本质上是在做分类、匹配、规则判定、格式检查——这些任务用一个大模型来做就像请一位博士去帮你按电梯按钮能力过剩得离谱成本却按博士的时薪算。2.2 成本、延迟、稳定性三重账浪费的不只是钱。我把它拆成三本账成本账。假设你用的是一个中等价位的模型输入 1 元/百万 token、输出 3 元/百万 token。上面那个任务总输入 token 大约 12000输出 3000单次任务成本约 0.021 元。看着不多但日活两千、人均触发五次一天就是 210 元一个月六千多。如果换成决策模型处理那七成调用成本能压到原来的三分之一甚至更低。延迟账。每次 LLM 调用网络往返加推理快的 800ms慢的 3 秒。一个任务 17 次调用串行下来光等待就十几秒。用户感知的卡八成卡在这里。决策模型因为小单次推理可以做到几十毫秒串行十几次也就一两秒。稳定性账。这是最容易被忽略的。LLM 输出是概率性的你让它判断这个工具结果算不算成功它今天说成功、明天可能说失败同样的输入给你不一样的答案。Agent 流程里只要有一个判定节点不稳定整条链路就会随机抖动。决策模型做的是确定性更强的分类任务输出分布收敛得多流程稳定性会明显提升。2.3 为什么以前没人这么干你可能会问这么明显的浪费为什么大家不早做原因有三个我觉得挺值得说清楚因为它解释了 Jev 为什么是现在火。第一以前 Agent 任务简单。早期 Agent 就是调个搜索、总结一下循环两三次就结束了浪费不明显。现在 Agent 要处理多步规划、多工具协作、长流程任务循环次数上去了浪费才被放大。第二以前没有合适的决策模型。你要替换 LLM 的判断得有一个足够小、足够准、还能理解 Agent 上下文的模型。通用的小模型要么太笨要么不懂 Agent 的语义。RLCD 这类针对决策专门训练的方法成熟才有了可用的底座。第三以前大家不敢动。Agent 流程里塞一个非 LLM 的判定模块万一判错了整条链路崩排查起来还麻烦。所以宁可多花钱买大模型的确定性幻觉。现在工具链和评测方法跟上了才有人敢动这块。3. Jev 的核心思路把判断从生成里剥出来3.1 Decision Model 到底是个什么东西Jev 最核心的概念是Decision Model决策模型。别被这个名字唬住你可以把它理解成一个专门做选择题的小模型。LLM 干的是开放生成——你给它一段话它给你一段新话答案空间是无限的。而 Agent 流程里大量的判断答案空间其实非常有限这个意图属于哪一类答案可能是 8 个类别之一。下一步该调哪个工具答案在工具列表里选。工具返回的结果算成功还是失败二分类。这个参数该填什么从上下文里抽一个实体。要不要重试要不要继续循环都是二选一或三选一。这些任务的共同点是输入是 Agent 的上下文输出是一个封闭集合里的选项。这正是分类模型最擅长的场景。Decision Model 就是针对这类任务训练的模型输入 Agent 状态输出决策标签不生成任何多余文字。Jev 的做法是在 Agent 的执行框架里插入一个决策层。每次原本要调 LLM 做判断的地方先问决策模型决策模型给出高置信度的答案就直接用置信度不够或者遇到它没见过的开放场景再回退到 LLM。这就是所谓的干掉大量 LLM 调用——不是全干掉是把那些决策模型能搞定的部分接管过来。3.2 RLCD 在中间扮演什么角色RLCD 是 Jev 用来训练决策模型的方法论全称是 Reinforcement Learning from Decision Comparison 这类思路不同资料表述略有差异但核心一致。我用大白话解释它的逻辑。传统训练分类模型你需要大量人工标注的输入-正确决策对。但 Agent 场景里什么决策是正确的很难标注——因为一个决策好不好要看它导致的后续结果。你今天决定调工具 A任务成功了但也许调工具 B 也能成功甚至更好。单看这一步你没法说 A 就是唯一正确答案。RLCD 的思路是不直接标注单步决策的对错而是比较不同决策路径的最终结果。让 Agent 用不同的决策策略跑同一个任务谁最后成功了、谁用的步数少、谁的成本低就给那条路径上的决策更高的奖励。通过大量这样的路径对比模型慢慢学会在什么状态下做什么决策长期来看更划算。这跟人类学下棋很像。没人告诉你某一步棋绝对正确但通过大量对局结果你能学到哪些走法胜率高。RLCD 就是把这种从结果反推决策质量的机制用到了 Agent 的决策模型训练上。提示RLCD 训练出来的决策模型学的是统计上更优的决策不是逻辑上绝对正确的决策。所以它一定会有判错的时候接入时必须保留回退机制这点后面会详细讲。3.3 为什么是剥出来而不是训一个更大的有人会想既然 LLM 判断不稳定那我训一个更大的、更懂 Agent 的 LLM 不就行了Jev 的路线恰恰相反它选择把判断能力从 LLM 里剥出来单独做成小模型。这个取舍背后有三个理由。理由一职责分离让每部分都能优化。生成任务和决策任务对模型的要求完全不同。生成要的是语言流畅、知识广、有创造力决策要的是快、稳、准、便宜。把它们塞进一个模型你优化任何一边都会牵制另一边。剥开之后生成模型可以专心做大做强决策模型可以专心做小做快。理由二小模型才能压住延迟和成本。决策模型参数量小可以本地部署、可以批处理、单次推理几十毫秒。这是 LLM 无论怎么优化都做不到的——你不可能让一个千亿参数模型在 50ms 内返回。理由三决策模型的行为可预测、可测试。这是工程上最值钱的一点。LLM 的输出你没法写单元测试但决策模型可以。你可以构造一千个 Agent 状态断言决策模型应该输出什么跑回归测试。Agent 流程的可靠性很大程度上取决于你能不能测试它。4. 一个 Agent 项目接入 Jev 的完整实操4.1 先做调用审计别急着接我见过太多人一听说 Jev 能省钱上来就改代码结果改完发现省的钱还不够填新引入的 bug。正确的第一步是审计你现有的 LLM 调用搞清楚哪些能替换、哪些不能。具体做法在你的 Agent 框架里给每次 LLM 调用打点记录这几个字段——调用环节名称、输入 token 数、输出 token 数、耗时、这次调用的输出是否属于封闭集合分类/选择/判定、这次调用的错误率。跑一周真实流量你会得到一张表。然后按这个标准筛输出是封闭集合的分类、选择、二值判定→ 候选替换。输出是开放文本的生成回复、写摘要、做规划→ 保留 LLM。调用频率高、单次 token 大的 → 优先替换收益最大。错误率高的 → 优先替换因为决策模型可能更稳。我们那个会议纪要 Agent 审计完17 次调用里有 11 次是候选替换对象主要集中在工具选择、参数抽取、结果判定、格式校验这四类。4.2 决策点的抽象与建模审计完下一步是把每个候选决策点抽象成一个标准的决策任务。这一步是接入成败的关键做不好后面全白搭。一个决策任务需要定义清楚四样东西输入 schema。决策模型吃什么通常是 Agent 当前状态的结构化表示——用户原始请求、当前步骤、已执行的动作历史、可用工具列表、上一步的工具返回。注意不要直接把原始的长文本塞进去要做结构化压缩。比如工具返回如果是 JSON就抽关键字段如果是长文本就截断加摘要。输出空间。决策模型能输出什么必须是一个有限集合。比如工具选择这个决策点输出空间就是工具列表加一个不调工具直接回复的选项。置信度阈值。决策模型输出每个选项的概率高于阈值才采纳低于阈值回退 LLM。阈值怎么定后面讲。回退策略。决策模型判错或低置信度时怎么办是直接调 LLM还是走一个保守的默认动作这个必须提前设计。我拿工具选择这个决策点举个例子抽象后的定义大概是这样{ decision_point: tool_selection, input_schema: { user_intent: string, 压缩后的用户意图, current_step: int, history_actions: list of {tool, params, result_summary}, available_tools: list of {name, description, param_schema} }, output_space: [tool_a, tool_b, tool_c, no_tool_direct_reply], confidence_threshold: 0.85, fallback: call_llm }4.3 置信度阈值怎么定一个可复现的计算过程阈值定太高决策模型大部分时候都不敢下判断回退 LLM等于没接定太低判错率上升流程崩。这个值不能拍脑袋得算。方法是这样拿一批标注好的历史数据或者用 LLM 跑一批作为基准让决策模型对每个样本输出概率分布。然后画一条曲线——横轴是阈值纵轴有两个采纳率决策模型敢下判断的比例和采纳后的准确率。理想情况下随着阈值升高采纳率下降、准确率上升。你要找的是那个准确率已经足够高、采纳率还没掉太狠的拐点。我实测的一组数据决策模型是本地部署的小模型任务类型是工具选择阈值采纳率采纳后准确率综合成本相对纯 LLM0.6092%81%0.420.7085%87%0.480.8074%92%0.550.8563%95%0.610.9048%97%0.700.9529%98.5%0.82看这张表0.85 是个不错的点采纳率 63%采纳后准确率 95%综合成本降到纯 LLM 的 0.61。再往上准确率提升有限但采纳率掉得快省的钱越来越少。再往下准确率掉到 90% 以下Agent 流程的失败率会明显上升。注意这个拐点跟你的任务容错率有关。如果决策判错的代价很高比如涉及资金操作阈值要往高调宁可多花钱也别判错。如果判错只是多绕一步阈值可以往低调多省点。4.4 接入代码结构一个最小可运行示例抽象完决策点接入本身其实不复杂。核心是在 Agent 循环里加一个决策路由层。下面是一个 Python 伪代码示例展示结构class DecisionRouter: def __init__(self, decision_model, llm_client, config): self.model decision_model self.llm llm_client self.config config # 每个决策点的阈值和回退策略 def decide(self, decision_point, state): cfg self.config[decision_point] # 1. 先问决策模型 probs self.model.predict(decision_point, state) best_label, best_prob max(probs.items(), keylambda x: x[1]) # 2. 高置信度直接采纳 if best_prob cfg[confidence_threshold]: return DecisionResult( labelbest_label, sourcedecision_model, confidencebest_prob ) # 3. 低置信度回退 LLM if cfg[fallback] call_llm: llm_result self.llm.decide(decision_point, state) return DecisionResult( labelllm_result.label, sourcellm_fallback, confidencellm_result.confidence ) else: return DecisionResult( labelcfg[default_action], sourcedefault, confidence1.0 )然后在 Agent 主循环里把原来直接调 LLM 的地方换成router.decide(...)def agent_loop(user_input): state init_state(user_input) while not state.done: # 原来这里直接调 LLM 判断下一步 # action llm.decide_next_action(state) # 现在走决策路由 decision router.decide(next_action, state) log_decision(decision) # 一定要打点后面分析用 state execute(decision.label, state) return generate_final_reply(state)关键点在于log_decision。每次决策都要记录来源决策模型还是 LLM 回退、置信度、最终结果。这些日志是你后续优化阈值、发现决策模型盲区的唯一依据。4.5 灰度上线与效果对比别一次性全量切。我的做法是分三步灰度第一步影子模式。决策模型照常跑但它的判断不生效只记录。同时 LLM 正常判断并生效。跑几天对比两者的一致率。如果一致率低于 80%说明决策模型还没准备好回去调。第二步小流量生效。选 5% 的流量让决策模型真正接管高置信度的判断。监控三个指标任务成功率、平均 LLM 调用次数、P95 延迟。任何一个指标恶化超过 10%立即回滚。第三步逐步放量。5% → 20% → 50% → 全量每步观察至少一天。我们那次灰度影子模式一致率 88%小流量上线后任务成功率从 94.2% 微降到 93.8%在可接受范围平均 LLM 调用次数从 17 次降到 6.3 次P95 延迟从 11.2 秒降到 4.7 秒。成本账前面算过降到原来的六成左右。5. 哪些场景适合哪些千万别碰5.1 高收益场景清单不是所有 Agent 都适合接 Jev。根据我的实践和跟同行交流下面这几类场景收益最明显多工具协作型 Agent。工具越多工具选择和参数填充的决策点越多LLM 调用浪费越严重。这类 Agent 接决策模型调用次数往往能砍掉一半以上。长流程任务型 Agent。任务步骤多、循环次数多每一步的继续/结束判定都是候选替换点。流程越长累积收益越大。高并发、成本敏感型。日调用量大哪怕单次省一点点总量也很可观。而且决策模型可以本地部署不受外部 API 限流影响。对延迟敏感型。客服、实时助手这类场景用户等不了十几秒。决策模型把串行等待压下来体验提升立竿见影。5.2 不建议接入的场景反过来这几类场景我建议你别折腾开放式创作型 Agent。写文章、做设计、头脑风暴每一步都需要创造力和开放推理没有封闭的决策空间决策模型无从下手。低频、低复杂度 Agent。一天跑几十次每次循环两三次省下的钱还不够你维护决策模型的成本。决策容错率极低的场景。涉及资金、医疗、法律等高风险判断判错代价远大于省下的成本。这类场景要么用高阈值加严格回退要么干脆别接。快速迭代期的项目。你的 Agent 流程一周改三次决策点天天变决策模型刚训好就过时了。等流程稳定了再考虑。5.3 一个判断口诀我总结了一个简单的判断口诀帮你快速决策封闭、高频、可测、容错。封闭决策输出是有限集合吗高频这个决策点调用频率高吗可测你能构造测试用例验证决策对吗容错判错了流程能兜住吗四个都满足放心接满足三个可以试满足两个以下先别动。6. 踩过的坑与排查实录6.1 决策模型看起来准用起来崩这是我们踩的第一个大坑。离线评测决策模型准确率 93%上线后 Agent 成功率反而掉了。排查发现离线评测用的是均匀采样的数据但线上流量分布极不均匀——80% 的请求集中在少数几个高频意图上决策模型在这几个高频意图上表现很好但在长尾意图上错得离谱。而恰恰是长尾意图判错后影响最大。解决办法离线评测必须按线上真实分布加权或者干脆用线上流量做影子评测。别用均匀采样的测试集自欺欺人。6.2 上下文压缩把关键信息压没了决策模型的输入要做结构化压缩但压缩是有损的。我们有一次把工具返回的长文本截断到 200 字结果决策模型判断结果是否成功时关键的错误信息恰好在 200 字之后被截掉了导致它把失败判成成功。解决办法压缩策略要针对决策点定制。判断成功/失败的决策点压缩时优先保留错误码、异常关键词、状态字段而不是简单截断。宁可多留一点 token也别把决策依据压没。6.3 回退风暴低置信度回退 LLM 是必要的但如果决策模型整体置信度偏低会出现回退风暴——大部分请求都回退不仅没省钱还多了一次决策模型推理的开销。我们遇到过一次原因是决策模型版本更新后输出概率整体偏保守置信度普遍在 0.7 以下而阈值是 0.85导致采纳率从 63% 掉到 20%。监控里表现为 LLM 调用次数不降反升。解决办法监控采纳率这个指标设置告警。采纳率突然大幅下降第一时间检查决策模型版本和阈值配置。6.4 常见问题速查表现象可能原因排查方向处理建议任务成功率下降决策模型判错率高看采纳后准确率、长尾意图表现提高阈值或补充长尾训练数据LLM 调用次数没降采纳率低、回退风暴看置信度分布、阈值配置调低阈值或重训决策模型延迟没改善决策模型推理慢看决策模型单次耗时换更小模型或本地部署优化成本反而上升决策模型开销大于节省算综合成本账缩小接入范围只接高频决策点流程随机抖动决策模型输出不稳定看同输入多次输出是否一致检查模型是否确定性推理上线后效果衰减线上分布漂移对比影子模式一致率变化定期用新数据重训决策模型6.5 几条血泪经验经验一先接一个决策点别贪多。我们一开始想一次接四个决策点结果出问题时分不清是哪个环节的锅。后来改成一次只接一个跑稳了再接下一个排查效率高很多。经验二决策日志比什么都重要。每次决策的来源、置信度、结果都要记。没有这些日志你优化决策模型就是盲人摸象。经验三给决策模型留我不知道的出口。训练时就要让它学会在不确定时输出低置信度而不是硬猜。硬猜的决策模型比没有还危险。经验四定期重训。线上流量分布会漂移用户行为会变决策模型不重训会慢慢失准。我们现在的节奏是两周一次影子评测一个月一次重训。7. 我对 Jev 这类方案的真实看法Jev 火起来本质上不是因为它发明了什么惊天动地的技术而是它把一个大家心里都清楚、但一直没人系统解决的问题摆到了台面上Agent 里的 LLM 调用大部分是浪费。Decision Model 和 RLCD 是解决这个问题的具体手段但真正有价值的是这个思路——把 Agent 的判断和生成分开让合适的模型干合适的事。我自己用下来这套东西不是银弹。它适合流程相对稳定、决策点封闭、调用量大的 Agent 项目能实打实省下成本和延迟。但它也引入了新的复杂度你要维护决策模型、要调阈值、要做灰度、要监控采纳率。如果你的项目还在快速迭代或者调用量根本不大接它反而是负担。最后分享一个我自己的判断标准当你开始为 Agent 的 LLM 账单肉疼并且能清楚说出哪几个决策点最费钱的时候就是你该考虑 Jev 这类方案的时候。如果这两个条件还不满足先把 Agent 流程跑通、把调用审计做起来比什么都强。