企业官网建设流程全解析

最近在折腾Agent落地，最扎心的不是模型不会回答问题，而是账单蹭蹭往上涨。多轮对话、工具调用、上下文累积，每一环都在烧Token，跑一个业务Agent一个月的费用比想象中高出一大截。所以当openJiuwen X-Router这套自演进模型路由技术放出来的时候，我第一时间就去搭环境做了实测。先说结论：在模拟客服和资料分析两个Agent场景下，综合Token消耗减少了50%以上，而且是在昇腾单机环境里跑的，不是纯演示。

这套方案的核心逻辑其实很朴素——不让所有请求都涌向同一个最强模型，而是让路由层根据任务特征，把请求分发给最合适的模型，并且路由策略会随着真实调用结果持续自我修正。听起来不复杂，但落地细节很多。这篇文章我把原理、部署、实测数据和踩坑记录全部写出来，给准备做Agent降本的朋友一个参考。

1. Agent吃Token的真相：先算一笔明白账

想理解X-Router为什么能省这么多Token，先得搞清楚Agent的Token到底消耗在哪。很多人有个误区，觉得输出Token才是大头，实际上在多轮Agent场景里，输入Token才是真正的无底洞。

1.1 一个业务Agent的Token消耗主要由哪三块构成

第一块是固定开销。每个请求都会携带系统提示词和工具描述，如果你给Agent挂了十来个工具，这一块的Token可能就有两三千。无论用户问的是“你好”还是复杂业务问题，这部分固定成本一分都少不了。

第二块是上下文累积。这是最要命的。Agent每轮对话都要把历史记录重新发给模型，第10轮的时候，前面9轮的输入输出全都在请求里，Token量成倍增长。很多Agent框架虽然有上下文压缩机制，但压缩本身又要消耗一次模型调用。

第三块是输出开销。不只是回答本身，还有工具调用的参数。Agent每调用一次工具，就要生成一段JSON格式的参数，而且模型为了“稳妥”，经常会把不该输出的推理过程也输出出来，这些全部按Token计费。

我做过一个粗略计算：某个客服Agent单次对话平均10轮，系统提示加工具描述按2500 Token算，上下文累积平均下来每轮要重发4000 Token的历史，再加上输出平均1500 Token，跑完一次完整对话大概要消耗6万到8万Token。如果每天有几千次这样的对话，成本直接起飞。

1.2 为什么“所有请求都走最强模型”是最贵的习惯

早期做Agent demo的时候，大家都习惯把请求固定发到能力最强的模型上，理由是“这样效果最稳”。这个习惯在样本量小的时候没什么问题，一旦流量上来，问题就暴露了。

最强模型的单价往往是轻量模型的几倍甚至十倍，而且能力溢价只体现在复杂推理任务上。对于“查个订单状态”“把用户的问题转成结构化标签”“抽取一段文本里的关键实体”这类任务，轻量模型已经完全够用，但你还是按最强模型的价格在付费。

我打个比方，这就好比不管送什么货都开大货车。送家具确实需要大货车，但送一份外卖也开大货车，油费就白花了。大模型参数量大，前向推理的计算量也大，同样的Token量，最强模型消耗的算力和时间都更高，账单自然更贵。

实际浪费体现在三个具体形态：第一，简单任务走了大模型，属于单价浪费；第二，多轮历史不做分级，长上下文场景和短对话场景用同一套策略，属于用量浪费；第三，模型调用超时或返回异常后无脑重试，而且重试还是走同一个最强模型，属于事故性浪费。这三种浪费叠加起来，账单里至少有四成是冤枉钱。

2. X-Router的自演进模型路由：从“猜流量”到“学流量”

模型路由不是什么新概念，做API网关的团队多少都接触过。但X-Router这套方案让我觉得有意思的地方，在于它把“静态路由”升级成了“自演进路由”，不是人肉配置规则，而是让路由策略根据真实调用反馈自己迭代。

2.1 模型路由路由的不是“模型”，是任务画像

要理解模型路由，先要纠正一个直觉：路由决策的本质不是“哪个模型好”，而是“哪个模型适合这个任务”。X-Router在做决策时，核心是构建任务画像。

任务画像包含几个维度：请求的长度、涉及的领域、是否包含工具调用、是否需要长上下文理解、问题的复杂度预估。比如一个请求只有二十几个字，问的是“退货政策是什么”，任务画像就是短文本、知识问答、低复杂度，这种请求路由给轻量模型就够了。反过来，如果请求是一份几十页的合同摘要，要求输出结构化风险点，就必须路由给支持长上下文的最强模型。

