Agent模型选型：把路由规则写进Runtime才是关键

最近接了一个跨平台助手项目，需求本身不复杂，但让我意外的是，前后换了三四款模型，每次都觉得“这版应该稳了”，一上真实链路就翻车。不是答非所问，就是工具调用格式飘了，再不然就是延迟高到用户直接关页面。直到某天我把问题从“换哪个模型”换成“当前请求到底该让哪个模型来处理”，整个系统的稳定性才真正起来。

这个转变让我意识到一个很多人忽略的事实：Agent 模型怎么选，真正的复杂度不在模型本身，而在 Runtime 中的路由规则。你选的模型再强，如果运行时没有一个清晰的规则来决定“什么任务走哪个模型、什么情况回退、什么成本能扛住”，那换多少模型都是赌运气。这篇就聊聊我是怎么把路由规则写进 Runtime，以及在这个过程中积累的选型和踩坑经验。适合正在做 Agent 应用、被模型选型折腾得不轻的开发者参考。

1. 换模型救不了烂路由，这是我在三个Agent项目里最贵的教训

我先从自己的经历说起，因为这个问题一开始我根本没意识到。第一个项目是客服分流 Agent，任务从用户意图识别到工单生成全走同一个模型，当时为了“省事”，所有请求一股脑交给那款综合能力最强的大模型。结果月底账单出来，成本翻了三倍，而且因为模型在处理简单重复问题时也在跑完整推理链路，延迟高了一些，客服坐席反馈“系统变笨了”。

第二个项目是个助手类产品，为了提升推理质量，我把底层换成了当时排行榜更靠前的旗舰推理模型。单测确实变好了，但端到端延迟从 1 秒涨到 3 秒，用户明显感觉到“转圈时间变长”。更难受的是，代码里到处充斥着针对旧模型的 Prompt 适配逻辑，换模型后这些逻辑全变成了技术债。

第三个项目是工具调用密集型 Agent，需要频繁把用户请求转成结构化参数。这次我吸取教训，选了“工具调用能力强”的模型，但上线后还是不稳定——同一个模型，在简单场景下能准确抽取参数，在对话轮次多、上下文杂的场景里就开始丢参数、乱格式。我把原因归结为“模型不够好”，又想去换下一个。直到我坐下来把所有请求日志拉出来分析，才发现问题根本不是模型能力，而是所有请求都走了同一个模型的同一条路径，没有任何分流机制。

这三个项目给了我同一条教训：模型选型的决策，必须建立在“运行时路由规则”已经存在的前提下。类比一下就是，你在组建一个演出团队，模型是台上的演员，而 Runtime 是舞台调度。演员再优秀，调度混乱、谁该什么时候上场都没安排好，整场演出照样砸。“先把路由规则写进 Runtime”的含义是：在你讨论选哪个模型之前，先想清楚运行时由谁、依据什么条件把一条条请求分发给不同的模型。

这可能也是很多 Agent 项目做到一半就卡住的核心原因——大家都在盯着模型的强弱，忽略了请求在运行时的“交通管制”。没有交通管制，每辆车都冲向同一条路，那路的宽度就决定了整个系统的上限。

2. Agent模型选型，先看任务负载表，再看模型排行榜

很多人选模型上来就打开榜单找分数最高的那款，这在大模型能力快速迭代的今天，其实是最容易出错的姿势。榜单反映的是静态 benchmark 上的平均能力，而你的 Agent 跑的是动态的真实请求。我建议先做一张任务负载表，把系统里实际出现的任务类型、调用频率、上下文长度、延迟敏感度都列出来，再拿这张表去和模型能力做匹配。

2.1 建一张任务负载表：把Agent拆成一串可量化的动作

具体做法不复杂，我会在项目启动后先跑一周的最小可用版本，把日志里出现的请求按意图归类。比如一个助手类 Agent 可能拆出这些动作：闲聊寒暄、知识问答、内容总结、代码生成、工具参数抽取、多步规划、记忆检索。每个动作再统计平均请求量、Token 消耗、是否依赖长上下文、用户能容忍多少延迟。

