企业官网建设流程全解析

1. 项目起源与核心诉求

1.1 是谁的痛点：Agent 比人更能“烧钱”

先聊聊我为什么会对 HiRoute 这种工具产生兴趣。过去一年我做 Agent 应用时，一开始想得很简单：调模型、拿结果、完事。可实际跑起来才发现，最大的瓶颈根本不是模型能力不够，而是“模型接口怎么用都不顺”。

这边 Agent 还不够“能干”——想让它在多轮对话里保持状态，我可能要同时调用快模型做意图识别、慢模型做深度推理、便宜模型做过滤和格式化；那边模型订阅又“不耐用”——我买了某家大模型的包月套餐，本来以为能随便跑，结果跑了一个星期就把配额用完了。一个 Agent 任务里，可能 80% 的调用其实是简单分类、抽取、改写，这些活儿完全可以用便宜模型扛住，但我一开始全都用最贵的模型处理。成本炸了，速度也慢，最后用户等得不耐烦，直接流失。

后来我试着把多个提供商的模型订阅拼在一起用，手动写了一套轮询逻辑。效果有一点，但很快暴露问题：有的订阅限流特别敏感，连续调十几次就给我 429；有的订阅是按日重置配额，有的按小时，有的按并发数。我顾此失彼，代码里全是 if-else，维护成本高到离谱。

1.2 用一句话讲清楚 HiRoute 是什么

HiRoute 是一个面向 Agent 应用的模型路由与订阅调度中间层。它的核心思路并不复杂：

1. 把“模型能力”和“底层提供商订阅”解耦。
2. 上层 Agent 只声明自己需要什么能力（比如“快、便宜、支持 JSON 输出”）。
3. HiRoute 根据路由策略把请求分发到最合适的模型订阅上。

这样做的好处直接体现在两个关键词上：“更能干”和“更耐用”。

先说“更能干”：因为 HiRoute 允许你做模型之间的自动降级和组合，Agent 不会因为某个模型不稳定就整体挂掉。比如你请求了一个 32K 上下文的模型但它超时了，HiRoute 可以自动切到另一个 16K 上下文的模型并启用摘要压缩，让流程继续走完。

再说“更耐用”：它会把你的多个订阅（比如月包、按量付费、免费额度）放在一个池子里做统一调度。订阅 A 配额快没了，自动换到订阅 B；订阅 B 触发限流，自动把请求挪到订阅 C 或者排队等待。这样不会出现“明明还有很多订阅没用到，主订阅却已经爆了”的糟心事。

注意：如果你只是个人写脚本，每天只调几十次接口，那 HiRoute 属于“杀鸡用牛刀”。但如果你在跑 Agent 服务、批量处理任务、或者做团队共享服务，它带来的收益会非常明显。

2. 整体设计思路与方案选型

2.1 为什么不做“全部请求走同一个模型”

很多人的第一直觉是：既然要省钱，那就把请求都切到最便宜的模型不就行了？这个想法在 Demo 里可行，在真实 Agent 场景里会翻车。

我拆解过一个典型的 Agent 请求生命周期：

• 第一步：意图识别，需要低延迟、模型不能太笨，但也不需要太聪明，预算要低。
• 第二步：上下文压缩，把多轮对话记录压短，需要模型有较好的指令遵循能力。
• 第三步：工具调用参数抽取，需要模型支持函数调用格式，对稳定性要求高。
• 第四步：最终结果生成，这个才真正需要强推理能力，可以用旗舰模型。

你看，如果整个链路只用一个模型，要么杀鸡用牛刀（全用旗舰，贵、慢、浪费配额），要么力不从心（全用便宜模型，抽取结果不稳定）。HiRoute 的做法是建立一个路由链（Route Chain），让每个步骤选择最合适的模型，而且链上的每个节点都带降级预案。

2.2 我在架构设计中反复权衡过的三个点

第一点：路由决策放在客户端还是服务端？

