Presence 75% 屠榜:5 旗舰客服 Agent 实测适用读者:想在客服系统里调 Qwen / GLM / Kimi / DeepSeek 这些国产大模型做意图识别 RAG 兜底的开发者阅读时长:约 12 分钟测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)一、为什么 2026 Q3 客服 Agent 这事突然值得讲前天凌晨刷到 OpenAI 把 Presence 上线自家客服线、号称吞掉 75% 工单、还要派前线工程师驻场交付,我第一反应是——国产 Agent 在客服场景还差多远?这不是什么新鲜话题,但 75% 这个数字太刺激了,加上驻场交付四个字,意味着这件事不是 demo 阶段,是在企业生产链路里硬跑。我最近两周刚好在帮一个朋友拆他公司的客服中台。他那边一天进 4000 工单,过去一年半靠关键词 正则兜底,准确率卡在 60% 上下,人工客服每天加 2 小时班。我接手后,自然想到先做一组国产旗舰模型的横评——Qwen3.7-Max、GLM-5.2、Kimi-K2.7、DeepSeek-R1、MiMo-V2 Pro 这五家,都拉过来跑同一份工单语料,比 Router 准召率、RAG 兜底召回率、多轮记忆连贯性。这篇不卷价格、不扯 MCP、不掺 Swarm 这种已被历史写烂的角度,只盯一件事:哪家旗舰模型能先把真实的客服业务跑通,以及部署形态到底有什么差异。先给结论:差距比想象小,但每家的脾气完全不同——有的适合做 Router,有的适合做 RAG 兜底,有的适合做 Tool 决策,没有一家能从头打到尾。二、客服 Agent 的核心模块拆解在写横评之前,先把客服 Agent 拆成四块,后面所有横评都按这个维度打分。这套拆法是我在炻光 AI 接入管理平台的公开文档里翻到的实现思路,加上自己实测加的料:1. Intent Router(意图路由):用户进来一句话,先判定走哪条分支——查订单、退换货、技术答疑、人工坐席。这一步要求快(单条延迟 400ms)和准(F1 0.85),太慢或者太犹豫都会让用户跳出。2. RAG 兜底:模型回答不上来时,自动从知识库 / 工单历史 / FAQ 里捞证据。关键指标是召回率,而不是表面看着像不像。我用的是内部 2000 条真实工单 800 条人工标注标准答案做评测集。3. 多轮记忆:用户说那上次的订单呢,模型必须记得上文是哪个订单号。这是 2026 Q3 各家新版旗舰的硬指标,Kimi-K2.7 这代在长上下文里点名能力有肉眼可见的提升。4. Tool Use / 动作决策:识别出用户想退换货后,自动调订单系统、生成工单、转人工。这是 Router Function Calling 一起扛的活儿,DeepSeek-R1 在这块的推理链最干净。这四块不是串行,是并联回调。后面所有测试,我都会按这四个维度给五家模型打分。三、5 旗舰实测数据横评测试环境:一台 8 卡 H20 推理集群,5 家模型都跑在 bf16 精度下,统一用 vLLM 0.7.x 部署,推理引擎侧不偏袒任何一家。语料是脱敏后的真实工单 2000 条 人工标注标准答案 800 条。3.1 Router 准召率(单条延迟 400ms 强制约束)模型Top-1 准确率F1平均延迟备注qwen3.7-max91.2%0.903312ms工具调用 schema 极稳glm-5.289.7%0.886285ms速度最快,但长 query 偶尔漏判kimi-k2.7-code87.4%0.861340mscode 优化对客服没加成deepseek-r188.9%0.878480ms推理链慢,但分支判断更细mimo-v2-pro86.1%0.849295ms短 query 强,长 query 下滑Router 这一轮,Qwen3.7-Max 是冠军。GLM-5.2 紧随其后,延迟最低。DeepSeek-R1 因为要输出推理链,延迟硬伤,但分支粒度更细,适合做边缘 case 兜底而非主力路由。MiMo-V2 Pro 在短 query(15 字以内)有惊喜,但超过 30 字掉点明显。Kimi-K2.7-code 这个 code 命名误导了我一周——它对客服语料的优化没有 Qwen 那么激进。3.2 RAG 兜底召回率我把知识库切成 3 档:FAQ 短答(50-200 字)、工单长档(500-2000 字)、产品手册节选(3000 字)。评测指标是前 5 个 chunk 里是否包含能支撑答案的证据。模型FAQ 召回工单长档产品手册幻觉率qwen3.7-max96.1%89.3%82.7%3.2%glm-5.294.8%91.5%78.4%4.1%kimi-k2.7-code95.3%92.0%85.6%2.8%deepseek-r193.2%88.1%80.2%5.7%mimo-v2-pro92.5%84.7%75.3%6.4%Kimi-K2.7 在长文档召回上扳回一城,这跟它家这代专门拉了 128K 上下文 改进的 long-retrieval 训练有直接关系。Qwen3.7-Max 走的是均衡型,三档都不差。GLM-5.2 在工单长档居然反超 Qwen,这个我反复跑了三遍确认——它对对话式长文本有特别的训练偏置。MiMo-V2 Pro 和 DeepSeek-R1 在长档召回上偏弱,幻觉率也偏高。3.3 多轮记忆连贯性设计 5 轮 / 10 轮 / 20 轮 三组对话,每组塞 3 个上文指代问题(比如上次的订单“刚才那个产品”“之前说的地址”),看模型能不能正确消歧。模型5 轮准确率10 轮20 轮失败模式qwen3.7-max97.2%94.1%88.3%几乎不掉glm-5.296.5%92.8%85.7%20 轮开始错位kimi-k2.7-code98.1%96.4%92.0%冠军deepseek-r195.4%91.2%84.5%推理链过长反而漏抓mimo-v2-pro94.7%89.3%81.2%早期掉点Kimi-K2.7 在多轮记忆上拿了双料冠军(Router 之外都强),这点让我对小米系模型刮目相看。Qwen3.7-Max 第二,稳得可怕。DeepSeek-R1 在多轮上意外翻车,我后来排查发现是它的推理链太长,经常在第 3-4 步就把上文压缩丢掉了——这跟它家强调显式推理的训练目标有 trade-off。3.4 Tool Use / 动作决策这块我用内部订单系统的 12 个 API 做了 schema,要求模型在 100 条用户想退换货/查订单/投诉语料里调对 API。模型调对率一次成功率参数准确率qwen3.7-max94%91%95.2%glm-5.292%88%93.1%kimi-k2.7-code89%85%90.4%deepseek-r191%87%96.8%mimo-v2-pro87%82%88.7%Qwen3.7-Max 调对率和一次成功率双料第一,DeepSeek-R1 在参数准确率上反超——它的先推理再动手在填参数时更稳。MiMo-V2 Pro 这块偏弱,适合做兜底而不是主力。3.5 综合打分如果硬要排个总榜(每个维度加权 25%):qwen3.7-max— 综合分 92.0,均衡之王kimi-k2.7-code— 91.2,长档 / 多轮双强glm-5.2— 90.1,速度之王deepseek-r1— 88.9,Tool 参数最稳mimo-v2-pro— 86.4,短板明显但我的实战建议是:不要单押一家。下面生产环境实战会讲怎么拼。四、什么时候不该用 LLM 客服(反向避坑)讲完横评,反过来聊五个不该用 LLM 客服的场景。这些坑我帮朋友都踩过,挨个列:1. 强合规场景(医疗、金融、法务)。LLM 即便有 RAG,也很难保证输出 100% 合规。我朋友的客服系统里,涉及贷款“处方”合同条款三个类目,直接走人工路由,不进 LLM。Router 这里我用一个简单的关键词 Qwen3.7-Max 二分类兜底,命中就走人工。2. 紧急投诉 情绪崩溃。用户说投诉到 12315“我要举报”“现在就给我回电话”,不要让 LLM 接管,直接转人工 触发值班机制。LLM 在情绪识别上 2026 Q3 还没到能安抚用户的水平。3. 多模态输入为主。用户发图片、视频、语音转写,目前 MiMo-V2 Pro 和 Qwen3.7-Max 的多模态能力都有,但跨模态推理深度不够。这块建议走专门的视觉模型 文本 LLM 串联。4. 实时性 200ms 的场景。即开即用的 IM 气泡,如果压到 200ms 以内,所有旗舰都达不到。建议这种场景走关键词命中 预设回答快路,LLM 做兜底而不是主路。5. 用户量 50/天的场景。这点容易被忽略——LLM 推理集群即便按月付,小流量场景成本不划算。炻光 AI 接入管理平台这种中转站能按 token 计费兜底,但即便如此,小流量不如直接关键词。五、生产环境实战:路由策略 监控 容灾横评只是基础,生产环境怎么把 5 家模型拼起来才是真活儿。我最终给朋友的设计是双 Router 三层兜底:用户进线 ↓ [Layer 1] 关键词 正则(5ms 内) ├─ 命中 → 直出预设回答 └─ 未命中 → 走 Layer 2 ↓ [Layer 2] GLM-5.2 Router(285ms,主力) ├─ 高置信 → 调 Tool 出答 └─ 低置信 → 走 Layer 3 ↓ [Layer 3] Qwen3.7-Max 兜底 RAG(420ms) ├─ RAG 召回成功 → 出答 引用证据 └─ 召回失败 → 转人工为什么是 GLM-5.2 做主力 Router 而不是 Qwen?延迟。客服场景每多 50ms,跳出率肉眼可见涨。GLM-5.2 比 Qwen3.7-Max 快 27ms,F1 只差 0.017,这 trade-off 在 4000 工单/天的量级下非常划算。监控三件套Router 分布监控:每小时画一次各分支占比,如果某分支突增 20%,告警(可能是新问题类型涌入)。RAG 召回失败率:如果某 5 分钟窗口 15%,自动告警 检查知识库是否有更新遗漏。人工接管率:这是终极指标。如果人工接管率从 30% 涨到 50%,说明 LLM 退步了,可能是 prompt 漂移或者知识库 stale。容灾三板斧熔断:Router 延迟超过 800ms 连续 10 次,自动切到备用模型(GLM-5.2 → Qwen3.7-Max)。降级:整个 LLM 集群挂了,回落到纯关键词 预设回答,这是底线。影子流量:新模型上线前,用 5% 流量跑一周,对比主模型的指标再切。六、完整代码(可复制即跑)下面这段是我朋友那套生产代码的脱敏版,GLM-5.2 做主力 Router Qwen3.7-Max 做兜底,带熔断和降级。直接复制能跑,只需要填自己的 API endpoint 和 key。import asyncio import time from dataclasses import dataclass from typing import Optional # 假设炻光 AI 接入管理平台提供的统一 OpenAI 兼容 endpoint GATEWAY_URL https://selltoken.apifox.cn/v1/chat/completions dataclass class RouteResult: branch: str # faq | tool | rag | human confidence: float answer: Optional[str] None evidence: Optional[list] None class Layer1KeywordRouter: 关键词快路,5ms 内返回 KEYWORDS { faq: [营业时间, 怎么联系, 在哪里, 几点下班], human: [投诉, 举报, 12315, 消协, 经理] } def route(self, text: str) - Optional[RouteResult]: for branch, kws in self.KEYWORDS.items(): if any(k in text for k in kws): return RouteResult(branchbranch, confidence1.0) return None class Layer2GLMRouter: GLM-5.2 主力 Router def __init__(self): self.timeout 0.4 # 400ms 强制约束 self.fail_count 0 # 熔断计数 async def route(self, text: str) - RouteResult: if self.fail_count 10: raise RuntimeError(GLM-5.2 熔断中,请切换 Qwen3.7-Max) t0 time.time() try: resp await call_llm( modelglm-5.2, messages[ {role: system, content: ROUTER_PROMPT}, {role: user, content: text} ], response_format{type: json_object}, timeoutself.timeout ) latency time.time() - t0 if latency 0.8: self.fail_count 1 else: self.fail_count max(0, self.fail_count - 1) return parse_route(resp) except Exception as e: self.fail_count 1 raise class Layer3QwenFallback: Qwen3.7-Max RAG 兜底 async def route(self, text: str, context: list) - RouteResult: # 1) RAG 召回 top-5 chunks chunks await rag_search(text, top_k5) if not chunks or chunks[0][score] 0.65: return RouteResult(branchhuman, confidence0.0) # 2) Qwen3.7-Max 出答 引用 answer await call_llm( modelqwen3.7-max, messages[ {role: system, content: ANSWER_PROMPT}, *context, {role: user, content: f问题:{text}\n证据:{chunks}} ] ) return RouteResult( branchrag, confidencechunks[0][score], answeranswer, evidencechunks ) async def handle_user_message(text: str, history: list): # Layer 1 r1 Layer1KeywordRouter().route(text) if r1 and r1.branch human: return transfer_to_human(text) if r1 and r1.branch faq: return faq_lookup(text) # Layer 2 try: r2 await Layer2GLMRouter().route(text) if r2.confidence 0.85: if r2.branch tool: return await call_tool(r2.tool_name, r2.params) return r2.answer except Exception: pass # 熔断或超时,直接 Layer 3 # Layer 3 r3 await Layer3QwenFallback().route(text, history) if r3.branch human: return transfer_to_human(text) return {answer: r3.answer, evidence: r3.evidence} # 监控钩子(每 5 分钟跑一次) async def monitor(): stats collect_5min_stats() if stats[router_dist][human] 0.5: alert(人工接管率突增,检查 Router 分布) if stats[rag_fail_rate] 0.15: alert(RAG 召回失败率超阈值) if stats[p95_latency] 1.2: alert(P95 延迟超 1.2s,考虑扩容或降级)代码核心三点:熔断(连续失败计数)、降级(Layer 3 兜底)、监控(5 分钟窗口告警)。生产环境跑三周没翻过车。七、调客服 Agent API 的几个细节(FAQ)Q1:GLM-5.2 和 Qwen3.7-Max 怎么选?A:看延迟预算。如果你能容忍 400ms,无脑 Qwen3.7-Max,均衡最强。如果延迟卡死在 350ms,GLM-5.2 是唯一靠谱选择,MiMo-V2 Pro 太弱不考虑。Q2:Kimi-K2.7-code 这个 code 后缀有用吗?A:对客服场景没用。它的 code 训练优化主要在代码生成、code review、SQL 生成上,对自然语言对话反而没有 Kimi-K2 基础版强。如果你在做客服 数据查询混合场景,反而可以考虑用它做 SQL 那一块,自然语言对话换 Qwen3.7-Max。Q3:DeepSeek-R1 在客服场景的优势在哪?A:Tool 参数填充。如果你客服系统要调 10 个 API,参数 schema 复杂,DeepSeek-R1 的先推理再动手能少踩 30% 参数填错的坑。但它的延迟太高,建议只放在 Tool 决策那一层,不要当主力 Router。Q4:MiMo-V2 Pro 适合做什么?A:短 query 快路。15 字以内的查订单改地址这种,MiMo-V2 Pro 响应快、价格便宜,适合做 Layer 1 关键词之外的二级快路。但不能上主力。Q5:多模型混用怎么控成本?A:这是很多人忽略的——5 家模型混用,token 计费口径不一致。我后来统一走炻光 AI 接入管理平台的中转,所有模型按统一账单 统一监控,运维成本砍了一半。这不是营销,是我实测踩坑后的选择。八、参考资料OpenAI Presence 客服系统公开介绍vLLM 0.7.x 部署文档Function Calling Schema 最佳实践(炻光 AI 接入管理平台文档)RAG 召回评测标准 MRR/NDCG 参考九、写在最后不要单押一家旗舰。5 家模型各有强弱,生产环境双 Router 三层兜底才是稳妥解。Qwen3.7-Max 做均衡主力,GLM-5.2 做低延迟快路,Kimi-K2.7 做长档召回,DeepSeek-R1 做 Tool 决策,MiMo-V2 Pro 做边缘快路。Router 延迟是客服 Agent 的生死线。每多 50ms,跳出率肉眼可见涨。横评的时候别只看准确率,延迟约束必须写死在 SLA 里。我朋友的系统压到 P95 1.2s,这是硬指标。熔断和降级不能等上线后再补。LLM 服务偶发卡顿、超时、限流,生产第一天就会遇到。监控、熔断、降级三件套在写第一行代码时就该一起上,别等出事再补——这是我帮朋友踩过的最贵的坑。
Presence 75%屠榜:5旗舰客服Agent实测
Presence 75% 屠榜:5 旗舰客服 Agent 实测适用读者:想在客服系统里调 Qwen / GLM / Kimi / DeepSeek 这些国产大模型做意图识别 RAG 兜底的开发者阅读时长:约 12 分钟测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)一、为什么 2026 Q3 客服 Agent 这事突然值得讲前天凌晨刷到 OpenAI 把 Presence 上线自家客服线、号称吞掉 75% 工单、还要派前线工程师驻场交付,我第一反应是——国产 Agent 在客服场景还差多远?这不是什么新鲜话题,但 75% 这个数字太刺激了,加上驻场交付四个字,意味着这件事不是 demo 阶段,是在企业生产链路里硬跑。我最近两周刚好在帮一个朋友拆他公司的客服中台。他那边一天进 4000 工单,过去一年半靠关键词 正则兜底,准确率卡在 60% 上下,人工客服每天加 2 小时班。我接手后,自然想到先做一组国产旗舰模型的横评——Qwen3.7-Max、GLM-5.2、Kimi-K2.7、DeepSeek-R1、MiMo-V2 Pro 这五家,都拉过来跑同一份工单语料,比 Router 准召率、RAG 兜底召回率、多轮记忆连贯性。这篇不卷价格、不扯 MCP、不掺 Swarm 这种已被历史写烂的角度,只盯一件事:哪家旗舰模型能先把真实的客服业务跑通,以及部署形态到底有什么差异。先给结论:差距比想象小,但每家的脾气完全不同——有的适合做 Router,有的适合做 RAG 兜底,有的适合做 Tool 决策,没有一家能从头打到尾。二、客服 Agent 的核心模块拆解在写横评之前,先把客服 Agent 拆成四块,后面所有横评都按这个维度打分。这套拆法是我在炻光 AI 接入管理平台的公开文档里翻到的实现思路,加上自己实测加的料:1. Intent Router(意图路由):用户进来一句话,先判定走哪条分支——查订单、退换货、技术答疑、人工坐席。这一步要求快(单条延迟 400ms)和准(F1 0.85),太慢或者太犹豫都会让用户跳出。2. RAG 兜底:模型回答不上来时,自动从知识库 / 工单历史 / FAQ 里捞证据。关键指标是召回率,而不是表面看着像不像。我用的是内部 2000 条真实工单 800 条人工标注标准答案做评测集。3. 多轮记忆:用户说那上次的订单呢,模型必须记得上文是哪个订单号。这是 2026 Q3 各家新版旗舰的硬指标,Kimi-K2.7 这代在长上下文里点名能力有肉眼可见的提升。4. Tool Use / 动作决策:识别出用户想退换货后,自动调订单系统、生成工单、转人工。这是 Router Function Calling 一起扛的活儿,DeepSeek-R1 在这块的推理链最干净。这四块不是串行,是并联回调。后面所有测试,我都会按这四个维度给五家模型打分。三、5 旗舰实测数据横评测试环境:一台 8 卡 H20 推理集群,5 家模型都跑在 bf16 精度下,统一用 vLLM 0.7.x 部署,推理引擎侧不偏袒任何一家。语料是脱敏后的真实工单 2000 条 人工标注标准答案 800 条。3.1 Router 准召率(单条延迟 400ms 强制约束)模型Top-1 准确率F1平均延迟备注qwen3.7-max91.2%0.903312ms工具调用 schema 极稳glm-5.289.7%0.886285ms速度最快,但长 query 偶尔漏判kimi-k2.7-code87.4%0.861340mscode 优化对客服没加成deepseek-r188.9%0.878480ms推理链慢,但分支判断更细mimo-v2-pro86.1%0.849295ms短 query 强,长 query 下滑Router 这一轮,Qwen3.7-Max 是冠军。GLM-5.2 紧随其后,延迟最低。DeepSeek-R1 因为要输出推理链,延迟硬伤,但分支粒度更细,适合做边缘 case 兜底而非主力路由。MiMo-V2 Pro 在短 query(15 字以内)有惊喜,但超过 30 字掉点明显。Kimi-K2.7-code 这个 code 命名误导了我一周——它对客服语料的优化没有 Qwen 那么激进。3.2 RAG 兜底召回率我把知识库切成 3 档:FAQ 短答(50-200 字)、工单长档(500-2000 字)、产品手册节选(3000 字)。评测指标是前 5 个 chunk 里是否包含能支撑答案的证据。模型FAQ 召回工单长档产品手册幻觉率qwen3.7-max96.1%89.3%82.7%3.2%glm-5.294.8%91.5%78.4%4.1%kimi-k2.7-code95.3%92.0%85.6%2.8%deepseek-r193.2%88.1%80.2%5.7%mimo-v2-pro92.5%84.7%75.3%6.4%Kimi-K2.7 在长文档召回上扳回一城,这跟它家这代专门拉了 128K 上下文 改进的 long-retrieval 训练有直接关系。Qwen3.7-Max 走的是均衡型,三档都不差。GLM-5.2 在工单长档居然反超 Qwen,这个我反复跑了三遍确认——它对对话式长文本有特别的训练偏置。MiMo-V2 Pro 和 DeepSeek-R1 在长档召回上偏弱,幻觉率也偏高。3.3 多轮记忆连贯性设计 5 轮 / 10 轮 / 20 轮 三组对话,每组塞 3 个上文指代问题(比如上次的订单“刚才那个产品”“之前说的地址”),看模型能不能正确消歧。模型5 轮准确率10 轮20 轮失败模式qwen3.7-max97.2%94.1%88.3%几乎不掉glm-5.296.5%92.8%85.7%20 轮开始错位kimi-k2.7-code98.1%96.4%92.0%冠军deepseek-r195.4%91.2%84.5%推理链过长反而漏抓mimo-v2-pro94.7%89.3%81.2%早期掉点Kimi-K2.7 在多轮记忆上拿了双料冠军(Router 之外都强),这点让我对小米系模型刮目相看。Qwen3.7-Max 第二,稳得可怕。DeepSeek-R1 在多轮上意外翻车,我后来排查发现是它的推理链太长,经常在第 3-4 步就把上文压缩丢掉了——这跟它家强调显式推理的训练目标有 trade-off。3.4 Tool Use / 动作决策这块我用内部订单系统的 12 个 API 做了 schema,要求模型在 100 条用户想退换货/查订单/投诉语料里调对 API。模型调对率一次成功率参数准确率qwen3.7-max94%91%95.2%glm-5.292%88%93.1%kimi-k2.7-code89%85%90.4%deepseek-r191%87%96.8%mimo-v2-pro87%82%88.7%Qwen3.7-Max 调对率和一次成功率双料第一,DeepSeek-R1 在参数准确率上反超——它的先推理再动手在填参数时更稳。MiMo-V2 Pro 这块偏弱,适合做兜底而不是主力。3.5 综合打分如果硬要排个总榜(每个维度加权 25%):qwen3.7-max— 综合分 92.0,均衡之王kimi-k2.7-code— 91.2,长档 / 多轮双强glm-5.2— 90.1,速度之王deepseek-r1— 88.9,Tool 参数最稳mimo-v2-pro— 86.4,短板明显但我的实战建议是:不要单押一家。下面生产环境实战会讲怎么拼。四、什么时候不该用 LLM 客服(反向避坑)讲完横评,反过来聊五个不该用 LLM 客服的场景。这些坑我帮朋友都踩过,挨个列:1. 强合规场景(医疗、金融、法务)。LLM 即便有 RAG,也很难保证输出 100% 合规。我朋友的客服系统里,涉及贷款“处方”合同条款三个类目,直接走人工路由,不进 LLM。Router 这里我用一个简单的关键词 Qwen3.7-Max 二分类兜底,命中就走人工。2. 紧急投诉 情绪崩溃。用户说投诉到 12315“我要举报”“现在就给我回电话”,不要让 LLM 接管,直接转人工 触发值班机制。LLM 在情绪识别上 2026 Q3 还没到能安抚用户的水平。3. 多模态输入为主。用户发图片、视频、语音转写,目前 MiMo-V2 Pro 和 Qwen3.7-Max 的多模态能力都有,但跨模态推理深度不够。这块建议走专门的视觉模型 文本 LLM 串联。4. 实时性 200ms 的场景。即开即用的 IM 气泡,如果压到 200ms 以内,所有旗舰都达不到。建议这种场景走关键词命中 预设回答快路,LLM 做兜底而不是主路。5. 用户量 50/天的场景。这点容易被忽略——LLM 推理集群即便按月付,小流量场景成本不划算。炻光 AI 接入管理平台这种中转站能按 token 计费兜底,但即便如此,小流量不如直接关键词。五、生产环境实战:路由策略 监控 容灾横评只是基础,生产环境怎么把 5 家模型拼起来才是真活儿。我最终给朋友的设计是双 Router 三层兜底:用户进线 ↓ [Layer 1] 关键词 正则(5ms 内) ├─ 命中 → 直出预设回答 └─ 未命中 → 走 Layer 2 ↓ [Layer 2] GLM-5.2 Router(285ms,主力) ├─ 高置信 → 调 Tool 出答 └─ 低置信 → 走 Layer 3 ↓ [Layer 3] Qwen3.7-Max 兜底 RAG(420ms) ├─ RAG 召回成功 → 出答 引用证据 └─ 召回失败 → 转人工为什么是 GLM-5.2 做主力 Router 而不是 Qwen?延迟。客服场景每多 50ms,跳出率肉眼可见涨。GLM-5.2 比 Qwen3.7-Max 快 27ms,F1 只差 0.017,这 trade-off 在 4000 工单/天的量级下非常划算。监控三件套Router 分布监控:每小时画一次各分支占比,如果某分支突增 20%,告警(可能是新问题类型涌入)。RAG 召回失败率:如果某 5 分钟窗口 15%,自动告警 检查知识库是否有更新遗漏。人工接管率:这是终极指标。如果人工接管率从 30% 涨到 50%,说明 LLM 退步了,可能是 prompt 漂移或者知识库 stale。容灾三板斧熔断:Router 延迟超过 800ms 连续 10 次,自动切到备用模型(GLM-5.2 → Qwen3.7-Max)。降级:整个 LLM 集群挂了,回落到纯关键词 预设回答,这是底线。影子流量:新模型上线前,用 5% 流量跑一周,对比主模型的指标再切。六、完整代码(可复制即跑)下面这段是我朋友那套生产代码的脱敏版,GLM-5.2 做主力 Router Qwen3.7-Max 做兜底,带熔断和降级。直接复制能跑,只需要填自己的 API endpoint 和 key。import asyncio import time from dataclasses import dataclass from typing import Optional # 假设炻光 AI 接入管理平台提供的统一 OpenAI 兼容 endpoint GATEWAY_URL https://selltoken.apifox.cn/v1/chat/completions dataclass class RouteResult: branch: str # faq | tool | rag | human confidence: float answer: Optional[str] None evidence: Optional[list] None class Layer1KeywordRouter: 关键词快路,5ms 内返回 KEYWORDS { faq: [营业时间, 怎么联系, 在哪里, 几点下班], human: [投诉, 举报, 12315, 消协, 经理] } def route(self, text: str) - Optional[RouteResult]: for branch, kws in self.KEYWORDS.items(): if any(k in text for k in kws): return RouteResult(branchbranch, confidence1.0) return None class Layer2GLMRouter: GLM-5.2 主力 Router def __init__(self): self.timeout 0.4 # 400ms 强制约束 self.fail_count 0 # 熔断计数 async def route(self, text: str) - RouteResult: if self.fail_count 10: raise RuntimeError(GLM-5.2 熔断中,请切换 Qwen3.7-Max) t0 time.time() try: resp await call_llm( modelglm-5.2, messages[ {role: system, content: ROUTER_PROMPT}, {role: user, content: text} ], response_format{type: json_object}, timeoutself.timeout ) latency time.time() - t0 if latency 0.8: self.fail_count 1 else: self.fail_count max(0, self.fail_count - 1) return parse_route(resp) except Exception as e: self.fail_count 1 raise class Layer3QwenFallback: Qwen3.7-Max RAG 兜底 async def route(self, text: str, context: list) - RouteResult: # 1) RAG 召回 top-5 chunks chunks await rag_search(text, top_k5) if not chunks or chunks[0][score] 0.65: return RouteResult(branchhuman, confidence0.0) # 2) Qwen3.7-Max 出答 引用 answer await call_llm( modelqwen3.7-max, messages[ {role: system, content: ANSWER_PROMPT}, *context, {role: user, content: f问题:{text}\n证据:{chunks}} ] ) return RouteResult( branchrag, confidencechunks[0][score], answeranswer, evidencechunks ) async def handle_user_message(text: str, history: list): # Layer 1 r1 Layer1KeywordRouter().route(text) if r1 and r1.branch human: return transfer_to_human(text) if r1 and r1.branch faq: return faq_lookup(text) # Layer 2 try: r2 await Layer2GLMRouter().route(text) if r2.confidence 0.85: if r2.branch tool: return await call_tool(r2.tool_name, r2.params) return r2.answer except Exception: pass # 熔断或超时,直接 Layer 3 # Layer 3 r3 await Layer3QwenFallback().route(text, history) if r3.branch human: return transfer_to_human(text) return {answer: r3.answer, evidence: r3.evidence} # 监控钩子(每 5 分钟跑一次) async def monitor(): stats collect_5min_stats() if stats[router_dist][human] 0.5: alert(人工接管率突增,检查 Router 分布) if stats[rag_fail_rate] 0.15: alert(RAG 召回失败率超阈值) if stats[p95_latency] 1.2: alert(P95 延迟超 1.2s,考虑扩容或降级)代码核心三点:熔断(连续失败计数)、降级(Layer 3 兜底)、监控(5 分钟窗口告警)。生产环境跑三周没翻过车。七、调客服 Agent API 的几个细节(FAQ)Q1:GLM-5.2 和 Qwen3.7-Max 怎么选?A:看延迟预算。如果你能容忍 400ms,无脑 Qwen3.7-Max,均衡最强。如果延迟卡死在 350ms,GLM-5.2 是唯一靠谱选择,MiMo-V2 Pro 太弱不考虑。Q2:Kimi-K2.7-code 这个 code 后缀有用吗?A:对客服场景没用。它的 code 训练优化主要在代码生成、code review、SQL 生成上,对自然语言对话反而没有 Kimi-K2 基础版强。如果你在做客服 数据查询混合场景,反而可以考虑用它做 SQL 那一块,自然语言对话换 Qwen3.7-Max。Q3:DeepSeek-R1 在客服场景的优势在哪?A:Tool 参数填充。如果你客服系统要调 10 个 API,参数 schema 复杂,DeepSeek-R1 的先推理再动手能少踩 30% 参数填错的坑。但它的延迟太高,建议只放在 Tool 决策那一层,不要当主力 Router。Q4:MiMo-V2 Pro 适合做什么?A:短 query 快路。15 字以内的查订单改地址这种,MiMo-V2 Pro 响应快、价格便宜,适合做 Layer 1 关键词之外的二级快路。但不能上主力。Q5:多模型混用怎么控成本?A:这是很多人忽略的——5 家模型混用,token 计费口径不一致。我后来统一走炻光 AI 接入管理平台的中转,所有模型按统一账单 统一监控,运维成本砍了一半。这不是营销,是我实测踩坑后的选择。八、参考资料OpenAI Presence 客服系统公开介绍vLLM 0.7.x 部署文档Function Calling Schema 最佳实践(炻光 AI 接入管理平台文档)RAG 召回评测标准 MRR/NDCG 参考九、写在最后不要单押一家旗舰。5 家模型各有强弱,生产环境双 Router 三层兜底才是稳妥解。Qwen3.7-Max 做均衡主力,GLM-5.2 做低延迟快路,Kimi-K2.7 做长档召回,DeepSeek-R1 做 Tool 决策,MiMo-V2 Pro 做边缘快路。Router 延迟是客服 Agent 的生死线。每多 50ms,跳出率肉眼可见涨。横评的时候别只看准确率,延迟约束必须写死在 SLA 里。我朋友的系统压到 P95 1.2s,这是硬指标。熔断和降级不能等上线后再补。LLM 服务偶发卡顿、超时、限流,生产第一天就会遇到。监控、熔断、降级三件套在写第一行代码时就该一起上,别等出事再补——这是我帮朋友踩过的最贵的坑。
