最近在折腾 Agent 成本优化翻到一个叫 openJiuwen X-Router 的项目主打的就是“自演进模型路由”这个方向。说实话模型路由本身不算新概念但真正把路由策略做成“系统自己能在线上根据反馈持续演进”的目前还是比较少见这也是我花时间拆它的主要原因。项目宣称的效果很直接在保持 Agent 任务成功率不明显下降的前提下把模型调用成本降低 50% 左右。如果你正在做 AI Agent 应用每个月看模型账单的时候肉疼或者团队里还在靠手工配置“哪些任务走贵模型、哪些任务走便宜模型”那这篇文章建议完整看一下。我会从 Agent 成本失控的根源讲起拆解 X-Router 的自演进机制然后给出一套可以照着接入的实操方式最后把我在实际测试里踩过的坑和排查思路一并整理出来。文章面向的是搞 Agent 开发、做 AI 应用架构、以及被模型账单困扰的从业者读完可以直接对照自己的项目做改造。1. Agent 成本失控的根源与模型路由的破局点1.1 Agent 的 token 消耗比你想象的更猛做 Agent 开发的人都有一个共同感受单次调用模型的 token 数其实还好真正可怕的是上下文膨胀。Agent 本质上是一个循环每一轮它都要做“理解指令 - 调用工具 - 把工具结果塞回上下文 - 让模型决定下一步”这套动作。工具返回的日志、JSON 结构、报错信息全都会留在对话历史里越滚越大。我拿自己的一个实际例子来说。一个看似很简单的任务“帮我把文档里所有联系人提取出来按公司分组再逐个发一封定制邮件”。这个任务跑下来Agent 调用了 4 次工具产生了 8 轮模型请求。因为每一轮请求都要把之前所有轮次的对话历史重新发送一遍最后一轮请求的输入 token 已经接近 8 万。整个任务累计消耗了大约 26 万 token而其中真正被“有效使用”的信息可能不到十分之一。这个现象可以总结成一个公式Agent 总 token 消耗 ≈ 平均上下文长度 × 模型调用次数。上下文因为工具结果累积而变长调用次数因为循环和重试而变多两者相乘成本自然非常夸张。很多团队以为自己在为“复杂的推理能力”付费实际上账单里相当大一部分是给“重复阅读历史记录”付的钱。1.2 一刀切式模型选择钱都烧在低价值请求上成本失控的第二个原因是模型选择策略太粗放。很多团队为了保证 Agent 的质量所有请求都打到旗舰模型上这当然省心但代价极高。关键在于Agent 内部的模型请求难度差异非常大。判断用户意图是“查询天气”还是“修改订单”这是非常简单的任务小型模型完全能胜任。从一段文本里提取若干个结构化字段属于中等难度用中等模型就够了。真正需要旗舰模型发挥能力的往往只是整个流程里的一小步比如生成一段策略性很强的回复、做复杂的多步推理、或者在信息模糊时做出合理推断。我实际测算过一个典型 Agent 场景大概 70% 的模型请求都属于“低难度”或“中等难度”只有 30% 的请求真正需要旗舰模型。如果 100% 的请求都按旗舰模型计费那相当于 70% 的调用在花冤枉钱。模型路由要做的事情就是把这部分冗余成本识别出来把简单请求分流到便宜的模型上。理解模型路由可以类比成分诊台。医院不会让所有病人都直接去找主任医师护士会先做分诊普通感冒去普通门诊疑难杂症再转专家。模型路由就是 Agent 系统的护士在请求正式发给模型之前先判断这个请求是什么难度、应该交给谁处理。1.3 自演进路由和人工规则的差距在哪既然路由的思路这么清晰为什么很多团队没有做最朴素的做法是人工维护规则。比如“prompt 里有‘总结’这个词就走便宜模型prompt 里有‘代码’就走贵模型”。这种规则在一两个场景下还能用但放到真实业务里很快就不灵了。用户的表达千变万化同一个意思可能有几十种说法规则不可能覆盖全。而且业务一扩展规则就要重新维护成本非常高。再进阶一点的做法是用一个小型分类模型做路由比如 BERT 级别的文本分类器。这个方案比纯规则好一些但仍然有一个致命问题分类器的训练需要人工标注数据而且 Agent 的任务分布不是静态的。今天主要处理文档提取明天主要做客服对话分类器的效果就会明显下滑需要频繁重新训练。X-Router 代表的“自演进”路线和上面这些方案有本质区别。它不预设任务的分类而是把路由当成一个可以持续优化的策略问题系统根据每个请求的特征prompt 内容、工具定义、历史上下文等输出一个“该用哪个模型”的概率分布。在任务跑完后又根据实际结果给这次路由决策打分再把这个分数反馈给路由策略做更新。整个过程不需要人工标注也不需要维护规则路由策略自己会随着真实任务分布的变化而调整。我把三种方案放在一起对比了下方案类型维护成本对新任务类型的适应性准确率天花板对线上反馈的利用人工规则高持续维护低新任务要重新写取决于规则覆盖度无小型分类模型中需要定期标注重训中分布变化后需要人工干预取决于标注质量无自演进路由低策略自动调整高任务分布变了能自适应理论上无明确上限完整利用2. 自演进路由闭环X-Router 的学习机制拆解2.1 概率路由在“稳”和“省”之间留出探索空间很多人第一次接触 X-Router 时最困惑的是路由策略输出的是一个概率分布而不是确定的模型 ID。比如面对某个请求策略输出“旗舰模型 0.25中等模型 0.45轻量模型 0.30”然后系统按这个概率去采样决定最终调用哪个模型。为什么要用概率分布而不是每次直接选“最有把握”的那个原因在于如果路由策略总是选择它当前认为最合适的模型那它永远得不到“如果当时选了另一个模型结果会怎么样”这个信息。这会形成一个死循环便宜模型因为没被选中所以没有效果数据因为它没有效果数据所以策略永远不认为它值得被选中。X-Router 的做法是探索与利用的折中。大部分请求比如 80%走策略认为最优的选择利用已有经验保证整体质量和成本小部分请求比如 20%做随机探索用真实线上数据验证那些还没被充分评估的模型组合。随着反馈数据的积累策略会逐渐降低表现不佳模型的概率提高表现优秀模型的概率整体分布会向“省钱且不翻车”的方向收敛。实际测试中我观察到这个概率分布变化是一件很有意思的事情。刚上线时策略比较保守旗舰模型占比较高跑了一两天之后轻量模型在某些任务类型上的概率快速上升大约一周后整个分布基本稳定下来只有遇到新类型任务时分布才会再次波动。这种自我调整的过程就是标题里“自演进”三个字的直观体现。2.2 反馈管道用什么信号来定义“这次路由选对了”自演进路由比静态路由多出来的一环是反馈管道。没有反馈路由策略就无从学习。X-Router 里的反馈信号来源有几个层次第一层是任务完成标志。Agent 最终有没有完成用户的目标是最硬的信号。比如任务是“查询并修改订单状态”如果 Agent 成功调用了修改接口并返回了确认信息这就是一个正向信号。第二层是中间步骤异常。Agent 在循环过程中出现的解析失败、工具调用报错、格式不正确这些都记录了当时的上下文是路由决策是否合理的重要参考。第三层是结果质量评估。有些任务没有明确的“成功”标准比如“写一封招聘邮件”完成度很难用布尔值判断。这种情况可以用一个 LLM 作为裁判把 Agent 的最终输出和一个参考标准做对比打分也可以结合用户有没有直接采纳或修改结果来判断。这里有一个容易被忽视的细节反馈不是针对“路由策略”这个整体做的而是针对“某一次具体的路由决策”做的。Agent 一次完整任务包含多轮模型请求每一轮对应一个路由决策这些决策组合起来构成一次完整的轨迹。等最终结果出来后系统会回溯这条轨迹给每一跳路由决策都分配一个信用分数——哪些轮次选择了合适的模型、哪些轮次选得不好。这比“一顿操作之后看个总结果”要精细得多。2.3 50% 成本降幅是怎么算出来的很多人看到“降价 50%”会觉得很夸张我一开始也持怀疑态度直到自己算了一笔账之后才觉得这个数字确实有道理。为了演示假设一个 Agent 任务平均消耗 30 万 token旗舰模型的价格是每百万 token 30 元轻量模型是每百万 token 3 元。如果按传统做法所有请求都走旗舰模型单个任务的模型成本就是 300000 / 1000000 × 30 9 元。接入 X-Router 后如果 70% 的请求被识别为低难度任务分流到轻量模型剩下 30% 仍走旗舰模型。这时成本变成两部分轻量模型部分 300000 × 0.7 / 1000000 × 3 0.63 元旗舰模型部分 300000 × 0.3 / 1000000 × 30 2.7 元合计 3.33 元。9 元降到 3.33 元降幅刚好是 63%。所以在路由准确率足够高的情况下降低 50% 是个保守的数字而不是吹牛。当然这个计算有一个前提任务分布里需要有足够多的低难度请求。如果你的 Agent 主要处理的是高难度推理任务那降幅自然达不到这个量级。但对于绝大多数真实业务 Agent尤其是工具调用型、文档处理型、客服型 Agent低难度请求占比普遍在 60% 到 80% 之间这个假设是成立的。还有一部分降幅来自重试次数的减少。使用旗舰模型时出现解析错误、格式错误重试成本极其高昂。而路由策略会学习到“哪些请求在哪些模型上更容易出错”尽量避免把高风险请求分配到不合适的模型上从源头上减少了重试的次数。这个间接收益往往比直接降本更可观。3. 实操过程把 X-Router 接入你的 Agent3.1 部署结构与最小配置X-Router 的部署结构分两部分策略服务是核心所有需要路由的模型请求都通过它来做决策对外暴露 HTTP 或 gRPC 接口入参是请求特征出参是各模型的选择概率评估管道负责产训练样本它异步消费 Agent 的运行日志结合最终结果生成反馈信号定期更新路由策略。对一个已经有 Agent 在跑业务的团队来说接入的规模不需要从一开始就做得很大。可以先搭建路由服务和评估管道把测试流量接进来。配置层面候选模型列表和初始策略是必须的。下面是一份参考配置router: candidates: - id: premium provider: openai model: gpt-4o unit_price_per_million: 30 - id: balanced provider: openai model: gpt-4o-mini unit_price_per_million: 8 - id: cheap provider: local model: qwen2.5-7b unit_price_per_million: 2 initial_strategy: premium: 0.5 balanced: 0.3 cheap: 0.2 optimization: metric: cost constraint: success_rate 0.95 exploration_rate: 0.2注意这里的 initial_strategy 我故意设置得比较保守。刚上线时大家都不知道哪个模型在哪些任务上表现好旗舰模型占比高一点是求稳让路由策略先积累数据后面它会自己调整。exploration_rate 控制探索流量的比例一般从 0.2 起步比较安全跑一段时间数据稳定之后可以降到 0.1 甚至更低。3.2 统一模型调用入口核心改造点接入 X-Router 最核心的工程改造是让所有模型请求从一个统一入口经过。看到这里很多团队会头疼自己的 Agent 代码里可能直接用 LangChain 调用模型也可能直接调 OpenAI SDK还可能有自己封装好的客户端没有统一入口怎么办我的建议是不要试图一次性改完所有调用点而是抽一个公共的模型调用函数或者网关层让后续新代码都走这个入口老代码逐个替换。核心封装思路大致是这样的import openai import requests class RouterClient: def __init__(self, router_url: str): self.router_url router_url def complete(self, messages, toolsNone, temperature0.3): # 第一步收集请求特征 features { prompt: messages[-1][content], total_length: sum(len(m.get(content, )) for m in messages), num_messages: len(messages), has_tools: bool(tools), } # 第二步交给路由服务决策 resp requests.post(f{self.router_url}/route, jsonfeatures, timeout2) resp.raise_for_status() choice resp.json()[choice] # 返回一个模型 ID # 第三步按选择结果调用真实模型 if choice premium: return openai.ChatCompletion.create( modelgpt-4o, messagesmessages, toolstools, temperaturetemperature, ) elif choice cheap: # 本地模型或其它提供商 ...这个封装有三个细节值得注意。第一route 接口的超时时间要设置得很短比如 2 秒因为路由服务本身不能成为 Agent 的瓶颈。第二路由的入参特征不要只传 prompt对话长度、消息条数、是否带工具这些都是影响任务难度的关键信号。第三路由返回超时或者失败时要有降级方案最简单的方式是直接走默认模型宁可贵一点也不能让 Agent 挂掉。3.3 接入 LangChain 时的具体做法如果你的 Agent 是基于 LangChain 或同类框架搭建的接入方式会稍微优雅一些因为框架本身支持自定义 LLM 封装。下面是一个最小示例from langchain.llms.base import LLM from typing import Optional, List, Mapping, Any class RouteLLM(LLM): client: RouterClient property def _llm_type(self) - str: return router_model def _call(self, prompt: str, stop: Optional[List[str]] None, **kwargs) - str: messages [{role: user, content: prompt}] response self.client.complete(messages, **kwargs) return response[choices][0][message][content] property def _identifying_params(self) - Mapping[str, Any]: return {router: True}接入之后Agent 里所有使用self.llm的地方在代码逻辑上不需要任何改动模型选择的决策完全交给路由层处理。实测下来这样的改造对原有代码侵入性最小也是我最推荐的方式。有一点需要提醒在 Agent 框架里工具调用和结构化输出的场景要特别注意路由服务返回的选择结果。如果你的 Agent 需要模型返回严格的 JSON 格式而路由策略把一个结构化输出占比很高的任务分给了本地小模型极大概率会出现格式问题。所以刚开始接入时建议在路由特征里加一个require_json的标记路由服务会根据这个标记提高对格式能力要求高的模型的选择概率。3.4 上线之后到底该盯哪些指标接完路由器只是开始更关键的是后续的观测和调优节奏。我自己的经验是上线后至少盯这几个指标第一个是成功率变化曲线。路由前后同样任务的成功率对比是最重要的指标。如果成功率下降超过 1 到 2 个百分点就要警惕这可能不是系统容错范围内的问题而是路由策略把某些关键任务误判到了低能力模型上。第二个是模型分布变化。看路由策略输出的选择比例在时间轴上的变化趋势。如果旗舰模型占比始终居高不下说明路由策略没有充分学到省钱信号如果便宜模型占比涨得太快那就需要回头检查反馈信号是不是出了偏差。第三个是成本趋势。成本不是匀速下降的往往在策略更新后的几小时内会出现一个明显下降阶梯然后进入平台期。如果成本曲线长期没有变化大概率是探索率设置得太低或者反馈信号根本没有正确回流。第四个是路由服务自身的延迟和稳定性。路由服务如果平均响应时间超过 200 毫秒或者错误率超过 1%对整个 Agent 的影响比模型本身的成本还大。这个基础设施必须稳定到让用户无感知才行。我实际跑在线调优时最常用的一套节奏是第一周设置 exploration_rate 为 0.2不求省钱先求摸清任务分布第二周把成功率的硬约束从 0.95 调到 0.93给策略更大一点的空间去切换模型第三周看整体成本降幅和成功率数据如果质量稳定就把探索率降到 0.1 并收敛策略。这种渐进式上线的方式风险最小。4. 常见问题与排查技巧实录4.1 路由策略“狂点贵模型”先别急着骂策略上线后最常见的现象是路由策略跑了好几天旗舰模型占比还在 80% 以上成本几乎没降。大部分人会本能地认为是策略没学好但实际原因往往在反馈信号上。我排查过的一个典型案例某客服场景的 Agent 接入 X-Router 后发现便宜模型被选中的概率极低。后来看日志才发现这个 Agent 大部分任务最终都以“用户没有明确确认”结束被判定为失败。但这里的失败其实并不是模型能力不足而是任务本身需要用户介入确认无论哪个模型来做都不可能成功。失败的反馈却一股脑全算在“你选了便宜模型”头上路由策略自然越来越保守。排查思路很简单看反向样本。把成功和失败的任务分别按模型拆解观察失败的任务里到底有多少是“模型本身能力不足导致的失败”有多少是“任务流程本身的局限”。发现后者占比过高说明反馈信号的归因逻辑有问题。解决方式是调整反馈管道把这类场景从失败样本里剔除。另一种常见情况是上下文特征太弱。如果路由服务只看到很短的 prompt而没有把工具数量、历史轮数、任务类型等特征传进去它很难准确区分任务难度。这时候不是策略出了问题而是模型看到的特征不够。可以把请求侧的特征采集补全再重新训练策略。4.2 便宜模型误判导致的质量滑坡怎么定位和“不敢选便宜模型”相反的另一个问题是“便宜模型被过度使用导致质量下降”。症状通常表现为某类任务的失败率突然上升但整体指标还是被大量简单任务的成功掩盖着。面对这个情况第一件事是分层看数据。不要只看整体成功率要按任务类型、prompt 上的特征等维度去拆分。我自己常用的方法是给每个模型选择决策打上日志重放一个时间段内被分到便宜模型的请求人工抽查其中失败的任务很快就能找出规律。定位到某类任务确实不适合便宜模型后最直接的办法是把它加入禁用黑名单。X-Router 支持在路由策略之上叠加硬规则比如“包含‘法律条款解读’这样特征的任务强制走旗舰模型”。有读者可能会觉得加硬规则违背了“自演进”的初衷但我认为两者并不矛盾。硬规则处理的是已经明确证实的异常区间自演进策略处理的是系统尚未发现的未知情况。在业务稳定期加入少量必要的硬约束能避免策略在一个“已经看得到坑”的地方反复踩进去。还有一类细节问题经常被忽略工具返回格式。任务失败的原因可能是工具返回的 JSON 结构与模型 prompt 的预期不符模型怎么选都会失败。如果反馈管道把失败归咎于路由策略会让策略学到一个错误的结论“这个任务就该用旗舰模型”。排查这种问题时要对照同一任务在不同模型下的失败原因是不是一致。失败原因相同说明问题不在模型选择而在上游数据处理。4.3 自演进回路的“自我满足陷阱”所有自演进系统都会面临一个问题系统倾向于强化自己已有的行为模式却对“没有尝试过的可能性”缺乏探索。X-Router 如果处理不好这个问题就会陷入局部最优。举个具体的例子。假设某个任务类型旗舰模型和轻量模型其实表现差不多但旗舰模型的成功率略高一点点。如果目标函数没有明确的成功率硬约束策略为了省钱会把大部分请求分给轻量模型随着这部分请求增多偶尔几个失败样本由于占比不高影响不大策略会继续加码。终于有一天某个边缘案例撞上了便宜模型的明显短板大规模失败就可能爆发。等到反馈回来再调整损失已经造成了。要避免这个陷阱核心是把质量作为约束条件而非目标函数。单纯追求“最低成本”系统一定会想办法在约束边缘游走而把“成功率不低于 95%”作为硬约束再在这个前提下优化成本才能保证路由策略不翻车。另一个手段是保持一定的探索流量恒定存在让策略始终有能力发现“某些任务还没被尝试交给便宜模型”的可能性而不至于在现有认知里越陷越深。在实际运行中我会建议大家每两周审视一次评估管道里的成功率和成本目标权重不要一套配置跑到底。业务变了、任务变了约束条件也得跟着变。4.4 缓存与并发问题路由层的新瓶颈接入 X-Router 后工程上最容易被忽略的问题不是路由准确率而是缓存与并发。先说缓存。如果一个 Agent 会话很长多轮请求之间相似的内容会被重复发送。为了让缓存命中率保持在一个较高的水平同一个会话里相同语义的请求最好路由到同一个模型否则缓存系统会因为模型不同导致搜索空间分裂。实际操作中路由服务可以对同一对话按会话 ID 请求摘要做一次本地缓存相同请求直接返回相同选择结果。这样既保证了模型选择的一致性也避免了路由层本身的重复计算。再讲并发。X-Router 作为 Agent 系统新增的一个依赖必须有明确的降级策略。我见过线上事故路由服务 OOM 之后Agent 所有模型请求超时整个业务直接不可用。正确的做法是路由服务的超时设置要远小于模型调用的超时一旦路由超时或者返回异常立即降级到默认模型路径而不是让 Agent 等待报错。同时路由服务要做水平扩展至少两个实例起步避免单点故障。还有一个小技巧路由服务本身是纯计算任务可以把模型选择和业务逻辑解耦。路由服务只需要知道请求特征不需要理解业务语义这样它可以被多个 Agent 项目共用。如果公司内部多个团队都在做 Agent搭一个公共的路由基础设施成本分摊下来核算会更划算。我个人在测试 X-Router 时最深的体会是它真正解决的其实不是“选模型”这个动作而是“让 Agent 团队不需要再手工维护一套模型选用规则”的问题。成本降低 50% 不是靠某套神奇的算法白捡的而是靠把原来那些高价低价值的调用一点一点吃掉。如果你也在做 Agent建议先把模型调用的分布统计起来哪怕暂时不接入路由器只是看清楚自己每个请求的真实模型消耗就能发现不少浪费的地方。后面等路由策略跑顺了还可以把这个思路进一步扩展到 embedding 模型选择、向量库配置、缓存策略上那又是一片新的优化空间。先把手头这笔账算明白比什么都重要。