这里要特别说一下，“模型路由”不等于“负载均衡”。负载均衡看的是后端实例的健康状态和并发压力，目的是把流量均匀分发；模型路由看的是任务特征和模型能力是否匹配，目的是让每个请求都找到性价比最高的模型。两者可以结合使用，但解决问题的层面完全不同。

2.2 自演进机制是怎么转起来的

X-Router的自演进机制，技术上其实是一个不断循环的闭环系统。整个流程可以拆成五步。

第一步是流量记录。路由层把每个请求的特征、路由到的模型、模型的响应结果全部记录下来。第二步是特征化，把原始请求转化成可计算的特征向量，包括语义特征和统计特征。第三步是结果反馈，这一步是关键，系统会从Agent的执行结果里提取质量信号，比如用户是否采纳了回答、是否有重试、任务是否完成、后续追问是否偏离主题。第四步是策略更新，基于这些反馈信号定期训练或更新评分函数，调整任务画像到模型池的映射关系。第五步是灰度生效，新策略先在少量流量上验证，确认指标不劣化再全量。

整个循环跑起来之后，就会出现标题里说的“越跑越省”。注意这里的“越跑越省”不是模型变强了，而是路由策略和你的真实业务数据越来越匹配。业务里的任务分布是固定的，刚开始路由不准，可能有30%的请求被错误分发到贵模型，跑一段时间之后，策略学会了你的任务规律，错误率降下来，Token消耗自然就少了。

静态路由和自演进路由的区别很明显。静态路由是上线前人工定规则，业务一变规则就得手动改；自演进路由是策略自己跟着数据走。下表是两者的对比：

3. 昇腾亲和是怎么做到的：不止是“能跑”

既然方案要在昇腾环境落地，那昇腾的适配深度就直接决定了这个东西能不能用在生产环境。我见过太多标榜“支持国产算力”的方案，实际上只是在昇腾上用了一个通用推理接口，性能和稳定性完全没法看。X-Router在这方面做了几层比较实在的适配。

3.1 昇腾NPU上跑Agent多模型会遇到什么坎

昇腾NPU和CUDA生态有本质差异，简单说就是算子库和加速栈不同。很多在GPU上跑得很顺的模型，直接搬到昇腾上可能某个算子不支持，或者图编译阶段失败，需要做算子映射和模型转换。

Agent场景里还有一个更麻烦的问题：多模型常驻。路由方案要求候选模型池里同时常驻几个不同规模的模型，比如一个小模型、一个中等模型、一个大模型，它们要共享同一块NPU的算力和显存。昇腾的显存管理和并发调度机制跟CUDA不太一样，多个模型同时加载时，如果不做显存规划和并发控制，很容易出现申请失败或者吞吐波动。

另外，Agent请求的特点是并发不高但请求频繁，而且序列长度变化剧烈。今天可能全是短问题，明天突然来一批长文档分析。昇腾NPU对动态shape的处理能力直接影响路由后的实际效果。如果模型经过图编译后只能支持固定shape，长文本请求就得做截断或填充，Token浪费反而更严重。

3.2 X-Router做昇腾亲和的具体设计

针对这些问题，X-Router在三个层面做了专门设计。

第一个设计是路由层本身极轻量化。路由决策尽量不要用大模型来算，X-Router用的是特征规则加轻量评分模型，整个路由服务的资源占用控制在很小的范围，不会出现“为了省Token，结果路由服务又吃掉一块显存”的尴尬。

第二个设计是统一推理接口。路由层不直接绑死某个推理引擎，而是通过一层统一的模型接入接口屏蔽后端差异。后端是昇腾的推理服务也好，是普通的HTTP推理接口也好，路由层只关心“这个模型能不能处理这个请求”“大概要花多少时间”，不关心底层的算子实现。这样在昇腾上适配时，只需要把推理服务接进来，路由策略本身不用重写。

第三个设计是调度器会感知昇腾NPU的特性。比如在单个NPU上同时跑多个模型时，调度器会限制并发上限，避免模型切换太频繁导致的性能抖动。同时会考虑NPU的显存带宽和算力余量，在路由决策阶段就把“这个模型此刻是否适合接收请求”纳入判断，而不是等请求发过去才发现后端已经打满。

