AI Agent决策模型架构模式

决策模型挂进 Agent 的五种姿势：我把 Laya 用成了教科书

2026-10-22 · PM Parker · 阅读约 8 分钟

上一篇的结尾留了个尾巴：66 题配对评测做完，d3-nano 接管主力判断流量，Laya 转备援。当时我说"门控线从 0.5 提到 0.8"，有读者问我：门控之后呢？模型答完了"急/不急"，Agent 拿这个结果干什么用？

这个问题问到了下半场。选模型是上半场，把模型接进工作流才是价值兑现的地方。这两周我把两件事做完了：一是把自己 Agent 框架里所有能挂辅助模型的槽位翻了一遍源码；二是把业界怎么组合"小决策模型 + 大模型 Agent"的公开材料扒了一遍。扒完发现一个有点好笑的事实：我过去半年凭手感搭的东西，几乎每一件都能在论文和生产系统里找到对应物。这篇就把两边对上，五种模式、各自的失败模式、以及我自己的挂载方案，一次讲清。

先给结论：五种模式一张表

把"小模型替大模型做判断"这件事拆开，业界沉淀下来的就五种模式，每种都有 canonical 来源：

模式	判断时机	代表来源	适合的判断
守门员 Guard	动作执行前	NeMo Guardrails、Claude Code Pre-Tool-Use hooks、Codex smart approvals	这条命令/请求能不能放行
级联裁判 Cascade Judge	便宜答案出来后	FrugalGPT（Stanford 2023）、AutoMix（NeurIPS 2024）	这个答案够不够好，不够就升级
前置路由 Router	问题进来时	RouteLLM（lmsys）	这题该派给谁
投机调用 Speculative Tool Calling	大模型思考时	arXiv 2512.15834	小模型先起草，大模型验证
语义缓存闸 Semantic Cache	请求进缓存前	GPTCache（zilliztech）	这题是不是问过了

五种模式不是并列选项，而是按"判断发生在哪个时刻"排的谱系：请求还没进来（缓存闸）、刚进来（路由）、答案出来了（裁判）、动作要执行了（守门员）、大模型在想别的（投机）。一张 Agent 的生命周期图上，它们挂在五个不同的点。

模式一：守门员——命令放行权交给判别模型

守门员是最直觉的模式：Agent 每次要执行命令或调用工具前，先过一道小模型安检，输出放行/拦截/转人工三选一。NVIDIA 的 NeMo Guardrails 把它做成了标准件（tool-calling rails），Claude Code 的 Pre-Tool-Use hooks 生态里有专门做命令拦截分类的开源项目，OpenAI Codex 的 smart approvals 是同一个思路。

这个位置为什么适合判别式小模型？三个原因。第一，纯分类零生成，判别模型的主场。第二，失败模式天然安全：判定器输出任何非标准答案都落到"转人工"，最坏结果是多问你几次，不会放行危险命令。第三，高频调用——smart 模式下每条被标记的命令都要判一次，云端大模型判一次约两秒，本地小模型一百毫秒，而且命令文本不出内网，安全判定本身不外流。

模式二：级联裁判——FrugalGPT 真正的贡献是裁判

级联是学术上最扎实的模式。FrugalGPT（Stanford 2023）的定义：便宜模型先答，裁判判定可不可靠，不可靠才升级贵模型，号称砍 98% 成本。但 2023 年到现在，真正值得记住的是那篇论文里最容易被忽略的细节：让级联成立的是裁判，不是便宜模型。他们专门训练了一个 DistilBERT 打分器来判"这个答案行不行"——便宜模型谁都会调，承重墙是裁判。

后面 AutoMix（NeurIPS 2024）用小模型自验证替代训练裁判，2026 年的校准研究把话说得更死：校准良好的裁判能砍 79.5% 成本保住 90% 前沿质量，校准不好的裁判，两种失败方向都贵——错误放行（false-accept），质量静默塌方，账单上看不见；无谓升级（false-escalate），白付钱，用户无感。有生产系统的裁判用 schema 校验实现，上游模型某天改了输出格式，schema 判不过，90% 流量全部涌向最贵模型，账单静默暴涨——没人发现，直到月底看账单。

模式三：前置路由——延迟最优，但没有后悔药

RouteLLM 一系的做法：请求进来先分类，预测该用哪个模型，只发一次。好处是延迟最优（一次推理），代价是没有兜底——分类器把难题错派给弱模型，坏答案直接出街，没有第二次机会。生产综述的共识：延迟是硬约束时选路由，质量下限是硬约束时选级联。我自己的判断流量的分诊（结构化决策先过小模型，置信度低于阈值升级大模型）名义上是路由，实际上带了置信度门控，已经是路由和级联的杂交——这大概是工程实践的自然归宿。

