自演进模型路由如何将Agent成本压下一半？openJiuwen X-Router实战解析

做 Agent 项目的朋友，大概率都经历过一个阶段：Demo 跑得飞起，一上线账单直接教你做人。我自己就见过一个团队，日活不到一千的 Copilot 产品，一个月的大模型账单飙到六位数。核心原因很直接——Agent 不像普通 API 调用，内部要循环多次大模型推理，每次还要把工具返回、历史记录、系统提示全部塞回上下文，烧 token 的速度肉眼可见。这也就是 openJiuwen X-Router 这个项目出现的背景：一套带自演进能力的模型路由系统，让 Agent 在质量基本不掉的情况下，把大模型成本压下去接近一半。它适合正在做 Agent 应用、被模型账单搞得头疼的开发者，也适合想优化多模型调用策略、但又不想手工维护规则的人。

我先把话说在前面：这活儿真正难的不是“路由”本身，而是“自演进”这三个字——路由策略要自己跟着任务分布变，而不是写死一套规则然后等着失灵。下面我把整个设计思路、核心实现、部署接入和实测数据全部拆开讲，踩过的坑也一并记录在内。

1. 先把问题看清楚：Agent 的成本到底被谁吃掉了

1.1 一次 Agent 任务的账单，拆开全是流水

很多人对 Agent 成本的认知还停留在“输入 token + 输出 token”这种简单乘法上，实际完全不是这么回事。一个普通的“比价查询 Agent”，用户问一句“帮我对比附近几家超市的牛奶价格”，它在后台干的事远不止一次大模型调用：

• 第一次调用：解析任务、拆解计划，决定要调用哪些工具
• 第二次调用：决定调用什么工具，输出 function call 参数
• 第三次调用：把工具返回结果读进来，判断信息是否足够、要不要继续查
• 第四次调用：把最终结果组织成自然语言回复用户

有时候还带 self-reflection，后台还要多一步自我检查。这还只是理想情况，工具调失败、结果不完整，重试次数直接翻倍。

更要命的是上下文膨胀。每轮调用都要把之前的对话历史、工具输出全部带回去，任务进行到第 10 轮，上下文可能已经堆到四五万 token。如果你给 Agent 配的是顶级 Pro 模型，单次任务烧掉 20 万到 40 万 token 完全是常态，折算下来一次任务几块钱甚至十几块钱。

这里最讽刺的地方在于：这些任务里有相当大比例难度并不高，完全用不到顶级模型的推理能力。用一个便宜模型输出，效果几乎没差别，成本却可能只有原来的十分之一。80% 的简单流量用着最贵的模型，这就是 Agent 成本居高不下的真正原因。

1.2 静态路由方案为什么在 Agent 场景不中用

先澄清一点：模型路由并不是个新概念，API 网关层早就有人做了。但市面上很多网关的路由策略是静态规则，最常见的套路是“输入超过 2000 token 走大模型，低于 2000 走小模型”。这种方案在普通接口调用场景没什么大问题，放到 Agent 场景就漏洞百出。

问题出在三个地方：

• 长度不等于难度。一个 300 token 的复杂推理题，可能比一个 2000 token 的“复制粘贴类任务”难得多。拿长度当难度指标，很容易把简单任务送进贵模型，把复杂任务送进小模型。
• 语义表达差异太大。用户可以换一百种说法问同一件事，关键词规则永远追不上语言表达的多样性。今天加一个规则，明天就有新说法漏网。
• 任务分布是活着的东西。业务方改了 Prompt、增删了工具、上了新功能，任务画像就漂移了。写死的路由规则，在写下的那一刻就已经开始过时。

所以静态路由适合的是相对稳定的接口调用场景，在 Agent 这种动态性极强的场景里，过不了几天就会变成一堆需要不断打补丁的烂账。

1.3 自演进模型路由的本质：把路由变成闭环

“自演进”是 openJiuwen X-Router 区别于普通路由网关的核心卖点，说白了就是三个环节转成一个闭环：路由决策、结果反馈、策略更新。

