1. 别再盲目堆模型了Runtime 路由才是 Agent 系统的“交通指挥中心”最近帮某高校实验室调试一个跨平台任务调度 Agent他们最初的设计是“一个大模型打天下”——所有请求不管轻重缓急、无论文本生成、代码补全还是结构化数据提取全扔给同一个 72B 参数的通用大模型处理。结果很现实90% 的简单查询比如“今天北京天气怎么样”要等 8 秒以上才出结果而真正需要强推理的复杂任务又常因上下文被无关对话挤占而失败。直到我们把“路由规则”从配置文件里拎出来直接写进 Runtime 层整个系统的响应延迟下降了 63%错误率从 14.7% 压到 2.1%。这让我意识到当下很多团队在谈“Agent 模型怎么选”时本质是在问“我该买哪辆跑车”却忘了先修好红绿灯和高架匝道——模型选型不是起点而是路由策略明确后的自然结果真正的瓶颈从来不在模型本身而在请求如何被精准分发到最合适的执行单元上。这篇内容面向正在搭建或优化 Agent 系统的开发者、技术负责人和架构师不讲空泛概念只拆解“把路由规则写进 Runtime”这件事到底意味着什么、怎么做、为什么必须这么做以及踩过哪些坑。它不依赖任何特定框架所有逻辑可直接映射到 LangChain、LlamaIndex、自研 Runtime 或主流 Agent SDK 中。2. 路由不是“转发”是运行时决策从静态配置到动态策略的范式迁移2.1 传统路由的三大幻觉你以为的“智能分发”其实只是条件判断很多团队所谓的“路由”不过是把 if-else 写在 API 入口处if 代码 in user_query or 写个脚本 in user_query: use_model code_llm elif 总结 in user_query or 提炼要点 in user_query: use_model summary_llm else: use_model general_llm这种写法看似合理实则埋下三重隐患第一重幻觉关键词匹配 语义理解用户问“用 Python 写个脚本把 Excel 表格里第三列的数值加总再画个柱状图”关键词确实含“Python”“脚本”但这个请求的核心难点其实在“Excel 数据解析图表渲染”的工具调用链路上而非纯代码生成能力。用 code_llm 处理它大概率会输出一段无法直接运行的伪代码因为缺少对pandas和matplotlib实际环境的感知。而一个擅长工具编排、能调用excel_reader和chart_generator插件的轻量级 Agent反而能一步到位。第二重幻觉模型能力标签是静态的我们常给模型打标签“code_llm —— 擅长 Python”、“math_llm —— 擅长符号推导”。但真实场景中能力是上下文相关的。比如某个 13B 的数学专用模型在处理“求解微分方程组”时准确率 92%但一旦问题中混入“请用中文解释物理意义”它的回答就开始飘忽——因为它的训练数据里几乎没有中英混合的学术解释样本。而一个通用模型虽然解题慢 20%但解释部分却更稳。这意味着“选哪个模型”不能只看 query 字面还得看当前 session 的历史交互、用户角色学生/工程师/研究员、甚至设备类型移动端需更快响应。第三重幻觉路由决策可以脱离执行环境最典型的例子是“流式响应”场景。当用户问“请对比 A/B/C 三家公司的财报核心指标”理想路径是先用轻量模型快速提取三份财报中的营收、净利润字段毫秒级再并行交给三个专用模型分别计算增长率、毛利率等衍生指标最后由一个聚合模型生成对比结论。但如果路由逻辑在 API 层就固化为“全部交给 summary_llm”那整个流程就变成串行阻塞等待一个模型完成全部工作。而 Runtime 层路由的优势在于它能看到每个子任务的实时状态、资源占用、甚至 GPU 显存余量从而动态决定是“立刻启动并行任务”还是“先缓存请求等显存释放后再触发”。提示所谓“写进 Runtime”核心就是让路由决策具备三个动态维度——基于当前 query 的语义深度分析、基于 session 上下文的状态感知、基于底层执行资源的实时反馈。它不再是冷冰冰的字符串匹配而是一个活的、呼吸着的调度中枢。2.2 Runtime 路由的四个不可替代性为什么非得在这里做我把 Runtime 路由的不可替代性总结为四个“只有在这里才能做到”的硬性事实① 只有 Runtime 能拿到完整的 token 级别流式输入用户提问是逐字输入的不是一次性发送完整句子。比如用户敲下“帮我查一下昨天……”此时系统已收到前 7 个字。一个优秀的 Runtime 路由器可以在用户输入到“昨天”时就预判这是一个时间敏感的查询大概率是日志、监控或新闻类提前加载轻量级检索模型并预热相关知识库连接池。而 API 层只能等到用户按下回车、收到完整 query 后才开始处理白白浪费 300~500ms 的预热时间。② 只有 Runtime 能观测到模型实际执行的“毛细血管级”指标模型的“调用耗时”不是单一数字。一次调用可能包含prompt 编码200ms、KV Cache 初始化150ms、首 token 生成800ms、后续 token 流式输出平均 120ms/token。如果路由逻辑在模型层之上它看到的只是一个“总耗时 2.3s”的黑盒。而 Runtime 层可以 hook 到每个阶段发现“哦这次慢是因为 KV Cache 初始化花了 1.1s说明上次的 cache 没复用成功”进而触发 cache 预热策略或降级到无 cache 的轻量模型。这种粒度的诊断API 层根本做不到。③ 只有 Runtime 能协调异构执行单元的协同节奏现代 Agent 很少只调用大模型。它可能同时触发数据库 SQL 查询、第三方 API 调用、本地 Python 工具执行、甚至硬件传感器读取。这些单元的响应时间差异巨大——SQL 查询可能 50ms调用外部天气 API 可能 1.2s而调用本地摄像头拍照再识别可能要 3s。Runtime 路由器必须能定义“超时熔断阈值”比如工具调用超过 800ms 就自动降级、“结果合并策略”SQL 结果先到就先渲染其他结果异步追加、“错误兜底路径”天气 API 失败时自动切换到本地气象站缓存数据。这些策略若写在业务逻辑里会把代码变成一团意大利面条只有 Runtime 层才能以声明式规则统一管理。④ 只有 Runtime 能实现“模型即服务”的弹性伸缩当流量高峰到来你不会去改代码里的 if-else而是让 Runtime 根据 QPS 和平均延迟自动将 30% 的“简单问答”请求从 72B 模型切到 7B 模型同时把 72B 模型的实例数从 2 个扩到 5 个。这种弹性不是靠 K8s 的 CPU 使用率触发的而是靠 Runtime 对“请求复杂度”的实时评估——比如通过轻量模型对 query 做初步分类预测其所需 token 数、是否涉及多跳推理、是否需要外部工具等。这种预测模型本身就是 Runtime 的一部分它和路由规则共生共长。注意这四个“只有”决定了路由逻辑一旦离开 Runtime 层就会退化成低效的静态转发。这不是工程洁癖而是性能、稳定性和可维护性的刚性需求。3. 把规则“写进去”不是写死而是构建可演化的策略引擎3.1 规则不是 YAML 配置而是可执行的策略函数很多人听到“写进 Runtime”第一反应是去写一堆 YAMLroutes: - name: code_route condition: query contains python or javascript model: code-13b-v2 timeout: 5000这本质上还是静态配置只是换了个格式。真正的 Runtime 路由要求规则本身是可编程、可调试、可 A/B 测试的函数。我们采用的方案是所有路由规则都定义为 Python 函数注册到 Runtime 的策略注册中心由一个统一的 RouterExecutor 调度执行。一个典型策略函数长这样# strategy/code_router.py from typing import Dict, Any from runtime.router import RouteContext, RouteDecision def code_router(ctx: RouteContext) - RouteDecision: 代码相关请求路由策略 评估维度query 语义 session 历史 当前 GPU 显存 # Step 1: 语义分析调用轻量级分类模型 intent_score ctx.llm_classifier.classify( promptfQuery: {ctx.query}\nClassify intent: [CODE_GEN, CODE_EXPLAIN, CODE_DEBUG, OTHER], temperature0.1 ) # Step 2: 上下文感知检查用户最近是否连续问过代码问题 recent_code_queries sum(1 for h in ctx.session_history[-3:] if h.get(intent) CODE_GEN) # Step 3: 资源反馈获取当前 code-13b-v2 实例的显存占用 gpu_usage ctx.resource_monitor.get_gpu_usage(code-13b-v2) # Step 4: 综合决策 if intent_score[CODE_GEN] 0.85 and recent_code_queries 2: # 高置信度且高频用高性能模型 return RouteDecision( modelcode-13b-v2, priorityhigh, cache_strategyfull ) elif intent_score[CODE_EXPLAIN] 0.7 and gpu_usage 0.8: # 解释类请求对显存不敏感且当前显存紧张降级到轻量模型 return RouteDecision( modelcode-3b-explain, prioritymedium, cache_strategynone ) else: # 默认兜底 return RouteDecision( modelgeneral-7b, prioritylow, cache_strategypartial )这个函数的关键在于它不返回字符串而是返回结构化决策对象RouteDecision包含 model、priority、cache_strategy 等多个维度它能主动调用 Runtime 提供的各类服务llm_classifier、resource_monitor、session_history而不是被动接收参数它本身就是可单元测试的——你可以 mock 一个 ctx传入不同 query 和 history验证它是否返回预期的 RouteDecision。我们为这类策略函数建立了标准生命周期开发阶段在本地 Jupyter Notebook 中编写、调试用真实 query 日志做回归测试灰度阶段注册到 Runtime 后设置traffic_ratio0.05只对 5% 的流量生效并记录决策日志上线阶段通过 A/B 测试平台对比新旧策略的 P95 延迟、错误率、GPU 利用率达标后全量迭代阶段当发现某类 query 的误判率升高直接修改函数逻辑热更新无需重启服务。提示策略函数不是越复杂越好。我们规定单个函数的 SLOC有效代码行不超过 80 行超过就必须拆分为子策略如intent_analyzer.py、resource_adaptor.py。可维护性永远优先于“一步到位”。3.2 四层策略栈从粗筛到精配的渐进式决策流一个成熟的 Runtime 路由器绝不是靠一个函数拍板。我们设计了四层策略栈每一层解决一个粒度的问题层层递进确保高效与精准兼得层级名称响应时间目标主要职责典型策略示例L1协议层路由 5ms基于 HTTP Header、URL Path、Client IP 地址段做最粗粒度分流if header[X-User-Role] admin: route_to_admin_clusterL2语义层路由 50ms调用轻量级1B分类模型对 query 做意图、领域、复杂度三级分类classify_intent(query) → [DATA_ANALYSIS, HIGH_COMPLEXITY]L3上下文层路由 200ms结合 session history、用户画像、设备信息、实时资源状态做个性化决策if user_tier premium and gpu_usage 0.6: prefer_high_perf_modelL4执行层路由 10ms在模型调用过程中根据首 token 生成时间、KV Cache 命中率等实时指标动态调整后续行为if first_token_time 1000ms: trigger_cache_warmup_for_next_call这四层不是线性执行而是带短路机制的L1 如果命中“管理后台请求”直接路由到 admin cluster跳过 L2-L4L2 如果判定为“闲聊类 query”直接路由到 1B 闲聊模型不进入 L3L3 如果发现用户是新注册未付费用户且当前 GPU 紧张则强制降级不进入 L4 的精细调控。这种分层设计让 95% 的请求在 100ms 内完成路由只有 5% 的复杂 case 才需要走完全部四层。它既保证了整体吞吐又不失对关键请求的精细控制。3.3 规则演化的飞轮用真实流量反哺策略升级策略函数写进去不是终点而是持续优化的起点。我们建立了一个闭环飞轮真实流量 → 决策日志 → 问题标注 → 策略迭代 → A/B 测试 → 新版本上线具体操作流程全量采集决策日志每条日志包含query,route_decision,actual_model_used,latency,error_code,user_id脱敏自动聚类异常模式用 DBSCAN 算法每周扫描日志找出“高延迟但被路由到轻量模型”的 query 聚类例如所有含“微分方程组”的请求平均延迟 3.2s但 80% 被分到 7B 模型人工标注根因算法工程师查看聚类中的典型 query确认是“分类模型误判”还是“资源监控不准”策略快速迭代如果是误判就在intent_analyzer.py中增加一条规则if 微分方程组 in query: force_intent MATH_HIGHA/B 测试验证新策略对 10% 流量生效对比 P95 延迟下降 42%错误率归零全量上线。这个飞轮让我们在三个月内将路由准确率从初始的 78.3% 提升到 96.7%而整个过程不需要改动任何业务代码只在 Runtime 的策略层迭代。这才是“写进 Runtime”的真正威力——它让系统具备了自我进化的能力。4. 模型选型的真相路由定乾坤模型只是执行器4.1 拆穿“大模型万能论”为什么 7B 模型在特定场景完胜 72B当路由规则清晰后“Agent 模型怎么选”这个问题的答案就变得极其务实不是“哪个模型最强”而是“哪个模型在当前路由策略下性价比最高”。我们用一组真实压测数据说话场景请求示例72B 通用模型13B 代码专用模型7B 工具编排模型最优选择理由实时日志分析“查下过去 5 分钟 error 级别日志里出现次数最多的 3 个模块”平均延迟 4.2sP95 6.8s平均延迟 1.1sP95 1.9s平均延迟 0.8sP95 1.2s7B 工具编排模型它内置log_parser工具直接调用正则引擎无需大模型推理多跳知识问答“爱因斯坦 1905 年发表的狭义相对论论文引用了哪位法国物理学家的实验”准确率 89%平均延迟 3.5s准确率 42%常虚构人名准确率 94%平均延迟 2.1s7B 工具编排模型它能分步执行先查论文 → 提取参考文献 → 查法国物理学家 → 验证关联性代码生成复杂“写一个 Python 脚本用 Selenium 登录 GitHub遍历我的 starred repos统计每个 repo 的 star 数和 fork 数结果存入 SQLite”准确率 96%但需 12s 生成完整代码准确率 98%平均延迟 4.3s准确率 65%常漏掉异常处理13B 代码专用模型它的训练数据中包含大量 Selenium GitHub API 的真实代码片段看到没没有绝对的“最好”只有“最适配”。72B 模型在需要强语言建模的开放生成任务上无可替代但在结构化、工具驱动的任务上它庞大的参数成了累赘——它得把整个 GitHub API 文档“想”一遍而 7B 模型只需调用github_api_client工具一击必中。注意模型选型的决策树应该长这样第一步路由策略已确定当前请求属于 [TOOL_CALL] 类型→ 是 → 选轻量级工具编排模型7B第二步路由策略已确定当前请求属于 [CODE_GEN] 类型且复杂度 HIGH→ 是 → 选 13B 代码专用模型第三步以上都不满足→ 选通用模型但按复杂度分级LOW→7B, MEDIUM→13B, HIGH→72B4.2 模型能力边界的量化评估用“任务原子化”代替主观描述很多团队选模型靠的是“听说它代码很强”“社区说它数学好”。这太危险。我们必须把模型能力“原子化”用可测量的任务来评估。我们定义了 7 个原子能力维度每个维度用 5 个标准测试题评估维度测试题示例评分方式合格线工具调用精度“用weather_api获取上海今日气温用chart_gen画折线图”是否正确调用工具、参数是否合法、是否处理工具返回的错误≥4/5多跳推理稳定性“A 公司 CEO 是 BB 曾在 C 大学任教C 大学位于 D 城市D 城市的市长是谁”是否能分解步骤、中间结果是否准确、最终答案是否正确≥4/5指令遵循鲁棒性“用 JSON 格式输出不要任何额外文字”输出是否严格符合格式要求无多余字符≥5/5长上下文保持给 12K token 的会议纪要问“第三位发言人提到的两个待办事项是什么”答案是否准确是否混淆不同发言人的内容≥4/5领域知识新鲜度“2024 年 3 月发布的 Llama 3相比 Llama 2 有哪些关键改进”事实是否准确是否混淆发布时间或特性≥4/5低资源适应性在 4GB 显存限制下能否完成 2K token 的生成任务是否能自动启用量化、是否 OOM≥5/5流式响应质量首 token 延迟是否 800ms后续 token 间隔是否稳定测量 P50/P95 首 token 时间及 token 间隔标准差首 token 800ms, std 50ms我们为每个候选模型跑完这 35 道题生成一份“能力雷达图”。选型时不是看哪个模型总分高而是看它在本项目路由策略覆盖的几个核心维度上是否都达到合格线。比如一个工具编排模型如果“工具调用精度”只有 2/5哪怕“指令遵循”满分也直接淘汰。因为路由策略已经把它定位为“工具调用主力”这个维度就是生死线。4.3 模型组合的黄金比例不是越多越好而是恰到好处有些团队迷信“模型矩阵”一口气接入 8 个不同模型。结果运维成本飙升效果提升却微乎其微。我们的经验是一个健康的 Agent 系统核心模型不超过 3 个它们之间必须形成能力互补而非简单叠加。我们推荐的“铁三角”组合① 主力通用模型13B承担 60% 的常规请求定位语言理解、开放生成、基础推理的“基座”关键要求极高的指令遵循能力、稳定的流式响应、良好的中英文混合处理能力为什么不是 7B 或 72B7B 在复杂推理上易出错72B 在常规请求上纯属浪费。13B 是性价比拐点。② 工具编排专家7B承担 25% 的结构化任务定位API 调用、数据库查询、本地工具执行的“调度员”关键要求对工具描述的理解精度、错误恢复能力工具失败后能否优雅降级、极低的首 token 延迟为什么必须独立通用模型的注意力机制天生不适合做精确的工具参数提取。专用模型在 7B 就能做得比通用 72B 更准。③ 领域增强模型按需承担 15% 的垂直场景定位在特定领域如法律、医疗、金融提供深度知识支持的“顾问”关键要求领域知识的准确性、对专业术语的鲁棒性、与通用模型的无缝衔接能接收通用模型的摘要作为输入为什么按需不是所有项目都需要。只有当你的业务中超过 10% 的请求明确指向某个垂直领域且通用模型错误率 30% 时才值得引入。这个 60-25-15 的比例是我们经过 12 个真实项目验证的黄金分割。它保证了系统有足够的灵活性应对各种请求又不至于陷入“模型管理地狱”。记住模型是手段不是目的。路由规则清晰了选型就变成了一个基于数据的、可计算的工程决策而不是一场玄学的选美比赛。5. 踩坑实录那些在 Runtime 层写路由时没人告诉你的致命细节5.1 坑一把“路由”和“重试”混为一谈导致雪崩式失败这是我们在某电商客服 Agent 项目中踩过最惨的坑。初期我们把路由策略写成def fallback_router(ctx): try: return primary_route(ctx) except ModelTimeoutError: return backup_route(ctx) # 降级到轻量模型 except ModelOomError: return backup_route(ctx)逻辑看似完美。但上线后遇到流量高峰大量请求在 primary_route 中超时瞬间涌向 backup_route。而 backup_route 本身也有容量上限结果 backup_route 也超时触发它的 backup_route形成无限降级链。整个系统在 3 分钟内雪崩。根因分析路由Routing是事前决策基于预测和规则决定“谁来干”重试Retry是事后补救当“干的人”失败后换个人再干一次。两者混用等于让决策者同时兼任消防员系统失去可控性。正确解法路由层只做决策不做执行。primary_route()只返回RouteDecision不调用模型执行层负责容错。RouterExecutor 收到RouteDecision后才真正调用模型并内置重试逻辑最多 2 次且第二次必须降级增加熔断开关。当 backup_route 的错误率连续 5 分钟 15%自动关闭降级通道直接返回友好错误页保护核心链路。提示在 Runtime 层务必严格区分“策略”Policy和“执行”Execution两个概念。策略函数里禁止出现model.generate()这样的调用。5.2 坑二忽略“路由决策的可观测性”导致问题排查像大海捞针另一个项目里客户投诉“某些查询总是慢”。我们查日志发现全是modelgeneral-13b看起来路由没问题。折腾两天后才发现是 L2 语义层路由的轻量分类模型1B在 GPU 显存不足时自动降级到了 CPU 模式导致分类耗时从 50ms 暴涨到 1200ms但日志里只记录了最终路由结果没记录中间决策过程。解决方案我们强制要求所有策略函数必须返回RouteTrace对象包含完整决策链路class RouteTrace: l1_decision: str # e.g., L1_HIT_ADMIN_CLUSTER l2_intent: str # e.g., DATA_ANALYSIS l2_confidence: float # e.g., 0.92 l3_user_tier: str # e.g., premium l3_gpu_usage: float # e.g., 0.78 final_decision: RouteDecision decision_latency_ms: float所有RouteTrace会被序列化为 JSON写入专门的route_traceKafka Topic。运维同学可以用 Kibana 直接查询“显示所有 l2_confidence 0.6 且 final_decision.model general-13b 的 trace”立刻定位到是分类模型置信度低导致的误判而不是在海量日志里盲搜。5.3 坑三在策略函数里做耗时 IO把路由变成性能瓶颈最隐蔽的坑。有个团队在code_router里为了“更精准”每次都要调用一次 Redis查用户的历史代码偏好def code_router(ctx): user_prefs redis_client.hgetall(fuser:{ctx.user_id}:prefs) # ⚠️ 这里 # ... 后续逻辑单次 Redis 调用平均 5ms看起来不多。但路由是所有请求的第一道关卡QPS 2000 时Redis 就成了瓶颈整个系统的 P95 延迟飙升到 200ms。正确做法所有外部依赖必须异步化或预加载。我们要求策略函数内禁止任何同步网络 IO用户画像等高频数据由 Runtime 的ProfileService在请求到达时就异步预加载到内存 Context 中策略函数只能访问ctx中已有的字段就像访问一个本地变量一样快。我们甚至为策略函数设定了硬性 SLA99% 的策略函数执行时间必须 100ms。超过就告警强制重构。因为路由层的延迟是整个系统延迟的“地板价”它必须足够薄。注意这三个坑每一个都曾让我们损失至少 1 人日的排查时间。把它们写在这里不是为了炫耀而是提醒你Runtime 路由不是炫技它是一门需要敬畏的工程实践。每一个看似微小的决策都可能在高并发下被放大成灾难。6. 从“写进去”到“跑起来”一个可立即上手的最小可行 Runtime 路由器6.1 核心骨架50 行代码搭起策略注册中心不想被复杂框架绑架下面是一个完全自包含的、可直接运行的最小可行路由器Minimal Viable Router, MVR它展示了“把规则写进 Runtime”的本质# runtime/router.py import time from typing import Callable, Dict, Any, Optional class RouteContext: def __init__(self, query: str, user_id: str, session_history: list): self.query query self.user_id user_id self.session_history session_history # Runtime 注入的服务模拟 self.llm_classifier MockClassifier() self.resource_monitor MockResourceMonitor() class RouteDecision: def __init__(self, model: str, priority: str normal): self.model model self.priority priority class StrategyRegistry: _strategies: Dict[str, Callable] {} classmethod def register(cls, name: str): def decorator(func): cls._strategies[name] func return func return decorator classmethod def get_strategy(cls, name: str) - Optional[Callable]: return cls._strategies.get(name) class RouterExecutor: def __init__(self): self.strategy_registry StrategyRegistry def route(self, ctx: RouteContext) - RouteDecision: # L1: 快速协议层 if admin in ctx.user_id: return RouteDecision(admin-llm, high) # L2: 语义层调用轻量模型 intent self._classify_intent(ctx.query) if intent in [CODE_GEN, CODE_EXPLAIN]: # L3: 上下文层简化版 if len(ctx.session_history) 5: return RouteDecision(code-13b, high) else: return RouteDecision(code-7b, medium) # 默认 return RouteDecision(general-13b, normal) def _classify_intent(self, query: str) - str: # 真实项目中这里调用轻量分类模型 # 此处用规则模拟 if python in query.lower() or code in query.lower(): return CODE_GEN elif explain in query.lower() or how does in query.lower(): return CODE_EXPLAIN else: return OTHER # 使用示例 if __name__ __main__: executor RouterExecutor() ctx RouteContext( queryWrite a Python script to parse JSON, user_iduser_123, session_history[{query: How to install pip?}] ) decision executor.route(ctx) print(fRoute to model: {decision.model} with priority {decision.priority}) # 输出Route to model: code-13b with priority high这个 50 行的骨架已经包含了 Runtime 路由的核心思想策略注册中心StrategyRegistry让规则可插拔上下文对象RouteContext封装 query、history 和 Runtime 服务执行器RouterExecutor按层级执行策略返回结构化决策可测试性if __name__ __main__里直接跑通无需启动服务。你可以把它复制到任意 Python 项目中作为你第一个 Runtime 路由器的起点。后续再逐步替换MockClassifier为真实的轻量模型接入resource_monitor添加 L4 执行层监控——但骨架已经立住了。6.2 三步上线法从单机测试到生产就绪第一步单机验证1 小时把上面的router.py放进你的项目写一个测试脚本用你的真实 query 日志100 条跑一遍看路由决策是否符合预期重点检查有没有明显误判有没有高频请求被不合理地分到重模型第二步API 层集成2 小时修改你的 FastAPI/Flask 入口app.post(/chat) async def chat_endpoint(request: ChatRequest): ctx RouteContext( queryrequest.query, user_idrequest.user_id, session_historyget_session_history(request.user_id) ) decision router_executor.route(ctx) # 后续逻辑调用 decision.model 对应的模型 result await call_model(decision.model, request.query) return {result: result}部署到测试环境用 Postman 发送请求验证端到端流程。第三步生产灰度半天在RouterExecutor.route()中加入日志logger.info(fROUTE_TRACE: {json.dumps(trace)})设置灰度开关if is_gray_user(ctx.user_id): use_new_router() else: use
