用Claude Haiku 5.5做子智能体路由，Agent成本直降60%

做了半年多Agent应用，我最大的感受就一个：能力没输过，账单没赢过。不管给客户演示多聪明的Agent，只要一聊到生产环境的token成本，气氛立刻冷下来。直到我把Claude Haiku 5.5拉进系统做子智能体路由，事情才发生转变——单次复杂任务的推理成本平均降了60%，有些场景甚至能到七成。这个数字不是拍脑袋，是我在三个项目里跑了一个季度，反复调整路由策略之后实测出来的。

这篇内容就围绕一件事展开：怎么用Claude Haiku 5.5这种轻量模型，给Agent体系做一套聪明的任务分发机制。我会从路由的必要性讲起，给到可以直接抄的架构设计和代码，再附上成本测算方法和一套完整的排坑指南。适合那些已经上过Agent、正在头疼成本爆炸的开发者，也适合准备设计多智能体系统的架构师参考。

1. 子智能体路由：先想清楚为什么非做不可

1.1 一个真实的成本失控场景

先还原一下我踩坑的场景。某公司让我搭一个“行业信息分析Agent”，需求不复杂：每天抓取公开信息，自动归类、抽取要点、生成一份带结论的分析简报。最初架构很粗暴——主Agent接到任务，直接调用当时最强的那档模型，所有子任务都走同一个大模型完成。

跑了一个月我看账单，发现一个扎心的事实：超过七成的token被用在了“信息归类”和“格式整理”这类活上。这些子任务根本不需要顶级推理能力，要的只是稳定的指令遵循和结构输出。真正需要深度思考的部分，其实只有“观点对比”和“结论推导”这两步。

这个现象不是个例。绝大多数Agent任务都是二八分布：80%的子任务是小学生能干的活，只有20%需要博士生级别的推理。问题就出在，传统Agent设计没有区分这两种需求，所有请求一股脑全发给最强模型，成本自然压不住。

1.2 传统多智能体的成本黑洞在哪

很多人会问：多智能体架构不是天然能解决这个问题吗？把不同能力的模型分给不同角色不就行了？

理论是的，但实际操作你会发现三个坑：

第一，角色与模型能力绑定氧化。架构设计初期想得挺好——“这个分析师用最强模型，那个数据员用轻量模型”。但跑两周就发现，任务边界根本不像设计时那么清晰，有些子任务比预想的难，有些比预想的简单。模型定死了，成本结构也就定死了。

第二，固定配置缺乏弹性。一个写周报的Agent，平时只需要简单汇总；赶上季度总结周，任务复杂度突然飙升。如果模型配置是写死的，要么日常浪费，要么关键时刻不够用。

第三，多智能体协调本身有开销。子智能体之间传递内容、重复总结上下文、互相等待，这些隐性token消耗在账面上很难察觉，但月底汇总时一定让你肉疼。

传统思路在“选模型”上花了很多功夫，却很少有人认真对待“选对模型”这个决策应该由什么来做。而路由机制解决的就是这个决策问题。

1.3 路由的本质：给任务定级，按级别分配

子智能体路由的核心思想，一句话总结：不要让你的Agent系统默认所有任务都是同一个难度。先让一个轻量模型当“调度员”，快速判断当前子任务的复杂度，再决定把它交给哪个子智能体处理。

你可以把它想象成一个外卖平台：平台收到订单，先判断是“商家自配送”还是“平台骑手配送”，再根据距离、天气、骑手忙碌程度分配给不同运力。不会因为用户点了一份凉皮，就派一个豪华车队去送。

这个“调度员”就是Claude Haiku 5.5。它在我的系统里承担一个独立的“路由子智能体”，输入是当前主任务的目标、上下文摘要和候选子智能体清单，输出是一个结构化的路由决策——该交给谁、用什么档位的模型、需要多长的思考深度。

关键是这个判断用轻量模型来做，成本几乎可以忽略，但换来的收益非常大。一句话就可以概括整个工作的核心价值：用一次廉价的判断，取代一段昂贵的推理。

2. 路由子智能体的架构设计与任务分类体系

2.1 三档任务分类法

在设计路由策略时，我最终沉淀了一套“三档分类法”。这套分类不是按领域分的，而是按推理深度分的。任何子任务进来，先归到下面三档之一：