先由路由器决定这次请求走哪个模型；Agent 执行完之后，验证器或用户把结果质量信号传回来；系统定期用这些信号更新路由参数，让路由策略自己适应任务分布的变化。

如果说传统网关是一个固定分岔路口，那自演进路由就是一位有经验的老司机——他不仅知道这条路怎么走，还会根据路况实时调整策略。表现为 “这个任务类型最近用 Lite 模型成功率变低了，下次遇到直接走 Pro”。这套能力对 Agent 项目特别关键，因为任务分布永远是动态的，路由策略只有跟着动态走，才不会被时间淘汰。

2. openJiuwen X-Router 的整体设计：把路由当作可学习系统来搭

2.1 双层路由架构：规则快路径 + 模型慢路径

X-Router 第一眼看上去最让人舒服的设计，是它没有把所有判断都交给一个黑盒模型，而是拆成了非常清楚的两个层级。

第一层叫规则层，负责处理硬约束。比如财务审计类的请求要强制走 Pro 模型，某些用户要求不降级，或者预算已经快触底了需要熔断。这层的判断成本为零、延迟为零，主要用来当安全兜底，不承担智能任务。

第二层才是模型层，把经过规则层过滤的请求交给一个轻量分类器做语义复杂度打分，输出三档结论：lite / mid / pro。也就是说，高优请求在规则层就被拦截了，剩下的普通流量才轮到路由模型来判断，这样既保证关键业务不出事，又让路由模型只处理它擅长的事情。

这个设计背后有个很实在的考量：把规则和模型混在一起，会导致系统更难排查、更难回滚。规则层是死逻辑，模型层是活逻辑，分开之后，出问题可以很清楚地知道是哪部分出了问题，回滚范围也小得多。

2.2 反馈信号从哪来：验证器、用户反馈、隐式统计

路由系统有个天然痛点：模型选得对不对，要等任务执行完才知道。所以反馈回路是决定自演进能不能跑起来的关键。openJiuwen X-Router 的做法是定义标准接口，要求 Agent 在任务执行完以后把评估结果回传。回传信号主要有三类：

• 验证器（Validator）信号：程序自动检验，比如 JSON 格式对不对、SQL 能不能跑通过、关键字段是否缺失。这类信号最客观，推荐优先接入。
• 显式反馈：用户实际点了赞还是踩了踩，权重最高。但用户一般懒得点，样本稀疏，只能作为校准参考。
• 隐式信号：Agent 执行统计，比如这个任务的调用轮数、整体耗时、失败重试次数。如果某个请求让 Agent 反复重试，那大概率是模型能力不够用。

这三类信号最终统一汇总成每个请求的“质量得分”，作为 X-Router 自演进更新的原材料。没有反馈闭环的路由是盲人摸象，有了反馈闭环，路由系统才算是长了眼睛。

2.3 自演进闭环的四个阶段：监控、分析、调整、灰度

X-Router 的自演进更新不是边跑边改的野路子，而是按照标准四阶段循环来做的：

这套流程下来，路由策略变成了一个可以迭代版本的系统，而不是一堆不能修改的临时规则。每次策略更新都有版本号，出问题可以直接回滚。

2.4 为什么选择了在线自演进而不是离线训练

这个点我在设计阶段纠结了很久。一开始的设想是定期离线训练一个路由模型，用历史数据批量更新。后来发现根本跑不通原因也很简单——Agent 的任务分布变化太快了。今天上线一个新工具，明天用户的语言习惯变了，离线模型训练一次要几个小时，训练完事上线的已经是过时策略。

X-Router 最终采用的是在线自演进方案，并且在策略里加入了 bandit 思想的探索机制。也就是说，大部分流量按当前已知的最优策略分配，但同时保留一小部分流量做随机试探。比如 95% 的请求按当前模型分配，5% 的请求故意送到其他档位的模型测试效果，通过试探样本的反馈来发现潜在地更优策略。

这种探索与利用的平衡，保证了系统不会因为固守当前策略而错过更优解，也不会因为频繁乱试探而影响大部分流量的体验。

