Dify 多 Agent 任务路由与负载均衡实战：让每个请求都被“最合适的智能体“接住

一、引言从一个 Agent到一群 Agent的调度难题上一篇文章我们聊了多 Agent 系统的记忆架构——让每个智能体记得住、想得起。但当系统里真的跑着十几个 Agent 时一个更基础的问题会首先跳出来请求进来之后到底该交给哪个 Agent想象一个企业级客服系统有处理订单的订单 Agent、解答售前的咨询 Agent、处理退款的售后 Agent、专门回复物流问题的物流 Agent还有兜底的通用 Agent。用户发来一句我昨天买的键盘想退了系统怎么知道这该路由给售后 Agent 而不是售前 Agent如果同时有 500 个用户涌进来订单 Agent 已经忙不过来了系统又怎么决定哪些请求先排队、哪些分流给别的 Agent这就是多 Agent 系统的任务路由Task Routing与负载均衡Load Balancing。路由解决的是派给谁的正确性问题负载均衡解决的是怎么派才不挤的效率问题。两者结合才能让一个多 Agent 系统既接得住又接得准。本文将从路由的核心概念讲起依次拆解三种主流路由方案基于规则、基于语义、混合路由然后给出负载均衡的四种经典策略最后用一个基于 DeepSeek Dify 的完整实战项目把路由与负载均衡真正落地。为什么路由是刚需而不是优化项很多开发者第一版多 Agent 系统是一根筋所有请求都发给同一个大 Agent让模型自己判断。这在请求量小、场景单一的时候没问题但一旦规模化三个问题立刻暴露上下文爆炸每个 Agent 都带全套工具和指令Prompt 越来越长推理越来越慢Token 成本指数上升。职责混乱同一个 Agent 既要懂订单又要懂物流工具列表互相干扰误调用、幻觉率显著升高。单点瓶颈所有请求挤在一个 Agent 上一个慢查询拖垮全部体验。而合理的路由架构让每个 Agent 只带自己的领域工具和知识请求按需分发——正确率更高、响应更快、成本更低还能独立扩缩容。路由不是锦上添花是多 Agent 系统走向生产环境的必经之路。二、路由的核心概念意图、技能与上下文在设计路由之前先建立三个基础概念意图Intent用户请求背后想达成的目标。用户说我想退了这个键盘意图是退货退款而不是购买咨询。意图是路由的第一依据。技能Skill每个 Agent 能做什么的声明。技能通常包括领域描述、可调用的工具、适合处理的输入类型。比如物流 Agent 的技能声明是查询订单物流轨迹、预测送达时间、处理地址变更。上下文Context除了用户这句话之外系统掌握的其他信息——用户历史、当前会话状态、各 Agent 的实时负载、业务优先级等。好的路由不只是听懂这句话而是结合场景做决策。路由的本质就是把(意图, 上下文) → 目标 Agent这个映射做对。映射的精度决定了系统的服务质量。三、路由方案一基于规则的确定性路由最朴素也最可靠的路由是规则路由Rule-based Routing用关键词、正则、业务字段直接映射到 Agent。# 规则路由示例基于关键词的意图匹配 import re ROUTES [ { agent: order_agent, pattern: re.compile(r下单|购买|加购|库存|有货|多少钱|价格), }, { agent: after_sale_agent, pattern: re.compile(r退款|退货|换货|赔偿|投诉|质量问题), }, { agent: logistics_agent, pattern: re.compile(r物流|快递|发货|配送|签收|到哪了|快递单号), }, { agent: pre_sale_agent, pattern: re.compile(r推荐|适合|对比|区别|参数|保修期), }, ] def rule_route(message: str) - str: for route in ROUTES: if route[pattern].search(message): return route[agent] return general_agent # 兜底 print(rule_route(我昨天买的键盘想退了)) # after_sale_agent print(rule_route(这个键盘多少钱)) # order_agent print(rule_route(帮我查下快递到哪了)) # logistics_agent优点零推理成本、毫秒级响应、行为完全可预期、方便单元测试。缺点无法处理模糊表达和长尾说法——这个键盘我不想要了匹配不到任何关键词会漏到兜底 Agent。所以规则路由适合两类场景强约束的业务入口如工单类型、菜单选项和作为快速通道的预处理层先拦截 80% 的典型请求剩下的交给语义路由。不要指望纯规则解决一切它只是地基。四、路由方案二基于 LLM 的语义路由当用户表达千变万化时就要让大模型来做意图理解。语义路由Semantic Routing的核心思路把候选 Agent 的技能描述和用户请求一起交给 LLM让它输出应该路由到的 Agent 编号。4.1 零样本路由让模型直接选from openai import OpenAI client OpenAI(base_urlhttps://api.deepseek.com, api_keyyour-key) AGENT_REGISTRY { order_agent: 处理下单、库存查询、价格咨询、商品购买流程, after_sale_agent: 处理退款、退货、换货、赔偿、投诉与售后问题, logistics_agent: 查询物流轨迹、配送时间、签收与地址变更, pre_sale_agent: 商品推荐、型号对比、参数解读、购买建议, general_agent: 其他所有不在上述范围内的通用问题, } def semantic_route(message: str, history: list None) - str: registry_text \n.join( f{aid}: {desc} for aid, desc in AGENT_REGISTRY.items() ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: ( 你是任务路由器。根据用户请求从下面的 Agent 列表中选择最合适的 Agent。 f只输出 Agent 名称不要任何解释。\n\n{registry_text} )}, {role: user, content: message}, ], temperature0, max_tokens10, ) return resp.choices[0].message.content.strip() print(semantic_route(我昨天买的键盘想退了)) # after_sale_agent print(semantic_route(这个键盘我不太想要了)) # after_sale_agent模糊表达也能命中关键细节temperature0保证路由结果稳定max_tokens10限制输出防止模型话痨系统提示词里只放技能描述而不放完整 Prompt既省 Token 又避免把 Agent 的内部指令泄露给路由层。4.2 少样本路由用例子校准边界零样本在边界模糊的请求上容易翻车比如这个键盘和那个机械键盘有什么区别——既像售前对比又像参数解读。此时可以给路由模型几个经典的判断题示例few-shot把边界校准清楚FEW_SHOT_EXAMPLES [ (键盘和鼠标哪个适合办公, pre_sale_agent), (我买错了想换个颜色, after_sale_agent), (能推荐一款 500 以内的机械键盘吗, pre_sale_agent), (退款多久能到账, after_sale_agent), ] def semantic_route_fs(message: str) - str: messages [ {role: system, content: 你是任务路由器根据示例风格选择 Agent只输出 Agent 名。}, ] for q, a in FEW_SHOT_EXAMPLES: messages.append({role: user, content: q}) messages.append({role: assistant, content: a}) messages.append({role: user, content: message}) # ... 调用模型返回 agent 名少样本示例的选择有讲究要选最容易被混淆的边界案例而不是随便挑几个常见问题。示例越多不一定越好——超过 8 个示例后收益递减还会拖慢首 Token 延迟。4.3 语义路由的性能指标语义路由不是能跑就行要量化。三个关键指标路由准确率Routing Accuracy路由到正确 Agent 的比例。用标注好的测试集评估目标 ≥ 95%。路由延迟Routing Latency路由本身消耗的时间。DeepSeek 推理通常 200-500ms对客服场景可接受但对高频内部调用要考虑缓存。兜底率Fallback Rate被抛给 general_agent 的比例。太高说明路由不自信太低说明在乱分。建议上线前用真实历史对话标注 500-1000 条测试集把这三个指标固化下来每次调整路由策略都跑一遍回归。五、路由方案三混合路由——先规则拦截再语义精分纯规则太死板纯语义太慢太贵。生产环境的最优解往往是混合路由Hybrid Routing用规则层做第一道快速过滤语义层只处理规则层拿不准的请求。def hybrid_route(message: str, history: list None) - str: # 第一层规则快速通道0 成本毫秒级 rule_result rule_route(message) if rule_result ! general_agent: return rule_result # 第二层业务字段强制路由例如用户正在处理的工单类型 if history and history.get(active_ticket_type) refund: return after_sale_agent # 第三层语义路由兜底只有规则拿不准才调用 LLM return semantic_route(message) # 触发语义路由的请求量通常只占全部请求的 20-30%这个架构的价值在于成本杠杆假设每天 10 万请求规则层命中 70%只有 3 万个请求需要走 LLM 路由。按每请求 300 Token 计算一天能省下约 2100 万 Token 的推理开销同时把平均路由延迟从 300ms 压到 30ms 以内。混合路由的工程细节规则层要偏保守宁可少拦截不要误拦截。误拦截的代价是用户被送错 Agent比多花一次 LLM 调用贵得多。语义层要带兜底LLM 输出不在注册表内时必须回退到 general_agent不能抛异常。日志要可回放每次路由决策都记录(输入, 规则命中, 语义输出, 最终路由)便于离线分析路由错误。六、负载均衡请求很多时怎么派才不挤路由解决了派给谁负载均衡解决怎么派才不挤。多 Agent 系统里每个 Agent 背后可能挂着不同的后端资源不同的模型实例、不同的知识库、不同的 API 限流配额负载情况千差万别。经典策略有四种6.1 轮询Round Robin请求按顺序轮流分给各个 Agent 实例简单公平但不感知实际负载——某个实例卡住了照样往里塞请求。import itertools class RoundRobin: def __init__(self, agents): self.pool itertools.cycle(agents) def pick(self): return next(self.pool)6.2 最少连接Least Connections记录每个 Agent 当前的在途请求数永远选最闲的那个。适合处理时长差异大的场景——有的请求 1 秒有的 30 秒轮询会导致慢请求堆积。class LeastConnections: def __init__(self, agents): self.inflight {a: 0 for a in agents} def pick(self): agent min(self.inflight, keyself.inflight.get) self.inflight[agent] 1 return agent def release(self, agent): self.inflight[agent] - 16.3 加权轮询Weighted Round Robin给不同 Agent 配权重——性能强的、配额多的多分一些。适合异构实例场景同一个订单 Agent 部署了 3 个实例权重各不同。实现上可以用权重计数递减的经典算法保证在多次调用中按权重比例均匀分发import heapq class WeightedRoundRobin: def __init__(self, agents_with_weights): # agents_with_weights: [(agent_id, weight), ...] self.items [(0, i, aid, w) for i, (aid, w) in enumerate(agents_with_weights)] heapq.heapify(self.items) self.n len(self.items) def pick(self): # 取出当前累计权重最大的 Agent选择后减去总权重 cur, i, aid, w heapq.heappop(self.items) total sum(x[3] for x in self.items) w heapq.heappush(self.items, (cur total, i, aid, w)) return aid # 订单 Agent 权重 3实例多、性能强售后 2物流 1 rr WeightedRoundRobin([(order, 3), (after_sale, 2), (logistics, 1)]) # 连续 12 次调用order 约 6 次、after_sale 约 4 次、logistics 约 2 次这段代码的核心是让权重大的 Agent 的累计值增长更快从而更频繁地成为最大值——它不依赖随机数行为可复现方便压测和单测。注意权重不是越大越好权重过高会让慢实例收到超出其处理能力的请求反而拖垮整体延迟。6.4 基于反馈的自适应均衡Adaptive最先进也最复杂实时监控每个 Agent 的 P95 延迟、错误率、队列深度动态调整分发权重。比如物流 Agent 的 P95 延迟飙到 5 秒就把它的权重从 1 调低到 0.3让更多请求流向健康实例。生产建议不要一上来就上自适应。先从轮询 最少连接二选一跑起来用监控数据说话确认瓶颈确实在负载分配上再逐步升级策略。七、实战基于 DeepSeek Dify 构建带路由的客服多 Agent 系统理论讲完现在落地。我们基于DeepSeek 推理服务 Dify 工作流引擎构建一个完整的客服多 Agent 系统入口节点负责混合路由四个领域 Agent 各司其职外加一个通用兜底。7.1 总体架构用户消息 │ ▼ ┌─────────────────────────────────────┐ │ Dify 入口工作流路由层 │ │ 1. 规则节点关键词快速通道 │ │ 2. 语义节点DeepSeek 意图路由 │ │ 3. 负载节点检查目标 Agent 负载 │ └──────────────┬──────────────────────┘ │ 路由结果 ┌──────────┼──────────┬───────────┐ ▼ ▼ ▼ ▼ 订单Agent 售后Agent 物流Agent 售前Agent 通用兜底Agent (Dify App) (Dify App) (Dify App) (Dify App) (Dify App)在 Dify 中入口是一个工作流类型应用四个领域 Agent 是四个独立的Agent 类型应用入口通过HTTP 请求节点或代码节点调用它们也可以用 Dify 的 Agent 节点直接嵌套。7.2 入口路由工作流核心节点编排入口工作流按顺序编排四个节点开始节点接收query用户消息和session_history会话历史。代码节点规则路由内置第三节的rule_route函数输出rule_result。条件分支节点若rule_result ! general_agent直接走快速通道输出否则进入语义路由。LLM 节点语义路由调用 DeepSeek系统提示词是 Agent 注册表描述输出semantic_result。代码节点负载检查 兜底检查目标 Agent 的在途连接数超过阈值则降级到通用 Agent或进入排队提示。HTTP 请求节点把query转发给最终选中的 Agent 应用Dify 的 Agent 应用都暴露了对话 API。7.3 负载检查与降级逻辑代码节点def main(query: str, target_agent: str, inflight: dict) - dict: MAX_INFLIGHT { order_agent: 20, after_sale_agent: 15, logistics_agent: 25, pre_sale_agent: 10, } if inflight.get(target_agent, 0) MAX_INFLIGHT.get(target_agent, 10): # 目标 Agent 过载降级到通用 Agent并附加排队提示 return { final_agent: general_agent, notice: 当前该业务线咨询量较大已为您转接通用客服预计等待时间较短。, } return {final_agent: target_agent, notice: }这里用的是最朴素的阈值 降级策略。想更精细可以把inflight换成滑动窗口统计的 QPS或者直接读 Dify 应用监控 API 拿实时延迟数据做自适应均衡。7.4 领域 Agent 的内部配置要点路由只是接住请求接住之后 Agent 自己得接得住。每个领域 Agent 注意三点Prompt 只写本领域职责物流 Agent 的 System Prompt 不要出现你还可以帮用户退款这种越界指令减少误操作。工具按领域挂载订单 Agent 挂订单查询 API、库存 API物流 Agent 挂物流轨迹 API。工具越少幻觉越少。开启记忆但限定范围用 Dify 的会话记忆功能但按本领域会话隔离避免跨领域上下文污染。7.5 完整调用链路示例入口路由确定final_agent后通过 Dify 的对话 API 调用目标 Agentimport requests def call_agent(agent_app_key: str, query: str, user: str, conversation_id: str ): resp requests.post( fhttps://api.dify.ai/v1/chat-messages, headers{Authorization: fBearer {agent_app_key}}, json{ inputs: {}, query: query, response_mode: streaming, user: user, conversation_id: conversation_id, }, ) return resp # 路由层示例调用 final {final_agent: after_sale_agent, notice: } if final[final_agent] after_sale_agent: call_agent(AGENT_KEYS[after_sale], 我昨天买的键盘想退了, user_id)7.6 一个完整的路由决策示例用户发来键盘昨天到的但是空格键有异响能换吗层级判断结果规则层命中换→ 售后关键词直接路由 after_sale_agent ✅负载层售后在途 8/15未过载正常分发 ✅最终售后 Agent 接单处理换货流程再比如你觉得我该买青轴还是红轴——规则层无命中语义层识别为购买建议→ pre_sale_agent负载检查通过后分发。两个例子一条链路路由与负载均衡协同工作。八、监控与调优路由系统上线后怎么持续优化路由系统上线不是终点是起点。三个必须盯的观测面8.1 路由质量监控错误路由率用户被路由到 A但实际是 B 的职责通过用户转人工/差评/二次转发间接推断。每周抽样本人工复核。兜底率持续偏高40%说明语义层置信度不够需要补充少样本示例或增强技能描述。平均路由延迟P50/P95 都要看。语义路由延迟异常时检查是否出现长尾输入超长消息被原样送入路由。8.2 负载均衡监控各 Agent 在途请求数长期接近阈值上限的 Agent 需要扩容或提权。P95 响应延迟按 Agent 维度拆分找出慢实例。排队/降级率降级率过高说明负载均衡策略太粗糙考虑升级到自适应策略。8.3 迭代节奏建议按周为单位迭代每周从生产日志抽 100 条路由决策做人工标注 → 修正规则表 → 补充 few-shot 示例 → 回归路由准确率 → 灰度发布。小步快跑路由系统会越用越准。九、总结与下期预告本文完成了多 Agent 系统任务调度的完整拼图路由三方案规则路由快而稳、语义路由准而活、混合路由生产首选负载均衡四策略轮询、最少连接、加权轮询、自适应均衡落地要点入口工作流编排、负载阈值降级、领域 Agent 职责收敛、路由质量监控闭环。一句话记住本文路由管方向负载管节奏监控管体检三者缺一不可。回顾开头的场景500 个用户同时涌进来混合路由用规则层秒级分流了 70% 的典型请求语义层在 300ms 内处理剩下的模糊表达负载层把过载业务线的请求平滑降级到兜底 Agent——没有一单丢失没有一次明显卡顿。这就是每个请求都被最合适的智能体接住的工程含义。下一期我们聊聊多 Agent 系统的工具权限与安全沙箱——当 Agent 开始调用真实 API、读写真实数据时怎么保证它有能力但不越权。 延伸阅读如果你对 DeepSeek 的实战用法感兴趣推荐阅读我的另一篇文章 DeepSeek 实战指南提示词工程、API 集成与效率提升全攻略这篇文章系统地拆解了 DeepSeek 的提示词工程技巧、API 封装方法以及日常效率提升场景全文代码可直接运行适合已经上手 DeepSeek 但希望更高效使用的开发者。Dify 多 Agent 实战系列- Dify 多 Agent 记忆架构实战让智能体记得住、想得起、用得上- Dify 多 Agent 安全边界与权限治理实战让每一个智能体都知道边界、守得住门- Dify 多 Agent 上下文工程实战让智能体记住该记住的忘掉该忘掉的- Dify 多 Agent 故障演练实战用混沌工程主动搞破坏让智能体系统越炸越稳- Dify 多 Agent 灰度发布实战让每一次变更都小步快跑、随时可回滚- Dify 多 Agent 评测实战用 DeepSeek-R1 当裁判打造多智能体系统的自动化质量保障体系本文是华为云FlexusDeepSeek征文系列文章之一。该系列基于华为云 Flexus 云服务器与 MaaS 平台 DeepSeek 推理服务结合 Dify 工作流引擎从部署、Agent 开发、评测、成本治理、稳定性建设、安全治理、记忆架构到任务路由系统拆解企业级 AI 应用的工程实践。