一、背景:SOTA + Skill 范式的胜利与盲区

过去两年,AI 工具的构建范式逐渐收敛成一套标准配方:

选一个 SOTA 模型(GPT-4 / Claude / Gemini)+ 包装一层 Skill / Function Calling / MCP + 套一个对话或 Agent 外壳 = 一个 AI 工具。

这套范式在探索性场景里几乎是无可争议的最优解:写代码、做调研、生成内容、多轮规划——SOTA 模型的通用能力 + Skill 的工具扩展性,足以覆盖长尾需求。社区也围绕这套范式沉淀了大量实践:Prompt Engineering、ReAct、Tool Use、Agent Loop……

但当我们把目光从"探索性场景"移开,看向另一类场景时,这套范式开始露出盲区。

垂类非探索场景——企业内部对话网关、客服路由、工单分发、FAQ 应答、内部知识问答——它们有几个共同特征:

1. 输入分布窄:80% 的请求集中在 20% 的高频模式上("你好"、"谢谢"、"请假怎么请"、"报表在哪看")

2. 延迟敏感:用户期望秒回,4 秒以上的 SOTA 调用会被吐槽"卡"

3. 成本敏感:日均万级请求 × SOTA token 单价 = 一笔不小的账

4. 确定性优先:寒暄就该回寒暄,FAQ 就该回标准答案,不需要模型"发挥"

5. 可降级:模型挂了不能让业务挂,要有兜底

在这类场景里,用 SOTA 模型 + Skill 范式去接每一个请求,就像用一辆 F1 赛车去送外卖——能力溢出、成本高、还容易熄火。

本文记录的,就是我们在飞书 Agent 网关场景下,对这套范式之外的一次工程探索。

二、核心问题:简单问题也调用大模型,这个项目的意义是什么?

项目最初的形态很简单:一个 Sentence-BERT 零样本文本分类器,判断用户输入是"小任务"还是"大任务",然后分流到不同的处理路径。

但第一版上线后,一个尖锐的问题被抛了出来:

"简单问题也调用大模型,这个项目的意义是什么?"

这句话点破了一个被 SOTA 范式掩盖的事实——分类本身不是目的,跳过不必要的 LLM 调用才是目的。

如果一个用户说"你好",分类器判定它是 small_task,然后还是把它送给大模型生成一句"你好,有什么可以帮你?"——那分类器存在的意义是什么?只是多加了一层延迟而已。

真正有意义的是:让 80% 的简单请求根本不触达 LLM。

这个反思直接推动了项目的演进方向:从"分类"走向"分流",从"判断大小任务"走向"四层逐级兜底"。

三、探索:四层分流架构

最终的形态是一个四层分流架构,每一层未命中才进入下一层:

L1 规则直回(0ms · 0 token)
精确关键词匹配。寒暄、固定话术、紧急指令——这些不需要任何"智能"的场景,直接用模板返回。{input} 占位符支持轻度个性化。

L2 FAQ 语义检索(~10ms · 0 token)
复用已加载的 Sentence-BERT,把用户输入和 FAQ 库的问题向量做余弦相似度,≥ 0.75 即命中。关键洞察:分类器和 FAQ 检索共用同一个向量模型,不需要额外加载模型,边际成本几乎为零。

L3 小 LLM(~100-200ms · 低 token)
只有 small_task 才进入这一层。用 0.5B 级别的小模型(Qwen2.5-0.5B)处理简单推理:算术、格式转换、单轮问答。失败可 fallback_to_real 降级到大模型。

L4 大 LLM(~500ms-4s · 高 token)
big_task 直接到这一层,L3 失败也会到这里。大模型失败再降级到 Mock 兜底,保证业务可用性。

为什么是四层,而不是两层或六层

两层(小模型/大模型)解决不了零 token 路径——寒暄和 FAQ 这种根本不需要 LLM 的请求,会被强行塞进小模型,白白浪费 token 和延迟。

六层以上则进入过度工程的区间——每一层都是一次判断 + 一次潜在未命中,层数越多,长尾请求的累积延迟越高,维护成本也越高。

四层是一个甜点:L1/L2 覆盖零 token 快路径,L3/L4 覆盖需要 LLM 的慢路径,降级链路清晰。

一个关键设计:ModelHolder 单例

整个架构里有一个容易被忽视但很重要的角色——ModelHolder。

它是一个单例,懒加载 Sentence-BERT,并缓存三类向量:

• small/big 任务模板向量(分类用)

• FAQ 问题向量矩阵(L2 检索用)

• 配置变更时 recompute_faq() 重算

这意味着 L2 FAQ 检索的边际成本几乎是零——模型已经加载,向量已经缓存,只是多一次矩阵乘法。这是四层架构能成立的经济基础:如果每一层都要加载新模型,分层就失去意义了。

四、收益:量化对比

以日均 10,000 请求的内部网关为例,假设请求分布:

对比 SOTA 范式(所有请求都走大模型):

• 延迟:P50 从 ~2s 降到 ~10ms(L1/L2 命中),P95 从 ~4s 降到 ~2s(L4 分流)

• token 成本:节省约 55%(L1/L2 零 token + L3 低 token)

• 可用性:L4 失败有 Mock 兜底,SOTA 范式则直接挂

更重要的收益是可观测性——每一层命中都在 trace 里用不同颜色标记(L1 琥珀、L2/L3 薄荷绿、L4 青色、降级玫红),运维可以清楚看到流量在每一层的分布,针对性地调阈值、补 FAQ、优化小模型。

五、反思:什么时候不该用这套架构

这套架构不是银弹,它有明确的适用边界。

适用:输入分布窄、延迟敏感、成本敏感、确定性优先的垂类非探索场景。典型如企业内部网关、客服路由、FAQ 应答、工单分发。

不适用:

• 探索性场景(写代码、做调研、创作)——长尾占比高,分层反而增加延迟

• 输入分布完全未知的新业务——没有数据支撑 FAQ 库和规则模板

• 对"发挥性"有要求的场景——创意写作、头脑风暴,确定性反而是缺点

一个简单的判断标准:如果用户经常说"帮我……一下"这类开放性请求,用 SOTA 范式;如果用户大部分时候在问"……怎么……"这类重复性问题,用分流范式。

六、结语:在 SOTA 之外,寻找工程的空间

SOTA 模型 + Skill 是过去两年 AI 工具构建的主流叙事,它解决了"能不能"的问题。但当 AI 工具从 Demo 走向生产、从通用走向垂类、从探索走向确定性时,"能不能"不再是唯一的问题——"贵不贵"、"快不快"、"稳不稳"同样重要。

四层分流不是对 SOTA 范式的否定,而是对它的补充。SOTA 模型依然在 L4 兜底,依然处理最复杂的 25% 请求。但那 75% 的简单请求,不再需要劳驾它了。

这或许是工程的本分——在能力溢出的时代,把合适的能力放到合适的请求上。

其他-流转图