3. X-Router 核心实现：路由判定与成本控制的关键细节

3.1 任务复杂度画像：不应该只看 Query 长度

之前说过，用“输入长度”判断任务难度是静态路由的死穴。X-Router 的做法是给每个请求构建一份“任务复杂度画像”，核心评估以下六个维度：

• 意图复杂度：这个请求是要简单事实查询，还是需要多步推理
• 检索深度：是否需要调用多个工具或检索多个数据源
• 推理要求：答案是直接从资料里复制，还是需要从多条信息中归纳推导
• 输出格式复杂度：只需要一段话，还是需要结构化 JSON、表格、图表
• 风险等级：任务内容是否涉及财务、医疗等高风险决策
• 上下文规模预期：历史轮数较多、上下文较长时，对模型的长期记忆能力有更高要求

实际实现时并没有追求每个维度的绝对精确，而是保证相对排序的稳定。拿意图复杂度来说，它做到的是“能区分出这个任务大概率是简单的还是复杂的”，而不是试图给出一个绝对评分。追求绝对精确只会让特征工程变成无底洞。

3.2 路由分类器为什么不用 LLM，而是轻量模型

有一个非常自然的想法是：让一个大模型来当路由器，由它判断请求的复杂度，再决定要不要升级。我在调研初期确实认真考虑过，很快就否了——因为这么做等于往路径上插入了一次额外的大模型调用，既增加了 token 开销，又给整个 Agent 加了几百毫秒的延迟。路由的意义是省钱，路由器本身却在烧钱，这笔账怎么算都不划算。

X-Router 的最终方案是：embedding 模型加一个极浅的 MLP 分类器。输入由 query 的 embedding 向量和手工特征的拼接向量组成，输出是 lite / mid / pro 三档的概率分布。因为分类器非常轻量，单次判断延迟可以压缩到几十毫秒以内，成本几乎可以忽略。

下面贴一段简化版的路由判定逻辑，方便理解整体流程：

import numpy as np def route_request(query_text, feature_vector, router_model, embed_fn): # 1. 规则的硬约束检查 if is_forced_pro(query_text): return "pro" if is_blocked_or_budget_over(query_text): return "lite" # 2. 计算 embedding query_embedding = embed_fn(query_text) # 3. 拼接 query_embedding 和手工特征 merged = np.concatenate([query_embedding, feature_vector]) # 4. 分类器输出三档概率 prob = router_model.predict_proba([merged])[0] # [p_lite, p_mid, p_pro] # 5. 按阈值决定路由结果 if prob[2] > 0.6: # pro 概率高 -> 走强模型 return "pro" elif prob[1] > 0.5: # mid 概率较高 -> 走中等模型 return "mid" else: return "lite"

这里的阈值不是写死不动的，自演进过程中会动态调整。Adjust 阶段干的事情，说白了就是拿着历史反馈数据，重新计算这三个档位的最优判定边界。

3.3 成本控制不能只靠路由，还要有预算熔断

路由只能决定“这次请求走哪个模型”，但一个完整的成本控制方案还需要在更高一层做预算管理。X-Router 在路由层实现了软性熔断机制。

具体做法是按租户、按天设置预算桶。每一次路由请求都会估算即将消耗的 token 成本，从预算桶里预扣。当预算快到红线时，路由系统会自动把策略向低成本方向偏移：本来走 mid 的请求降到 lite，本来走 pro 的核心链路以外的请求也降到 mid。预算见底时触发硬熔断，要么拒绝服务，要么全部流量降到最低成本模型，保证业务不断。

这个机制的价值在于，成本是可预知、可控制的。不然就算有路由，月底账单依然可能超支失控。

3.4 自演进策略的安全网：质量底线与版本回滚

自演进这个词听起来很美好，但也潜藏风险：系统为了降低成本，会不会把越来越多的请求压向小模型，导致整体质量缓慢下滑？这是任何自动调优系统都绕不开的失控风险。

X-Router 在设计中配置了三层安全网：

