把「决策」从大模型里拆出来是我今年在 Agent 架构上做得最值的一笔投资。先说结论不是所有事情都要让那个上千亿参数的大模型来拍板很多高频、小颗粒、模式固定的决策完全可以用一个极轻量的 System One 模型来接管。这个思路落到项目里就是我最近一直在打磨的 Jev——一个专门负责「快速决策」的小模块把大模型从每秒钟都要做的低价值判断题里解放出来。先说说我为什么会被这个问题缠住。之前做某个客服 Agent 项目线上流量一上来模型推理延迟就跟着涨尤其是那种「用户说一句话、Agent 要决定调哪个工具、要不要反问、要不要直接回答」的场景每轮对话都要等大模型完整跑一次前向token 烧得心疼响应还慢。后来我意识到一个特别朴素的道理人脑做判断也不是每次都启动慢思考的。卡尼曼那套 System 1 / System 2 的说法放在大模型架构里其实特别贴切——大模型是合格的 System 2慢、重、但推理能力强而我现在缺的恰恰是一个 System 1快、轻、能形成肌肉记忆。Jev 就是干这个的。这篇文章我不会去讲什么花哨的学术理论就分享我自己从拆分思路、边界判断到落地部署、踩坑修复的完整过程顺便把几个关键的参数设计和排查技巧也一并写清楚。适合正在做 Agent 应用、被大模型延迟和成本折腾得头疼的开发者参考你对双系统架构的理解会在读完以后从概念层面落到能直接下手的工程层面。1. 拆决策之前的账大模型做决策到底贵在哪1.1 先理解「决策」和「推理」根本不是一回事很多人在 Agent 上踩坑第一步就错在把「决策」和「推理」混为一谈。我见过不少团队明明只是要判断「用户这句话是不是在问天气」也要把整句话塞给一个大模型让它输出一段 JSON里面还要带着 reasoning。这就好比你去公司楼下买杯咖啡结果非要开一辆重型卡车去——不是不能到是每公里成本高得离谱。决策是什么决策是在有限选项里做选择。用户说「帮我退掉这单」Agent 需要判断的是这是退款意图应该调退款工具附带参数是订单号。这是一个分类问题加参数抽取问题本质上是高确定性的。推理是什么推理是在未知信息之间建立关联。用户说「我这两个方案各有优劣你帮我综合分析一下」这需要大模型理解上下文、比较利弊、生成有逻辑的结论这才是 System 2 该干的活。Jev 的核心主张特别简单把前者从大模型里拆出来交给一个专门负责决策的 System One 模型后者继续留在大模型里。前者用极小成本实现后者按需调用。这样做不是牺牲质量而是把资源用在刀刃上。1.2 算一笔成本账为什么高频决策是隐形杀手我当时的项目大概一天要处理 10 万轮对话其中 70% 以上都集中在「查订单」「退换货」「转人工」「问物流」这几个固定意图上。每一轮主模型都要走一遍完整的 prefill 加 decode平均消耗 1200 到 1800 个 token。按当时的服务价格粗算一天光处理这些高频决策就要花掉大几百。更难受的是延迟——每轮 1.5 到 2 秒的响应时间用户等得焦躁客服那边压力也大。后来我做了个小实验把其中 5000 条历史对话捞出来用规则加小模型去模拟决策只看最终判断对不对。结果发现70% 的意图识别和工具路由一个小型的序列分类模型就能做到 97% 以上的准确率而且单次推断只要几毫秒。那一刻我心里就有数了——让千亿参数模型去处理这 70% 的请求本质上是拿大炮打蚊子而且是全天候不间断地打。这也解释了为什么「拆分」比「优化单次推理」更重要。你就算把大模型的推理速度优化一倍边际收益也不如直接把 70% 的请求挪到 10 毫秒内完成来得猛。成本曲线会从线性变成断崖式下降。1.3 Jev 在架构里到底是个什么角色给 Jev 定位这件事我反复纠结了很久。它不是单纯的意图分类器也不是单纯的规则引擎更不是传统意义上的对话系统。打个比方如果说大模型 Agent 是一个需要层层审批的大公司那 Jev 就是前台加秘书处先听用户说什么快速判断这事归哪个部门管、要不要转给总监、还是可以直接按标准流程办。所有不需要深度思考的请求在前台就消化掉了真正棘手的才送到后面。落地形态上Jev 作为主 Agent 循环里的一个前置决策层存在。每次用户请求进来先打到 Jev输出三件事意图标签、置信度、路由建议。Jev 给出高置信度的标准决策时直接走快捷通道不启动大模型置信度不够或者任务确实复杂再原样转交大模型。这个「先快后慢」的两级结构是我实验下来最稳的形态比单纯用一个模型试图吞下所有请求要可靠得多。2. 什么决策该拆、什么不该拆边界判断是门手艺2.1 可拆解决策的三条硬性标准光有想法不行拆之前你得先给自己的业务场景做一次「体检」判断哪些决策真的适合从大模型里拆出来。我总结下来有三条硬性标准缺一条都别硬拆。第一选项空间必须有限且封闭。Jev 本质上是在有限候选项里做选择所以候选意图、候选工具、候选动作必须是可枚举的。你想让它自由发挥生成新决策路径那是大模型的活不是 System One 的活。我当时把客服场景的意图收敛到 23 个工具收敛到 17 个所有组合都是提前定义好的这个基础不打好后面训练和评估都会失控。第二输入输出要有清晰的边界。Jev 的输入是一句用户消息加上必要的上下文比如会话状态、之前的意图记录输出是一个结构化的决策结果。如果任务要求模型自己决定需要什么上下文、自己判断该输出什么内容那它就不是一个纯粹的决策任务拆出来反而会把简单问题复杂化。第三错误容忍度要可控。Jev 再准也会有失误所以拆出来的决策场景必须是即使偶尔判错了也能通过回退机制兜底。当时我把「识别用户想退款但判断错了退款方式」视为高风险错误因为直接关联资金操作而「识别用户想查物流却先弹了订单详情」就属于低风险用户纠正一句就行。高风险的部分Jev 只负责初筛最终确认权在大模型手里低风险部分Jev 可以直接执行。2.2 适合拆出来的四类高频决策结合我实际跑过的项目有四类决策是公认的拆分收益高地参考价值最大。一是意图识别与路由。这个最经典用户说一句话判断他想干什么然后决定调用哪个下游模块。它完全是封闭集合内的分类问题Jev 的舒适区。二是常识性参数补齐。像「帮我订下周三去杭州的票」这句话里没有年份常识判断是今年如果今天是周六那下周三显然不是明天。这些简单的常识推理用规则加轻量模型就能搞定完全不需要大模型出来分析一通。Jev 可以直接补全参数给下游工具一个完整的调用参数表。三是简单的状态判断与终止决策。比如多轮问答里判断用户是不是已经确认、是不是在重复提问、要不要结束当前任务。这些决策依赖当前会话状态机状态是有限的转移是预设的Jev 做这个又快又省。四是安全与合规初筛。识别用户是不是在试图越权操作、是不是在问一些敏感信息。这类请求不一定需要深度理解只需要匹配已知模式。Jev 做第一道闸门命中敏感模式就直接拦截拦截不了的再放大模型那边判断能挡掉大量脏流量。2.3 不适合拆的场景这些雷区我替你们踩过了有适合拆的就一定有不适合拆的。我踩过最狠的一个坑是试图让 Jev 做「用户情绪识别」和「个性化回复生成」的联合决策。当时想着反正都是分类情绪识别也是分类干脆一起拆了。结果是情绪标签还勉强能看但基于情绪的回复策略建议基本不可用——因为「用户在生气应该怎么回复」这句话里真正难的不是判断情绪而是生成一个既安抚情绪又解决实际问题的回复。这部分根本没有封闭选项你硬拆就是把开放问题强行降维成封闭问题结果必然是决策质量打折。另一个雷区是涉及多轮上下文深度推理的任务。比如用户绕了好几圈说了一堆需求最终想要一个定制方案这中间的决策依赖大量隐含信息不是看一眼当前这句话就能定。Jev 训练数据里这类样本表现极差强行让它做只会给大模型带去一个错误的初步路由反而加重了后续负担。所以我的经验是拆之前拿那张有三条标准的体检表过一遍三关全过再动手有任何一关模棱两可就继续让大模型顶着不要为了拆而拆。3. 从 0 到 1 落地 Jev 的完整方案3.1 整体架构与调用链路落地 Jev 的时候我最初尝试过把它做成一个 Python 函数直接嵌在 Agent 主进程里后来发现不行——决策层一旦出问题整个 Agent 都跟着挂于是改成了独立微服务单独部署、单独扩容、单独降级。架构上主 Agent 的每一次请求先经过一个轻量的分发网关网关把请求复制一份给 JevJev 在几十毫秒内返回结果网关根据结果决定是否真正把请求发往大模型。调用链路的伪代码大概是这样的async def handle_request(user_msg, session): # 第 1 步先问 Jev decision await jev.decide( textuser_msg, session_statesession.get_state(), candidate_intentsINTENT_SET, candidate_toolsTOOL_SET ) # 第 2 步置信度足够直接走快捷通道 if decision.confidence HIGH_CONF_THRESHOLD and decision.risk_level low: return await fast_path(decision) # 第 3 步置信度一般但意图明确让 Jev 先做粗路由大模型只做确认 if decision.confidence MID_CONF_THRESHOLD: return await confirm_path(decision, user_msg) # 第 4 步低置信度整体交还给大模型 return await llm_full_path(user_msg, session)这里面最关键的设计是 thresholds 不能拍脑袋定而是基于历史数据算出来的。我们收集了 2 万条人工标注的决策样本统计了 Jev 在不同置信度下的准确率分布然后选了「高置信阈值 准确率要超过 99%」「中置信阈值 准确率要超过 95%」这两个点。这么设计的好处是Jev 真正全权决策的部分极其可靠而稍微没把握的部分大模型还有机会纠正。3.2 Jev 模型本身怎么做数据蒸馏与训练Jev 的「大脑」是训练出来的不是拍规则拍出来的。数据来源里最核心的一路是大模型自身的历史决策轨迹。我运营线上 Agent 时把所有请求连同大模型最终执行的决策结果都录了日志攒了一个大池子。然后做了两件事第一洗数据把涉及用户隐私的字段做脱敏第二做标签把大模型当年的决策结果当作监督信号喂给 Jev。这种做法的本质是知识蒸馏——让大模型当老师小模型当学生学生只学「做决策」这部分能力不学生成。模型本身我用的是一个参数量很小的文本编码器加一个多层感知机头整体规模不到 1 亿参数单次推理在 CPU 上都能做到几十毫秒。训练过程不复杂重点在于样本构造。决策不仅仅是「意图分类」我把它建模成一个多任务输出意图标签、关键槽位类型、路由动作、置信度。每个任务共享底层编码器头上分叉这样一次前向就能拿到完整决策包。训练数据里还有一个特别容易忽略的坑——正负样本比例。线上日志天然偏向高频意图低频意图几乎见不到。如果直接拿原始日志训练Jev 会对高频意图过拟合对长尾意图完全失明。我做了重采样把低频意图的样本复制加扰动再把高频意图按比例裁掉一部分最后让训练集里每个意图的样本数量处在一个量级内。这一步做完Jev 的长尾召回率从 62% 直接拉到 88%。3.3 评估指标怎么设计只看准确率会骗你评估一个决策模型只看整体准确率是最容易自欺欺人的。整体准确率只要高频意图占多数就会显得很高但低频意图错得一塌糊涂你根本看不见。我用的评估体系里有四个核心指标缺一不可。第一个是分意图准确率。不汇总按 23 个意图逐个看。任何单个意图的准确率掉到 90% 以下任凭整体指标再漂亮也要拉回去补数据。第二个是高置信覆盖率。它的定义是「有多少请求能达到高置信阈值从而进入快捷通道」。如果覆盖率只有 30%说明 Jev 虽然准但大多数请求它不敢拍板大模型仍然被压着跑拆分毫无意义。我给自己定的及格线是 60% 以上。第三个是回退率也就是「Jev 决策后被大模型或用户纠正的比例」。这个指标比准确率更真实——它衡量的是系统在真实环境中被否定的概率。我要求回退率长期稳定在 3% 以下一旦超标说明某个决策边界可能画错了。第四个是延迟与成本评测。上线前后对比 p95 响应延迟下降了 70%每万次对话的大模型 token 消耗下降了 62%。这些数字是向团队证明拆分价值最直接的材料比什么技术报告都好使。3.4 部署与回退Jev 和大模型的权责分工部署 Jev 时我用了一套独立于大模型的容器集群给它配了独立的监控面板。这样做的好处是Jev 的延迟、吞吐、准确率全部独立观测不会和大模型的指标混在一起。一旦 Jev 出问题可以单独回滚到「全部请求走大模型」的模式不用动主 Agent 的其他部分。回退有两种分别是静默回退和显式回退。静默回退是说Jev 置信度不够直接把请求转交大模型对外无感知显式回退是说Jev 做了决策并执行了但用户随后纠正了系统记下这次失败并触发补偿逻辑。补偿逻辑里的关键数据是失败样本我要求每条失败样本都自动回流到标注池定期补充进训练集。这样一个星期后Jev 就会在同类样本上表现得更好形成一条飞轮。权责分工上Jev 可以决定「做什么」但涉及资金、权限、隐私的高风险动作它只能建议不能执行。比如识别到退款意图Jev 可以把订单号、退款路径都准备好但执行退款动作前必须由大模型对 Jev 的结论做一次确认。这个「建议权」和「执行权」分离的设计让我对 Jev 的大规模放权有了底气。4. 踩过的坑与排查实操4.1 拆错边界的典型症状与止损方案第一个大坑就是我前面提过的情绪识别具体症状特别典型上线第一周Jev 对「用户生气」的识别准确率有 92%但据此生成的安抚策略准确率只有 53%导致客服助手经常给出驴唇不对马嘴的建议。排查后发现问题不是出在「识别情绪」这个环节而是出在「基于情绪做开放策略」这个被强行塞进封闭决策框架里的环节。止损方案也不复杂把「生成回复策略」这一路从 Jev 的输出里卸掉Jev 只输出情绪标签策略交给大模型生成。改动之后回退率立刻下降了两个百分点。另一个高频坑是「长尾输入识别」。Jev 对标准句式很准但用户说话千奇百怪比如「帮我退了谢谢」这种省略主语宾语的口语Jev 一度识别成「取消订阅」而不是「退款」。后来我们在训练集里加了一大批口语化变体还做了一些简单的文本增强比如随机删词、换词序、加入语气词。这个操作把口语样本的准确率从 78% 拉到了 93%。4.2 数据漂移与模型过期更新机制怎么设计System One 模型有个天然的阿喀琉斯之踵它一旦训练完行为就固化了。而线上的用户表达会随着时间变化产品也会不断迭代旧的意向集可能过时新意图可能冒出来。如果不做更新机制Jev 的准确率会在上线后两三个月开始肉眼可见地滑坡。我的做法是给 Jev 配了一个「周级更新 月度重训」的节奏。每周从线上抓取新增失败样本和低置信度样本人工标注后增量训练模型每个月底用全量数据重新训练基线确保旧知识不遗忘。增量训练用的是正则化约束防止新数据把模型基础能力冲掉。同时监控意图分布的变化一旦发现某类请求占比连续一周显著上升就单独拉出来看看是不是出现了新意图如果是就手动扩充意图集合。这套机制跑下来我最直观的感受是System One 模型不是一劳永逸的东西它需要像养植物一样定期施肥修剪你持续给它喂数据它才能持续保持敏锐。4.3 现场排查的几个实用技巧遇到 Jev 决策异常我的排查顺序是三板斧。第一板斧是查日志看「它到底接了什么输入、吐了什么输出」。很多问题一眼就能看出来是输入解析问题比如用户消息包含了特殊符号前端做了截断Jev 拿到的根本不是完整句子。第二板斧是拉出同意图的最近 50 条决策记录看是突然性退化还是渐进式漂移。突然性退化一般指向代码变更或上游数据质量变化渐进式漂移则指向用户表达习惯变化。第三板斧是人为复测直接构造一批典型输入打给 Jev对照它输出的置信度分布。如果置信度普遍偏低说明模型不认识这批输入这是数据问题如果置信度虚高但实际是错的这是训练目标的 calibration 出了问题需要调整损失函数。我印象最深的一次排查是 Jev 突然连续三小时对「转人工」的识别准确率暴跌。查了半天发现不是模型问题而是当天上线了一个营销活动一波新用户涌进来他们的表达习惯和存量用户差异很大。Jev 没见过这种说话方式全部低置信度全量转给了大模型。这其实是 Jev 做了正确的事情——知道自己不确定就放手。所以排查时不要只盯着模型本身也要看业务侧有没有变化。4.4 常见问题速查表总结一下我反复遇到的典型问题做成一张速查表备用症状大概率原因排查与处理办法整体准确率高但某个低频意图持续出错训练样本不均衡对该意图做重采样补充人工标注样本高置信覆盖率长期低于 50%阈值设置过于保守基于历史数据校准阈值找到准确率与覆盖率的平衡点某类输入置信度虚高但多数错误训练目标对齐不足检查损失函数和标签噪声增加校准层上线几周后准确率逐渐下滑数据漂移或新意图出现启动周级增量训练必要时扩充意图集合单个请求延迟偶尔飙到秒级Jev 被大流量阻塞或服务降级扩容 Jev 实例加缓存和熔断机制用户纠正率突然上升上游业务变化导致表达分布变化拉取近期失败样本人工分析后补入训练集Jev 输出正常但下游工具报错决策正确但参数抽取不完整单独检查槽位填充效果必要时为 Jev 增加参数抽取专项训练这套速查表我打印出来贴在工位上每次 Jev 出异常基本能在十分钟内定位到根因。排查本身不复杂真正难的是你是否建立了「数据回流—标注—重训—评估」的闭环。没有这个环System One 模型就跟普通规则引擎没什么区别只是把问题延后暴露而已。最后分享一点个人体会。把决策从大模型里拆出来我花的时间比我预想的多但收益也比我预想的大。项目上线三个月后回看当初设下的指标——延迟、成本、准确率——全部都在预期之上。而我自己最大的变化是再也不把「大模型」当作唯一的解题工具了。什么时候用 System 2 深度推理什么时候该用 System 1 快速决策这个判断能力才是做 Agent 架构最值钱的东西。Jev 只是一个名字这套「双系统」的思路在接下来很长一段时间里应该都能用得上建议你也试试。
把「决策」从大模型里拆出来是我今年在 Agent 架构上做得最值的一笔投资。先说结论不是所有事情都要让那个上千亿参数的大模型来拍板很多高频、小颗粒、模式固定的决策完全可以用一个极轻量的 System One 模型来接管。这个思路落到项目里就是我最近一直在打磨的 Jev——一个专门负责「快速决策」的小模块把大模型从每秒钟都要做的低价值判断题里解放出来。先说说我为什么会被这个问题缠住。之前做某个客服 Agent 项目线上流量一上来模型推理延迟就跟着涨尤其是那种「用户说一句话、Agent 要决定调哪个工具、要不要反问、要不要直接回答」的场景每轮对话都要等大模型完整跑一次前向token 烧得心疼响应还慢。后来我意识到一个特别朴素的道理人脑做判断也不是每次都启动慢思考的。卡尼曼那套 System 1 / System 2 的说法放在大模型架构里其实特别贴切——大模型是合格的 System 2慢、重、但推理能力强而我现在缺的恰恰是一个 System 1快、轻、能形成肌肉记忆。Jev 就是干这个的。这篇文章我不会去讲什么花哨的学术理论就分享我自己从拆分思路、边界判断到落地部署、踩坑修复的完整过程顺便把几个关键的参数设计和排查技巧也一并写清楚。适合正在做 Agent 应用、被大模型延迟和成本折腾得头疼的开发者参考你对双系统架构的理解会在读完以后从概念层面落到能直接下手的工程层面。1. 拆决策之前的账大模型做决策到底贵在哪1.1 先理解「决策」和「推理」根本不是一回事很多人在 Agent 上踩坑第一步就错在把「决策」和「推理」混为一谈。我见过不少团队明明只是要判断「用户这句话是不是在问天气」也要把整句话塞给一个大模型让它输出一段 JSON里面还要带着 reasoning。这就好比你去公司楼下买杯咖啡结果非要开一辆重型卡车去——不是不能到是每公里成本高得离谱。决策是什么决策是在有限选项里做选择。用户说「帮我退掉这单」Agent 需要判断的是这是退款意图应该调退款工具附带参数是订单号。这是一个分类问题加参数抽取问题本质上是高确定性的。推理是什么推理是在未知信息之间建立关联。用户说「我这两个方案各有优劣你帮我综合分析一下」这需要大模型理解上下文、比较利弊、生成有逻辑的结论这才是 System 2 该干的活。Jev 的核心主张特别简单把前者从大模型里拆出来交给一个专门负责决策的 System One 模型后者继续留在大模型里。前者用极小成本实现后者按需调用。这样做不是牺牲质量而是把资源用在刀刃上。1.2 算一笔成本账为什么高频决策是隐形杀手我当时的项目大概一天要处理 10 万轮对话其中 70% 以上都集中在「查订单」「退换货」「转人工」「问物流」这几个固定意图上。每一轮主模型都要走一遍完整的 prefill 加 decode平均消耗 1200 到 1800 个 token。按当时的服务价格粗算一天光处理这些高频决策就要花掉大几百。更难受的是延迟——每轮 1.5 到 2 秒的响应时间用户等得焦躁客服那边压力也大。后来我做了个小实验把其中 5000 条历史对话捞出来用规则加小模型去模拟决策只看最终判断对不对。结果发现70% 的意图识别和工具路由一个小型的序列分类模型就能做到 97% 以上的准确率而且单次推断只要几毫秒。那一刻我心里就有数了——让千亿参数模型去处理这 70% 的请求本质上是拿大炮打蚊子而且是全天候不间断地打。这也解释了为什么「拆分」比「优化单次推理」更重要。你就算把大模型的推理速度优化一倍边际收益也不如直接把 70% 的请求挪到 10 毫秒内完成来得猛。成本曲线会从线性变成断崖式下降。1.3 Jev 在架构里到底是个什么角色给 Jev 定位这件事我反复纠结了很久。它不是单纯的意图分类器也不是单纯的规则引擎更不是传统意义上的对话系统。打个比方如果说大模型 Agent 是一个需要层层审批的大公司那 Jev 就是前台加秘书处先听用户说什么快速判断这事归哪个部门管、要不要转给总监、还是可以直接按标准流程办。所有不需要深度思考的请求在前台就消化掉了真正棘手的才送到后面。落地形态上Jev 作为主 Agent 循环里的一个前置决策层存在。每次用户请求进来先打到 Jev输出三件事意图标签、置信度、路由建议。Jev 给出高置信度的标准决策时直接走快捷通道不启动大模型置信度不够或者任务确实复杂再原样转交大模型。这个「先快后慢」的两级结构是我实验下来最稳的形态比单纯用一个模型试图吞下所有请求要可靠得多。2. 什么决策该拆、什么不该拆边界判断是门手艺2.1 可拆解决策的三条硬性标准光有想法不行拆之前你得先给自己的业务场景做一次「体检」判断哪些决策真的适合从大模型里拆出来。我总结下来有三条硬性标准缺一条都别硬拆。第一选项空间必须有限且封闭。Jev 本质上是在有限候选项里做选择所以候选意图、候选工具、候选动作必须是可枚举的。你想让它自由发挥生成新决策路径那是大模型的活不是 System One 的活。我当时把客服场景的意图收敛到 23 个工具收敛到 17 个所有组合都是提前定义好的这个基础不打好后面训练和评估都会失控。第二输入输出要有清晰的边界。Jev 的输入是一句用户消息加上必要的上下文比如会话状态、之前的意图记录输出是一个结构化的决策结果。如果任务要求模型自己决定需要什么上下文、自己判断该输出什么内容那它就不是一个纯粹的决策任务拆出来反而会把简单问题复杂化。第三错误容忍度要可控。Jev 再准也会有失误所以拆出来的决策场景必须是即使偶尔判错了也能通过回退机制兜底。当时我把「识别用户想退款但判断错了退款方式」视为高风险错误因为直接关联资金操作而「识别用户想查物流却先弹了订单详情」就属于低风险用户纠正一句就行。高风险的部分Jev 只负责初筛最终确认权在大模型手里低风险部分Jev 可以直接执行。2.2 适合拆出来的四类高频决策结合我实际跑过的项目有四类决策是公认的拆分收益高地参考价值最大。一是意图识别与路由。这个最经典用户说一句话判断他想干什么然后决定调用哪个下游模块。它完全是封闭集合内的分类问题Jev 的舒适区。二是常识性参数补齐。像「帮我订下周三去杭州的票」这句话里没有年份常识判断是今年如果今天是周六那下周三显然不是明天。这些简单的常识推理用规则加轻量模型就能搞定完全不需要大模型出来分析一通。Jev 可以直接补全参数给下游工具一个完整的调用参数表。三是简单的状态判断与终止决策。比如多轮问答里判断用户是不是已经确认、是不是在重复提问、要不要结束当前任务。这些决策依赖当前会话状态机状态是有限的转移是预设的Jev 做这个又快又省。四是安全与合规初筛。识别用户是不是在试图越权操作、是不是在问一些敏感信息。这类请求不一定需要深度理解只需要匹配已知模式。Jev 做第一道闸门命中敏感模式就直接拦截拦截不了的再放大模型那边判断能挡掉大量脏流量。2.3 不适合拆的场景这些雷区我替你们踩过了有适合拆的就一定有不适合拆的。我踩过最狠的一个坑是试图让 Jev 做「用户情绪识别」和「个性化回复生成」的联合决策。当时想着反正都是分类情绪识别也是分类干脆一起拆了。结果是情绪标签还勉强能看但基于情绪的回复策略建议基本不可用——因为「用户在生气应该怎么回复」这句话里真正难的不是判断情绪而是生成一个既安抚情绪又解决实际问题的回复。这部分根本没有封闭选项你硬拆就是把开放问题强行降维成封闭问题结果必然是决策质量打折。另一个雷区是涉及多轮上下文深度推理的任务。比如用户绕了好几圈说了一堆需求最终想要一个定制方案这中间的决策依赖大量隐含信息不是看一眼当前这句话就能定。Jev 训练数据里这类样本表现极差强行让它做只会给大模型带去一个错误的初步路由反而加重了后续负担。所以我的经验是拆之前拿那张有三条标准的体检表过一遍三关全过再动手有任何一关模棱两可就继续让大模型顶着不要为了拆而拆。3. 从 0 到 1 落地 Jev 的完整方案3.1 整体架构与调用链路落地 Jev 的时候我最初尝试过把它做成一个 Python 函数直接嵌在 Agent 主进程里后来发现不行——决策层一旦出问题整个 Agent 都跟着挂于是改成了独立微服务单独部署、单独扩容、单独降级。架构上主 Agent 的每一次请求先经过一个轻量的分发网关网关把请求复制一份给 JevJev 在几十毫秒内返回结果网关根据结果决定是否真正把请求发往大模型。调用链路的伪代码大概是这样的async def handle_request(user_msg, session): # 第 1 步先问 Jev decision await jev.decide( textuser_msg, session_statesession.get_state(), candidate_intentsINTENT_SET, candidate_toolsTOOL_SET ) # 第 2 步置信度足够直接走快捷通道 if decision.confidence HIGH_CONF_THRESHOLD and decision.risk_level low: return await fast_path(decision) # 第 3 步置信度一般但意图明确让 Jev 先做粗路由大模型只做确认 if decision.confidence MID_CONF_THRESHOLD: return await confirm_path(decision, user_msg) # 第 4 步低置信度整体交还给大模型 return await llm_full_path(user_msg, session)这里面最关键的设计是 thresholds 不能拍脑袋定而是基于历史数据算出来的。我们收集了 2 万条人工标注的决策样本统计了 Jev 在不同置信度下的准确率分布然后选了「高置信阈值 准确率要超过 99%」「中置信阈值 准确率要超过 95%」这两个点。这么设计的好处是Jev 真正全权决策的部分极其可靠而稍微没把握的部分大模型还有机会纠正。3.2 Jev 模型本身怎么做数据蒸馏与训练Jev 的「大脑」是训练出来的不是拍规则拍出来的。数据来源里最核心的一路是大模型自身的历史决策轨迹。我运营线上 Agent 时把所有请求连同大模型最终执行的决策结果都录了日志攒了一个大池子。然后做了两件事第一洗数据把涉及用户隐私的字段做脱敏第二做标签把大模型当年的决策结果当作监督信号喂给 Jev。这种做法的本质是知识蒸馏——让大模型当老师小模型当学生学生只学「做决策」这部分能力不学生成。模型本身我用的是一个参数量很小的文本编码器加一个多层感知机头整体规模不到 1 亿参数单次推理在 CPU 上都能做到几十毫秒。训练过程不复杂重点在于样本构造。决策不仅仅是「意图分类」我把它建模成一个多任务输出意图标签、关键槽位类型、路由动作、置信度。每个任务共享底层编码器头上分叉这样一次前向就能拿到完整决策包。训练数据里还有一个特别容易忽略的坑——正负样本比例。线上日志天然偏向高频意图低频意图几乎见不到。如果直接拿原始日志训练Jev 会对高频意图过拟合对长尾意图完全失明。我做了重采样把低频意图的样本复制加扰动再把高频意图按比例裁掉一部分最后让训练集里每个意图的样本数量处在一个量级内。这一步做完Jev 的长尾召回率从 62% 直接拉到 88%。3.3 评估指标怎么设计只看准确率会骗你评估一个决策模型只看整体准确率是最容易自欺欺人的。整体准确率只要高频意图占多数就会显得很高但低频意图错得一塌糊涂你根本看不见。我用的评估体系里有四个核心指标缺一不可。第一个是分意图准确率。不汇总按 23 个意图逐个看。任何单个意图的准确率掉到 90% 以下任凭整体指标再漂亮也要拉回去补数据。第二个是高置信覆盖率。它的定义是「有多少请求能达到高置信阈值从而进入快捷通道」。如果覆盖率只有 30%说明 Jev 虽然准但大多数请求它不敢拍板大模型仍然被压着跑拆分毫无意义。我给自己定的及格线是 60% 以上。第三个是回退率也就是「Jev 决策后被大模型或用户纠正的比例」。这个指标比准确率更真实——它衡量的是系统在真实环境中被否定的概率。我要求回退率长期稳定在 3% 以下一旦超标说明某个决策边界可能画错了。第四个是延迟与成本评测。上线前后对比 p95 响应延迟下降了 70%每万次对话的大模型 token 消耗下降了 62%。这些数字是向团队证明拆分价值最直接的材料比什么技术报告都好使。3.4 部署与回退Jev 和大模型的权责分工部署 Jev 时我用了一套独立于大模型的容器集群给它配了独立的监控面板。这样做的好处是Jev 的延迟、吞吐、准确率全部独立观测不会和大模型的指标混在一起。一旦 Jev 出问题可以单独回滚到「全部请求走大模型」的模式不用动主 Agent 的其他部分。回退有两种分别是静默回退和显式回退。静默回退是说Jev 置信度不够直接把请求转交大模型对外无感知显式回退是说Jev 做了决策并执行了但用户随后纠正了系统记下这次失败并触发补偿逻辑。补偿逻辑里的关键数据是失败样本我要求每条失败样本都自动回流到标注池定期补充进训练集。这样一个星期后Jev 就会在同类样本上表现得更好形成一条飞轮。权责分工上Jev 可以决定「做什么」但涉及资金、权限、隐私的高风险动作它只能建议不能执行。比如识别到退款意图Jev 可以把订单号、退款路径都准备好但执行退款动作前必须由大模型对 Jev 的结论做一次确认。这个「建议权」和「执行权」分离的设计让我对 Jev 的大规模放权有了底气。4. 踩过的坑与排查实操4.1 拆错边界的典型症状与止损方案第一个大坑就是我前面提过的情绪识别具体症状特别典型上线第一周Jev 对「用户生气」的识别准确率有 92%但据此生成的安抚策略准确率只有 53%导致客服助手经常给出驴唇不对马嘴的建议。排查后发现问题不是出在「识别情绪」这个环节而是出在「基于情绪做开放策略」这个被强行塞进封闭决策框架里的环节。止损方案也不复杂把「生成回复策略」这一路从 Jev 的输出里卸掉Jev 只输出情绪标签策略交给大模型生成。改动之后回退率立刻下降了两个百分点。另一个高频坑是「长尾输入识别」。Jev 对标准句式很准但用户说话千奇百怪比如「帮我退了谢谢」这种省略主语宾语的口语Jev 一度识别成「取消订阅」而不是「退款」。后来我们在训练集里加了一大批口语化变体还做了一些简单的文本增强比如随机删词、换词序、加入语气词。这个操作把口语样本的准确率从 78% 拉到了 93%。4.2 数据漂移与模型过期更新机制怎么设计System One 模型有个天然的阿喀琉斯之踵它一旦训练完行为就固化了。而线上的用户表达会随着时间变化产品也会不断迭代旧的意向集可能过时新意图可能冒出来。如果不做更新机制Jev 的准确率会在上线后两三个月开始肉眼可见地滑坡。我的做法是给 Jev 配了一个「周级更新 月度重训」的节奏。每周从线上抓取新增失败样本和低置信度样本人工标注后增量训练模型每个月底用全量数据重新训练基线确保旧知识不遗忘。增量训练用的是正则化约束防止新数据把模型基础能力冲掉。同时监控意图分布的变化一旦发现某类请求占比连续一周显著上升就单独拉出来看看是不是出现了新意图如果是就手动扩充意图集合。这套机制跑下来我最直观的感受是System One 模型不是一劳永逸的东西它需要像养植物一样定期施肥修剪你持续给它喂数据它才能持续保持敏锐。4.3 现场排查的几个实用技巧遇到 Jev 决策异常我的排查顺序是三板斧。第一板斧是查日志看「它到底接了什么输入、吐了什么输出」。很多问题一眼就能看出来是输入解析问题比如用户消息包含了特殊符号前端做了截断Jev 拿到的根本不是完整句子。第二板斧是拉出同意图的最近 50 条决策记录看是突然性退化还是渐进式漂移。突然性退化一般指向代码变更或上游数据质量变化渐进式漂移则指向用户表达习惯变化。第三板斧是人为复测直接构造一批典型输入打给 Jev对照它输出的置信度分布。如果置信度普遍偏低说明模型不认识这批输入这是数据问题如果置信度虚高但实际是错的这是训练目标的 calibration 出了问题需要调整损失函数。我印象最深的一次排查是 Jev 突然连续三小时对「转人工」的识别准确率暴跌。查了半天发现不是模型问题而是当天上线了一个营销活动一波新用户涌进来他们的表达习惯和存量用户差异很大。Jev 没见过这种说话方式全部低置信度全量转给了大模型。这其实是 Jev 做了正确的事情——知道自己不确定就放手。所以排查时不要只盯着模型本身也要看业务侧有没有变化。4.4 常见问题速查表总结一下我反复遇到的典型问题做成一张速查表备用症状大概率原因排查与处理办法整体准确率高但某个低频意图持续出错训练样本不均衡对该意图做重采样补充人工标注样本高置信覆盖率长期低于 50%阈值设置过于保守基于历史数据校准阈值找到准确率与覆盖率的平衡点某类输入置信度虚高但多数错误训练目标对齐不足检查损失函数和标签噪声增加校准层上线几周后准确率逐渐下滑数据漂移或新意图出现启动周级增量训练必要时扩充意图集合单个请求延迟偶尔飙到秒级Jev 被大流量阻塞或服务降级扩容 Jev 实例加缓存和熔断机制用户纠正率突然上升上游业务变化导致表达分布变化拉取近期失败样本人工分析后补入训练集Jev 输出正常但下游工具报错决策正确但参数抽取不完整单独检查槽位填充效果必要时为 Jev 增加参数抽取专项训练这套速查表我打印出来贴在工位上每次 Jev 出异常基本能在十分钟内定位到根因。排查本身不复杂真正难的是你是否建立了「数据回流—标注—重训—评估」的闭环。没有这个环System One 模型就跟普通规则引擎没什么区别只是把问题延后暴露而已。最后分享一点个人体会。把决策从大模型里拆出来我花的时间比我预想的多但收益也比我预想的大。项目上线三个月后回看当初设下的指标——延迟、成本、准确率——全部都在预期之上。而我自己最大的变化是再也不把「大模型」当作唯一的解题工具了。什么时候用 System 2 深度推理什么时候该用 System 1 快速决策这个判断能力才是做 Agent 架构最值钱的东西。Jev 只是一个名字这套「双系统」的思路在接下来很长一段时间里应该都能用得上建议你也试试。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