这张表看起来朴素，但价值非常大。它让你意识到“Agent 模型的压力不是平均值，而是峰值分布”。比如我的项目里，80% 的请求是短文本的意图识别和工具调用，只有 20% 是长文档总结。如果这 80% 和 20% 共用同一个旗舰模型，那就是用大炮打蚊子，成本高、速度慢，还把简单任务的成功率拉低——因为超强模型在简单任务上反而容易出现“想太多”的跑偏。

有了任务负载表，选型才真正有了依据。我不会再问“哪个模型最强”，而会问“哪组模型组合起来，能让这张表里每一项任务都落在合适的模型上”。通常我最后会选两到三款模型组成一个模型池，而不是押注单一模型。

2.2 六项核心评估指标：工具调用、长上下文、并发、结构化输出、成本、横向公平对比

在具体的评估维度上，我会重点看六项，这些比泛化的“推理能力”更贴近 Agent 场景：

这六项里，工具调用可靠性和结构化输出稳定性最容易被忽略，因为 benchmark 榜单上它们并不直观。但在 Agent 场景里，这两项就是生命线。某一次我对比两款模型时发现，A 模型的综合分数比 B 模型高了一大截，但在工具调用测试集上，A 的成功率只有 82%，B 是 97%。如果你的 Agent 每三步就要调一次工具，82% 的成功率意味着整条链路成功率只有一半多一点，这样的模型再强也没法用。

2.3 如何做一轮不骗自己的A/B盲测

选型评估最大的敌人是“先入为主”。团队讨论时很容易有人直接说“某模型我试过，挺好”，然后所有人都开始找证据支持这个观点。我后来改成了一套比较严格的盲测流程：

先从生产日志里挑出 100 条真实请求，按任务类型分层抽样，确保简单、中等、复杂都有覆盖。然后让两个模型分别跑同一批请求，输出记录到两个目录里，去掉模型名字。最后找团队里不参与开发的人帮忙打分，评分维度就三个：任务完成度、格式合规度、内容边界安全。跑完之后再揭晓模型身份，统计各维度胜出情况。

有意思的是，好多轮盲测下来，胜出的往往不是“感觉最强”的那个，而是“错得最稳”的那个。模型 A 在复杂任务上表现惊艳但在简单任务上偶发跑偏，模型 B 每个任务都稳定 85 分，后者才是 Agent 更需要的。因为 Agent 是链路式系统，一个环节的偶发错误会被后续环节放大，稳定性的价值远大于上限表现。

这轮盲测得到的结果，会成为我后面写路由规则的输入。哪个模型适合处理复杂推理，哪个适合快速分类，哪个适合工具调用，全部基于真实数据，而不是直觉。

3. 写进Runtime的路由规则，我整理出七类常用策略

现在进入正题：路由规则到底怎么“写进 Runtime”。这里的 Runtime 不是指某个特定框架，而是指 Agent 从接收请求到输出结果的整个运行环境，包括请求入口、主循环、工具调用层、上下文管理模块。路由规则要下沉到这些公共层，而不是散落在业务代码里。

3.1 任务类型路由：让擅长推理的去推理，让擅长分类的去分类

最基础的路由是按任务类型分发。实现思路是在请求入口做一个前置分类器，这个分类器本身可以用轻量模型完成，通过一次小成本调用判断请求属于哪类任务，然后把请求分发给对应的模型。

例如一个助手 Agent 里，我可以把“闲聊”路由到快速响应的小模型，把“代码生成”路由到推理更强的模型，把“长文档总结”路由到上下文窗更大的模型。这样做最大的收益是成本和延迟同时下降，因为简单任务不再被沉重模型拖慢。需要注意的是，前置分类器本身也会引入额外延迟和一次模型调用成本，所以不要让分类器走完整思维链，用一个带有少量指令的快速输出即可，理想情况下控制在几百 Token 以内。

3.2 上下文复杂度路由：以对话轮次和Token量为准绳

第二种常用路由指标是上下文复杂度。它是任务类型路由的重要补充，因为同一类任务在不同上下文长度下的表现差异很大。

我的判定规则比较容易落地：统计当前对话轮次和累计 Token 数，超过阈值就切换到长上下文模型或启用摘要压缩流程。比如某次在测试知识问答类 Agent 时，我发现当上下文超过 12k Token，轻量模型的回复开始丢早期信息，但我的业务里，90% 的对话在 8k Token 以内就能完成。于是我把 12k 作为切换阈值，低于它走轻量模型，高于它才走强推理模型。这样既不牺牲长对话质量，又避免了常规对话全部被高成本模型“吃掉”。