• L1：规则任务。查表格、取字段、格式转换、清洗数据、调用API并返回结果。这些任务有明确执行路径，模型只需要理解指令并稳定执行，不需要发散思考。
• L2：轻推理任务。摘要提取、信息归类、情感判断、简单对比。需要对上下文有一定理解，能抓住主次，但推理链短，不需要多步思考。
• L3：深推理任务。多因素分析、对立观点权衡、长链条因果推导、创造性方案生成。这类任务需要模型具备较强的抽象思维和逻辑严密性，是真正值得烧高端算力的部分。

这套分类的价值在于，它给路由判断提供了一个可执行的判别标准。路由子智能体不需要理解“这个任务是金融分析还是医疗问答”，只需要判断“这个任务需要几步推理才能完成”。

2.2 路由的三级决策链

路由子智能体不是一个孤立的判断节点，我给它设计了三级决策链，逐步过滤，减少误判和浪费：

第一级，规则过滤器。在进入模型判断之前，先跑一段基于关键词和上下文的规则逻辑。比如任务里出现“翻译”“JSON格式化“”查字典映射”这类高频信号，直接归类到L1，连模型调用都可以省掉。这一步的拦截率大概能覆盖20%的任务。

第二级，上下文画像判断。规刚没拦截住的，进入路由子智能体。输入是任务文本、上下文摘要、历史执行统计（这个类型任务上次实际用的模型档位和耗时），输出分类建议和置信度。置信度高就直接分配；置信度低，进入第三级。

第三级，兜底策略。路由判断置信度低于阈值时，不要赌。直接把任务升档处理，交给更强模型。我宁愿在L3模型上多花一点token，也不愿意因为路由判断失误导致任务失败，反复重试的成本远比一次升档要高。

2.3 为什么选Claude Haiku 5.5当路由大脑

把路由决策交给大模型，而不是传统的决策树或者规则引擎，这个选择我挣扎过一段时间。规则引擎我试过，问题在于真实任务的表达太灵活了，同样是“总结一下”，可能只是提取标题，也可能是写一页纸的分析摘要，规则很难覆盖这些灰色地带。

Haiku 5.5在我实测中的表现，恰好卡在了“足够便宜”和“足够聪明”的交界点上。路由判断这个任务，本身不需要深推理能力——它是分类任务，不是分析任务。而Haiku 5.5在分类、指令遵循、结构化输出这几个维度上，做得已经非常稳。更关键的是它的响应速度极快，路由决策的延迟只有几百毫秒，对用户来说几乎感知不到。

选型逻辑再总结一下就是：路由决策这件事的复杂度，本身属于L2轻推理；你用L3档位的大模型来做L2的事，本身就是一种资源浪费。用Haiku 5.5做路由，恰恰是在“给任务定级”这个动作上也要贯彻成本意识。

3. 实操上线：从代码到成本测算的完整拆解

3.1 主Agent入口与路由调用逻辑

直接上实操。我的系统是一个典型的“主Agent + 子智能体池”架构。主Agent负责拆解用户请求，每个子任务在进入子智能体池之前，都要经过路由判断。

路由的调用方式很简单，主Agent在生成子任务时，把任务描述、上下文和子智能体清单传给路由接口，拿回结构化决策结果。关键代码长这样：

# agent_router.py import json from anthropic import Anthropic class AgentRouter: def __init__(self, api_key: str): self.client = Anthropic(api_key=api_key) self.router_model = "claude-haiku-5.5" # 路由用轻量模型 def route_task( self, task_desc: str, context_summary: str, candidates: list[dict], temperature: float = 0.1 ) -> dict: # 第一级：规则快筛，省掉一次模型调用 rule_hit = self._rule_filter(task_desc) if rule_hit: return rule_hit # 第二级：Haiku 5.5 路由判断 prompt = self._build_routing_prompt(task_desc, context_summary, candidates) response = self.client.messages.create( model=self.router_model, max_tokens=300, temperature=temperature, system=self._ROUTER_SYSTEM, messages=[{"role": "user", "content": prompt}] ) decision = self._parse_decision(response.content[0].text) # 第三级：置信度兜底，低置信度升档 if decision["confidence"] < 0.6: decision["route_target"] = "deep_reasoning" decision["note"] = "low_confidence_fallback" return decision def _rule_filter(self, task_desc: str) -> dict | None: # 高频固定任务直接走规则 if any(kw in task_desc for kw in ["翻译", "JSON格式化", "字段提取"]): return { "route_target": "rule_executor", "confidence": 0.99, "model_tier": "cheap", "reason": "rule_match" } return None

