做了半年多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_keyapi_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( modelself.router_model, max_tokens300, temperaturetemperature, systemself._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深推理三个档位各配一个子智能体。按功能领域划分是支线——比如“检索”“写作”“分析”各自独立成组但这里要注意支线领域的子智能体内部仍然要标明对应的推理档位。比如我的池子是这样的子智能体ID负责职责推理档位建议模型executor规则执行、格式处理L1任意轻量模型summarizer摘要、分类、归纳L2中档模型analyst深度分析、方案推演L3高性能模型retriever搜索、信息抓取L1-L2中档模型writer内容生成、报告撰写L2-L3中档偏上每个子智能体内部定义自己的执行提示词、输出格式和成功标准。路由子智能体只负责分配不负责具体执行职责干净互相不干扰。3.4 成本测算从“毛估估”到“心中有数”做了路由之后怎么证明它真的省了钱不要只看月底的账单总额你需要先建立一套成本基准。我给这个项目做过一份成本测算流程是先跑一周“全量走L3”的对照组记录每个子任务的token消耗和耗时再跑一周“路由分配”的实验组同样记录数据。把两组做对比省了多少一目了然。假设模型单价如下实际价格以官方为准这里只演示算法逻辑模型档位输入价/千token输出价/千token轻量档Haiku级别0.5元1.5元中档1.5元5元高性能档4元12元某天系统跑了一千个子任务分布假设是L1任务580个L2任务300个L3任务120个。L1任务平均消耗输入2k输出0.5k tokenL2平均消耗输入5k输出1.5k tokenL3平均消耗输入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 常见问题速查表问题可能原因排查方式解决方案路由决策频繁变动边界任务无优先级规则检查日志中各决策的置信度增加优先级规则和一致性沿用策略路由判断质量差上下文过长稀释主信息统计路由输入的平均长度使用上下文压缩器限制输入长度路由调用超时/限流并发过高、无降级查API调用频率和错误码设超时重试、做缓存、加兜底规则任务失败率上升过度成本优先分配不当对比同一任务类型路由前后失败率低置信度强制升档坚持质量优先新子智能体长期闲置路由提示词未同步更新查看路由日志中新智能体命中次数维护路由提示词补充新智能体示例5. 进阶玩法让路由系统越用越聪明5.1 构建路由反馈闭环路由日志不只是用来排查问题更可以用来做闭环优化。我在日志回放机制上往前走了一步每天统计各子智能体的执行表现用执行结果反向修正路由决策。具体做法如果某类任务被路由到A子智能体但执行结果不理想而同类任务换到B子智能体后成功率和质量都更高那么路由就会在第二天自动调整判断规则。跑了一个月之后整个系统的路由策略就像被反复训练过一样越来越贴合实际任务的分布。这一步也是让“省六成成本”能长期稳定的关键——不是一次调优就一劳永逸而是让路由随业务形态的变化持续适配。5.2 多级路由的扩展思路单一层次的路由解决了“分给谁”的问题但在更大规模的Agent系统里你可以考虑多级路由架构。第一级路由决定任务属于哪个大方向——检索、分析、生成还是执行第二级路由再决定具体分配给这个方向下的哪个子智能体。多级路由的好处是每层只做一次小决策判断难度低准确率高。坏处是多一次模型调用多一次延迟。我目前的取舍标准是子智能体池超过8个就分两级不超过5个就维持单级。5.3 与缓存策略的协同最后补一个省钱杀手锏路由和缓存叠加效果是乘法级的。我在路由返回决策时同时把“上下文摘要任务类型子智能体ID”的组合写入缓存。相同摘要的任务在短时间内再次出现就直接跳过路由判断连Haiku 5.5的调用都能省。结合缓存之后我发现系统中大概有20%的任务会命中缓存这部分的成本直接归零。这一刀看上去不多但叠加在路由省下的60%之上整体的成本曲线已经非常好看。实际操作中缓存键的设计要谨慎过细命中率太低过粗命中后容易返回过期决策。我的经验是缓存键包含子任务类型前缀和语义化摘要指纹有效期控制在10分钟以内。这套路由方案的适用性很广。不管你是基于哪家的模型构建Agent只要模型体系里存在“轻量档”和“高性能档”这套思路都能平移过去。核心从来不是某个具体模型而是“让任务难度和模型能力对齐”这个原则。我个人在实际使用中最深的体会有两条。第一条路由系统的成败不在模型而在数据——路由日志记录得越细你才越有据可依地持续优化第二条不要迷信“最强模型”正确的资源分配往往比更强的单体能力更值钱。这两句话听起来朴素但真在账面上看到那个降幅之后才会真正理解它们的分量。