刚开始我准备把路由逻辑写在 Agent 进程内，直接用函数调用来实现。好处是部署简单，坏处是每个 Agent 实例都要维护订阅池的状态，多实例部署时会出现“明明总配额还有，但单实例拿到旧的剩余配额，导致误判”的情况。

HiRoute 做成了独立服务，Agent 只通过标准 HTTP 接口跟它通信。这样路由决策统一、配额统计统一、限流也统一。你可以在任意语言里接入，Python、Node.js 都能行。

第二点：路由判断基于什么信号？

可选方案有四种：

1. 按模型能力标签（比如fast、json_mode、reasoning）匹配，最简单，但不够细。
2. 按输入 token 长度和预估复杂度匹配，可以防止小请求打大模型。
3. 按订阅剩余配额动态匹配，这是最有价值的维度。
4. 按历史请求成功率动态调整权重，属于锦上添花。

HiRoute 实际是把 1、2、3 结合起来：先按能力标签过滤出候选模型，再按上下文大小缩小范围，最后结合配额和成功率做排序。这样既能保证模型满足需求，又能兼顾经济性。

第三点：降级到什么程度才算“安全”？

降级不是无限降。假设你原本要调用模型 A，它挂了，降级到模型 B，这没问题；但如果 B 也挂了，继续降级到比 B 更弱的模型，很可能生成的 JSON 格式乱了，反而让 Agent 流程出错。

我最终采用的原则是：只允许降级到同一个“能力档位”或相邻档位，并且对输出格式要求苛刻的任务，降级时必须启用输出校验和自动重试。宁可多等几秒，也不能让坏数据流到下游。

2.3 订阅调度的核心模型

把订阅看作一个资源池。每个订阅有：

• 剩余配额（可能按次数或 token 计算）
• 重置周期（小时/天/月）
• 并发限制
• 单次最大上下文
• 成本权重

HiRoute 内部的调度器会周期性（默认每 10 秒）同步这些信息，然后构建一份优先级列表。当请求进来时，先锁定当前时间片内最合适的订阅，再以“尽量不换订阅”为原则处理后续请求。这能显著减少因频繁切换订阅导致的上下文不连续问题。

我可以拿一个实际配置来举例。假设你有三个订阅：

如果用最粗暴的方式，90% 请求都会打到 sub-primary 上，因为它效果最好。但真实场景里，有些请求根本不需要旗舰模型，比如“把用户输入里的邮箱地址提取出来”。HiRoute 会把这类请求自动识别为“轻量任务”，直接分配给 sub-backup 甚至 sub-paygo，省下主订阅配额做真正的深度推理。

实操心得：不要把主订阅的配额当作“无限资源”来规划。我一开始规划的是“主订阅只跑核心推理，占 50%”，实际上跑起来发现核心推理只占 28%，其余全是辅助任务。流量全打到主订阅时，日均消耗冲高非常快，用 HiRoute 分流后，主订阅的月度配额能撑到月底。

3. 核心机制解析与实操要点

3.1 路由匹配是怎么工作的

HiRoute 的请求体非常简单。你不需要在代码里硬编码模型名，只需要声明任务特征：

{ "task": "extract_email", "input_tokens": 1200, "max_output_tokens": 200, "preferences": { "speed": "fast", "cost": "low", "format": "json" }, "fallback": true }

HiRoute 内部会做三步匹配。

第一步：能力过滤。它把“提取邮箱”映射为低复杂度标签，把cost: low映射成“优先考虑低成本模型”，所以 sub-primary 在第一轮就被排除了，剩 sub-backup 和 sub-paygo。

第二步：上下文匹配。input_tokens是 1200，所有订阅都能承载，这一步不会淘汰任何人。

第三步：配额与稳定性排序。如果 sub-backup 的剩余配额还很多，且成功率高于 99%，它就是首选；如果 sub-backup 当前并发已经到达限制，sub-paygo 就会被临时拉上来。

