1. 从什么都问大模型说起Agent 架构里那个被忽视的裂缝做 Agent 开发的人大概都经历过这样一个阶段手里有了一个能力还不错的大模型第一反应就是把它当成万能引擎——意图识别交给它、任务规划交给它、工具选择交给它、参数填充交给它、结果校验还交给它。整个 Agent 跑起来本质上就是大模型在不停地自言自语中间穿插几次工具调用。这种架构在 Demo 阶段看起来很美因为流程简单、代码量少、效果也还过得去。但只要把 Agent 放到真实场景里跑上一段时间问题就会集中爆发。最典型的表现是响应延迟忽高忽低同样的输入今天跑得通明天跑不通工具调用的参数偶尔会莫名其妙地错位多轮任务里模型会忘记前面已经确认过的约束条件。更让人头疼的是你很难定位问题到底出在哪一环——因为所有环节都是同一个大模型在做决策它既是运动员又是裁判出了问题只能靠反复调提示词去碰。Jev 这个项目给出的思路恰恰是冲着这个裂缝来的。它的核心主张可以概括成一句话Agent 里不该什么都交给大模型该用 System One Model 的地方就用 System One Model。这里的 System One Model 借用了认知心理学里系统一的概念——快速、直觉、低成本、模式化的决策对应到工程上就是那些小而专的模型或规则模块而大模型则承担系统二的角色——慢速、深思、高成本、需要推理的复杂决策。这个划分听起来像是老生常谈的分工但真正落地到 Agent 架构里它带来的变化是结构性的。我最初接触这个思路时也犯嘀咕小模型能力那么弱能扛得住吗后来在实际项目里把一部分决策从大模型手里抢出来交给轻量模块之后才真正理解 Jev 想表达的东西——不是小模型更强而是很多决策压根不需要那么强的模型。这篇文章我会围绕 Jev 的核心主张把Agent 里什么该交给大模型、什么不该这件事拆开讲透。包括 System One Model 到底指什么、它在 Agent 执行链路里应该插在哪些位置、怎么判断一个决策该归谁、以及我在实际改造 Agent 时踩过的坑。适合正在做 Agent 开发、被延迟和稳定性折磨过、或者正在选型 Agent 框架的同行参考。2. System One Model 到底指什么不是小模型是快决策层2.1 认知隐喻背后的工程含义很多人第一次听到 System One Model会下意识理解成一个小参数量的模型。这个理解不算错但太窄了。Jev 语境下的 System One Model本质是一个决策层的抽象它可以由以下几种东西实现一个微调过的小模型比如几亿参数级别的分类或抽取模型一套确定性的规则引擎一个向量检索加阈值判断的匹配模块甚至就是一段写死的状态机逻辑关键不在于它是不是模型而在于它承担的角色在毫秒级时间内对高频、模式化、边界清晰的决策给出稳定答案。大模型则被解放出来专门处理那些真正需要推理、需要跨域知识、需要处理模糊语义的任务。我在实际项目里做过一个粗略统计一个典型的客服类 Agent单次完整任务链路里大约有 60% 到 70% 的决策点其实是模式化的。比如判断用户这句话是咨询还是投诉、判断当前该走退款流程还是查询流程、判断某个字段有没有填完整。这些决策用大模型做每次都要几百毫秒到几秒而且结果还会因为提示词的微小变化而漂移。换成轻量模块之后这部分耗时直接压到了个位数毫秒而且结果稳定得像开关一样。2.2 为什么快决策层必须独立存在这里有个反直觉的点值得说清楚。很多人会觉得既然大模型能力这么强让它顺手把简单决策也做了不是更省事吗为什么要额外维护一套 System One Model原因有三个而且都是工程上绕不开的第一成本结构完全不同。大模型的推理成本是按 token 算的而且随着上下文变长成本是超线性增长的。一个 Agent 如果每轮都把完整历史塞给大模型做意图判断token 消耗会迅速失控。System One Model 处理同样的判断成本可能只有前者的百分之一甚至更低。第二稳定性要求不同。大模型是概率性的同样的输入在不同温度、不同上下文下可能给出不同结果。但 Agent 里很多决策是必须确定的——比如权限校验、流程分支、字段格式判断。这些地方用大模型等于把确定性交给了概率迟早出事。第三可观测性不同。当所有决策都藏在大模型的黑盒里你没法知道它为什么这么选。而 System One Model 是白盒的规则就是规则分类就是分类出问题能直接定位到具体模块。提示判断一个决策该不该下沉到 System One Model我常用的标准是——如果这个决策用如果……那么……能写清楚且不需要跨领域知识那它就不该占用大模型。2.3 大模型在 Agent 里的正确位置把 System One Model 抽出来之后大模型的职责反而更清晰了。它应该专注在开放式任务规划面对模糊目标时拆解步骤跨工具推理需要综合多个工具返回结果做判断自然语言生成最终面向用户的表达异常兜底当 System One Model 无法处理时接管这个划分不是拍脑袋定的而是基于一个朴素的事实大模型的强项是处理没见过的情况弱项是处理见过一万次的情况。让它在自己弱项上反复消耗既贵又不稳。3. 把决策从大模型手里抢出来Jev 思路的落地拆解3.1 先画清楚 Agent 的决策点地图在动手改造之前我建议先做一件事把你现有 Agent 的完整执行链路画出来标出每一个需要做判断的节点。这一步看起来笨但极其关键因为很多决策点是隐性的藏在提示词里你不画出来根本意识不到。我自己的做法是拿一张纸从左到右写用户输入 → 意图识别 → 任务规划 → 工具选择 → 参数构造 → 工具执行 → 结果解析 → 结果校验 → 回复生成。然后在每个箭头下面标注这里谁在做决策。画完之后你会发现大模型几乎无处不在。接下来对每个决策点问三个问题判断维度该下沉 System One该留给大模型决策是否模式化是可枚举否开放是否需要跨域知识不需要需要错误代价高必须确定可容忍模糊调用频率高频低频延迟敏感度高低三个问题里有两个以上指向该下沉那就把它从大模型手里拿出来。3.2 意图识别是最该被下沉的一环意图识别几乎是所有 Agent 的第一道关卡也是最典型的高频模式化决策。用户说的话千变万化但落到意图上往往就那么十几二十类。我见过太多项目用大模型做意图识别提示词写得老长还要求输出 JSON。结果就是每次调用都要几百毫秒而且模型偶尔会发挥输出一个你没定义的意图。改成 System One Model 之后做法通常是收集历史对话人工标注意图类别用轻量模型做分类微调或者直接用向量检索加阈值设置一个置信度阈值低于阈值的才转交大模型兜底这个改造的收益非常直接。我经手的一个项目意图识别从大模型换成微调小模型后单次耗时从 800ms 降到 30ms准确率反而从 91% 提升到 96%——因为小模型在封闭类别上不会想太多。3.3 参数构造和校验规则能做的别让模型猜工具调用的参数构造是另一个重灾区。大模型经常会把参数填错、漏填、或者格式不对。比如日期格式你要求YYYY-MM-DD它可能给你2024年3月5日你要求数字它可能给你带单位的字符串。这些问题的本质是参数构造和校验是确定性问题不该用概率方法解决。Jev 的思路在这里体现得很明显——参数从对话里抽取可以用模型但抽取之后的格式校验、必填检查、类型转换全部交给 System One Model这里就是规则层。我的做法是分两步第一步用轻量抽取模型把原始值抽出来第二步用一套 schema 校验规则做清洗和补全。校验不通过就触发追问而不是让大模型再试一次。这样做的结果是工具调用的失败率从原来的 15% 左右降到了 3% 以下。3.4 结果校验别让大模型自己给自己打分还有一个容易被忽略的点是结果校验。很多 Agent 在工具返回结果后会让大模型判断这个结果是否合理。这其实是个陷阱——大模型既生成了调用意图又来评判调用结果等于自己给自己打分很容易出现明明错了却说对的情况。更稳的做法是把校验规则外置。比如工具返回了订单列表校验规则就是列表非空、字段完整、金额为正。这些用规则判断几行代码的事比大模型判断快得多也准得多。只有规则无法覆盖的语义合理性判断才交给大模型。4. 大模型和 System One Model 怎么协作编排层的设计4.1 不是二选一而是分层路由把决策下沉不代表大模型就不重要了。真正难的是怎么让两者协作得自然。Jev 的思路里编排层Orchestration Layer是关键它负责决定每个请求该走哪条路。我实践下来比较稳的一种结构是三级路由第一级规则命中。如果请求能直接被规则匹配比如明确的命令式输入直接走 System One Model不惊动大模型。第二级轻量模型判断。规则没命中交给轻量模型做意图和槽位判断置信度高就直接执行。第三级大模型接管。前两级都搞不定或者置信度低才把完整上下文交给大模型做深度推理。这个结构的好处是大部分请求在前两级就被消化了大模型只在真正需要的时候被调用。我实测下来大模型的调用量能降到原来的 30% 左右整体延迟下降一半以上。4.2 上下文传递别把整个历史都塞过去分层路由之后一个必须解决的问题是上下文怎么传。很多人的习惯是把完整对话历史一股脑塞给大模型这在分层架构里是浪费。我的做法是System One Model 处理完之后只把结构化的中间结果传给下一层而不是原始对话。比如意图识别完传下去的是{intent: refund, confidence: 0.95, slots: {...}}而不是用户原话。这样大模型拿到的上下文更干净推理也更快。注意结构化传递的前提是你的 System One Model 输出格式要稳定。如果它输出不稳定下游会更乱。所以下沉的模块一定要有严格的输出 schema。4.3 兜底策略大模型接管时的边界大模型接管不是无条件的。我在项目里会设置几个明确的兜底触发条件轻量模型置信度低于阈值连续两轮 System One Model 无法推进任务用户明确表达了超出预设范围的需求工具返回了 System One Model 无法解析的异常触发兜底时我会把前面所有层的中间结果一起打包给大模型让它知道前面已经试过什么、卡在哪。这样大模型不会重复劳动接管效率更高。5. 实测中的坑下沉决策没那么简单5.1 坑一下沉过头System One Model 变成规则地狱我最早做下沉的时候犯过一个典型错误——把太多东西塞进规则里。结果规则文件越写越长分支越来越多最后维护成本比用大模型还高。有一次改一个判断逻辑牵动了七八条规则改完还引入了新 bug。后来我总结出一个边界System One Model 只处理稳定且高频的决策。如果一个决策的规则经常变或者出现频率很低那它就不适合下沉。判断标准很简单——如果这条规则三个月内改了三次以上就该考虑把它交回大模型。5.2 坑二轻量模型和规则打架另一个坑是轻量模型和规则层的职责重叠。比如轻量模型判断意图是退款但规则层根据某些字段判断应该是换货两者冲突时听谁的我的处理方式是明确优先级规则层永远优先于模型层。因为规则是确定性的模型是概率性的。当规则明确命中时直接覆盖模型判断。这个原则定下来之后冲突问题基本消失了。5.3 坑三可观测性没跟上出问题还是抓瞎下沉之后链路变长了如果没有配套的日志和追踪出问题反而更难查。我吃过这个亏——一个请求走了规则、轻量模型、大模型三层最后结果不对但我不知道是哪一层出的错。后来我强制要求每一层都输出结构化的决策日志包括输入、输出、耗时、置信度。这样出问题时直接看日志就能定位到具体层。这个投入非常值尤其是在多轮任务里能省下大量排查时间。5.4 坑四忽略了大模型的冷启动价值还有一个认知上的坑。有些人下沉之后觉得大模型可以完全不要了全用规则和小模型。这也不对。大模型在冷启动阶段的价值是不可替代的——当你还没有足够数据训练轻量模型时大模型能帮你快速跑通流程、积累数据。我的建议是先用大模型跑通收集数据再逐步下沉。不要一上来就追求完美分层那样反而会拖慢进度。6. 从 Jev 的思路往外延Agent 架构的下一步6.1 分层不是终点动态调度才是Jev 给出的分层思路解决的是什么该交给谁的问题。但真实场景里这个边界不是固定的。同一个决策在系统负载低的时候可以交给大模型负载高的时候就得下沉。所以下一步一定是动态调度——根据当前负载、置信度、历史表现实时决定每个决策走哪条路。我最近在尝试的一个方向是给每个决策点维护一个路由策略策略本身可以根据运行时指标调整。比如某个轻量模型最近准确率下降了就自动提高它转交大模型的比例。这套东西还在打磨但方向我觉得是对的。6.2 数据回流让下沉的模块越用越准System One Model 要持续好用必须有数据回流机制。每次大模型接管之后它的决策结果应该被记录下来作为轻量模型的训练数据。这样轻量模型能不断覆盖新的模式下沉的比例也能逐步提高。我在项目里搭了一个简单的回流管道大模型接管的 case 自动打标定期增量训练轻量模型训练完做 A/B 对比效果达标就替换线上。这个循环跑起来之后轻量模型的覆盖率每个月都能涨几个百分点。6.3 别把 System One Model 理解成降级方案最后想说一个观念上的事。很多人把 System One Model 当成大模型不够用时的降级方案这个理解是反的。它应该是一等公民是 Agent 架构里和大模型平级的存在。大模型负责它擅长的System One Model 负责它擅长的两者各司其职而不是谁替代谁。我在实际项目里最大的体会是Agent 的稳定性往往不取决于大模型有多强而取决于你把多少决策从大模型手里拿了出来。大模型是 Agent 的大脑但大脑不该管心跳和呼吸。那些基础的生命维持功能交给更底层、更稳定的机制去做整个系统才能跑得久、跑得稳。如果你现在正在被 Agent 的延迟和稳定性折磨不妨先做一件事把执行链路画出来数一数有多少决策点其实根本不需要大模型。我敢打赌这个数字会让你吃惊。
