1. 从一次账单失控说起：为什么路由层才是成本命门
去年下半年我接手了一个多智能体协作系统的调优工作，系统本身跑得挺稳，但每个月结算的时候，账单数字总让人心里一紧。拆开看调用日志才发现一个很反直觉的现象：真正承担复杂推理任务的主力模型调用量只占三成左右，剩下七成全部消耗在那些"看起来不起眼"的子任务上——意图识别、参数抽取、格式校验、简单问答、工具选择。这些任务单次消耗不大，架不住量大，一天几十万次调用累积下来，成本曲线直接翘头。
这个现象在智能体架构里非常普遍。很多人设计 Agent 的时候习惯"一个模型打天下"，主控、子任务、兜底全用同一个大模型，图省事。但实际业务里，不同子任务的难度差异极大。让一个擅长复杂推理的模型去判断"用户这句话是问天气还是问订单"，就像请一位资深架构师去贴发票——能力过剩，成本浪费。
我后来做的核心改造，就是在主控智能体和具体子智能体之间加了一层路由层，用轻量模型 Claude Haiku 5.5 来做任务分派和预处理，把真正需要重推理的请求才转发给大模型。改造完成后，整体调用成本下降了约六成，响应延迟也明显改善。这篇文章就把这套路由方案的设计思路、实现细节、踩过的坑和调优经验完整拆开讲一遍。
先说清楚适合谁看：如果你正在做多智能体系统、RAG 应用、或者任何有大量子任务分发的 AI 工程，并且开始被成本或延迟困扰，这篇内容会很有参考价值。如果你还没接触过智能体架构，建议先了解基本的 Agent 概念再回来看，理解会更顺。
需要提前说明的是，路由层不是简单地"用小模型替换大模型"，那样做准确率会崩。它是一套分级决策机制，核心在于判断"这个请求到底该谁来处理"。判断本身要足够便宜、足够快、足够准，这才是 Haiku 这类轻量模型的价值所在。
2. 路由层到底在做什么：拆解子智能体分派的三个决策维度
2.1 意图分类：把请求先归到正确的"科室"
路由层最基础的工作是意图分类。用户或上游系统丢过来一个请求，路由层要判断它属于哪一类任务。比如一个客服场景的智能体系统，请求可能落在"订单查询""退换货""产品咨询""投诉建议""闲聊"这几个类别里。不同类别对应的子智能体、工具链、甚至模型规格都不一样。
这一步用 Haiku 来做非常合适。意图分类本质是一个短文本分类任务，输入通常就一两句话，输出是一个类别标签。Haiku 5.5 在这种任务上的准确率，实测下来和更大模型差距很小，但单次调用成本可能只有后者的十分之一到二十分之一。我做过一组对比测试，在 2000 条真实客服语料上，Haiku 的意图分类准确率是 94.2%，大模型是 96.1%，差了两个百分点，但成本差了将近十五倍。这两个百分点完全可以通过后置校验和兜底策略补回来。
这里有个经验：意图分类的类别设计不要贪多。我见过有人一口气设计了三十多个意图类别，结果路由准确率反而下降。原因是类别越细，边界越模糊，模型越容易混淆。我的做法是先粗分到 5 到 8 个大类，每个大类内部再由对应的子智能体做二次细分。分层分类比一次性细分准确率高得多。
2.2 复杂度评估：判断这个请求值不值得"上大模型"
意图分类解决的是"去哪"，复杂度评估解决的是"用多大力度"。同样是订单查询，有的请求是"我的订单到哪了"这种一句话能答的，有的是"我上个月买的东西和这个月买的能不能合并开票，另外帮我查下退货进度"这种多意图混合的复杂请求。前者用 Haiku 直接处理就行，后者必须转给大模型。
复杂度评估我总结了几个可量化的信号：
- 输入长度：超过一定字符数的请求，往往包含多个意图或复杂约束，倾向于转大模型。
- 意图数量：路由层如果检测到一句话里命中多个意图标签，说明请求复合度高。
- 历史轮次：多轮对话中，如果前面已经来回好几轮还没解决，说明问题棘手。
- 关键词触发：出现"投诉""法律""紧急"等敏感词，直接升级处理。
- 置信度：Haiku 自己给出的分类置信度低于阈值时，说明它拿不准，转大模型。
这几个信号加权打分，超过阈值就走大模型，否则 Haiku 自己处理。这套打分逻辑本身很轻，几乎不增加延迟。
2.3 参数抽取与格式规整：让下游子智能体"开箱即用"
路由层还有一项容易被忽视但价值很高的工作：参数抽取。上游请求往往是自然语言，下游子智能体或工具调用需要的是结构化参数。比如"帮我查一下上周三下单的那个蓝色杯子发货没"，下游需要的是{action: "query_order", product: "蓝色杯子", order_date: "上周三"}。
让 Haiku 在路由阶段顺手把参数抽出来，下游子智能体拿到就是干净的结构化数据，不用再解析一遍自然语言。这一步省下来的不只是成本，还有整条链路的延迟。我实测过，把参数抽取前置到路由层，下游子智能体的平均处理时间缩短了约 30%，因为它们省掉了理解自然语言的开销。
提示：参数抽取的 schema 一定要提前定义好，并且和下游子智能体的接口严格对齐。我早期吃过亏，路由层抽出来的字段名和下游期望的不一致，导致大量请求在子智能体那里报错，排查了半天才发现是命名问题。
这三个维度组合起来，路由层实际上承担了"分诊台"的角色：判断病情（意图）、判断轻重（复杂度）、准备好病历（参数），然后把病人分给合适的医生。分诊做得好，整个系统的效率和成本都会大幅改善。
3. 为什么是 Haiku 5.5：轻量模型做路由的选型逻辑
3.1 路由任务的本质决定了它不需要重模型
选型之前先想清楚一件事：路由任务到底难在哪？它难在快和稳，不难在深。路由层要在几十毫秒内对每个请求做出判断，而且判断逻辑相对固定——分类、打分、抽字段，这些都是模式识别类任务，不需要多步推理、不需要长链思考、不需要复杂数学。
这就像公司前台，她不需要懂业务细节，但需要反应快、判断准、态度稳。你让 CTO 去坐前台，能力是够了，但成本离谱，而且 CTO 的时间应该花在更值钱的地方。Haiku 5.5 的定位就是"反应快、够聪明、成本低"的前台角色。
具体到能力维度，Haiku 5.5 在几个关键指标上很适合路由场景：响应延迟低，适合高并发；指令遵循能力强，能稳定按 schema 输出结构化结果；上下文窗口够用，处理多轮对话历史没问题；成本相比大模型有数量级优势。这几点组合起来，正好命中路由层的需求。
3.2 成本账要算清楚：单次便宜不等于整体便宜
很多人算成本只看单次调用价格，这是不够的。路由层的成本账要算三个部分：路由本身的调用成本、路由错误导致的额外成本、以及路由带来的节省。
路由错误有两种：误升级和误降级。误升级是把本该 Haiku 处理的请求转给了大模型，浪费钱；误降级是把该大模型处理的请求留给了 Haiku，导致答错、重试、用户体验下降，隐性成本更高。所以路由层的目标不是"尽量少用大模型"，而是"把大模型用在刀刃上"。
我做过一个粗略的测算模型，假设每天 10 万次请求：
| 方案 | 大模型调用占比 | 单日成本估算 | 平均延迟 |
|---|---|---|---|
| 无路由，全用大模型 | 100% | 基准值 100 | 基准值 100 |
| 简单规则路由 | 约 45% | 约 52 | 约 70 |
| Haiku 路由层 | 约 28% | 约 38 | 约 55 |
这个表是示意性的，具体数字因业务而异，但趋势很明确：规则路由能省一部分，但规则覆盖不了长尾情况；Haiku 路由层因为能理解语义，能把更多"其实不难"的请求正确识别出来，降级给轻量处理，所以节省更彻底。
3.3 和大模型路由方案的对比：什么时候该用哪个
也不是所有场景都适合 Haiku 做路由。我整理了一个判断表：
| 场景特征 | 推荐方案 |
|---|---|
| 请求量大、意图类别固定、延迟敏感 | Haiku 路由层 |
| 请求量小、意图复杂多变、准确率优先 | 大模型直接处理或大模型路由 |
| 规则明确、边界清晰 | 规则引擎 + Haiku 兜底 |
| 多模态输入（图、音、视频） | 需评估 Haiku 的多模态能力是否够用 |
我的建议是：先用规则跑一版，把明显的、高频的请求用规则分流掉；剩下的长尾请求交给 Haiku 判断；Haiku 也拿不准的，再升级给大模型。这是三层漏斗结构，成本控制效果最好。
注意：不要一上来就追求全自动路由。我见过团队直接上 Haiku 路由，结果因为 prompt 没调好，误降级率很高，用户体验崩了。稳妥的做法是灰度上线，先让 Haiku 只做"建议"，实际路由还是走规则，对比一段时间后再逐步放权。
4. 路由层的工程实现：从 prompt 设计到兜底策略
4.1 路由 prompt 的写法：结构化输出是生命线
路由层的 prompt 和普通对话 prompt 完全不是一个写法。它的核心目标是稳定输出结构化结果，而不是生成漂亮的话。我踩过的最大坑就是早期 prompt 写得太"自然"，导致 Haiku 有时候输出一段解释文字，有时候输出 JSON，解析器直接崩。
后来我固定了一套模板，核心要素包括：
- 角色设定：明确告诉模型它是路由器，只做分类和抽取，不做回答。
- 类别定义：每个意图类别给出明确定义和正反例。
- 输出 schema：严格规定输出格式，字段名、类型、取值范围都写死。
- 边界说明：遇到无法判断的情况，输出特定的兜底标签，而不是瞎猜。
- 少样本示例：给 3 到 5 个典型示例，覆盖常见和边界情况。
一个简化版的路由 prompt 结构大概是这样：
你是任务路由器。根据用户输入，输出 JSON： { "intent": "order_query | refund | product_info | complaint | chitchat | unknown", "complexity": "low | medium | high", "params": { ... }, "confidence": 0.0-1.0 } 规则： - 只输出 JSON，不要任何解释。 - 无法判断时 intent 填 unknown，confidence 填 0。 - complexity 为 high 时，params 可以为空。 示例： 输入：我的订单到哪了 输出：{"intent":"order_query","complexity":"low","params":{},"confidence":0.95}这套模板跑下来，输出格式的稳定性从早期的 80% 多提升到 99% 以上。剩下那不到 1% 的异常输出，用解析器的兜底逻辑处理掉就行。
4.2 置信度阈值怎么定：别拍脑袋，用数据说话
置信度阈值是路由层的核心参数。阈值定高了，大量请求被误升级，省不下钱；定低了，误降级增多，体验下降。这个值不能拍脑袋，要用真实数据标定。
我的做法是：先跑一批真实请求，让 Haiku 输出意图和置信度，同时人工标注正确答案。然后画一条曲线，横轴是置信度阈值，纵轴是准确率和大模型调用占比。找到那个"准确率还能接受、调用占比明显下降"的拐点。
实测下来，大多数场景的拐点在 0.75 到 0.85 之间。低于这个区间，准确率掉得很快；高于这个区间，大模型调用占比降不下来。具体值还是要看业务对准确率的容忍度。客服场景可以稍微激进一点，金融、医疗场景要保守。
还有一个技巧：按意图类别分别设阈值。高频、简单的意图（比如闲聊、产品咨询）阈值可以低一些，放心让 Haiku 处理；低频、敏感的意图（比如投诉、退款）阈值设高一些，宁可多花点钱转大模型。这种差异化阈值比全局统一阈值效果好很多。
4.3 兜底与降级：路由层自己挂了怎么办
路由层是整个系统的入口，它挂了整个系统就瘫了。所以必须有兜底机制。我设计了三层兜底：
第一层是解析兜底。Haiku 输出格式异常时，解析器不直接报错，而是尝试修复（比如提取 JSON 片段），修复失败则走默认路由（通常是转大模型，保证正确性优先）。
第二层是超时兜底。路由调用设了超时时间，比如 800 毫秒。超时了不等，直接走默认路由。路由层慢一点没关系，但不能拖垮整个链路。
第三层是熔断兜底。如果路由层连续失败率超过阈值，自动切换到纯规则路由，保证系统可用。等路由层恢复后再切回来。
这三层兜底加上去之后，路由层本身的可用性基本不是问题了。我线上跑了几个月，因为路由层故障导致的整体不可用，一次都没发生过。
提示：兜底路由的选择很关键。我建议默认兜底走大模型，因为兜底的场景本来就是"路由拿不准"的情况，这时候正确性比成本重要。等系统稳定了，再考虑把部分兜底也降级。
5. 实测数据与调优：六成成本是怎么省下来的
5.1 上线前后的关键指标对比
改造上线后，我跟踪了两周的数据，核心指标变化如下（数据做了脱敏和归一化处理）：
| 指标 | 改造前 | 改造后 | 变化 |
|---|---|---|---|
| 大模型调用占比 | 100% | 27% | 下降 73 个百分点 |
| 单请求平均成本 | 基准 100 | 约 39 | 下降约 61% |
| 平均响应延迟 | 基准 100 | 约 58 | 下降约 42% |
| 意图识别准确率 | 96.1% | 94.8% | 下降 1.3 个百分点 |
| 端到端任务成功率 | 基准 100 | 约 99.2 | 基本持平 |
成本下降六成这个结论，主要来自大模型调用占比的大幅下降。虽然路由层本身有调用成本，但因为 Haiku 单价低，摊到每个请求上几乎可以忽略。延迟下降是意外收获，因为大量请求不再需要排队等大模型。
准确率下降的 1.3 个百分点，通过后置校验和兜底补回来了一部分，最终端到端成功率基本没受影响。这说明路由层的"小误差"在系统层面是可以被吸收的。
5.2 调优过程中发现的三个反直觉现象
调优过程中有几个发现和直觉相反，值得单独说。
第一个：意图类别不是越细越好。前面提过，我一开始设计了二十多个细分类别，结果路由准确率反而比粗分低。原因是细分类别之间边界模糊，Haiku 容易混淆。改成 6 个大类后，准确率反而上去了。细分的工作交给下游子智能体做，它们有更多上下文，判断更准。
第二个：prompt 里加示例不一定提升准确率。我试过在路由 prompt 里塞十几个示例，结果准确率没升反降。后来分析发现，示例太多会让模型过度拟合示例的表述方式，遇到稍微不同的输入就懵。最后精简到 4 个示例，覆盖典型和边界情况，效果最好。
第三个：延迟和成本不是完全正相关的。我原以为降级到 Haiku 一定更快，但实测发现，如果 Haiku 判断错误导致重试，整体延迟反而更高。所以路由准确率对延迟的影响，比模型本身的速度更大。这提醒我，路由层的准确率优化，本质上也是在优化延迟。
5.3 持续监控：路由层不是上线就完事
路由层上线只是开始，持续监控才是关键。我搭了一套监控看板，核心盯几个指标：
- 大模型调用占比：这个指标突然上升，说明路由层可能在误升级，要查原因。
- 各意图的置信度分布：某个意图的置信度整体下降，说明这类请求的表述在变化，prompt 可能要更新。
- 误降级率：通过抽样人工评估，或者用大模型反向校验，估算误降级比例。
- 路由层 P99 延迟：路由层自己不能成为瓶颈。
这套监控跑起来之后，我发现业务话术会随时间漂移，比如新上了某个功能，用户提问方式就变了。所以路由 prompt 需要定期用新数据回归测试，必要时更新示例和类别定义。我大概每个月做一次回归，每次都能发现一些可以优化的点。
6. 那些让我熬夜的坑：路由层实战避坑清单
6.1 坑一：把路由层当成了"小号大模型"
这是我早期最大的认知错误。我一开始想让 Haiku 在路由的同时，顺便把简单问题也答了，结果 prompt 写得又长又杂，路由准确率直线下降。后来想明白了：路由层就该专注做路由，回答问题是子智能体的事。职责单一，才能稳定。
这个道理和微服务架构一样，一个服务只做一件事。路由层如果又分类、又抽取、又回答，prompt 会变得极其复杂，模型容易顾此失彼。拆分职责后，每个环节的 prompt 都简单清晰，整体稳定性反而更高。
6.2 坑二：忽略了多轮对话的上下文管理
单轮请求的路由很简单，多轮对话就麻烦了。用户第三轮说的话，可能依赖前两轮的上下文才能正确分类。我早期只把当前这轮输入丢给路由层，导致大量误判。
解决方案是把最近几轮对话的精简摘要一起传给路由层。注意是摘要，不是完整历史，否则 token 消耗上去了，路由层也不便宜了。我的做法是维护一个滚动摘要，每轮更新，控制在 200 字以内。这样既保留了上下文，又控制了成本。
6.3 坑三：schema 变更没有版本管理
路由层的输出 schema 是和下游子智能体强耦合的。我吃过一次亏：下游子智能体升级，改了参数名，但路由层的 prompt 没同步更新，导致大量请求参数抽取失败。排查了半天才发现是接口不一致。
后来我强制要求 schema 变更必须走版本管理，路由层和下游子智能体引用同一个 schema 定义文件，任何变更都要同步更新并回归测试。这个规范加上去之后，这类问题再没出现过。
6.4 坑四：没有做 A/B 测试就全量上线
我第一次上线路由层的时候，信心满满直接全量，结果当天就出了状况。部分长尾请求被误降级，用户反馈答非所问。虽然当天就回滚了，但影响已经造成。
后来我改成灰度上线：先放 5% 流量，观察一周；没问题放到 20%，再观察；逐步放大到全量。每一步都对比核心指标，确认没有退化才继续。这个过程慢，但稳。做基础设施改造，稳比快重要。
提示：灰度期间一定要有快速回滚机制。我当时的回滚开关是配置化的，改一个配置就能切回旧逻辑，不用重新部署。这个设计救了我好几次。
7. 路由层还能怎么进化：几个我验证过的扩展方向
7.1 用缓存进一步压成本
路由层的判断结果是可以缓存的。很多请求是重复的，或者高度相似的。我把路由结果按输入哈希缓存起来，命中缓存的请求直接复用判断结果，连 Haiku 都不用调。实测缓存命中率在 15% 到 25% 之间，这部分请求的路由成本直接归零。
缓存要注意失效策略。业务话术变化、意图定义调整时，缓存要能及时失效。我用的是带 TTL 的缓存，加上版本号，schema 变更时版本号一变，旧缓存自动失效。
7.2 路由层自己学习：用反馈数据持续优化
路由层的判断结果，最终会有个"对不对"的反馈——要么下游子智能体处理成功，要么用户满意。这些反馈数据可以收集起来，定期用来优化路由 prompt，甚至微调一个更小的专用分类模型。
我目前还在用 prompt 优化的阶段，效果已经不错。未来如果请求量再上一个量级，可能会考虑微调一个专用的小模型做路由，进一步降本增效。不过微调有维护成本，要权衡。
7.3 多路由层协作：应对超大规模场景
如果系统规模继续扩大，单个路由层可能扛不住。这时候可以考虑多路由层协作：第一层做粗分，把请求分到几个大域；每个大域有自己的第二层路由，做细分。这种分层路由架构，和前面说的分层分类是一个思路，只是从逻辑分层变成了物理分层。
分层路由的好处是可扩展，每个路由层可以独立优化、独立扩容。代价是架构复杂度上升，延迟可能增加一点点。是否值得，要看具体规模。
8. 写在最后：一些掏心窝的经验
这套路由方案我前后打磨了大半年，从最初的规则路由，到 Haiku 路由层，再到现在的分层路由加缓存，中间踩的坑比省下的钱还多。如果让我给正在考虑类似改造的朋友几句实在话：
第一，先量化再动手。别凭感觉觉得"成本高"，先把调用日志拆开，看清楚钱花在哪。很多时候你会发现，真正的大头不是你以为的那个地方。
第二，路由层的准确率比成本更重要。省钱的诱惑很大，但误降级带来的体验损失，往往比省下的钱更贵。宁可保守一点，多转一些给大模型，也别为了省钱牺牲正确性。
第三，基础设施改造要灰度。路由层是入口级组件，一旦出问题影响面很大。灰度、监控、回滚，这三样一个都不能少。
第四，prompt 是要养的。业务在变，话术在变，路由 prompt 不可能一劳永逸。把它当成一个需要持续维护的资产，定期回归、定期更新。
最后分享一个我最近在试的小技巧：把路由层的置信度和下游子智能体的处理结果关联起来分析，能发现一些隐藏的误判模式。比如某个意图的置信度普遍偏高，但下游成功率偏低，说明这个意图的定义可能有问题，或者 Haiku 对这类请求有系统性误判。这种交叉分析，比单看路由层指标更能发现问题。这套方法我还在验证，目前看效果不错，有兴趣的可以试试。