一个容易被忽略的细节是温度选择。路由判断是分类决策，不是创意生成，我把temperature压到了0.1。过高会导致同样结构的任务每次路由结果都不同，这在生产环境是灾难性的——你今天跑同一个任务分给“轻智能体”，明天变成“深推理智能体”，成本波动就没有规律可循了。

3.2 配套提示词是这样设计的

路由子智能体能不能判断准，一大半看提示词。我踩过一次很深的坑——提示词里只描述了每个子智能体“能干什么”，没有描述“不干什么”，结果路由经常把活分错。

最初版本的系统提示词，我只写了每个子智能体的名称和职责描述：

• 子智能体A：负责信息检索和抓取
• 子智能体B：负责摘要和归纳
• 子智能体C：负责复杂分析和推理

看起来挺清楚的，但Haiku 5.5判断时的逻辑是：任务只要沾点边，就会被分到“看起来最权威”的子智能体。比如“把这段英文翻译成中文并概括大意”，它直接分给了“复杂分析”，因为系统提示词里明确写了推理两个字。后来我改了提示词的写法，给了大量的反面示例：

系统提示词核心部分： 你的任务是判断一个子任务应该交给哪个子智能体。参考以下规则： 1. 子智能体A "executor"：执行明确的、有固定步骤的操作。适合格式转换、查询接口、字段提取。不适合做任何需要提炼和总结的操作。 2. 子智能体B "summarizer"：适合压缩信息、提取要点、归纳分类。不适合做数值计算、方案生成。 3. 子智能体C "analyst"：适合多因素分析、长链推理。不适合做机械的格式操作。 对于以下任务，明确属于"executor"： - "把A列和B列的数据合并成JSON" → executor - "调用天气API返回当前温度" → executor 对于以下任务，明确属于"summarizer"： - "用三句话概括这篇文章" → summarizer - "这篇评论的总体情绪是正面还是负面" → summarizer 对于以下任务，明确属于"analyst"： - "分析三个方案各自的优缺点并给出推荐" → analyst

加了反面示例之后，路由准确率肉眼可见地提升。原因很简单：小模型受提示词中示例的影响很大，你只给正向描述，它就按照自己的模糊理解去猜；给了边界案例，它才能学会区分任务类型。这一步调整把路由误判率从最初的15%降到了3%左右。

注意一个问题：路由提示词和维护的子智能体清单是强耦合的。每新增一个子智能体，提示词里的描述和例子必须同步更新，否则新子智能体永远分不到活，它会变成摆设。

3.3 子智能体池的配置原则

子智能体池是路由的“候选目的地”。我的经验是，不建议配置太多。道理很简单，子智能体池里的角色越多，路由判断的区分难度越大，误判率越高。尤其当两个子智能体的职责描述高度重叠时，Haiku 5.5会随机选一个，你的系统就出现了不可控的抖动。

一个健康的中小型Agent系统，子智能体池我建议控制在5个以内。职责划分遵循两个原则：一是按推理等级划分，二是按功能领域划分。

按推理等级划分是主干——L1执行、L2轻推理、L3深推理，三个档位各配一个子智能体。按功能领域划分是支线——比如“检索”“写作”“分析”各自独立成组，但这里要注意，支线领域的子智能体内部，仍然要标明对应的推理档位。

比如我的池子是这样的：

每个子智能体内部定义自己的执行提示词、输出格式和成功标准。路由子智能体只负责分配，不负责具体执行，职责干净，互相不干扰。

3.4 成本测算：从“毛估估”到“心中有数”

做了路由之后，怎么证明它真的省了钱？不要只看月底的账单总额，你需要先建立一套成本基准。

我给这个项目做过一份成本测算，流程是先跑一周“全量走L3”的对照组，记录每个子任务的token消耗和耗时；再跑一周“路由分配”的实验组，同样记录数据。把两组做对比，省了多少一目了然。

假设模型单价如下（实际价格以官方为准，这里只演示算法逻辑）：