3.3 成本感知路由与并发熔断：不让烧钱变成事故

成本是一个容易被忽略但实际会翻车的问题。某个月初我在生产环境里看到成本曲线异常上翘，排查后发现是某个上游系统的重试风暴，导致所有失败请求都反复调用旗舰模型。当时没有成本相关的路由规则，成本直接失控。

后来我把成本感知路由写进了 Runtime 的公共层，核心是三道防线：

• 单次任务预算：一个任务链路的 Token 估算超过设定上限时，强制切换到成本更低的模型或降级策略。
• 模型池月度配额：给每个模型配置月度上限，达到阈值后自动把流量切换到次优模型。
• 并发熔断：监控模型商的返回延迟和错误率，当错误率超过 5% 时触发熔断，降低对该模型的调用速率，同时启动备用模型。

这三道防线不要求复杂的机器学习，就是几个计数器加阈值判断，但非常管用。那次成本事故之后，我再加上熔断机制，月底成本曲线基本都在预算内。

3.4 失败回退路由：换模型不能“无脑重试”

模型调用失败时，很多人直接重试同一模型，这在高负载或模型商故障时毫无意义。我的做法是建立按次序回退的模型链：主模型失败后，先检查失败类型，是超时、限流、内容安全还是格式错误，再决定回退到哪个模型。

比如工具调用场景的主模型如果返回了一段抽取失败的 JSON，我会把它路由到另一个结构化输出能力更强的模型重新解析，而不是让同一个模型再试一次——同一模型的失败模式往往是可复现的，“再试一次”大概率还是同一个错。这块在下面的“回退闭环”里还会展开讲，因为这里最常犯的错误就是无脑重试引发级联失败。

3.5 延迟敏感路由与结构化输出路由：往前端体验和下游可靠性让步

交互体验对延迟非常敏感。某助手项目的用户主要来自移动端，网络环境复杂，端到端超过 2 秒用户就会流失。面对这种情况，我把“交互型请求”和“后台处理型请求”分开：需要即时响应的场景，路由到响应速度更快的模型，哪怕它的推理深度浅一点；后台批量任务、离线总结等不敏感场景，才路由到效果更好的大推理模型。

结构化输出路由是另一类：当任务的下游依赖严格 JSON 输出时，我会在运行时增加一个“格式校验器”，校验失败直接进入重新生成流程，并把重生成任务路由到结构化输出更稳的模型。有人觉得这一步可以被 Prompt 工程替代，但实际测试下来，在复杂工具调用场景里，Prompt 工程的上限远不如“选定模型+格式校验+失败重路由”的组合稳。

3.6 少样本拾取路由：让案例自动匹配最合适的模型

少样本拾取听起来有点高级，实际上就是在路由规则里加了一个“同类型任务历史成功案例匹配”的环节。比如用户的请求和过去某个已成功完成的请求在语义上相似度很高，那就直接参考那次成功的模型配置和 Prompt 模板，而不是重新走完整的模型决策。

我在一个数据处理 Agent 里试过这个思路。用户反复上传相似的报表，第一次系统用通用流程处理，成功率不算高；积累了几次成功案例后，路由规则会自动匹配相似历史请求，把对应模型和 Prompt 模板捞出来。运行三周后，这类报表的处理成功率从 78% 提升到了 95% 左右。这算是一种轻量级的“经验记忆”，实现成本不高，但效果提升明显。

3.7 不把规则写死在工具里：Runtime路由链骨架

前面这些路由策略，如果写在业务代码或工具内部，就会散落成大量重复的 if-else，维护的人会疯掉。我推荐把它们抽成一个路由链，挂在 Runtime 的公共层。核心思路是这样一段伪代码：

class RouteContext: task_type: str # 由前置分类器产出 ctx_tokens: int # 当前上下文 token 数 budget_left: float # 剩余预算 retry_count: int # 已重试次数 latency_sensitive: bool # 是否交互型请求 trace_id: str # 用于全链路追踪 class RoutingChain: """路由规则按优先级依次执行，命中即返回目标模型""" def route(self, ctx: RouteContext) -> ModelEndpoint: for rule in self.rules: target = rule.match(ctx) if target is not None: # 记录路由决策，供可观测性系统使用 audit.record(ctx.trace_id, rule.name, target) return target return self.default_model