这三步是我觉得 HiRoute 做得最踏实的地方。它不会因为“这个模型能力强”就盲目把流量都打过去，而是结合任务复杂度、上下文大小、配额余量三个维度动态调整。

3.2 订阅池管理的细节

单订阅管理很简单，多订阅管理最麻烦的问题是配额状态不同步。

比如 sub-primary 是按 token 数计费的月包，显示剩余 80 万 token；sub-paygo 是按次数计费的按量包，还剩一万次调用。如果我只做“按 token 数排序”，那 sub-paygo 会因为“剩余 token 显示为负数”而被永远排在最后，但实际上它剩的次数还很多。

HiRoute 的做法是抽象出一个配额维度自动识别机制：

• 如果订阅的计费单位是 token，就用 token 剩余量排序。
• 如果订阅的计费单位是请求次数，就用次数剩余量排序。
• 如果订阅是按量付费（不限额），就根据预估单次请求消耗换算成“等效剩余量”。

在这个基础上，还可以为每个订阅设置“每日最大消耗预算”，防止某一个订阅因为总是在降级时被选中，结果一天就把月包跑完。我见过不止一个团队踩过这个坑：他们设置了优先顺序，但由于主模型性能不稳定，流量自动降级到备用模型，备用模型价格比主模型还贵，月底账单出来吓一跳。HiRoute 允许对每个订阅单独设置日消耗上限，这个功能在真实运营里非常关键。

3.3 缓存层值得单独拿出来说

Agent 场景里，很多调用其实是重复的。比如多轮对话里，每轮都要调用工具去获取当前时间；又比如用户反复询问同一个知识库片段。如果每次请求都实时发给模型，纯属浪费订阅配额。

HiRoute 内置了语义缓存（Semantic Cache）。它会把“请求内容的向量表示”和“响应结果”存起来。下次来了类似的请求，先算一下相似度，如果超过阈值（默认 0.92），直接返回缓存结果。

实操里我建议把缓存时间设短一点，默认 600 秒就够了。太长了容易给用户返回过期信息，太短了缓存命中率不高。比如在客服 Agent 场景里，用户问题“怎么退款”和“退款流程是什么”语义高度一致，缓存可以把第二个请求直接命中，省一次模型调用。但是在“查询订单状态”这种强时效性任务里，缓存会导致用户看到旧状态，这是不能接受的。

所以我最终在各个 Agent 的场景配置里，对“通用问答”启用了缓存，对“实时状态查询”强制关闭缓存。这也是用 HiRoute 之后我才体会到的一件事：缓存不是通用的免费午餐，必须和业务场景强绑定。

3.4 输出校验与格式化纠错

这是 HiRoute 隐藏很深但很有用的一个能力。Agent 应用经常需要模型输出 JSON 去驱动工具调用。我遇到最多的问题是：模型虽然支持 JSON 模式，但偶尔会在 JSON 前后多加几行解释文字，或者逗号多了一个导致解析失败。

以前我在代码里写 try-except 去解析，失败了就重新请求一次，白白消耗订阅配额。HiRoute 可以在返回响应之前做一次轻量校验，发现格式不合法时，自动触发“单步重写”而不是“完整重试”——它会把原来的响应内容和解析错误信息一起发给同一个模型，让它只修复格式，不重新生成内容。

这个设计非常聪明。完整重试的成本约等于重新生成一遍全文，而单步重写的 token 消耗通常只有原来的 10% 到 20%。对订阅配额来说，能省下很大一块。

注意事项：单步重写依赖模型本身能理解错误信息。如果模型太弱，重写之后格式还是错的，这时候 HiRoute 会放弃修正，返回原始响应，并把错误信息附带在响应头里。不要把这个功能寄托在底端模型上，至少要选中等偏上能力的模型。

4. 部署实操与关键配置

4.1 环境准备与安装

HiRoute 提供两种部署方式：二进制单文件和 Docker 镜像。我建议在 Linux 服务器上直接用 Docker Compose 部署，因为它和 Redis、日志组件、监控面板能一次拉起。