某天系统跑了一千个子任务，分布假设是：L1任务580个，L2任务300个，L3任务120个。L1任务平均消耗输入2k输出0.5k token，L2平均消耗输入5k输出1.5k token，L3平均消耗输入10k输出3k token。

如果不做路由，全走高性能档，总成本是：

• L1部分：580 * (2 * 4 + 0.5 * 12) = 580 * 14 = 8120元
• L2部分：300 * (5 * 4 + 1.5 * 12) = 300 * 38 = 11400元
• L3部分：120 * (10 * 4 + 3 * 12) = 120 * 76 = 9120元
• 合计：28640元

做了路由之后，各档位按实际分配计算：

• L1部分（走轻量档）：580 * (2 * 0.5 + 0.5 * 1.5) = 580 * 1.75 = 1015元
• L2部分（走中档）：300 * (5 * 1.5 + 1.5 * 5) = 300 * 15 = 4500元
• L3部分（走高配档）：120 * (10 * 4 + 3 * 12) = 120 * 76 = 9120元
• 合计：14635元

两组一对比，省了将近一半。如果你系统里L1任务占比更高，节省幅度还能再往上走。标题说的“砍掉六成”，实际是在任务分布中L1、L2占比超过75%时测出来的数据。

这个测算方法请抄走，它能解释你系统里每一分钱花哪了，也能支撑你后续做成本预算。注意价格只是演示，真实测算要结合你实际拿到的API价格。

3.5 路由日志是金矿

最后说一个很多人忽视的细节：每次路由决策都要落日志。我后面做的所有优化，都建立在日志回放的基础上。

每一条路由日志，我记录这几个字段：任务ID、任务摘要、路由决策、置信度、实际执行子智能体、执行耗时、成功与否、实际消耗token。有了这些数据，你才能回答几个关键问题：哪些任务被路由分错了？哪些任务明明标了高置信度却执行失败？哪些任务经常徘徊在两个子智能体之间？

这些问题的答案，会直接告诉你下一步优化方向。比如我发现某类“对比分析”任务经常在高置信度下被分给analyst，但执行结果却不如分给summarizer好——因为这类对比只是表格字段对照，不需要深度推理。我就在规则里加了一条硬编码，这类任务直接走summarizer，又省下了一部分L3开支。没有日志，这种优化就是盲人摸象。

4. 踩过的坑：路由系统的常见故障与排查实录

4.1 故障一：路由判断反复横跳，任务时好时坏

症状：同一个任务，这周被分到summarizer，下周被分到analyst，系统响应速度和结果质量都不稳定。

排查过程：我先看路由日志，发现横跳的任务大多属于边界模糊类型——既含摘要成分，又含分析成分。又检查路由子智能体的输出，置信度普遍在0.4到0.6徘徊。

根因：模型面对边界模糊的工具时机，会在两个选项之间摇摆。加上我在系统提示词里没有定义“当任务既有摘要又有分析需求时优先分给谁”的优先级规则。

解决方法两层：一是在提示词里增加优先级规则——“含多个环节的任务，按最重的环节分档”；二是引入“历史一致性”逻辑，同一类任务如果上一轮分给了某子智能体，本轮默认沿用，除非新任务的重心偏移。实施之后，横跳现象基本消失。

4.2 故障二：上下文太长，路由判断失去准心

症状：一个子任务的任务描述只有几百字，但为了让它理解背景，我把上下文摘要全塞了进去，结果路由决策质量明显下降。

排查过程：看日志发现长上下文场景下Haiku 5.5的置信度普遍走低，而且分类结果经常与任务描述的核心内容不相关。

根因：路由子智能体并不需要完整理解“背景故事”，它只需要理解“当前这一步在做什么”。上下文太长反而稀释了任务描述的权重，模型抓不住重点。

解决方案：设计了一个“路由上下文压缩器”。在主Agent把任务发给路由之前，先对上下文做截断和提炼，只保留三类信息——任务的历史目标、本轮子任务的目标、相关的关键数据。这一刀切下去，路由准确率又提升了一截。经验是：路由输入的上下文长度，控制在任务描述自身的3倍以内比较健康。

4.3 故障三：路由本身成为瓶颈，单点故障