每个具体的路由策略，比如任务类型路由、上下文复杂度路由、成本熔断，都是RoutingChain上的一个规则对象。这样新增策略不需要改动业务代码，只需要追加规则，而且每一条规则都能被独立观测和验证。这也回应了标题里的“写进 Runtime”——路由规则不是业务逻辑，应该沉淀在运行时基础设施里。

4. 路由表、状态机与可观测性，是规则可维护的三大支柱

路由规则能跑通和能维护是两回事。我见过不少项目，路由规则用代码实现得很“灵活”，但过了一个月没人敢动，因为根本不知道哪些规则在生效、哪些规则已经冗余。要让路由规则长期可维护，我自己的经验是抓好三大支柱：路由表、状态机、可观测性。

4.1 路由表：用声明式配置代替散落的if-else

路由规则写死在代码里还是声明在配置里，决定了这套系统的演进空间。我的做法是把常见路由规则抽成一张 YAML 路由表，运行时加载，支持热更新。表的结构大致是这样：

rules: - name: task_type_route priority: 100 condition: field: task_type operator: eq value: casual_chat target: fast_cheap_model - name: context_complexity_route priority: 90 condition: field: ctx_tokens operator: gt value: 12000 target: long_context_model - name: cost_budget_route priority: 80 condition: field: budget_left operator: lt value: 0.05 action: switch_to_cheaper_model

用配置而不是代码的好处有三个：一是规则之间的关系清晰可见，二是没有编程经验的产品同学也能参与调整阈值，三是配置变更可以通过发布流程做版本管理。缺点是配置多了以后，条件之间可能互相覆盖，所以我在表里加了一个 priority 字段，优先级高的规则先匹配，避免条件重叠时出现歧义。

4.2 状态机：路由判定发生在Agent生命周期的哪个环节

路由规则不是只在请求入口执行一次就完事了。Agent 的完整生命周期通常包括理解、规划、调用工具、反思、回复等阶段，每个阶段适合的模型可能都不同。如果只在入口路由一次，后面环节的问题依然解决不了。

我的做法是给 Agent 加一个轻量状态机，状态包括：意图识别中、任务规划中、工具调用中、结果反思中、回复生成中。每个状态都有对应的路由上下文。比如“意图识别中”这个状态，路由规则会倾向把请求交给响应快的模型，因为这里追求的是速度和大致方向；“工具调用中”则可能切换到工具调用能力更强的模型，并且在该状态开启结构化输出校验；“结果反思中”这个状态对延迟不太敏感，可以用更强模型做一次质量复核。

状态机与路由表联动之后，模型选择就从“每个请求选一次”细化成“每个生命周期阶段选一次”。这样做的效果很直接：整条链路的成本能降下来，同时每个环节的成功率都有对应的模型兜底。不过也要提醒一句，状态机不是越细越好，状态太多会让路由规则本身的维护成本上升，基本五个左右的状态就够了。

4.3 可观测性：路由决策要能追溯，否则调优就是盲人摸象

路由规则写完后，最怕的就是线上出问题却说不清是哪条规则把请求分到了哪个模型。为此我每次路由决策都会记录一份不可篡改的路由日志，字段至少包括：trace_id、请求路径、命中的规则名、目标模型、匹配时的上下文快照、最终结果是否成功、消耗 Token 数、环节延迟。

这份日志的作用不仅是排查问题，更是调优的依据。我每周会跑一次路由效率分析，看四条核心指标：

• 各条规则的命中比例，是否存在某些规则几乎没机会命中（冗余规则）。
• 各模型端点的错误率和回退发生率，识别给出问题最多的模型。
• 平均单任务成本和 P95 延迟，判断路由策略有没有达到预期收益。
• 规则命中后任务成功率 vs 未命中时的成功率，用来评估规则本身的质量。

有一次分析发现，我加的“少样本拾取路由”规则命中率只有 2%，而且命中的任务成功率提升也不明显，于是果断下线了它，路由链反而清爽了不少。可观测性的价值就在这里：它不是事后追责用的，而是让每个规则都能被量化和验证，避免路由规则膨胀成无人敢动的历史遗留。