3.3 昇腾A2单机部署的路由配置思路

具体到部署，我在一个昇腾A2单机环境里做了验证，方案是“一个小模型负责简单任务，一个中等模型负责常规问答，一个大模型负责复杂推理”。

显存规划上要精打细算。三个模型的权重加起来不小，还要留出KV Cache和推理中间结果的空间。我的做法是小模型用较低精度的量化部署，中等模型用标准精度部署，大模型开启KV Cache复用，三个模型常驻后，剩余显存还能支撑一定的并发推理。

这里有个重要提示，模型量化会引入精度损失，路由策略上要做兜底：如果请求被路由到量化小模型，但Agent执行后反馈质量不达标，下一次类似的请求会被自动升级到中等模型。也就是说，自演进机制不光会“降级省钱”，也会“升级保效果”，省钱的底线是效果不崩。

此外并发参数也要单独调。昇腾NPU上多模型共存时，并发开太大容易导致单个请求时延飙升，开太小又浪费算力。我实测下来，在一个具体业务负载下，并发数设置成4到6是比较稳的区间，再往上时延抖动就会明显。这个值跟模型大小和显存都有关系，建议上线前用真实请求做一次压测，不要照抄别人的配置。

4. 实测50%+Token节省：数据与代价拆解

光说不练没用。下面这部分是我实际测试的记录，直接放数据和结论，但我得先把口径说清楚，避免读者被一个“50%”误导。

4.1 我用来测试的场景和口径

测试场景选了Agent领域最常见也最有代表性的两种：一个是客服问答Agent，用户会问各种售前售后问题，Agent需要调用订单查询、物流查询、售后规则等多个工具；另一个是资料分析Agent，用户上传一段文本或文档，Agent负责提取要点、做摘要、回答相关问题。

对照组的设计是：同一批任务，一组固定使用大模型处理；另一组接入X-Router，由路由层决定用哪个模型。所有请求走同一个Agent框架，工具定义一致，系统提示词一致，唯一变量就是模型选择方式。

Token统计上，我同时看了三个口径：网关日志里记录的总Token消耗、模型返回的usage字段总和、以及平台侧的实际扣费Token。为什么要看三个口径？因为只看任何单独一个都可能被坑，有些平台的usage统计和实际扣费并不完全一致。最终我以实际扣费口径为准，其他两个作为参考。

4.2 实测结果和收益来源拆解

先放结果表格，这是一批2000次模拟对话的统计值：

Token消耗少了超过一半，时延也几乎砍半，任务完成率和采纳率略有下降。这个下降幅度在我能接受的范围内，而且随着自演进策略在更多数据上迭代，质量指标会慢慢回升。

收益来源可以拆成三块。第一块是模型降级，约占总节省的四成。简单任务被路由到轻量模型后，同样的请求Token数本身没少，但单价大幅下降，这块直接体现在成本上，如果只看Token数量可能看不出来。第二块是避免重试，约占总节省的两成。路由层发现某个模型反复出错时会触发熔断，把流量切到其他模型，不会再对着同一个最强模型硬重试。第三块是上下文策略优化，约占总节省的三成。对于短对话直接走普通上下文，对于长对话才路由给长上下文模型，不再一刀切地给所有请求都预留超大上下文窗口。

4.3 什么场景能省最多，什么场景省不了

实测下来我发现，这个方案能省多少，跟任务分布强相关。最适合的场景是任务多样性高的Agent，比如客服、RAG问答、多工具编排，请求里有大量简单意图，也有少量复杂推理，模型路由就可以把简单任务大量分流到便宜的模型上。

不太适合的场景也有。如果你的Agent只做一件事，比如就是给长文档写摘要，所有请求都走同一个最强模型，那路由层的存在意义就很小了，反而多了一层开销。还有一类场景要注意，就是输出质量极其敏感，比如金融合规分析，这时候即使省了Token，如果质量下降一点点，代价都远大于省下的成本。要不要用模型路由，实质上是在做一个“成本和质量”的权衡，而不是无脑降本。

5. 从选型到落地：接入与实践要点

看完数据，接下来是最关键的落地环节。我把自己踩过的坑和验证过的步骤整理一下。

5.1 接入方式：透明网关代理

X-Router的接入方式走的是透明网关代理，而不是侵入式SDK。Agent那边只需要把模型调用的base_url改成X-Router的地址，然后在X-Router里配置模型池和路由策略，剩下的逻辑全部由网关处理。

