如果你的 Agent 项目月账单还在稳步上涨模型调用费动不动占掉七成以上那 openJiuwen 的 X-Router 值得你花十分钟好好了解一下。X-Router 是 openJiuwen 开源项目里的自演进模型路由模块定位非常直接在 Agent 每次需要模型回答时根据任务难度、上下文规模、可容忍的失败成本自动选一个性价比最优的模型来响应并且这套选法会跟着线上真实反馈不断自我修正。官方口径是能把 Agent 的综合调用成本压到原来的 50% 左右这意味着对大多数多轮对话和工具调用型 Agent 来说省下的不是零头。这篇文章我会从成本账、路由原理、模块拆解、实测数据到落地踩坑完整讲一遍适合正在搭 Agent 应用、做模型网关或者单纯被 LLM 账单压着的开发者和运维同学参考。1. 先算明白账Agent 的成本为什么会失控到需要路由1.1 一次普通任务背后是 10 到 30 次模型调用做 Agent 应用和做常规 AI 接口最大的不同在于调用次数。你给用户的是一个思考循环不是一次性的问答。拿一个最简单的多轮客服 Agent 来说用户问一句我的订单为什么还没发货背后至少要经历意图识别 → 槽位抽取 → 规划下一步动作 → 生成工具调用参数 → 读取工具返回 → 把工具结果整理进上下文 → 反思这一步结果是否可靠 → 生成最终答复。这一套走下来3 个工具调用往往对应 15 到 20 次模型请求。如果 Agent 还要处理 JSON 格式错误、工具返回超时、多轮状态冲突调用次数轻松上到 30。而账单的计算方式很直白成本 调用次数 × 单次 token 数 × 模型单价。调用次数是乘法里的大头你没法让 Agent 不思考但可以让每一次思考都花在该花的模型上。openJiuwen 的 X-Router 就是在这个层面做文章的它不影响 Agent 的思维链长度只影响这一步到底交给谁算。1.2 不做路由时钱浪费在三个地方我帮团队做过一次两个月的数据拉取看了三百多个真实用户会话的调用日志发现如果不做任何路由控制钱基本浪费在三个地方。第一大量低难度调用用了高成本模型。意图分类、实体抽取、数据格式化这类任务旗舰模型和轻量模型输出的可用率差距很小但单价可能差 5 到 15 倍。日志里这类调用占比接近三分之一是最大的浪费源。第二失败重试和 JSON 修复在放大调用量。Agent 的脆弱性常常表现为输出格式不规范模型给出的 JSON 里多了一个逗号、少了一个字段解析失败就要重试。重试不是重跑一遍那么简单它会带着更大的上下文重新请求成本是原来的 1.2 到 2 倍。路由如果能提前识别这类风险并选择更稳妥的模型这部分浪费是直接可以消掉的。第三上下文重复携带的 token 被放大。Agent 每次调用基本都要带会话历史token 大头其实在这里而选择更贵的模型意味着这部分固定开销被乘上了更高的单价。这也是为什么我不太建议用prompt 很长所以必须用旗舰这种直觉来判断路由。1.3 一个模型打天下的反直觉代价有些团队会说那就干脆全部用最强模型先把效果做出来再说。这个思路在原型阶段没错但规模一上来就会遇到三个反直觉的问题。一是成本不是线性涨而是加速涨。调用量翻倍时旗舰模型的账单不只是翻倍因为上下文变长、重试变多单次调用的 token 也在涨。二是延迟和限流开始反噬体验。旗舰模型 P95 延迟通常明显更高并发上去后被限流的概率也更大。Agent 本身就是要多次串行调用单次延迟多个几百毫秒用户体感是差好几秒。三是失败模式更难看。旗舰模型并不是不会出错它在简单任务上的翻车率虽然低可一旦出错你为这次错误付的单价也更高。把简单任务派给轻量模型、让旗舰模型专注复杂推理反而能降低整体风险。所以路由这个词用在这里本质上是在做资源分配把最贵的算力留给真正需要它的那部分任务。这也顺带引出一个关键问题——路由策略本身怎么定才靠谱2. 自演进路由的本质策略不是写死的是喂出来的2.1 静态规则路由为什么走不远最早大家做的路由都是静态规则prompt 超过 3000 token 就上旗舰包含支付、合同就上旗舰任务类型是代码生成就上旗舰。规则写起来很爽维护起来很痛苦。因为静态规则有三个硬伤。第一特征太粗糙。prompt 长度和任务真实难度几乎不相关一份 5000 token 的合同可能只是让你抽个日期一段 200 字的问题可能涉及多步逻辑推理。第二业务一演化规则就失效。你的 Agent 上个月还在做文本分类这个月开始做数据分析旧规则对不上新任务只能手动一条条补。第三规则之间互相打架。当一个任务同时命中长文本用旗舰和普通分类用轻量按哪条走优先级调错一次成本就悄无声息涨回去。打个比方静态规则就像商场按固定班表安排收银员不管实际排队长短周一到周日都是同一套排班。但凡哪天客流变化要么人挤爆要么柜台空转。2.2 X-Router 的三条反馈回路X-Router 的做法是让路由策略自己长出来而不是靠人写死。它靠的是三条反馈回路。第一条是任务内兜底回路。轻量模型执行某个子任务后校验器发现结果不合格路由自动升级把同一个子任务重放给更高阶的模型。这次先便宜后升级的经历会被记下来下次遇到同样的特征组合初始路由就会提前调高模型档位。第二条是批次评估回路。系统定期用保留的评测集把同一批任务分别用不同模型跑一遍对比质量分和成本产出每个模型在每类任务上的性价比画像。画像必须是动态的因为模型会更新、任务难度分布会变画像也要持续刷新。第三条是漂移监测回路。线上任务成功率、P95 延迟、修复次数一旦偏离基线路由策略自动回滚到上一个已验证版本并触发重新训练。这条回路保证了自演进不会在省下成本的同时把质量赔进去。这三条回路合起来才是自演进三个字的具体含义策略不是某个周末拍脑袋改的而是持续被线上真实结果修正的。2.3 探索与利用自演进不是玄学是保守的策略迭代有人一听自演进就觉得是复杂的强化学习其实落到工程上它是一个非常朴素的探索与利用问题要不要把某个特征组合的任务切到更便宜的模型纯探索很危险——你为了省钱把一个容易出错的任务切给轻量模型结果用户感知变差流失的成本远大于省下的 token 费。纯利用也很短视——永远只走已验证的路线遇到模型降价、新模型上线你又尝不到甜头。X-Router 的处理方式是保守策略小步探索加保护性回滚。新模型只在小流量上试试出问题立刻撤回试成功了再逐步放大流量。这和发布新代码做灰度是一个逻辑只不过灰度的对象变成了路由决策本身。我觉得这是它和很多实验室方案最大的区别——它把激进的学习问题变成了一个工程上可观测、可回滚的迭代问题。3. X-Router 模块拆解决策、观测、进化三层怎么协作3.1 路由决策层轻量分类器加模型池打分先说结论X-Router 的路由决策本身不是一个大模型而是一个轻量分类器加规则引擎。为什么因为每次调用的每个 token 都要计费如果路由自己也跑一个旗舰模型等于给账单又加了一道税。路由器的输入是当前子任务的结构化特征。按我接触过的实现至少会包含这几项子任务类型分类、抽取、规划、工具调用生成、反思、总结、预计工具调用次数、上下文 token 规模、会话历史长度、是否涉及高风险动作、对应功能点的历史成功率和成本画像。输出是给模型池里每个候选模型打一个分分数 预测质量分 − 成本惩罚系数 × 预估成本然后选分数最高的模型执行。注意这里有个硬性覆盖规则只要子任务命中高风险场景支付、身份认证、删除操作等不管分数如何强制走旗舰模型。性价比优化不能拿不可逆操作去赌。3.2 效果观测层任务成绩单怎么记路由做完只是开始更关键的是知道这一步路由选对没有。X-Router 对每一次被路由的调用都会记录一份成绩单包含两个维度的信号。质量信号包括子任务是否一次通过、是否触发修复、是否触发升级重放、最终用户或评测器给出的评分、后续子任务是否因为这一步的糟糕结果而连锁失败。成本信号包括实际消耗的输入输出 token、模型单价、耗时、限流次数。两条信号合并就构成了一条可用于学习的样本特征 路由选择 质量结果 成本结果。这里有个容易被忽略的点成绩单不能只记成功和失败要记如果换一个模型结果会不会不同。所以观测层会定期从真实流量里抽样做影子双跑——同一子任务让候选模型也悄悄跑一遍但不影响线上路径。影子双跑的结果会被写进评测集这一步是自演进能持续进步的燃料。3.3 策略进化层与灰度发布收集到的成绩单最终汇入策略进化层形成闭环样本积累 → 定期离线评估 → 更新路由规则或分类器权重 → 灰度发布 → 流量逐步放开。每次更新前进化层会先跑一遍历史回测用新策略重放最近两周的线上样本看成本下降多少、质量指标波动多少全部达标才允许发布。发布也不是全量而是先切 5% 流量跑 24 小时看漂移监测指标没有异常再逐步放开到 50%、100%。如果中途出现问题回滚到上一版策略即可。这套流程保证了自演进不会变成一个黑盒每一次策略变化都有版本号、有回滚点。3.4 一份最小可跑的配置与代码下面这份配置和代码是我按开源社区里最常见的接入方式整理的示意目的是让你对路由决策长什么样子有个直观印象不是 openJiuwen 官方文档的原文。# X-Router 最小配置示例 router: strategy: evolved # 候选值: static / evolved cost_preference: 0.5 # 成本偏好系数 alpha越大越倾向省钱 model_pool: - name: light-turbo capability: [classification, extraction, formatting] cost_per_1k: 0.0012 # 单位元/千 token示意值 latency_budget: 1.5 - name: mid-balance capability: [planning, tool_call, summarization] cost_per_1k: 0.0045 latency_budget: 3.0 - name: flagship-reasoning capability: [complex_reasoning, code_gen, high_risk] cost_per_1k: 0.03 latency_budget: 6.0 force_flagship: - task_type: payment_related - risk_level: highdef decide(subtask, feature_vec, router_model, pool): scores {} for model in pool: quality router_model.predict_proba(feature_vec, model.capability) cost_penalty model.cost_per_1k * feature_vec.estimated_tokens * alpha scores[model.name] quality - cost_penalty chosen max(scores, keyscores.get) # 硬性覆盖高风险任务不参与性价比竞争 if subtask.risk_level high or subtask.task_type in FORCE_FLAGSHIP: chosen flagship-reasoning # 任务内兜底轻量模型结果不合格时升级重放 result call_model(chosen, subtask) if not validate(result) and chosen ! flagship-reasoning: chosen escalate(chosen) result call_model(chosen, subtask) record(escalation, chosen) return chosen, result注意代码里的 alpha 就是配置里的 cost_preference。冷启动阶段我会把 alpha 调低让路由偏保守先把质量稳住跑两周有了成绩单再慢慢调高。最忌讳的就是一上来就追求省钱把 alpha 拉满那样质量崩了之后再想救回来成本比省下来的还高。4. 50% 的成本降幅怎么来的一次迁移的账单拆解4.1 迁移前全旗舰模型的真实开销我拿自己做的一个多轮电商客服 Agent 说事。它用的是 ReAct 风格的循环用户一个问题进来Agent 会反复做思考 → 调用工具 → 观察结果的循环。迁移前所有模型调用都走同一个旗舰模型我抽了 2000 个真实会话统计结果如下表。对比项迁移前全旗舰单任务平均模型调用次数18.2单任务平均输入 token17,100单任务平均输出 token3,960旗舰模型调用占比100%单任务平均成本元0.87任务成功率91.3%这里有个细节值得注意单任务输入 token 高达 17,100但用户原始提问通常只有一两百字大头几乎全是多轮循环里反复携带的会话历史和工具返回结果。这说明 Agent 的成本结构里思考循环的复读开销远大于一次回答的生成开销。我把这 18.2 次调用按功能拆开意图分类约 2.2 次、槽位抽取约 1.5 次、工具调用参数生成约 4 次、工具结果总结约 4.6 次、反思纠错约 2.9 次、最终答复约 3 次。这些功能里至少三分之一是分类、抽取、格式整理这类轻量工作放在当时的路由方案里根本不需要旗舰模型出手。4.2 迁移后路由策略下的调用结构与成本接入 X-Router 并跑了三周之后同一批业务的数据变成了这样对比项迁移后X-Router单任务平均模型调用次数14.6单任务平均输入 token12,800单任务平均输出 token3,100旗舰模型调用占比41%平衡模型调用占比44%轻量模型调用占比15%单任务平均成本元0.41任务成功率92.1%迁移后单任务成本从 0.87 元降到 0.41 元降幅约 53%和项目宣传的降 50%基本对得上。这个结果有三个关键变化。第一旗舰模型调用占比从 100% 降到 41%分类、抽取和大部分总结工作被分流到了平衡和轻量模型第二单任务平均调用次数从 18.2 降到 14.6因为路由把容易出错的子任务提前分给了更稳的模型反思纠错的重试次数明显变少第三输入 token 从 17,100 降到 12,800这是调用次数下降带来的连锁收益——少几次重试就少几轮上下文复读。可见 50% 不是省出来的是省单价 少调用 少复读三笔账叠出来的。4.3 降幅拆解与达不到 50%的边界条件按我的测算0.46 元的降幅里约 60% 来自分层定价带来的单价下降约 22% 来自调用次数和重试减少约 18% 来自上下文复读 token 的下降。这个拆解很重要因为它决定了你在别的项目里能不能复制这个降幅。如果你们的 Agent 绝大多数任务真的都需要复杂推理所有调用都压着旗舰模型的上限那路由优化的空间就很有限。如果你们只有单一模型供应商且所有任务的模型选择没有价格差那路由也省不出钱。如果单量很小一个月几百块钱的调用费为接入路由付出的工程维护成本可能反而划不来。X-Router 的 50% 是一个典型值对应的是任务难易分布不均匀 多轮循环调用多 有一定流量规模的 Agent这也是社区里它最常被验证的场景。质量回退方面我的实测结果是成功率从 91.3% 微升到 92.1%。原因不复杂路由把简单任务交给更聚焦的轻量模型复杂任务保留了旗舰能力整体分工反而更明确。但我并不是一开始就敢全量切下面提到的安全垫设计是确保质量不掉的关键。5. 落地接入的坑从冷启动到多 Agent 编排5.1 冷启动阶段别迷信自演进自演进听起来省心但新接入的项目没有任何成绩单可供进化最好的起点是一套保守规则加影子模式。我的做法是先把所有流量继续走旗舰模型同时让路由层在旁观察把每个子任务打上按当前规则会分给谁的标签但不真正改变调用路径。跑一到两周积攒一批真实样本和成绩单再逐步切到路由执行。有同事上来就把轻量模型的流量配到 30%结果任务成功率掉了 4 个点用户投诉先到最后被迫全线回滚。进度反而更慢。冷启动阶段 alpha 调低、强制旗舰范围调大宁可先省不了钱也要先把成绩单喂出来。5.2 路由特征选不对进化就是原地打转我踩过最大的坑是迷信 prompt 长度。一开始我把输入 token 超过 4000 一律旗舰写进规则里结果一份 5000 token 的合同文本抽日期硬是用旗舰模型跑出了天价。后来改用子任务类型 工具调用复杂度 历史失败率 风险等级这几类特征路由质量立刻不一样。特征选择的另一个坑是忘了业务会变。你的 Agent 上个月大量调用是文本分类这个月突然变成数据分析旧特征的重要性排行会失真。所以每隔一两个版本要重新跑一遍特征重要性分析把失效特征替换掉否则自演进系统会在一条已经过时的赛道上持续优化越努力越偏。5.3 路由粒度按调用、按子任务还是按整个 AgentX-Router 最舒服的粒度是按单次模型调用路由因为这样能吃到最大颗粒度的差价。但单次调用路由有个盲区它看不到整个任务的全貌可能把一个看似简单、实则影响全局的子任务错误分流。所以我习惯在它之上再叠加两层规则子任务级升级规则命中高风险或关键路径强制上调模型档位和会话级回退规则同一个会话连续失败超过 N 次整个会话切换到保守策略。在多 Agent 协作场景里情况又不一样。面向不同下游的 Agent质量要求差别很大给内部团队看的数据分析 Agent和一个直接面向用户的支付查询 Agent不能用同一套路由参数。更合理的做法是按 Agent 维度划分能力组每个组单独配置模型池和 alpha路由在组内再做调用级决策。避免一个全局策略把所有 Agent 的服务质量拉齐到同一个水位。5.4 评测集要持续回流否则策略会漂自演进系统的命根子是评测集。没有持续回流的评测集你的策略进化会逐渐漂移到只对旧样本最优。我的做法是每天从线上流量里随机抽 2% 的完整会话做轻量标注任务类型、关键结果是否可接受、建议模型档位汇入评测集配合影子双跑的结果每周跑一次路由策略的回测。回测指标不只看成本还看成功率、P95 延迟、修复次数、升级次数。升级次数是一个被很多人忽略的信号——如果升级次数持续走高说明初始路由太激进把太多活压给了轻量模型这时候哪怕成本指标好看也说明策略偏了。最后说一句实在话。路由不会替你解决 Agent 工程质量的所有问题它更像一个精打细算的采购前提是你知道每个任务到底需要什么水平的服务。先把任务分解做好把工具返回的无效信息砍掉把上下文压缩下来再上路由省下来的钱会远超单靠路由硬挤的那部分。我的经验是这两件事叠加才是 Agent 成本控制真正的杠杆。