微软把分类系统拆了3层，企业AI路由突然能省钱了

去年一家金融公司的客服系统每天处理12万封邮件，其中78%是"账户锁定"这类标准问题。他们最初全部丢给云端大模型处理，账单月增340%。

后来工程师换了个思路：让本地小模型先筛一遍，只有"语义模糊、涉及合规"的邮件才上云。成本降到原来的19%，响应速度反而快了2.4倍。

这个案例暴露了一个被忽视的事实——企业分类问题的瓶颈从来不是模型够不够聪明，而是架构会不会"偷懒"。

从"输入→模型→标签"到三层代理

传统分类系统的设计简单得像自动售货机：塞进去请求，吐出来标签。这种模式在实验室跑分很漂亮，放进真实企业环境就开始水土不服。

真实场景里，同一批客服请求可能包含：密码重置（规则就能解决）、退款争议（需要查历史订单）、疑似欺诈（得调风控模型）、情绪激动的VIP客户（优先人工）。

用同一个模型处理所有情况，就像用手术刀切菜、用菜刀做手术——都能用，都别扭。

微软Azure AI团队最近推了一套"代理式路由"架构，把分类拆成三个角色：接收代理、推理代理、任务代理。每个代理只干自己最省力的活。

接收代理像医院分诊台，不做诊断，只看"这人该去内科还是外科"。它的核心指标是速度和成本，通常用本地轻量化模型或规则引擎。

推理代理是真正的调度中枢。它判断的不只是"这是什么类型"，而是"该用哪种处理方式、哪个模型、走什么流程"。

任务代理负责执行最终决策——可能是调用本地模型、唤醒云端大模型、或者转人工队列。

本地模型该守哪几道门

不是所有分类都值得上云。本地模型（这里指部署在企业内网的小参数模型）在四类场景里性价比极高：

第一，输入高度结构化。工单系统里的下拉菜单选项、API传来的标准字段、表单里的勾选框——这些用正则表达式或轻量模型就能解决，上云纯属浪费带宽。

第二，类别边界清晰且稳定。制造业的"设备故障代码分类"、物流的"包裹状态标记"，这类问题半年不变一次，本地模型训完就能长期服役。

第三，延迟敏感。产线质检的视觉分类、实时风控的毫秒级决策，走网络往返一趟可能就超时了。

第四，数据不能出境。医疗影像初筛、军工文档归类，合规红线画在那里，云端再强也用不了。

一位在券商做AI基础设施的工程师告诉我，他们把"新股申购资格校验"从云端迁到本地后，单笔查询成本从0.003美元降到0.00004美元，"省出来的钱够再养两个算法团队"。

云端模型的真正战场

云端大模型（如Azure OpenAI服务）的价值不在"能分类"，而在"能处理模糊性"。

当输入变成这样的时候，本地模型就开始吃力：客户邮件里同时抱怨"发货慢"和"包装破损"（多意图交织）、一段口语化的语音转文字充斥着方言和口误（噪声极高）、需要结合最新新闻事件判断舆情风险（上下文动态变化）。

更关键的是，云端模型能把"分类"扩展成"分类+推理+生成"。比如不仅判断"这是退款请求"，还能同步生成：退款原因摘要、建议处理方案、关联历史订单列表、风险提示等级。

这种能力在客服场景里直接省掉人工复核环节。某电商平台测试显示，接入云端推理代理后，"是否需要升级主管"的决策准确率从67%提升到89%，平均处理时长从14分钟压缩到4分钟。

但代价是成本曲线陡峭。如果让所有请求都走这条链路，账单会失控。

代理式架构的隐藏收益

三层代理设计最被低估的价值，是让系统具备"可进化性"。

传统硬编码的分类流水线，改一个规则可能要动十几处代码。代理架构里，你只需要调整推理代理的决策逻辑——比如新增一条"如果客户过去30天投诉超过3次，直接升优先级"，不需要重写接收代理或任务代理。

另一个隐性收益是审计友好。企业越来越需要解释"为什么这个请求被分到A类而不是B类"。代理架构天然保留了决策链条：接收代理看到了什么原始特征、推理代理调用了哪些判断条件、任务代理最终选择了哪条路径——全部可追溯。

数据治理也变得可操作。推理代理可以内置规则："含客户身份证号的数据不得离开内网""涉及欧盟用户的请求必须走法兰克福节点"。这些约束在硬编码系统里往往散落在各处，在代理架构里集中在一处决策点。

微软的文档里提到一个细节：某客户最初把"情感分析"全部放在云端，后来发现80%的文本情感极性非常明显（大量五星好评和一星差评），只有中间地带需要深度推理。把明显案例切回本地后，云调用量下降73%，而情感判断的F1分数只掉了0.3个百分点。

落地时的三个认知陷阱

这套架构听起来合理，实际部署时容易踩坑。

陷阱一：过度设计路由逻辑。有些团队把推理代理做得过于复杂，层层嵌套的条件判断反而拖慢整体速度。判断标准是：如果路由决策本身消耗的算力超过最终任务代理的30%，就该简化。

陷阱二：忽视反馈闭环。分类系统上线后，任务代理的执行结果（客户是否满意、是否被投诉、是否产生后续工单）应该回流给推理代理做校准。没有这层闭环，路由策略会快速过时。

陷阱三：把"本地"和"云端"对立起来。实际最优解往往是混合：同一个请求可能先过本地模型做初筛，再送云端做精修，最后回本地执行动作。某汽车厂商的售后系统就是这么设计的——本地模型识别"发动机故障"大类，云端模型细分为"具体哪个传感器异常"，最后本地系统调取维修手册生成工单。

一位在Azure做解决方案架构的工程师说，他们现在给客户做方案时，第一个问题从"你要用什么模型"变成了"你的请求里有多少比例是重复的、结构化的、敏感的"——这三个维度决定了本地和云端的切分比例。

分类系统的竞争，正在从"我的模型比你大"转向"我的架构比你省"。

当你的竞争对手还在用云端大模型处理每一封"密码重置"邮件时，你省下来的那81%成本，会变成什么？