本文要回答的问题Agent主循环里大量毫秒级的小判断怎么从大模型调用里拆出来交给专用小模型同时不丢安全性。背景调用画像先摸清对一个跑单据处理的内部Agent做了一次调用画像统计结论很典型-62%的请求是有限候选路由选择三选一、是非判断、五级评分-25%是短生成改写一句话、抽字段-13%才是真正的长推理。62%的流量走大模型换来的是每次1–3秒的延迟和按token计的账单。这些判断的答案空间早就定死了让生成式模型先写一段话再解析纯属浪费。顺带说一句这个占比在不同业务里会浮动但形状类似越靠近流程自动化的Agent判断类请求占比越高。画像要做的事很简单给每个请求打标——候选是否有限、日调用量、答错代价。三列填完拆层对象自己浮出来。另一个隐性收益是稳定性判断链路短出错面就小排查时不用在大模型的长回答里找一行分类结果。方案加一层判断路由9月底一家国内团队开源了决策模型系列0.8B–27B五档GGUF量化可本地部署实测思路可以直接复用。核心动作是把判断请求从主模型剥离挂一个本地小模型端点#router.yaml——判断层路由配置示意judge_endpoint:http://your-domain.test:8940/v1/decideroutes:-match:[team_route,severity_level,yes_no]backend:judgecandidates_file:candidates/team.yamlconfidence_threshold:0.86on_low_confidence:escalate#升级到大模型-match:[payment,delete,grant_role]backend:human_confirm#高风险一律人工授权override:truefallback:backend:main_llm三个要点1.判断请求不走对话接口走结构化接口输入候选集与上下文输出选项加概率分布2.概率分布是路由依据置信度过阈值直接执行几个候选咬得近就升级别硬选3.涉及资金、删除、权限的判断不进自动路由人工授权这道闸永远保留。接口设计上判断请求与生成请求彻底分离判断请求携带候选集与上下文返回选项与概率分布生成请求继续走主模型。两边互不干扰出问题时日志也容易分锅。为什么强调概率分布而不是只拿选项因为路由策略全靠它高置信直走、低置信升级、双高冲突转人工。只回选项的路由是盲的。这套分离还带来一个运维便利小模型端点不可用时路由自动降级到主模型业务不中断。监控指标单独建面板判断量、置信度分布、升级率、人工拦截率。踩坑记录先说结论三个坑都出在边界上——阈值边界、精度边界、职责边界。坑一阈值拍脑袋定0.9。上线头一天卡人工的请求占了三成。后来按任务类型分别校准阈值——路由类0.86就够评分类要收到0.92上下。阈值是调出来的不是设出来的。坑二以为量化后判断会崩。复测结果打脸官方231道公开判断题上高精度版与原始权重逐题一致压到2.71GB的深度量化版一致率98.3%只错2题。判断类任务对精度畸变的敏感度远低于生成类。坑三让小模型顺带写解释文字。一加生成就回到秒级。判断层只回选项和概率解释让主模型在需要时补——分层就要分干净。三个坑的共同教训分层不是把小模型当缩水版大模型用而是把它当一个只做判断的新组件来设计——接口、阈值、监控都按组件标准来。验证数据|指标|拆层前|拆层后||单次判断延迟|1–3s|26ms4B一次三问||小规格延迟|—|12.2ms0.8B||高峰期超时率|6.8%|0.4%|延迟数字是官方在单卡H200、BF16、短请求条件下的口径本地环境按硬件浮动但量级一致判断环节从秒级进入毫秒级。成本侧的变化同样明显判断环节从按token计费变成本地固定开销账单曲线的高频毛刺直接消失。判断延迟进入毫秒级之后原来因为慢而不敢自动化的环节现在可以放心自动化。检查清单[]调用画像有限候选请求占比是否过半[]候选集是否可枚举、可维护[]阈值是否按任务类型分别校准[]低置信度升级路径是否可用[]高风险操作是否全部走人工授权[]判断层是否零生成只回选项与概率判断层拆出去之后主模型只处理真正需要推理和生成的13%整体体验和成本都松了一口气。候选集维护建议直接进代码评审流程——候选集变了判断行为就变了理应走变更管理。那又是另一篇文章了。