模式四和模式五：投机调用与语义缓存

投机工具调用（arXiv 2512.15834）：小模型先起草工具调用，大模型只做验证，Agent 推理显著加速。这条路要求小模型能生成，判别式模型干不了——我家的 Laya 出局，生成式小模型才行。

语义缓存闸（GPTCache）：用 embedding 相似度判"这题是不是问过了"，问过直接回缓存。判定器是 bge-m3 这类 embedding 模型，不是分类器。顺带一提，我翻自己 Agent 框架的检索栈时发现，记忆库和脑库的语义检索早就在用 bge-m3 了，这条模式我 unknowingly 跑了半年——只是没把它当作"决策模型挂载点"来认识。

翻自己框架源码：20 个官方槽位

业界模式看完，回到落地问题：我的 Agent 框架（开源的 Hermes）有没有官方支持的接入点？翻完源码（v0.21.5）答案是肯定的，机制叫 auxiliary 辅助模型系统，一共 20 个任务槽，每个可以独立指定 provider、model、base_url、api_key。和"决策"直接相关的槽位有六个：命令审批（approval）、代码审查（review）、任务分诊（triage_specifier）、目标达成判定（goal_judge）、技能生命周期处置（curator）、后台任务监控（monitor）。

其中我仔细读了命令审批的实现源码：输入 shell 命令文本，输出三选一，且对注入攻击有防御设计（先剥命令里的注释再送判，判定提示词明确要求忽略命令内嵌的指令）。这个实现和守门员模式严丝合缝——也就是说，框架层面已经为"判别式小模型做安检"留好了位置，只是默认塞的是云端 LLM。

我的挂载方案：一个槽位 + 一个协议垫片

把五种模式和自家槽位对完，我的方案收敛得很干净：

第一，Laya 挂进命令审批槽，走守门员模式。这是它唯一同时满足三个条件的槽位：高频调用（延迟收益大）、纯分类（能力对口）、失败安全（非标准输出自动转人工）。其余生成类槽位（标题生成、任务规格化）判别模型干不了，不碰。

第二，中间加一层约五十行的协议垫片。辅助槽位说的是 chat/completions 方言，Laya 说的是 System One 方言，直连对不上。垫片做两件事：把对话里的命令文本抽出来喂给 Laya 的 choice 原语，把判定结果映射回 APPROVE/DENY 两个标准词。

第三，上线前跑金标准测试，指标就一个：危险命令误放行率，必须为零。这是那篇生产综述给的铁律——裁判是承重墙，必须单独基准测试，不许跟着级联一起裸奔上线。业界所有级联事故，根因都是裁判没测就上线。误拦截偏高可以接受（多问几次人），误放行一次都不行。

第四，升级率上监控。误放行之外唯一的健康指标：正常流量下应该有相当比例的命令被小模型直接放行（省钱省时间），这个比例突然塌掉，要么命令分布变了，要么裁判坏了，要么有人在拿注入攻击探测你——三种情况都该收到告警。

给同样想挂的人三条原则

第一，按判断时机选模式，不按模型能力选模式。同一个模型，挂错位置就是负资产：判别模型挂到生成槽位是浪费，生成小模型挂到守门员位是延迟灾难。先看你的判断发生在请求生命周期的哪个时刻，再选模式，最后才轮到选模型。

第二，置信度门控是所有模式的公共件。路由要门控（低置信升级），裁判要校准（阈值用自己流量标定），守门员要兜底（非标准输出转人工）。大模型自报置信度天然失准，这条在上一篇 100 题测试里就踩过——门控线必须拿真实业务数据标，不能抄论文的数。

第三，升级率是唯一需要上监控的指标。小模型直答率、误升级率、人工转办率，三个数加一个告警阈值，比任何复杂的可观测性方案都管用。裁判坏了不会报错，只会让账单或质量悄悄变化——没有这个监控，你永远是最后一个知道的人。

回看这半年的路：先是给 Laya 出了 100 道中文题摸清能力边界，再是 66 题配对评测决定主力与备援，现在是把挂载位置从凭手感升级成按模式选。三篇连起来正好是一个完整的决策模型落地链路：选型、评比、集成。下一篇如果还有，应该是金标准测试的实测数据——五十条命令，Laya 的误放行率到底是不是零，到时候见分晓。