症状：某个高峰期同时涌入大量Agent请求，路由子智能体出现了限流报错，所有任务都卡在了第一级。

排查过程：查API调用记录，发现路由接口的调用频率冲到了每分钟上千次，部分请求因为限流直接失败。主Agent没有设置失败降级，上游任务只能排队等待。

根因：把路由设计成了同步阻塞调用。主Agent必须拿到路由结果才能继续执行，路由一旦挂了，整个Agent系统就瘫了。

解决方案：做了两级降级——第一级，路由调用设置超时和重试，超过3秒直接走兜底规则，分配默认档位；第二级，路由结果本地缓存，相同结构的任务在五分钟内重复出现时，直接复用上次的路由决策。这两招一上，高峰期不再被打穿了。这次踩坑留给我的教训是：你能智能路由系统本身就是系统的一个节点，它同样需要有降级机制，不能因为省了成本就忽略可用性。

4.4 故障四：误把成本优化当成性能优化

这个坑更像一个认知误区。我见过有人把路由优化做成了“尽量把任务分给轻量模型”，结果省了成本，但任务失败率也跟着上去了。

要搞清楚一个事实：路由的目标是在不影响任务质量的前提下优化成本，不是无条件地成本优先。我在兜底策略上坚持的原则是：低置信度任务宁愿升档，也不会硬分给轻量模型。一次任务失败，重跑的成本是原成本的2到3倍，比升档贵多了。

做个粗略测算：一次任务如果该花10元但硬省到3元，失败后重跑一次，总共花了13元，比直接花10元还贵。路由的核心价值是“正确分配”，而不是“省钱”。省钱的正确路径是提升分配的准确率，而不是压榨单次调用的预算。

4.5 常见问题速查表

5. 进阶玩法：让路由系统越用越聪明

5.1 构建路由反馈闭环

路由日志不只是用来排查问题，更可以用来做闭环优化。我在日志回放机制上往前走了一步：每天统计各子智能体的执行表现，用执行结果反向修正路由决策。

具体做法：如果某类任务被路由到A子智能体，但执行结果不理想，而同类任务换到B子智能体后成功率和质量都更高，那么路由就会在第二天自动调整判断规则。跑了一个月之后，整个系统的路由策略就像被反复训练过一样，越来越贴合实际任务的分布。这一步也是让“省六成成本”能长期稳定的关键——不是一次调优就一劳永逸，而是让路由随业务形态的变化持续适配。

5.2 多级路由的扩展思路

单一层次的路由解决了“分给谁”的问题，但在更大规模的Agent系统里，你可以考虑多级路由架构。第一级路由决定任务属于哪个大方向——检索、分析、生成还是执行；第二级路由再决定具体分配给这个方向下的哪个子智能体。

多级路由的好处是每层只做一次小决策，判断难度低，准确率高。坏处是多一次模型调用，多一次延迟。我目前的取舍标准是：子智能体池超过8个就分两级，不超过5个就维持单级。

5.3 与缓存策略的协同

最后补一个省钱杀手锏：路由和缓存叠加，效果是乘法级的。我在路由返回决策时，同时把“上下文摘要+任务类型+子智能体ID”的组合写入缓存。相同摘要的任务在短时间内再次出现，就直接跳过路由判断，连Haiku 5.5的调用都能省。

结合缓存之后，我发现系统中大概有20%的任务会命中缓存，这部分的成本直接归零。这一刀看上去不多，但叠加在路由省下的60%之上，整体的成本曲线已经非常好看。实际操作中，缓存键的设计要谨慎，过细命中率太低，过粗命中后容易返回过期决策。我的经验是：缓存键包含子任务类型前缀和语义化摘要指纹，有效期控制在10分钟以内。

这套路由方案的适用性很广。不管你是基于哪家的模型构建Agent，只要模型体系里存在“轻量档”和“高性能档”，这套思路都能平移过去。核心从来不是某个具体模型，而是“让任务难度和模型能力对齐”这个原则。

我个人在实际使用中最深的体会有两条。第一条，路由系统的成败不在模型而在数据——路由日志记录得越细，你才越有据可依地持续优化；第二条，不要迷信“最强模型”，正确的资源分配往往比更强的单体能力更值钱。这两句话听起来朴素，但真在账面上看到那个降幅之后，才会真正理解它们的分量。