• 质量阈值自动兜底：如果某个任务类型的 Lite 模型成功率低于设定值（比如 85%），策略会自动把这些请求回归到 Pro 模型。
• 策略版本管理：每一次 Adjust 产生的策略都有版本号，任何异常都可以秒级回滚到上一个稳定版本。
• 人工熔断开关：出现紧急问题时，可以一键冻结所有策略更新，把系统切回纯静态规则模式。

这三层安全网的价值在于：系统可以自演进，但它的边界永远受业务安全约束。我一直认为，做自演进系统的人必须时刻警惕“全自动”这三个字，真正的全自动不是没有刹车，而是刹车永远在旁边等着。

4. 实操接入：把 X-Router 接到 Agent 项目的完整步骤

4.1 接入对业务代码的侵入，比想象中小得多

X-Router 上线之前，团队最担心的是 Agent 代码要大改。真正接完才发现，因为它在实现上兼容 OpenAI SDK 的协议，接入基本是无感的——只需要把 Agent 原本请求的 base_url 改成 X-Router 的网关地址，并在请求头里带上租户标识，原有代码的 model 参数即便保持不变，路由器也会接管真实的模型选择。

这对 LangChain、Dify、AutoGen 这类框架来说非常友好，框架内部的 Model 调用不感知底层变化，省掉了大量改造工作量。如果以后想下线 X-Router，把 base_url 改回去就完成回退，没有任何历史包袱。

4.2 环境准备与启动：用 Docker 拉起来就能跑

实际部署 openJiuwen X-Router 的流程比想象中顺畅。整个系统包含两部分：路由网关本体和反馈分析组件，官方给了 Docker Compose 编排，一条命令就能把整套环境拉起来。

启动前要准备两项基本配置：一是路由分类器和 embedding 模型的模型服务地址，二是 Agent 侧反馈上报 API 的对接密钥。下面是一段简化版配置文件的关键字段说明：

router: model_pool: lite: endpoint: "http://lite-model-service:8000/v1" api_key: "sk-xxx" weight: 0.6 mid: endpoint: "http://mid-model-service:8000/v1" api_key: "sk-xxx" weight: 0.3 pro: endpoint: "http://pro-model-service:8000/v1" api_key: "sk-xxx" weight: 0.1 default_route: "mid" safety: min_lite_success_rate: 0.85 budget_lock_enabled: true force_pro_whitelist: - "finance_audit" - "medical_consult" feedback: endpoint: "http://x-router-feedback:9000/report" validation_header: "x-request-id"

模型池的 weight 字段是最开始的路由权重，这个值只影响初始状态，系统跑起来之后，自演进过程会根据反馈数据逐步修改实际分配比例。配置阶段不需要去精调权重，重点是把策略和熔断开关设好。

4.3 反馈上报接口怎么对接：x-request-id 是关键

路由出结果之后，质量反馈必须回传，否则自演进闭环就是空转。X-Router 要求 Agent 在发起第一次路由请求时拿到一个 x-request-id，整个任务执行过程中所有相关调用都携带这个 ID，任务结束后统一上报验证结论。

上报逻辑一般在两个地方接入：一是在 Agent 框架完成工具调用后马上把结构化结果发给验证器做自动校验；二是用户界面收到显式点赞或点踩时，把这些信号通过反馈上报 API 传回去。真实项目中 I 建议先做自动验证器的信号，因为这是唯一可以全量覆盖的信号源，显式用户反馈可以后续慢慢补。

4.4 灰度发布：先让 10% 流量试水

自演进系统上线，最忌讳一步到位全量切换。推荐做法是按流量灰度推进：

1. 先把 10% 的流量切到 X-Router，保持全部请求映射到 Pro 模型，这一步只是验证协议和网络链路，路由层暂时不改变模型决策。
2. 下个阶段开启路由决策，但路由阈值设得非常保守，只有极度明显的简单任务才分配给 Lite 模型。观察成功率。
3. 逐步放开阈值和探索比例，让自演进真正跑起来，每调一次版本就等一个完整的反馈统计周期。

整个过程至少经历两到三个灰度阶段，切忌跨阶段冒进。

