Agent 模型怎么选先把路由规则写进 Runtime上个月某平台组A同学找到我表情很凝重。他说他们做了一个内部智能助手产品面向业务人员提供数据分析、报告生成、知识问答三类功能。初期图省事所有请求统一打到一个旗舰级大模型上效果确实不错但月底成本对账出来的时候大家都沉默了——一个月光模型调用费就烧掉了小半年的预算。团队内部开始激烈争论要不要换个更便宜的模型有人说换开源模型有人说换中型闭源模型吵了一个星期也没定论。我听完只问了一个问题你们有没有统计过这三个功能各自的调用量、平均Token消耗和失败重试率他愣了一下说没统计过。这正是大多数Agent项目的通病大家把“选哪个模型”当成一个纯参数对比问题比上下文长度、比跑分、比价格却忽略了一个更根本的问题——你的Agent请求长什么样哪些请求需要顶级模型哪些请求用轻量模型绰绰有余这个问题的答案才是真正应该写进Runtime里的路由规则。这篇文章不聊参数跑分聊一个我在几个模拟项目和跨平台系统里反复验证过的思路Agent模型选型的决策重心应该从“模型对比”转移到“路由规则设计”。先想清楚怎么路由再决定要引入哪几个模型。1. 选型困局的根源把“比模型”当成了目的1.1 跑分高不等于任务完成得好我在不少项目里见过同一种现象团队在模型选型阶段花费大量时间比较各种基准测试分数仿佛分数最高的那个模型天然就是正确答案。但Agent场景和单轮问答有本质区别模型分数高只说明它在标准测试集上表现好不代表它在你的业务上下文里能把任务闭环做完整。Agent的真实调用链路往往是这样的用户一句话进来Agent要先做意图识别然后决定要不要调工具工具返回结果之后还要做上下文总结再把结果组织成自然语言回复。中间还可能涉及多轮追问、错误纠正、格式转换。每一步都可能产生额外Token消耗而复杂任务的Token消耗通常是指数级增长的。A同学他们的智能助手就是一个典型例子。数据分析这个场景下Agent需要把用户的自然语言问题转成结构化的查询语句查询执行完拿到结果之后还要生成解读。这个链路一旦跑偏重试一次的成本可能就是正常调用的三到五倍。他们在对比模型时只看单次问答的准确性完全没考虑重试成本和失败率等月底账单出来才发现问题。1.2 单一模型策略的隐性代价很多团队走上“全都用最强模型”这条路其实是偷懒的产物。不用设计路由不用维护多套模型配置一个API一个Key搞定所有事情。但这条路在请求量小的时候没问题一旦Agent接入真实业务、日调用量上万成本曲线会变得非常陡峭。旗舰级模型的价格通常是轻量模型的几十倍而实际上你的请求里可能有超过七成根本用不到那么强的推理能力。反过来如果为了省钱全部换成轻量模型复杂任务又会拉胯。工具调用经常出错代码生成质量下降用户体感断崖式下跌。A同学他们内部做过实验在中型模型上跑数据分析类任务成功率比旗舰模型低了将近二十个百分点这个差距在业务场景里是没法接受的。所以问题从来不是“哪个模型更好”而是“什么请求应该走哪个模型”。这个问题不解决选什么都难受。1.3 比模型更优先的问题你的请求分几类我在做架构设计的时候从来不先问团队想用什么模型。我让他们先做的第一件事是给请求分类。最简单的分类方法是拉一周的线上日志按三个维度打标任务类型、平均输入Token、平均输出Token。任务类型字段在Agent里通常都是现成的——意图识别模块本身就会输出这个结果不需要额外改造。打完标之后你会看到一张分布表百分之六十的请求是轻量问答型输入输出都很短百分之三十的请求是工具调用型输入长输出短但链路复杂还有百分之十是复杂推理型需要多步思考、长上下文。这张表一出来模型选型的答案基本就清晰了一半。剩下的一半才是怎么把路由规则落地到Runtime里。2. 先写路由规则再选模型一种反直觉的设计顺序2.1 业务需求决定了模型天花板而不是反过来大部分团队的选型流程是先选一个模型然后看这个模型能做什么再围绕它设计业务功能。这其实是倒过来了。正确的顺序应该是先把业务请求的复杂度梯度摸清楚把每种请求对模型能力的最低要求定义出来再去市场上匹配模型。我用一个不太严谨但很直观的类比来说明你不能因为买了一辆越野车就规定所有出行必须走山路。你要先理清楚通勤、长途、越野各自的比例再决定是买一辆全能车还是买一辆通勤车加一辆越野车。Agent模型选型的本质就是做这个匹配决策。2.2 从请求特征反推模型能力需求给请求分类之后下一步是把每一类请求映射到模型能力需求上。这个映射不需要很精细但必须明确。我一般用四个维度来判断推理复杂度、上下文预算、工具调用密度、响应时效。推理复杂度对应模型的思维链能力上下文预算对应模型的上下文窗口和长文本处理能力工具调用密度对应模型的函数调用稳定性响应时效对应模型的推理速度和系统的超时容忍度。四个维度综合下来请求自然分成了三个梯度轻量梯度、标准梯度、高负载梯度。以A同学他们的智能助手为例知识问答类功能——直接检索、直接回答——属于轻量梯度轻量模型完全够用报告生成类功能需要结构化输出和一定程度的推理属于标准梯度中型模型可以胜任数据分析类功能需要多步工具调用和复杂推理属于高负载梯度才需要旗舰级模型兜底。2.3 路由规则本质上是对业务规则的翻译很多团队看到“路由规则”四个字第一反应是这东西很技术、很高深。其实路由规则说白了就是把业务规则翻译成机器可判断的条件。业务说“数据分析功能必须精准”翻译过来就是“任务类型等于数据分析的请求路由到旗舰模型”业务说“知识问答快点出结果就行”翻译过来就是“任务类型等于知识问答的请求路由到轻量模型超时自动降级”。这个翻译过程不需要算法工程师参与产品经理和开发就能完成。真正的技术活在于把这个规则落进Runtime让它能在毫秒级完成请求画像和模型分配。3. 为什么路由规则必须写在Runtime层3.1 写在业务代码里的致命问题改一次规则要重新发版我见过不少项目路由逻辑是写在业务代码里的。比如某个服务里写死了如果请求类型是A走模型A的API如果请求类型是B走模型B的API。这种写法在刚上线的时候没毛病但运行一段时间后问题就出来了。模型价格调整了想把某些请求切换到更便宜的模型你得改代码重新发布某个模型服务不稳定想临时把流量切到备用模型你得改代码重新发布新业务接入新增了一个请求类型你还是要改代码重新发布。每一次发布都是一次风险事件而路由调整这件事本身应该是低频但零成本的。把路由规则写进Runtime本质上是把决策逻辑从应用代码里抽离出来放到一个可以动态调整的位置。3.2 Runtime层路由的三层结构我在实际项目中常用的结构是三层的接入层、路由层、执行层。接入层负责拿到原始请求做统一的鉴权、参数校验和格式对齐路由层根据请求画像命中规则决定当前请求应该走哪个模型通道执行层负责真正调用模型API处理重试、超时、流式输出和错误归一化。三个层各司其职任何一层的改动都不影响其他层。这个结构最大的好处是业务方完全感知不到模型的存在。他们的代码只和Runtime网关交互Runtime帮他们决定背后用哪个模型。未来哪怕把所有模型供应商都换一遍业务方的代码一行都不用动。3.3 配置热更新与灰度能力路由规则写进Runtime的另一个关键收益是可以做热更新和灰度发布。路由配置存在配置中心里每次调整只需要推送新的配置上去Runtime在毫秒级内就能生效。这不是理论上的设计我在某跨平台系统里就是这么落地的。配置中心里的路由规则分版本管理每次变更都会生成一个版本号。我习惯先推一个灰度版本把规则生效范围限定到百分之五的流量跑一天看成功率、延迟、成本三个指标没有异常再全量推上去。这个流程跑顺之后日常调模型比调业务功能还快。4. 路由规则的四种核心维度与优先级设计4.1 意图复杂度路由最基础的路由维度是意图复杂度。Agent系统通常都会做意图识别这个结果天然就是路由的第一层判据。对比意图字典命中“复杂任务”类别的请求走高能力模型命中“简单问答”类别的走轻量模型。实际操作中意图粒度不要太细否则维护成本太高。我一般建议控制在五到八个意图分类以内超过十个就要考虑是不是合并了。某个知识助手接入了十二个意图后来发现其中四个完全可以合并成一个“信息查询”意图路由规则也因此从十二条缩减到五条配置的可读性和可维护性都提高了很多。4.2 成本预算路由这个维度是成本敏感型团队最关心的。成本预算路由的含义是给每个请求类型设置一个Token预算上限在预算范围内选择当前可用的模型里能力最强的那个。实现方式是在路由规则里加一个成本权重字段Runtime在匹配时先按意图分类粗筛再按成本权重细选。举个例子同样是“报告生成”请求如果当前预算充足可以路由到旗舰模型追求最佳质量如果当天成本已经逼近阈值路由到中型模型维持基本可用。这种动态调整能力是写死在业务代码里的逻辑很难实现的。4.3 延迟敏感路由Agent场景里延迟和模型能力经常是矛盾的。能力越强的模型推理时间通常越长。某些场景——比如机器人客服、交互式对话——用户等不了太久这类请求应该路由到速度更快的轻量模型哪怕牺牲一点质量。而离线生成报告、批量数据分析这类场景对延迟不敏感可以放心走慢但准的模型。我在一个模拟项目里测过一组数据同样一个“内容总结”任务轻量模型平均耗时一点二秒旗舰模型平均耗时四点五秒。如果所有请求都走旗舰模型不仅成本高用户体验反而更差——用户等四秒半就为了看一个几百字的总结这个体验是灾难性的。4.4 容错与降级路由任何路由系统都会遇到模型服务不可用的情况。我习惯在路由规则里预留一条降级链路主模型超时或者报错达到阈值时自动切换到备选模型继续处理。降级策略有两种形态一种是顶层降级——整个请求切到另一个模型重新跑另一种是局部降级——只对当前失败的步骤进行重试用轻量模型完成剩余部分。局部降级在Agent链路里尤其重要。Agent的中间步骤如果全量重来Token消耗会翻倍局部降级能保留已经完成的结果只对失败部分做替代处理。我踩过的坑是只做了顶层降级某个时段主模型偶发超时每次超时都全量重跑成本翻了一倍多。后来改成局部降级成本立刻恢复正常。5. 落地示例一个完整的Runtime路由配置与调度流程5.1 路由配置的数据结构配置中心的规则我用JSON存储结构分成两层第一层是模型池定义第二层是路由规则列表。模型池声明当前接入了哪几个模型每个模型有哪些属性路由规则列表按优先级从上到下匹配命中即终止。{ models: { heavy: { provider: flagship-api, context_window: 128000, cost_per_k: 0.03, priority: 1 }, standard: { provider: mid-size-api, context_window: 32000, cost_per_k: 0.008, priority: 2 }, lite: { provider: fast-api, context_window: 16000, cost_per_k: 0.002, priority: 3 } }, routes: [ { name: complex-data-analysis, match: { intent: data_analysis, tools_count_range: [2, 10], est_input_tokens_range: [4000, 60000] }, target: heavy, fallback: standard }, { name: normal-report, match: { intent: report_generation, est_output_tokens_range: [1000, 8000] }, target: standard, fallback: lite }, { name: quick-qa, match: { intent: knowledge_query, est_input_tokens_lt: 3000 }, target: lite, fallback: standard } ] }这个结构支撑了A同学他们那个智能助手三个核心功能的全部路由简单清晰每一个字段的含义都能在十分钟内给新同学讲清楚。5.2 请求进入Runtime的调度流程请求到达接入层后Runtime会执行一个顺序固定的流程身份认证、请求规范化、请求画像生成、规则匹配、模型调用、响应返回。其中请求画像生成这一步是路由能工作起来的前提它需要从原始请求里提取几个关键特征意图分类、估算输入Token数、工具调用数量、响应时效要求。估算输入Token数这个动作不需要额外调用模型直接用字符数除以一个经验系数就行。中文场景下我习惯用大概一个汉字对应一点三个Token的比例来估算误差在接受范围内。这个估算是给规则匹配用的粗筛条件不需要很精确只要能在量级上区分请求大小就够了。5.3 路由匹配与模型调用的伪代码示例路由匹配的逻辑我用一段伪代码来表示方便理解整个流程的先后关系def route_request(req): profile build_request_profile(req) for rule in sorted(routes, keylambda r: r.priority): if match_rule(rule, profile): return rule return default_route def execute_with_fallback(rule, req): try: resp call_model(rule.target, req) return resp except ModelTimeoutError: if rule.fallback: return call_model(rule.fallback, req) raise def call_model(model_key, req): model_cfg models[model_key] resp http_post(model_cfg.provider, req.payload) return resp真实项目中这段代码会散落在不同的模块里但整体逻辑就是这样。值得强调的是execute_with_fallback里的降级处理主模型超时后调用备选模型备选模型的请求参数基本不变只是换了一个通道。这个设计保证了极端情况下用户还能拿到一个可用的结果只是质量可能降一档。5.4 路由结果的上报与观测路由系统做出来之后最容易被忽略但价值最大的一步是把每次路由的结果记录下来。我在某跨平台系统里实现过一个轻量上报模块每次请求完成之后把用时、Token消耗、命中规则、是否触发了降级、最终模型ID五个字段上报到日志系统。这些数据就是后续优化路由规则的依据。哪里成本占比高哪些规则经常被绕过哪个模型总在降级一切决策都靠数据说话。没有这块路由规则过两周就变成僵尸配置了——没人敢动因为不知道动了会有什么连锁反应。6. 实测效果成本降了收益稳了之后我遇到的三类问题6.1 成本对比组路由上线前后的数据变化A同学他们的智能助手在做完这次改造之后中间层加了一层Runtime路由三个功能分别路由到三个不同梯度的模型。跑了四周之后核心数据变化非常直观指标改造前改造后变化幅度全月模型调用成本基准线约三成降低约七成复杂任务成功率基准线持平无显著变化简单任务平均响应时间基准线约四成降低约六成降级触发率未统计百分之一点二可接受成本降低七成成功率没有下降响应时间反而因为简单任务走了轻量模型快了很多。这个结果验证了一个判断大多数Agent项目的性能瓶颈根本不在模型能力而在于没有把合适的请求分配给合适的模型。路由规则写进Runtime之后模型选型这个原本争论不休的问题就直接解掉了。6.2 只做路由不设兜底的隐患某次上游模型抖动我最初做路由系统的时候想着有主有备了降级链路也配了应该没什么大问题了。结果有一次上游旗舰模型服务出现周期性抖动主模型大量超时流量自动降级到中型模型。中型模型扛了一会儿因为流量太集中也开始出现错误。那一次的经验是路由规则必须内置一层全局熔断和逃生舱逻辑。逃生舱指的是当所有模型通道都不稳定时Runtime返回一个预设的兜底话术并标记请求失败让上游业务方感知到这是一个可重试的临时故障而不是一个正常的业务响应。加了这层之后故障期的用户体感明显好了很多。6.3 路由规则过度精细导致的配置熵增还有一个坑也很常见路由规则设计得太精细每条规则覆盖的场景过于狭窄最后配置中心里躺着几十条规则互相之间还会偶尔冲突。规则一旦冲突匹配顺序又设计得不好就会出现本应走轻量模型的请求被前面的规则截胡走了旗舰模型。应对方法是定期做一次规则合并检查。我每两周会把近两周的线上上报数据拉出来看每条规则的命中次数和平均成本把命中率极低或者成本异常的规则标出来找对应场景确认是保留、合并还是删除。事实证明规则越少越稳定覆盖面越广越好维护。追求极致的精准匹配收益很小维护负担却很大。7. 持续调优让路由规则自我进化7.1 从链路追踪数据反向修正规则路由规则上线之后不是一劳永逸的。模型在升级、业务在变化、用户的使用习惯也在变。最好的状态是让路由规则能跟着数据持续迭代。我一般会在上报模块里增加一个标记字段用来记录“当前请求如果换到另一个模型预期成本和预期质量变化”。这个标记不需要很精准只需要做估算。比如某个走轻量模型的请求如果按当前输入长度判断强模型也就是快一点点那就维持现状。但如果发现某些请求频繁触发降级或者经常因为模型能力不足而重试那就说明规则把请求分到了能力偏低的一侧需要调高该请求类型的模型梯度。7.2 模型池的动态进出机制模型不是一成不变的。新模型发布、旧模型调价、供应商服务升级这些都会影响路由的最优解。我建议把模型池定义也纳入配置管理让模型池支持动态增减。这里有一个实操技巧新增模型时不要直接改路由目标先把新模型加入模型池然后通过灰度规则引入少量匹配流量做对比。等新模型的成功率数据和成本数据跑出来了再决定是否把对应路由的target字段切换过去。这个流程避免了“上线即踩坑”的情况。7.3 路由规则的版本管理与回滚配置中心的规则支持版本管理是底线要求。我在给某跨平台系统做路由设计时把配置的历史版本完整保留每次变更记录操作人、变更原因、前后规则diff。一旦新规则跑出问题一键回滚到上一个版本整个过程不超过三十秒。这个能力看着简单但在生产环境里救过很多次场。有一次我在调整某个意图分类的模型梯度时误把“标准”写成了“heavy”推送之后成本曲线肉眼可见地往上翘。发现之后及时回滚到上一个版本确认了原因再重新推送修正版整个事故只持续了不到十分钟几乎没有造成实际损失。7.4 定期成本预算校准最后再分享一个习惯每季度做一次路由规则的成本复盘。把上个季度的实际调用数据按模型ID聚合算出每个模型的平均单次调用成本、平均Token消耗、Top调用意图和路由规则里配置的预期值对比。偏差超过百分之二十的要么是规则写得不对要么是请求形态发生了改变。比如出现“某轻量模型的实际单次调用成本比预期高三倍”这种情况排查下来往往不是模型涨价而是请求的平均输入Token变长了——用户开始把更多的上下文塞进请求里导致轻量模型也消耗了大量Token。这个时候要做的不是换模型而是限制请求的上下文长度或者做上下文摘要压缩。8. 结尾前最后要说的一段话做了几个Agent相关项目之后我越来越确信一件事在Agent工程里模型本身只是整个系统中的一环。把路由规则写好让每个请求都能找到最合适的模型通道这个收益远比纠结“用A模型还是B模型”大得多。现在的模型迭代速度很快今天的最优解可能下个月就过时了但一套灵活的路由框架可以让模型随时替换而不动核心逻辑。如果你正在为Agent模型选型头疼我建议你先冷静下来把线上请求日志翻出来按任务类型、Token消耗、工具调用密度做一次分类统计。这个动作做完你会发现自己要解决的其实不是选型问题而是把合适的请求送到合适的模型面前的问题。先把路由规则写进Runtime再谈模型选型。让Runtime帮你把模型统一管起来把决策变成一个可配置、可灰度、可回滚的工程行为而不是一个一次性的线上争论。这个思路值得你在下一个Agent项目里认真试一次。