1. 从一次线上事故说起为什么大家都在聊 Jev上个月我们团队做了一次 Agent 系统的成本复盘结果挺扎心的。一个日均调用量在 40 万次左右的客服 Agent光 LLM 推理费用一个月就烧掉了将近六位数而其中真正需要动脑子的请求按事后抽样统计不到 18%。剩下的 82% 是什么是意图分类、参数抽取、路由判断、格式校验、简单问答、状态确认——这些活儿用一个大模型去干就像请一位资深架构师去贴发票能力过剩得离谱。这就是 Jev 突然火起来的背景。它想干的事情非常直接把 Agent 里那些高频、低复杂度、模式固定的 LLM 调用替换成一个更轻、更快、更便宜的决策模型。热搜里出现的 Jev、RLCD、Decision Model 这几个词其实指向的是同一件事——用强化学习式的决策机制去接管 Agent 编排中原本由 LLM 承担的那部分判断工作。我第一次看到 Jev 这个概念的时候第一反应是这不就是规则引擎换皮吗。但仔细看完它的思路之后我改主意了。规则引擎的问题是写死的遇到边界情况就崩而 Jev 这类 Decision Model 是从数据里学出来的它能处理模糊输入还能随着使用不断调整。它和 LLM 的关系不是替代而是分工LLM 负责开放域理解、复杂推理、长尾生成Jev 负责高频决策、快速路由、确定性判断。这篇文章适合三类人看。第一类是在做 Agent 开发、被 LLM 调用成本压得喘不过气的工程师第二类是在设计 Agent 框架与编排层、需要做架构取舍的技术负责人第三类是刚接触 agent 智能体、想搞清楚为什么不能什么都丢给大模型的入门者。我会把 Jev 的核心逻辑、RLCD 的机制、Decision Model 的落地方式以及我自己踩过的坑全部摊开讲。2. Jev 到底解决的是什么问题Agent 里的 LLM 浪费2.1 一个 Agent 请求的生命周期里LLM 被调了多少次先别急着聊 Jev 本身我们得先看清楚问题在哪。一个典型的 Agent 处理一次用户请求内部会发生什么我拿我们自己的客服 Agent 举例拆解一下调用链用户输入进来先做意图识别——调一次 LLM根据意图决定走哪条工具链做路由决策——调一次 LLM抽取工具调用需要的参数——调一次 LLM工具返回结果后判断结果是否可用、是否需要重试——调一次 LLM生成最终回复——调一次 LLM回复前做安全与格式校验——调一次 LLM一次请求六次 LLM 调用。其中第 1、2、3、4、6 步本质上都是分类问题或结构化判断问题输入输出空间是有限的、可枚举的。只有第 5 步是真正的开放域生成。我做过一个统计在我们系统里这六步的 token 消耗占比大概是意图识别 8%、路由 6%、参数抽取 15%、结果判断 10%、生成 55%、校验 6%。也就是说45% 的 token 花在了决策类任务上而这些任务的准确率要求其实并不高——意图识别做到 92% 就够用了路由做到 88% 就能跑但为了这 45% 的消耗我们付的是和生成任务一样的单价。提示你可以自己跑一遍统计把 Agent 里每一次 LLM 调用的输入输出长度、任务类型、是否可枚举输出记录下来。大部分团队做完这个统计都会发现决策类调用占比在 35% 到 55% 之间。2.2 为什么不能直接用规则或者小分类模型看到这里你可能会说那用规则引擎或者训个小 BERT 不就行了我试过都试过。规则引擎的问题在于维护成本随复杂度指数上升。我们最早用 if-else 写意图路由一开始 20 条规则很清爽三个月后变成 200 条规则之间开始互相冲突改一条崩三条。而且规则处理不了用户说了一半又改口这种模糊情况。小分类模型比如微调一个 BERT的问题是每个任务都要单独训一个模型。意图识别一个、路由一个、参数抽取一个、结果判断一个四个模型四套训练流程四份维护成本。而且这些模型之间不共享上下文路由模型不知道意图模型的置信度判断模型不知道路由走了哪条路。Jev 这类 Decision Model 的思路是用一个统一的决策模型接管所有决策类任务输入是当前 Agent 的完整状态对话历史、工具返回、中间变量输出是下一步动作。它不生成自然语言只做决策。这就把四个小模型合并成了一个而且因为共享状态决策质量反而更高。2.3 RLCD 在这里扮演什么角色热搜里的 RLCD我理解是Reinforcement Learning from Decision Comparison或者类似的决策对比学习机制。它的核心思想是不依赖人工标注每一步决策的对错而是通过对比不同决策路径的最终结果来学习。举个例子。用户问帮我查一下上个月的订单Agent 面临两个决策直接调订单查询工具还是先调用户信息工具确认身份。如果最终用户满意那这条路径上的决策就是正样本如果用户中途说不对我要查的是退款那这条路径就是负样本。RLCD 通过大量这样的路径对比让 Decision Model 学会在什么状态下该做什么决策。这比传统监督学习强在哪强在不需要标注每一步。你只需要知道最终结果好不好模型自己反推中间哪一步决策出了问题。这对 Agent 场景特别友好因为 Agent 的最终结果任务完成没完成、用户满意不满意是天然可获取的但中间每一步的标注成本极高。3. Decision Model 的核心机制拆解3.1 状态表示Agent 的当前局面怎么编码Decision Model 要做的第一件事是把 Agent 的当前状态编码成一个向量。这个状态包括什么根据我的实践至少要有这几块对话历史摘要不是原始对话是压缩后的意图序列和关键实体当前任务进度已经完成了哪些子任务还剩哪些可用工具列表及其状态哪些工具当前可用上次调用返回了什么中间变量已经抽取的参数、已经确认的信息约束条件超时限制、权限限制、格式要求这里有个坑我踩过状态表示不能太细也不能太粗。太细的话模型会被噪声干扰比如对话历史里用户的一句嗯其实不影响决策但如果编码进去模型可能会过度关注。太粗的话关键信息丢失决策质量下降。我的经验是状态向量控制在256 到 512 维比较合适。对话历史用滑动窗口加摘要的方式压缩工具状态用 one-hot 加最近一次返回的 embedding中间变量直接拼接。具体维度要根据你的任务复杂度调但别超过 1024超过之后收益递减明显。3.2 动作空间Decision Model 能做什么决策Decision Model 的输出是一个动作这个动作空间是预定义、可枚举的。常见的动作类型包括动作类型说明示例调用工具选择某个工具并传入参数调用订单查询参数 order_id123请求澄清向用户追问缺失信息追问您说的是哪个订单路由跳转切换到另一个处理流程从售前流程跳到售后流程终止结束当前任务任务完成或无法完成重试重新执行上一步工具返回超时重试降级切换到 LLM 处理决策置信度低交给大模型动作空间的设计直接决定了 Decision Model 的能力边界。我建议动作数量控制在 20 到 50 个之间。太少的话覆盖不了场景太多的话模型学不好而且每个动作的训练样本会被稀释。注意动作空间一旦确定后期修改成本很高。因为修改动作空间意味着所有历史训练数据都要重新映射。所以前期设计的时候宁可多留几个动作位也不要后期频繁增删。3.3 决策置信度与 LLM 兜底Decision Model 最关键的机制之一是置信度阈值。模型对每个动作输出一个概率分布如果最高概率超过阈值比如 0.85就直接执行如果低于阈值就把这个请求升级给 LLM 处理。这个机制是 Jev 这类方案能落地的核心。因为 Decision Model 不可能覆盖所有情况遇到没见过的、模糊的、高风险的请求必须有一个兜底。LLM 就是那个兜底。我实测下来阈值设在0.8 到 0.9之间比较合适。设太低错误决策变多设太高大量请求被升级给 LLM省不了钱。具体数值要根据你的业务容错率调金融类场景可以设到 0.92一般客服场景 0.85 就够。3.4 训练数据的来源从 LLM 日志里挖金矿Decision Model 的训练数据从哪来最实际的来源就是你现有的 LLM 调用日志。你现在的 Agent 每次调 LLM 做决策输入是什么、输出是什么、最终结果好不好这些日志里全都有。把这些日志整理成状态动作结果的三元组就是天然的训练数据。我整理数据的流程是这样的从日志里提取每次决策类 LLM 调用的输入状态和输出动作追踪这次调用之后的最终任务结果成功/失败/用户满意度用最终结果给每个决策打标签对于结果好的路径路径上的决策标为正样本结果差的标为负样本用 RLCD 的方式做对比学习这套流程不需要额外标注全部从现有日志里挖。我们大概积累了 3 个月的日志整理出 12 万条有效决策样本训出来的 Decision Model 在意图识别上做到了 94% 的准确率路由做到了 89%。4. 实操把 Jev 接入现有 Agent 的完整流程4.1 第一步盘点你的 LLM 调用找出可替换的决策点别一上来就想着全量替换。先做盘点。把你 Agent 里所有 LLM 调用列出来按这个表打分调用点输出是否可枚举调用频率单次 token 消耗准确率要求可替换优先级意图识别是8类极高低92%高路由决策是5条路极高低88%高参数抽取部分高中95%中结果判断是3类高低90%高最终生成否极高高高低安全校验是2类高低99%中优先级高的先做。我的建议是从意图识别和路由决策入手这两个任务输出空间小、频率高、容错率高最容易看到效果。4.2 第二步定义状态编码和动作空间这一步是纯设计工作但决定了后面所有事情。我拿意图识别举例。状态编码取最近 5 轮对话的摘要 embedding每轮 64 维拼接当前用户输入的 embedding128 维拼接上一轮决策的动作 one-hot16 维总共 5×6412816 464 维。动作空间8 个意图类别加上一个不确定动作共 9 个动作。置信度阈值0.85。这套配置我们跑下来意图识别的 Decision Model 推理延迟在8ms 左右CPU 上对比 LLM 的 800ms 到 2s快了两个数量级。成本更是可以忽略不计。4.3 第三步从日志生成训练数据这一步是体力活但有几个技巧。第一负样本要平衡。如果你的日志里 90% 的决策都是对的直接训会得到一个永远输出多数类的模型。我的做法是对负样本做 3 倍过采样让正负比例接近 1:1。第二要标注决策的关键性。有些决策错了无所谓有些决策错了整个任务就崩了。我在数据里加了一个权重字段关键决策的权重是普通决策的 5 倍。这样模型会优先学好关键决策。第三留出验证集。我一般留 15% 的数据做验证而且验证集要按时间切分——用前 3 个月的数据训练用第 4 个月的数据验证。这样能真实反映模型在新数据上的表现。4.4 第四步训练与调参Decision Model 本身不大我用的是一个 4 层 MLP隐藏层 512 维参数量在 200 万左右。训练在单张消费级显卡上跑 2 小时就能收敛。关键参数学习率1e-3用 cosine 衰减Batch size256优化器AdamW损失函数交叉熵 RLCD 对比损失权重 0.7:0.3训练轮数50 轮早停 patience5RLCD 对比损失的实现思路是对同一个状态下的不同决策路径让好路径的决策概率高于坏路径。具体来说取一个 batch 里的正负样本对计算它们的决策概率差用 margin loss 拉大这个差距。4.5 第五步灰度上线与置信度校准别一次性全量切。我的做法是先切 5% 的流量给 Decision Model同时 LLM 也跑一遍对比两者决策统计 Decision Model 和 LLM 决策一致的比例以及不一致时谁对谁错如果一致率超过 90%且不一致时 Decision Model 不差于 LLM扩大到 20%逐步扩大到 50%、80%、100%置信度校准也很重要。模型输出的概率往往不是真实概率需要做 Platt scaling 或者 isotonic regression 校准。校准之后阈值 0.85 才真正代表85% 的情况下这个决策是对的。5. 常见问题与排查技巧实录5.1 Decision Model 准确率上不去怎么办这是最常见的问题。我遇到过的原因和排查思路现象可能原因排查方法解决训练准确率高验证低过拟合看训练/验证 loss 曲线加 dropout、减参数量、增数据训练验证都低状态编码信息不足检查状态向量是否包含关键信息补充特征、增大维度某些类别准确率特别低样本不平衡统计各类别样本数过采样、加类别权重置信度普遍偏低校准问题画 reliability diagram做概率校准上线后效果差训练数据与线上分布不一致对比训练集和线上数据的特征分布用近期数据重新训练我踩过最大的坑是状态编码里漏了上一轮决策这个特征。结果模型不知道上一轮做了什么导致在多轮对话里反复做同一个决策。补上这个特征之后多轮场景的准确率从 76% 提到了 91%。5.2 置信度阈值怎么定才合理阈值不是拍脑袋定的要用验证集算。具体做法在验证集上跑 Decision Model得到每个样本的置信度和是否正确画一条曲线横轴是阈值纵轴是被 Decision Model 处理的请求中错误的比例找到你业务能接受的错误率对应的阈值比如你能接受 5% 的错误率那就在曲线上找错误率 5% 对应的阈值。我们业务能接受 8% 的错误率对应的阈值是 0.83。提示不同动作类型可以用不同阈值。高风险动作比如涉及金额、权限用高阈值低风险动作用低阈值。我们系统里查询类动作阈值 0.8修改类动作阈值 0.92。5.3 遇到 Decision Model 没见过的状态怎么办这是必然发生的。我的处理策略是三级兜底第一级Decision Model 置信度高于阈值直接执行。第二级置信度低于阈值但状态在训练分布内用马氏距离判断交给一个轻量 LLM比如 7B 模型处理。第三级状态在训练分布外交给完整 LLM 处理同时把这个样本记录下来加入下一轮训练数据。这套机制跑下来大概 70% 的请求走第一级25% 走第二级5% 走第三级。整体 LLM 调用量下降了 70% 以上。5.4 怎么衡量省了多少钱别只看调用次数下降要算综合账。我的计算方式是原来每次决策 LLM 调用平均消耗 800 token单价按 0.002 元/千 token 算单次成本 0.0016 元现在Decision Model 推理成本忽略不计但 30% 的请求升级给 LLM单次成本 0.00048 元节省比例70%但还要算上 Decision Model 的训练成本、维护成本、以及错误决策带来的业务损失。我们算下来综合节省在 55% 到 60% 之间。这个数字已经很可观了。6. 我对 Jev 这类方案的真实看法Jev 火起来不是偶然。Agent 开发走到今天大家都过了什么都丢给 LLM的兴奋期开始算账了。算账的结果就是LLM 应该用在它真正擅长的地方——开放域理解、复杂推理、长尾生成而不是用来做那些本来就不需要它的决策。Decision Model 加 RLCD 这套组合本质上是在 Agent 架构里加了一层快思考系统。LLM 是慢思考负责难的部分Decision Model 是快思考负责高频的部分。这跟人脑的工作方式其实很像——大部分日常决策是直觉性的、快速的只有遇到复杂问题才启动深度思考。我自己的体会是这套方案的门槛不在技术在数据。你得有足够多的历史日志才能训出可用的 Decision Model。如果你是个新项目没有历史数据那前期还是得靠 LLM 跑边跑边攒数据等数据够了再切。另外别指望 Decision Model 能覆盖所有场景。它的定位就是处理高频、模式化的决策长尾的、复杂的、高风险的该给 LLM 还是得给。把这两者的边界划清楚比追求 Decision Model 的覆盖率更重要。最后分享一个小技巧Decision Model 上线之后别停止记录 LLM 的决策。让 LLM 在后台继续跑和 Decision Model 的决策做对比。这样你既能监控 Decision Model 的表现又能持续获得新的训练数据。我们系统里这个影子模式跑了大半年积累了 30 多万条对比样本模型迭代了 4 个版本准确率从最初的 82% 提到了 94%。