version: "3.8" services: hiroute: image: hiroute-server:latest ports: - "8080:8080" environment: HROUTE_REDIS_URL: "redis://redis:6379" HROUTE_ADMIN_TOKEN: "replace-with-a-long-random-string" HROUTE_CONFIG_FILE: "/etc/hiroute/config.yaml" volumes: - ./config:/etc/hiroute - ./logs:/var/log/hiroute depends_on: - redis redis: image: redis:7-alpine volumes: - redis-data:/data volumes: redis-data:

这里有几个关键环境变量解释一下：

• HROUTE_ADMIN_TOKEN：管理接口的访问令牌。务必换成随机长字符串，并且不要把令牌写进 docker-compose 文件里提交到仓库。
• HROUTE_CONFIG_FILE：指向挂载进来的配置文件目录。
• Redis 的作用：存放订阅配额快照、缓存响应、路由规则。如果 Redis 挂掉，HiRoute 仍能基于内存快照运行，但缓存和配额同步会失效，所以建议给 Redis 加持久化。

4.2 订阅配置实战

下面是我实际在用的订阅配置样例，脱敏处理后放这里供参考。

providers: - name: provider-x base_url: "https://api.example-x.com/v1" api_key_env: "PROVIDER_X_API_KEY" - name: provider-y base_url: "https://api.example-y.com/v1" api_key_env: "PROVIDER_Y_API_KEY" subscriptions: - id: sub-primary provider: provider-x model: flagship-model quota: type: token limit: 4000000 reset: monthly rate_limit: rpm: 60 tpm: 120000 cost_weight: 3.0 capabilities: [reasoning, json_mode, long_context] budget: daily_token_limit: 800000 - id: sub-backup provider: provider-x model: standard-model quota: type: token limit: 2000000 reset: monthly rate_limit: rpm: 120 tpm: 200000 cost_weight: 1.0 capabilities: [fast, json_mode, tool_call] budget: daily_token_limit: 400000 - id: sub-paygo provider: provider-y model: cheap-model quota: type: pay_as_you_go rate_limit: rpm: 200 tpm: 300000 cost_weight: 0.4 capabilities: [fast, basic_tool_call] budget: daily_token_limit: 600000

然后定义路由策略：

routes: - pattern: "reasoning" preferred_subscription: sub-primary fallback_order: [sub-backup, sub-paygo] - pattern: "fast_generation" preferred_subscription: sub-backup fallback_order: [sub-paygo] - pattern: "extraction" preferred_subscription: sub-paygo fallback_order: [sub-backup]

这里我需要重点提醒一个问题：fallback_order 和实际效果的关系。

我第一次配置时想把所有请求的兜底都指向 sub-paygo，因为它是按量付费，不会“爆量”。但后来发现，当一个比较复杂的推理请求落到 sub-paygo 上时，效果明显变差，经常出现输出格式不稳定。所以降级链不能一刀切。正确做法是：每个 pattern 的 fallback 链都不一样。快速生成可以降级到便宜模型；深度推理宁愿重试旗舰模型也不能降级太多。

4.3 Agent 接入方式与代码示例

接入方式很简单，Agent 侧不再直接调用模型服务商 SDK，而是统一请求 HiRoute。

Python 侧示例：

import requests HROUTE_URL = "http://localhost:8080/v1/chat" def generate_reply(messages, task="reasoning"): resp = requests.post( HROUTE_URL, json={ "messages": messages, "task": task, "max_tokens": 1024, "temperature": 0.3, }, headers={"Authorization": "Bearer your-hiroute-token"}, timeout=60, ) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"]

这段代码看不出模型名，因为模型名已经被路由规则代替了。你只需要根据当前任务语义，传入对应的 task 标签。比如“提取用户邮箱”用task="extraction"，“总结对话历史”用task="summarization"，“复杂逻辑推理”用task="reasoning"。

Node.js 侧同理：