为什么要用网关模式？因为Agent框架五花八门，不同框架对模型调用的封装方式不一样，如果做成SDK，每个框架都要写适配代码，维护成本太高。网关在传输层拦截请求，对上层应用完全透明，Agent框架本身不用改一行代码。我在测试里就是这么接的，几分钟就能切换完成。

配置上需要声明模型池。下面是一个简化的配置片段：

model_pool: - name: light-v1 route_type: light endpoint: http://127.0.0.1:8001/v1/completions max_context: 8192 cost_per_k_token: 0.02 - name: medium-v1 route_type: standard endpoint: http://127.0.0.1:8002/v1/completions max_context: 32768 cost_per_k_token: 0.12 - name: heavy-v1 route_type: heavy endpoint: http://127.0.0.1:8003/v1/completions max_context: 131072 cost_per_k_token: 0.5 route_policy: strategy: self-evolving feedback_timeout: 300 fallback_model: medium-v1

这里有两个必须注意的点。

第一，max_context一定要按真实值写，不要为了保险写大。路由决策的很大一部分依据是请求长度，如果模型A标注了131072的上下文，路由层就会倾向于把长请求分给它，但这个模型可能实际跑到65536就性能骤降了，所以配置要和部署时的实测值保持一致。

第二，fallback_model一定要配。路由层可能会出现判断失误，比如把复杂请求发给了小模型，小模型能力不够或者超时，这时候需要有一个兜底模型接管。我见过有些人配了这个字段但指向的还是大模型，那兜底就失去意义了，应该指向一个“比当前候选高一级”的模型，而不是永远指向最强。

5.2 自演进策略的灰度与回滚

自演进听起来很好，但直接全量开启是有风险的。你不可能保证新学出来的策略一定比旧策略好，万一它学偏了，业务质量就会受影响。所以灰度是自演进策略的生命线。

我的建议是分三步走。

第一步冷启动。刚开始流量数据不够，自演进没有可学习的样本，这时候应该运行静态规则，规则可以很简单，比如“长度小于500 Token的走小模型，大于8000 Token的走大模型，中间走中等模型”。这条规则准确率可能一般，但能保证基本不崩。

第二步影子模式。让自演进模块在线运行，但它的决策结果不真正影响线上流量，只是记录“如果按照新策略，这个请求会被分到哪个模型”，然后把结果跟实际使用的模型做对比。这一步的目的是积累证据，确认新策略在历史数据上的表现。

第三步小流量灰度。确认新策略在影子模式下没有明显劣化后，先切5%到10%的流量跑一段时间，对比Token消耗和质量指标。确认没问题再逐步放量，直到100%。我在实际操作中一般是放量到30%之后观察24小时再决定是否继续。

还要有主动回滚机制。一旦发现某个策略版本导致质量指标下降超过阈值，立刻切回上一个稳定版本。回滚动作必须自动执行，不能等人去看监控。等稳定之后，把这次劣化的原因找出来，写进反馈信号里，防止再学出同样的错误策略。

5.3 成本观测与Token口径

接入路由之后，成本观测的口径一定要统一。我见过最典型的问题，是业务方说Token消耗降低了，但平台账单没有降，最后排查发现是网关日志和平台计费的口径不一致。

建议至少做三层统计。第一层是路由网关日志，可以看到每个请求被路由到了哪个模型、模型返回的usage是多少；第二层是模型推理服务侧日志，跟网关日志比对可以确认是否有日志丢失；第三层是平台实际扣费记录。三层数据互相印证，才能确认省下的Token是真实的。

还有一个容易忽略的坑：路由层自身的开销。如果路由决策过程依赖大模型来判断，那路由服务本身也在消耗Token，这部分省下来的可能还不够填进去的。X-Router的做法是用轻量评分模型做路由决策，但我见过其他方案里有人直接用大模型做路由判断，结果Total Token没有明显下降，就是因为路由本身的Token开销把收益吃掉了。

6. 常见问题定位与排查实录

最后整理一下我在这段时间里遇到的实际问题，以及排查思路。这些问题有代表性的，也有比较隐蔽的。

6.1 路由结果不准怎么排查

自演进策略跑了一段时间后，如果发现路由结果越来越不准，首选排查方向有两个：样本量和反馈信号质量。