5. 踩坑后的路由治理经验：误路由、回退闭环与规则膨胀

最后这部分，聊几个我在真实项目里踩过的坑。这些坑几乎每类 Agent 项目都会遇到，提前知道能帮你省下至少一两轮的“全链路排查”时间。

5.1 误路由的代价比模型弱的代价更大

路由规则本身也会出错。分类器置信度不高时，把复杂任务错误地路由到轻量模型，整条链路的输出质量会大幅下降；或者把简单请求路由到旗舰模型，虽然质量没问题，但成本和延迟白白浪费。

我遇到的最严重一次误路由，是把一个高复杂度任务路由到了快速小模型，小模型给出一个看似完整的方案，但在细节上是错的。这个错误方案被后续工具调用环节放大，最终污染了整个任务结果，比我直接用弱模型做完整链路还要差。经验是两条：当分类器置信度低于阈值（比如 0.75）时，不要强行分流，直接走默认的安全模型；路由目标的选择标准不是“这个模型够不够好”，而是“这条任务在目标模型上的最差表现能不能接受”。

5.2 回退链要设计闭环，避免反复调用同一个模型

回退链路设计不当，会出现“环型失败”：主模型超时了，回退到备选模型，备选模型也超时，然后又绕回主模型，如此反复，直到请求彻底失败。而且每次绕回都带着累计延迟，用户体验非常差。

我的应对策略有两条。第一，对每个模型设置独立的超时上限，主模型和备选模型之间不能共享同一个超时配置，否则回退没有意义。第二，为每次请求记录“已尝试模型列表”和“失败原因哈希”，如果同一个请求已经被某个模型处理过并失败，后续规则直接跳过它。这种闭环机制让回退链最多只会走两到三跳，不至于在多个模型之间死循环。

5.3 路由膨胀：当规则多到没人敢改

路由规则最大的渐进式风险是膨胀。我在某个服务里曾经把路由规则加到了四十多条，看起来覆盖了所有可能的情况，但上线后很多规则之间存在条件交叉，明面上没有冲突，实际行为却取决于规则的加载顺序。团队成员改任何一条规则都会担心影响到其他规则。

后来我做了一次“减法重构”，原则很简单：留“必需品”路由，砍“想了很久但实际极少触发的情况”。分类后保留的规则类型大概只是前面说的任务类型、上下文复杂度、成本感知、失败回退、延迟敏感、结构化输出这六类，少样本拾取在数据不够充分时也先不启用。路由规则的精髓在于“决策可解释、行为可预期”，计算得越复杂反而越难信任。

5.4 哪些路由必须下沉到Runtime，哪些可以留在业务层

最后关于架构边界：不是所有“判断”都应该塞进 Runtime。总结下来，全局性的、跨业务模块的、涉及成本控制的规则，必然要下沉到 Runtime；而那些业务含义特别强的一次性判断，比如某个流程自身需要的一次特殊分流，就没必要抽成通用规则。

我的划分标准是：如果这条规则在两个月内，大概率会被同项目的另一个模块或另一个项目复用，就下沉到 Runtime；如果只是为了解决当前模块的一个局部抖动，就留在业务层，用简单条件判断处理。坚持这个标准，可以让 Runtime 路由层的规则保持精炼，又不至于失去可复用价值。

收尾

最后一个个人体会：Agent 模型选型这个问题的答案，从来不应该是一行“我推荐某模型”的结论，而应该是一套“什么任务在什么条件下由哪个模型处理”的规则系统。我现在的习惯是先画任务负载表，再写路由规则，最后才打开模型列表做匹配。这样每次模型场上出现新的强模型，我都能快速判断它在我的规则系统里适合填补哪个位置，而不是冲动换机。

另外想分享一个这个项目带来的后续启发：路由规则做得好了，模型切换本身会变成一个非常轻量的操作。某次要换掉主力推理模型，我提前一周把路由规则和回退链配置好，正式切换时只是改了路由表里的一个 target 字段，跑了十分钟金丝雀，就把流量放过去了，没有任何代码变更。这种体验，和早期换模型就要改一大堆适配逻辑相比，天壤之别。希望这篇偏实战的拆解，能让你在选模型时不再被榜单牵着走，真正把注意力放到运行时的那套规则上。