1. 从一次账单失控说起为什么子智能体路由值得认真做去年下半年我接手了一个多智能体协作系统的调优工作主流程跑得挺顺但月底账单出来的时候整个小组都沉默了——单月调用成本比预算高出一倍还多。排查下来问题很典型主智能体在处理用户请求时无论任务轻重几乎都调用了同一个高能力、高单价的模型。用户问一句今天天气怎么样系统也要走一遍完整的大模型推理链路token 消耗和响应延迟都白白浪费。这个场景其实非常普遍。只要你的 Agent 系统开始承接真实流量就一定会遇到能力过剩的问题简单意图识别、字段抽取、格式转换、路由分发这类任务用顶级模型跑纯属杀鸡用牛刀。而真正需要复杂推理、长链条规划的任务占比往往不到三成。把不同难度的任务分发给不同档位的模型也就是所谓的子智能体路由Sub-agent Routing是当前把 Agent 成本压下来的最直接手段之一。这篇内容我想聊的就是怎么用 Claude Haiku 5.5 作为轻量路由层把整个 Agent 体系的成本砍掉六成左右。核心思路不复杂让 Haiku 5.5 承担分诊台的角色判断任务类型和复杂度再决定把请求转给哪个子智能体、用哪个模型。适合正在做多智能体系统、被成本困扰、或者想给现有 Agent 加一层智能调度的开发者参考。哪怕你只是刚接触 Agent 编排只要跟着思路走也能理解这套路由机制的设计逻辑。需要先说明一点标题里的砍掉六成不是拍脑袋喊的口号而是我在实际压测和线上灰度中观察到的区间。具体能省多少取决于你的任务分布、路由准确率和兜底策略。后面我会把测算过程拆开讲让你能套用到自己的场景里估算。2. 为什么是 Haiku 5.5 来当这个分诊台2.1 路由层对模型的真实要求快、准、便宜缺一不可很多人第一反应是路由嘛随便找个便宜模型就行。但真做过就知道路由层有三个硬指标任何一个不达标都会拖垮整个系统。第一是延迟。路由是请求进入系统的第一道关卡它多花 200 毫秒用户就能明显感知到卡顿。路由层必须是整个链路里最快的一环否则省下的钱会被体验损失抵消掉。第二是判断准确率。路由判断错了简单任务被丢给贵模型成本没省下来复杂任务被丢给便宜模型结果质量崩了用户投诉。路由错误是双输所以准确率比单纯的价格更重要。第三才是单价。路由层每次调用都要消耗 token如果它自己就很贵那省下来的钱又被它吃回去了。理想状态下路由层的成本应该只占整体成本的个位数百分比。把这三个指标放在一起看就能理解为什么 Haiku 系列适合干这个活。它在同价位模型里响应速度属于第一梯队指令遵循能力足够稳定价格又压得很低。用一句话概括路由层要的不是最聪明而是够聪明且反应快、花钱少。2.2 Haiku 5.5 相比前代在路由场景下的实际提升我在迁移前后做过对比测试重点看的是路由判断的稳定性。前代模型在边界任务上容易犹豫比如一个既像查询又像操作的请求它有时会给出模棱两可的分类导致下游子智能体拿到不明确的指令。Haiku 5.5 在这块的表现明显更干脆。我构造了 500 条边界模糊的测试样本让它输出结构化的路由决策JSON 格式包含任务类型、复杂度等级、目标子智能体前代的格式合规率大概在 92% 左右5.5 能稳定在 98% 以上。别小看这 6 个百分点路由输出格式一旦不合规下游解析就会报错需要重试重试又意味着额外的延迟和成本。另一个提升是长上下文下的判断一致性。当路由层需要参考对话历史来做决策时比如判断用户是不是在追问同一个任务上下文一长前代模型容易忘记前面的约束条件。5.5 在 8K 以上的上下文里对系统提示词里定义的分类规则保持得更好。这一点对多轮对话场景特别关键。2.3 一个容易被忽略的点路由层本身也要能拒答我踩过的一个坑是早期版本的路由层遇到完全无法分类的请求时会硬着头皮选一个类别结果把垃圾请求路由到了核心子智能体浪费了贵模型的算力。后来我在路由提示词里加了一条明确的兜底规则如果置信度低于阈值就路由到通用兜底子智能体由它用中等档位模型处理。Haiku 5.5 对这类允许说不的指令执行得很好它不会为了完成任务而强行编造分类。这个设计让整个系统的鲁棒性上了一个台阶也避免了大量无效的贵模型调用。3. 路由架构怎么搭从请求进入到子智能体分发的完整链路3.1 整体分层设计路由层、执行层、兜底层我把整个系统分成三层职责边界划得很清楚。路由层只做一件事接收原始请求输出一个结构化的路由决策。它不执行业务逻辑不调用外部工具纯粹是分诊。这一层用 Haiku 5.5提示词里固化分类规则和输出格式。执行层是各个子智能体每个子智能体绑定一个特定档位的模型和一套工具集。比如简单问答子智能体绑定轻量模型数据分析子智能体绑定中档模型复杂规划子智能体绑定顶级模型。路由决策里的目标字段直接决定请求进哪个子智能体。兜底层处理两类情况路由置信度低的请求以及执行层返回失败的请求。兜底层用中等档位模型保证最坏情况下也能给出可用结果而不是直接报错。这样分层的好处是每一层都可以独立优化。路由层换模型不影响执行层执行层加子智能体也不用改路由逻辑只要更新分类规则就行。3.2 路由决策的输出结构为什么一定要结构化路由层的输出必须是机器可解析的结构化数据这是硬性要求。我见过有人让路由模型直接输出自然语言描述这个请求应该交给 XX 处理然后在下游用正则去匹配这种做法极其脆弱模型换个措辞就崩了。我的做法是让 Haiku 5.5 输出固定 schema 的 JSON字段包括{ task_type: query | action | analysis | planning | chitchat, complexity: low | medium | high, target_agent: simple_qa | data_analysis | complex_planner | fallback, confidence: 0.0, reason: 简短说明 }task_type和complexity是中间判断target_agent是最终决策confidence用于兜底判断reason主要用于调试和日志分析。字段不要贪多每多一个字段就多一份 token 消耗和出错概率。我一开始加了七八个字段后来砍到五个路由准确率反而更稳了。提示schema 里的枚举值一定要在系统提示词里穷举清楚并且明确告诉模型只能从这些值里选。Haiku 5.5 对枚举约束的遵循度很高但前提是你得把约束写明白。3.3 置信度阈值怎么定一个需要实测调参的关键参数置信度阈值是路由系统里最需要调参的地方。阈值定高了大量请求被丢进兜底层路由层形同虚设阈值定低了错误路由增多贵模型被滥用。我的经验值是0.75 起步。具体做法是先跑一批真实流量样本统计不同阈值下的路由准确率和兜底率找到那个准确率还能接受、兜底率又不至于太高的平衡点。我当时的测试数据大致是这样置信度阈值路由准确率兜底率综合成本指数0.6088%5%1000.7092%11%940.7595%18%890.8597%34%96可以看到阈值从 0.75 提到 0.85准确率只涨了 2 个点但兜底率翻了一倍综合成本反而上升了。所以不是越保守越好得看整体账。这个表是我自己场景下的数据你的任务分布不同最优阈值也会不同但调参方法是一样的。4. 提示词工程让 Haiku 5.5 稳定输出可用的路由决策4.1 系统提示词的分层写法规则、示例、约束路由层的提示词我分成三块写顺序很重要。第一块是角色和任务定义用一两句话讲清楚它是干什么的。比如你是一个请求路由分诊器负责判断用户请求的类型和复杂度并决定由哪个子智能体处理。第二块是分类规则把每个 task_type 和 complexity 的判断标准写清楚。这里要具体不能含糊。比如如果请求需要多步骤规划或涉及多个工具的协同调用complexity 标记为 high而不是笼统地说复杂任务标记为 high。第三块是输出格式和约束给出 JSON schema并强调只输出 JSON不要有任何额外文字。我试过把示例放在规则前面结果模型容易照搬示例里的具体内容泛化能力变差。把规则放前面、示例放后面或者干脆用 few-shot 放在单独的消息里效果更稳。4.2 Few-shot 示例的选择覆盖边界情况比覆盖常见情况更重要很多人准备 few-shot 示例时喜欢挑最典型的例子。但路由层的难点恰恰在边界情况典型例子模型自己就能判断对真正需要教的是那些模棱两可的。我的示例集里至少一半是边界样本。比如帮我看看这个数据对不对——它既可能是简单查询看一眼也可能是数据分析需要跑统计。我的处理是把它归到 data_analysis因为看看对不对隐含了验证逻辑简单查询子智能体搞不定。这种判断标准必须通过示例明确传达给模型。示例数量我控制在 8 到 12 条。太少覆盖不全太多会挤占上下文、增加成本而且边际收益递减。我实测下来超过 15 条之后准确率基本不再提升。4.3 输出格式的强约束JSON 模式与失败重试即使提示词写得很清楚模型偶尔还是会输出带 markdown 代码块包裹的 JSON或者前后多一句解释。我的处理是双保险一是在提示词里明确直接输出 JSON 对象不要用代码块包裹二是在解析层做容错遇到代码块包裹就剥掉再解析。如果解析还是失败就触发一次重试重试时把上一次的错误输出一起带上告诉模型你的输出无法解析请严格按 schema 重新输出。实测重试的成功率很高而且重试本身也用 Haiku 5.5成本可以忽略。但重试次数要设上限我设的是 1 次超过就直接走兜底层避免无限重试拖垮延迟。5. 成本测算六成到底是怎么省出来的5.1 拆解成本结构路由成本、执行成本、兜底成本要算清楚省了多少得先把成本拆开。整个系统的成本 路由层成本 执行层成本 兜底层成本。路由层成本很好算每次请求调用一次 Haiku 5.5输入是系统提示词加用户请求输出是那五个字段的 JSON。假设系统提示词加示例约 1500 token用户请求平均 200 token输出约 80 token那么单次路由的 token 消耗约 1780。按 Haiku 5.5 的单价算这个成本非常低大概只占整体成本的 3% 到 5%。执行层成本是大头也是省钱的关键。假设没有路由时所有请求都走顶级模型平均每次消耗 3000 token。有了路由后只有约 25% 的请求走顶级模型40% 走中档模型35% 走轻量模型。中档模型单价约为顶级的五分之一轻量模型约为十分之一。这样一算执行层成本能降到原来的三成左右。兜底层成本取决于兜底率我控制在 15% 以内用中档模型处理占比不大。5.2 一个可复用的成本估算公式我把上面的逻辑整理成一个公式你可以直接套原成本 N × C_top 新成本 N × C_route N × (P_top × C_top P_mid × C_mid P_low × C_low) N × P_fallback × C_mid其中 N 是请求数C_route 是路由成本P_top/P_mid/P_low 是各档位请求占比C_top/C_mid/C_low 是对应模型单价P_fallback 是兜底率。代入我的实际数据C_mid ≈ 0.2 × C_topC_low ≈ 0.1 × C_topC_route ≈ 0.03 × C_topP_top0.25P_mid0.40P_low0.35P_fallback0.15新成本 ≈ N × 0.03C N × (0.25 0.40×0.2 0.35×0.1)C N × 0.15×0.2C ≈ N × (0.03 0.25 0.08 0.035 0.03)C ≈ N × 0.425C也就是说新成本约为原来的 42.5%省下约 57.5%接近六成。这个数字和标题里的砍掉六成基本吻合。注意这里的关键变量是 P_top也就是走顶级模型的请求占比。如果你的任务里复杂任务占比更高省的比例就会下降反之则更省。5.3 别忽略隐性成本重试、兜底和延迟带来的体验损耗账面上省了六成但有几个隐性成本必须算进去。一是路由错误导致的重试。如果路由把复杂任务错分给了轻量模型轻量模型处理失败请求会被打回兜底层重跑这一次重跑的成本可能比一开始就走顶级模型还高。所以路由准确率直接决定了实际节省幅度。我实测准确率 95% 时重试带来的额外成本约占 4%。二是延迟。路由层本身增加了一次模型调用虽然 Haiku 5.5 很快但加上网络往返还是会增加 100 到 300 毫秒。对于延迟敏感的场景这个开销要评估。我的做法是对延迟要求极高的请求比如实时对话走一条快速通道跳过复杂路由直接用轻量模型加规则判断。三是维护成本。路由规则和示例需要随着业务变化持续更新这是一笔持续投入。如果业务场景很稳定维护成本低如果业务频繁变化就得留出人力。6. 上线后踩过的坑与调优经验6.1 路由层过度自信置信度虚高怎么破上线初期我发现一个诡异现象路由层给出的置信度普遍偏高很多明显该兜底的请求它也标了 0.9 以上。结果就是错误路由没有被兜底机制拦住。排查后发现问题出在提示词里对 confidence 的定义太模糊。模型不知道0.9到底代表什么就倾向于给高分。我的修复方法是在提示词里给出锚点明确告诉它只有当你完全确定分类时才给 0.9 以上如果有任何不确定给 0.6 到 0.8完全无法判断时给 0.5 以下。加了锚点之后置信度分布明显更合理了兜底机制也开始正常发挥作用。这个坑的教训是凡是让模型输出数值型字段都要给锚点和参照否则模型会按自己的直觉来而它的直觉往往偏乐观。6.2 子智能体边界重叠两个 Agent 抢同一个任务随着子智能体增多出现了职责重叠。比如数据查询和数据分析两个子智能体遇到统计一下上个月的销售总额这种请求路由层有时分给前者有时分给后者导致结果格式不一致。解决办法是重新梳理子智能体的职责边界并在路由提示词里用互斥规则明确划分。我加了一条规则如果请求涉及聚合、统计、对比等操作一律归为 analysis即使它看起来像简单查询。同时把两个子智能体的能力描述写进提示词让路由层知道各自的边界在哪。这件事让我意识到路由层的分类规则其实是整个系统架构的映射。如果子智能体职责本身就不清晰路由层再怎么调也调不好。先把架构理清楚再写路由提示词顺序不能反。6.3 灰度发布与 A/B 对比怎么验证路由真的有效路由系统上线不能一把梭必须灰度。我的做法是先把 10% 的流量接入路由另外 90% 走原来的全顶级模型链路对比两组的成本、延迟和用户满意度。对比时重点看三个指标单位请求成本、P95 延迟、任务成功率。前两个是成本和体验第三个是质量底线。如果任务成功率下降超过 1 个百分点就说明路由准确率不够需要回退调优。灰度期间我还做了一件事把路由决策和最终执行结果都记进日志定期抽样人工复核。这一步很费时间但能发现很多自动化指标看不出来的问题比如某些特定类型的请求总是被错分。复核了两周之后路由准确率从 91% 提到了 95% 以上。6.4 一个反直觉的发现不是所有请求都值得路由调优到后期我发现有一类请求路由反而亏。就是那些极短、意图极其明确的请求比如你好谢谢取消。这类请求用规则引擎关键词匹配就能判断根本不需要调用模型。如果硬走路由层反而多花了一次 Haiku 5.5 的调用成本。所以最终的架构是规则优先模型兜底先用轻量规则匹配明显简单的请求匹配不上的再进 Haiku 5.5 路由层。这一层规则过滤又省下了大约 8% 的成本而且延迟几乎为零。这个优化思路其实很通用能用确定性规则解决的就别交给模型。7. 关于这套方案适用边界的几点个人体会这套路由方案不是万能的我在实践中总结出几个适用边界供你判断自己的场景是否合适。如果你的任务类型高度单一比如所有请求都是同一种复杂推理那路由层没有意义因为根本没有分流的空间。路由的价值来自任务分布的差异性差异越大省得越多。如果你的系统对延迟极度敏感比如要求端到端 200 毫秒以内那路由层增加的那一次模型调用可能就无法接受。这种情况下可以考虑把路由逻辑前置到客户端或者用更轻量的本地分类模型替代。如果你的请求量很小比如每天几百次那省下来的绝对金额可能还不够覆盖路由系统的开发和维护成本。路由方案更适合有一定流量规模、成本压力真实的场景。最后说个我自己的判断子智能体路由这件事技术难度其实不高难的是持续调优和对业务的理解。模型选型、提示词写法、阈值调参这些都有章可循真正拉开差距的是你有没有耐心去分析真实流量、复盘错误路由、迭代分类规则。我见过太多团队把路由搭起来就不管了结果准确率一直卡在 90% 上下省的钱远不如预期。路由系统是个需要养的东西前期投入的调优时间会在后续的账单里慢慢还给你。