5. 落地实测：50% 成本下降是怎么算出来的

5.1 测试场景与对照组设计

我们最终在三个场景做了实测，分别对应 Agent 应用最典型的三种形态：

对照组保留原有全量 Pro 模型配置，实验组在同样流量下接 X-Router，所有业务代码和 Prompt 严格保持一致，唯一变量就是模型路由策略。每个场景跑了完整一周，避免拿一天数据拍脑袋下结论。

5.2 实测数据与成本核算

实测跑完以后，三个场景的汇总数据如下：

成本下降接近 52%，和项目目标高度吻合。成功率从 99.2% 降到 97.6%，这个差异在多数场景下业务侧可以接受，但必须说明的是，金融、医疗这类容错率极低的场景绝对不能用同一套标准。实验组延迟反而更低，原因是轻量模型的响应速度更快，抵消了路由层带来的少量延迟。

5.3 为什么下降一半而不是更多

放开胆子的话，成本其实还能再往下压。实验组里 Pro 15%~25% 的流量，如果全部强行降到 mid，成本至少再降 10 个百分点。但我们没这么做，原因很实际：小模型偶尔犯错的样本全集中在那些最复杂的推理链上，强行压价会踩到质量红线，反而得不偿失。

另外要说清楚，50% 这个数字不是每个项目都能复现的。能不能省这么多，高度依赖任务分布中简单任务的比例。如果某个 Agent 本身就是做复杂推理的，简单任务占比很低，那路由能优化的空间天然就有限。判断一个项目适不适合上路由，标准只有一条：简单任务占比是否足够高。

6. 常见问题与排查技巧实录

6.1 路由全部被派到 Pro 模型，成本没降

上线后发现账单变化不大，先别急着骂路由算法，大概率是反馈环节断了或者规则层太严。第一个要查的是反馈上报接口有没有收到数据，如果反馈为空，自演进策略会默认保守，倾向于把请求全送到 Pro 模型。第二个要查的是 force_pro 白名单，是不是把大量普通请求都写进去了。我见过有团队图省事直接把整个租户加进白名单，那路由自然等于没生效。

6.2 Lite 模型经常把简单任务答错

如果简单任务的小模型成功率低于设定阈值，优先怀疑的应该是任务分类画像不准确，而不是模型本身太弱。处理思路是先把答错的样本捞出来，逐个查看验证器的判定依据，看看这些请求是真难还是验证器太严格。另一个常见原因是 embedding 模型质量不够，区分不开语义相近但难度差异很大的任务，这时候该做的是换更好的 embedding 模型。

6.3 如何判断自演进闭环真的在生效

看策略版本变更记录是最直观的方法。如果系统跑了一周，路由策略版本号和初始版本完全没有变化，说明闭环没转起来。正常状态下，系统每隔一两个反馈统计周期就会微调一次路由参数，可能是阈值偏移一点点，可能是某个任务分类的模型分配发生变化。版本号不动的系统等于没接自演进。

6.4 上线一段时间后效果缓慢退化

这个问题我踩过最深的坑。起初以为策略是稳定的，放养一段时间后成功率悄悄往下掉，账单又开始慢慢往上爬。事后定位原因就是任务分布漂移了，业务加了新工具，用户提问方式也变了，旧的策略版本没有及时跟上。解决办法是把策略自动更新的频率提上去，同时给 Monitor 阶段加上告警，当某任务类型的成功率连续异常下降时就自动触发策略重算，而不是等周会复盘时才发现。

6.5 问题排查速查表

这整套项目做完，我个人最大的体会是：模型路由不是一个“选个模型就完了”的体力活，它是一个需要反馈、迭代、灰度、回滚支撑的系统工程。如果你现在正准备给 Agent 项目降本，我建议先别一头扎进路由算法里，第一步把反馈数据接扎实了，比什么奇技淫巧都管用。最后再分享一个小技巧：路由策略的更新永远不要一次性调到底，每次只调一个维度，留足观察期，才能在省钱和质量之间找到那条真正稳的曲线。