★ FEATURED ARTICLE 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约 70Haiku 路由层约 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 填 unknownconfidence 填 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 对这类请求有系统性误判。这种交叉分析比单看路由层指标更能发现问题。这套方法我还在验证目前看效果不错有兴趣的可以试试。
阅读完成 · 觉得有帮助？