const response = await fetch('http://localhost:8080/v1/chat', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': 'Bearer your-hiroute-token' }, body: JSON.stringify({ messages: [{ role: 'user', content: '帮我规划一下去机场的路线' }], task: 'reasoning', max_tokens: 800 }) }); const data = await response.json();

唯一需要重点设计的是：task 标签的语义体系。建议不要搞太多标签，否则策略配置会爆炸。我见过一个团队定义了 30 多个标签，结果配置文件里 fallback 链像蜘蛛网一样密集，最后根本没法维护。合理的情况是控制在 5 到 8 个标签以内，比如：

• reasoning：复杂推理
• fast_generation：一般对话生成
• extraction：信息抽取
• summarization：文本总结
• tool_call：工具调用参数生成
• classification：分类打标

4.4 监控面板与日志分析

部署完成后，HiRoute 会在 8080 端口的/metrics路径暴露 Prometheus 格式的指标。我用 Grafana 简单看几个关键数：

1. 订阅剩余容量趋势：每天剩余 token 是线性下降还是阶梯式下降。
2. 路由命中分布：各个 pattern 实际命中哪个订阅，这能帮你发现“你以为走了便宜模型，实际全走了旗舰模型”的问题。
3. 降级次数：如果 sub-primary 降级次数变多，说明主订阅配额即将耗尽或主模型限流频繁。
4. 缓存命中率：命中率太低说明任务差异化太大；命中率太高则要关注是否会返回过时结果。

我在实际运营中看到最典型的图表是：sub-primary 的剩余量呈前半月平稳、后半月断崖的走势。原因就是每天请求量差不多，但月初时路由策略把预算用得太均匀，到了月底遇到某个高消耗任务，直接把主订阅打穿。后来我设置了budget.daily_token_limit，限量后多余的流量自动挤到按量订阅，这个问题就基本消失了。

5. 性能调优与实际效果

5.1 延迟优化：首 token 延迟和端到端延迟

引入中间层之后，很多人第一反应是“多了一层网络，延迟会不会变高”。HiRoute 实测在局域网部署时，路由决策本身耗时可忽略，真正影响延迟的是订阅选择后的连接建立和排队。

我做了几组对比测试：

1. 直连旗舰模型：平均首 token 延迟 1.2 秒。
2. 走 HiRoute 且命中首选订阅：平均首 token 延迟 1.3 秒，多出的 0.1 秒来自路由判断和网络转发。
3. 走 HiRoute 但触发降级到备选订阅：平均首 token 延迟 2.1 秒，其中 0.8 秒是降级切换产生的额外连接时间。

从数据看，命中首选订阅时，中间层开销完全可以忽略；降级切换才是真正的延迟大头。因此 HiRoute 做了一个优化：尽力缓存订阅的后端连接状态，降级时不走“断开重连”而是直接复用连接池。这个优化实测能把降级切换耗时压缩到 0.3 到 0.5 秒。

如果你的 Agent 应用对延迟极度敏感，我建议：

• 把 HiRoute 服务部署在和 Agent 同一 VPC/内网内。
• 优先保证主订阅本身的稳定性，减少降级触发次数。
• 开启连接池复用，避免每次请求都重新做 TLS 握手。

5.2 成本收益对比

我用一个类似客服问答的 Agent 场景做了连续 7 天的测试。数据如下：

成本下降约 43%，成功率反而提高了，原因很直接：轻量任务走便宜模型不会变差，反而因为并发余量更足，降低了限流概率。缓存命中又省掉了一部分重复请求的开销。

当然，这个数字有场景特殊性。如果你的任务全是强推理场景，几乎没有轻量任务，那 HiRoute 的收益会小很多，主要收益集中在“订阅配额保护”和“降级稳定性”上。

5.3 承压测试：抢占场景的表现

我最担心的问题是抢配额。多个 Agent 任务同时进来，都想要 sub-primary，这时候怎么办？

HiRoute 的策略是按优先级排队，而不是直接拒绝。每个请求带一个priority字段，默认是 3。高优先级请求（比如用户实时交互）可以插队到低优先级请求之前。但为了防止高优先级请求饿死低优先级请求，每 30 秒会提高低优先级队列的权重，确保它们不会被无限延迟。

我做过一次压测：同时开 200 个并发请求，其中 80 个是priority=1，120 个是priority=5。结果是高优先级的请求全部在 2 秒内得到响应，低优先级的最长等待 11 秒，但没有一个请求被丢弃。对于我这个场景来说，这完全够用。

实操心得：如果你有“批处理任务”和“实时交互任务”混跑的情况，一定记得给请求设置正确的优先级。我一开始没设，导致半夜的批量任务抢占了用户白天的交互配额。后来把所有批处理请求强制标记为priority=5后，问题才解决。

6. 常见问题与排错实录

6.1 请求超时但原模型明明很快

现象：某些请求在 HiRoute 里耗时超过了模型本身的耗时。

排查路径：

1. 看是否走了降级切换。到管理后台/日志查route_hop字段，统计当前请求经过了几次转发。
2. 看是否触发了缓存写入。如果 result 很大，写入 Redis 时可能有一段时间阻塞。
3. 看是否触发了格式重写。重写调用也是要消耗时间的。

我遇到最多的情况是第一条：主订阅限流，请求被转发到备选订阅，而备选订阅的首 token 延迟本来就高。解决办法是把主订阅的限流阈值调高，或者增加一个与主订阅能力相近的订阅，降低“跨档位降级”概率。

6.2 订阅配额一天内被打满

原因往往很简单：路由策略的 daily budget 没有生效，或者缓存命中率太低导致实际 token 消耗远超预期。

建议分三步排查：

• 检查配置文件中budget.daily_token_limit是否真的对这一天的请求量生效。
• 检查是否所有请求都带上了正确的 task 标签。如果都默认成reasoning，流量会全部涌向最强模型。
• 检查缓存命中率是否过低了。如果低于 10%，需要调低相似度阈值，或者检查请求里是否携带了随机无意义参数。

我自己踩过的一个坑是：在请求里加了一个timestamp参数用于日志追踪，结果这个参数参与了语义向量计算，导致每次请求的语义向量都不一样，缓存永远不命中。后来改成把 timestamp 放在自定义请求头里，不参与路由和缓存计算，命中率才恢复正常。

6.3 模型返回格式仍然错误，即使开启了重写

部分场景下，模型同时存在“内容错误”和“格式错误”。比如它不仅把 JSON 截断了，还在中间生成了虚构信息。单步重写只能修复格式，不能修复内容。

这种情况下，HiRoute 的日志里会标记parse_error和retry_reason。我做了一个额外的校验规则：如果返回结果中缺少必填字段，直接判定为重试，而不是重写。方案如下：

{ "validate": { "required_fields": ["action", "parameters"] } }

只要响应体中缺失任何一个必填字段，就强制走完整重试，而不是单步重写。这会多花一点订阅配额，但能避免把残缺数据交给下游 Agent。

6.4 两个订阅同时触顶

如果你确实只有两个订阅且都满了，那就没有降级空间了。HiRoute 不会魔法般凭空变出配额，它只能做两件事：

1. 返回 429 错误并附带retry_after秒数，等待订阅配额重置。
2. 如果订阅是按量付费的，不会“触顶”，只是成本会增加。

所以真正的兜底方案，永远是至少保留一个按量付费订阅。按量付费可能是贵一点，但它是整个系统的保底水位线。

6.5 排查小技巧汇总

我把日常排查时用到的命令和技巧整理如下：

• 查看某个请求的完整路由路径：

curl -H "Authorization: Bearer your-token" http://localhost:8080/logs/request-001

• 实时查看降级事件：

hiroute-cli debug events --type fallback --tail 50

• 重置某订阅的每日预算计数器：

hiroute-cli quota reset --sub sub-primary --scope daily

• 查看缓存命中情况：

hiroute-cli cache stats --active

不要等到出了故障才用这些命令。我现在的习惯是每天固定看一次指标面板，每周整理一次降级统计。这种节奏能让你在订阅配额耗尽之前就发现问题。

7. 从“能用”到“好用”的几个进阶建议

7.1 把日志里的路由决策数据再利用

HiRoute 每条日志都会记录“请求特征 + 模型选择结果 + 消耗量 + 是否降级”。这些数据积累多了以后，可以用来优化你自己的任务分类，甚至能发现一些有意思的规律。

比如我发现：在“总结对话历史”这个任务上，standard-model 的成功率其实和旗舰模型持平，但耗时低了 25%。于是我把这个任务的 preferred 从旗舰模型调成了 standard-model，直接省下日均 8 万 token 的消耗。

另一个发现是：某些用户请求的 prompt 会刻意写很长，导致输入 token 高，模型处理时间拉长。后来我在 Agent 侧加了 prompt 长度控制，把平均输入 token 从 3200 压到 1800，整体延迟肉眼可见地降低。

7.2 给团队内不同成员分配不同的预算权重

如果是团队共用一套 HiRoute，千万别所有人共享同一个订阅池。否则某个成员跑一个耗量大的实验，很可能把别人在用的主订阅配额打爆。

HiRoute 支持基于 API Key 的预算分组。你可以为不同项目或成员分配不同的budget_group，每个组有独立的每日消耗上限和可用的订阅范围。这个功能在多人协作场景里简直是刚需。我自己就吃过亏：团队里一个同事跑数据清洗任务，一晚上消耗了 150 万 token，第二天所有人的实时请求全部降级到次等模型，体验大打折扣。加了分组以后，这种事情再也没发生过。

7.3 预留“关键任务通道”

如果你的 Agent 系统里有负责支付、订单等关键操作的流程，我建议给它单独配置一个路由规则，禁止降级到低成本模型。省钱的底线是“不影响核心功能正确性”。

HiRoute 支持在路由规则里加一个lock_subscription字段。一旦选了主订阅，就锁定该订阅执行完整个请求，不做中途切换。这对支付流程尤其重要，因为中途切换模型可能导致上下文丢失，进而引发状态不一致。

routes: - pattern: "critical_payment" preferred_subscription: sub-primary lock_subscription: true fallback_order: []

注意这里的fallback_order: []不是没有兜底，而是“不自动兜底”。如果主订阅不可用，请求会快速失败，由 Agent 侧决定是重试还是转人工。这比自动降级到弱模型更安全。

8. 写在最后的实操体会

绕了这么大一圈，我想分享一个核心心得：用 HiRoute 不是为了让系统更复杂，而是为了让复杂系统变得更可控。

以前我在 Agent 项目里最怕的就是“跑着跑着突然某一个模型服务出问题”，整个流程卡住，用户干等，我还不知道到底卡在哪一步。有了路由和订阅调度之后，大多数异常都被中间层消化掉了，我需要处理的只剩少数真正需要人工干预的情况。

如果你准备上手 HiRoute，我建议从小步开始，不要第一天就把所有流量切过去。先搭一个测试环境，接入两三个订阅，跑一个非核心场景，观察一两天的路由分布和成本账单。等确认稳定了，再把核心业务逐步迁移过去。这样即使出现问题，影响面也是可控的。

配置上还有个小建议：命名一定要有语义感。别用sub1、sub2这种名字，最好直接体现用途，比如sub-flagship、sub-standard、sub-paygo。命名清晰的配置文件，几个月后再回来看依然能一眼看懂。

最后，如果你也走到了“日志分析”这一步，可以多看看那些被降级的请求，它们往往是优化空间最大的地方。每次降级背后都对应着一次模型选择不当，把这些事件累积起来，你会越来越了解自己的 Agent 究竟需要什么样的模型组合。