样本量不足是最常见的原因。策略模型的学习需要足够多的成功案例和失败案例，如果业务流量本身不大，或者路由层刚上线没跑几天，策略很可能还在震荡期，表现为“今天省Token，明天又乱路由”。这种只能等数据积累，没有捷径。

反馈信号质量的问题更隐蔽。如果反馈信号本身是脏的，策略学出来的结果必然是歪的。比如Agent执行成功的判断逻辑写得太宽松，把模型胡编的回答也判定为“用户采纳”，策略就会认为“反正效果好，什么任务都分配给小模型也没关系”，久而久之质量就崩了。排查方法是抽检一部分Agent会话，人工比对反馈信号和实际对话质量，确认信号标注的准确率。

6.2 接入后Token不降反升的原因

我遇到过接入X-Router之后，Token消耗不降反升的情况，原因不在路由策略本身，而在配置细节。

第一个原因是模型频繁切换带来的系统提示词重复加载。如果路由策略把相似的请求在不同模型之间来回切换，每个模型都需要携带自己的系统提示词和工具描述，这些Token是独立计费的，切换越频繁浪费越大。解决方法是给路由策略加稳定性约束，同类请求在一个时间窗口内尽量保持同一个目标模型。

第二个原因是路由决策链路的日志信息被当成了模型输入。如果网关在转发请求时不小心把路由决策结果、模型候选列表、评分详细信息带进了发送给模型的prompt，凭空多出上千Token。这个坑很隐蔽，排查方法是把发给模型的原始请求抓包看一遍，确认prompt里没有多余内容。

第三个原因是反馈评估环节本身在消耗Token。为了做自演进，需要定期对Agent输出做质量评估，如果评估也走大模型，这部分Token是额外的成本。我在实践中的做法是评估只采样5%到10%的流量，避免为了监控花太多钱。

6.3 把“鉴权失效”误判成路由问题的排查方法

接入网关之后，报错类型会变多，一个特别容易混淆的情况是“Token失效”类报错。比如请求返回类似token exchange failed或者403的鉴权错误，第一反应可能会以为是路由配置问题，实际上这跟路由层一点关系都没有。

排查顺序我建议这样来。第一步，先看报错发生在什么环节，如果路由日志里根本没有这条请求的记录，说明请求根本没进到路由层，那是上游Agent框架的鉴权配置或者账号凭证过期了。第二步，如果路由日志里有记录，但转发到模型服务时被拒，那要看模型服务侧返回的是鉴权错误还是模型不存在。鉴权错误基本就是模型服务的API Key无效或者没有对应模型的访问权限，去检查模型服务的凭证就行。第三步，如果模型服务侧返回的是invalid model或model not found，那才是路由配置的问题，说明模型池里配置的模型名称跟推理服务实际部署的模型不一致。

从我的经验来看，这类“虚拟网络故障”很多时候都是配置不同步造成的，尤其是模型服务更新了接入凭证之后，网关侧没有同步，导致路由后的请求一直被拒绝。遇到这种情况，别一上来就怀疑路由逻辑，先把两端日志对齐，通常十分钟就能定位。

另外，路由层一定要做好异常请求的类型透传。原始报错是什么状态码，转发时就应该原样透传给Agent，不要吞掉错误码重新包装成自己的错误格式。否则Agent侧会困惑，排查的线索也被切断了。

最后再分享一点我的实际体会

测试这套方案的时候，我心里最担心的其实是“省了Token但掉质量”，毕竟Agent项目里省钱的前提是业务还能正常跑。实测下来，任务完成率确实有轻微下降，但下降幅度在一个可以接受的范围内，而且随着自演进策略和业务数据磨合，这个差距在收窄。

我个人踩过最值得提醒的坑有两个。第一个是冷启动阶段别急着开自演进，先用静态规则把基础盘子稳住，让数据积累一两周再切，否则策略会在小样本上“过度自信”，上线就劣化。第二个是Token省下来的收益要能对账单，如果发现网关日志显示省了但账单没变，先去看是不是统计口径不一致，不要盲目调路由参数，方向搞反了越调越乱。

这套方案后续还有一个很自然的扩展方向，就是跟缓存和上下文压缩联动。目前路由主要解决“请求该给谁处理”的问题，如果再加上语义缓存和按需压缩，Agent降本的空间还能再挖一层。我目前的实测数据已经验证了路由的价值，下一步准备把这三个能力放在一起做一轮更完整的压测，到时候再写一篇新的记录。