跨四个LLM层级的代理工作路由：编排器、顾问、深度推理、Premier

我运行一个四层LLM路由栈来管理我的代理工作。大多数调用会打到便宜的编排器，且永远不会升级。只有在编排器判定任务需要时，昂贵的模型才会启动。核心理念：大多数代理调用并不需要前沿模型。它们需要的是一个快速模型用于路由和分类，以及在需要实际推理时的更强模型。将模型深度与任务深度匹配，对成本和循环体验的影响比选择单个更聪明的模型要大得多。 速度才是交互式代理循环的真正瓶颈。一个每次决策需要10秒以上的监督者，会让整个代理感觉迟钝，即使每个单独的回答都很出色。当编排器决策在2-5秒内完成时，循环就流畅了，这大大改变了系统日常的使用感受。 智能评分来自Artificial Analysis Intelligence Index（获取于2026-06-20）。 层级 模型 AA指数 速度 角色 编排器 DeepSeek V4 Flash ~40 2-5秒 路由、分流、分类 主要顾问 GLM-5.2 ~51 7-8秒 战略分析 深度推理 GLM-5.2 (最大努力) ~51 24-72秒 难题 Premier Opus 4.8 ~56 10-30秒 仅对经过净化的输入，高风险 每个层级在实际中的用途 编排器：对任务进行分类，判断是否能直接回答，并将更困难的任务向上路由。大多数调用在此开始和结束。在2-5秒内，永远不会让循环感觉在等待。 主要顾问：代码评审推理、计划批评、有界分析。编排器在需要真实但非深度推理时会升级到此层级。 深度推理：多步推理、新颖综合、无清晰分解。与顾问同属一个模型家族但强度更高。大约18%的调用会到达此层级。 Premier：高风险、不可逆或对正确性要求极高的决策，且仅对经过净化的输入。严格把关。到达Premier的4%的调用是经过深思熟虑的，而非自动的。 路由模式 路由逻辑很直接。编排器执行一次廉价分类并通过，然后发出层级决策： def route(request): tier = orchestrator.classify(request) if tier == "direct": return orchestrator.answer(request) if tier == "advisor": return glm_standard.answer(request) if tier == "deep": return glm_max_effort.answer(request) if tier == "premier": clean = sanitize(request) return opus.answer(clean) 分类提示定义了层级和升级规则。关键规则：默认使用能合理处理的最便宜层级，仅在多步推理或新颖综合时升级。不确定时，向上提升一个层级。编排器对每个传入请求运行此提示。过度升级的修复几乎总是在此提示中，而不是模型。经过调整后的当前分布：大约78%直接或顾问，18%深度，4%Premier，这是基于6周内数千个路由请求。开始时接近60/40。最难调优的问题在于编排器将输入长度与任务复杂度混淆。一个2000字的请求如果只是'总结一下'，并不需要深度推理。修复方法是默认将所有内容降级到最便宜的层级，仅在明确需要推理时升级，而不是依据请求包含的文本量。 其他人在他们的代理设置中使用了哪些路由策略？按任务类型分层？置信度阈值？或者其他？