《Agentic Design Patterns》第 2 章导读路由Routing本文是对开源书籍《Agentic Design Patterns》第 2 章的解读与导读内容忠实呈现原文并附个人思考。原书在线阅读https://adp.xindoo.xyz/ 翻译项目代码仓库https://github.com/xindoo/agentic-design-patterns上一篇我们聊了第 1 章的提示词链——它解决的是线性、有依赖的确定性任务流。但现实世界远没有那么规整智能体经常会遇到**需要看情况决定下一步怎么做**的场景。用户问的问题五花八门有时是查订单、有时问产品、有时要技术支援、有时干脆没说清楚——这些根本没法用一条固定的流水线走到底。这正是第 2 章**路由Routing**模式要解决的问题让智能体能根据输入内容和当前状态动态决定把流程引向哪个专门工具、函数或子流程。一、什么是路由从固定路径到动态仲裁路由把条件逻辑引入智能体的运行框架让系统从固定的执行路径变成动态评估标准、从一组可能动作中做选择。它让系统变得更灵活、更有上下文感知能力。书里用一个客服智能体的例子讲得很清楚带路由能力的智能体拿到用户查询后会先对查询分类、判断意图然后据此分流分析用户的查询基于其意图路由查询意图是检查订单状态 → 路由到与订单数据库交互的子智能体或工具链意图是产品信息 → 路由到搜索产品目录的子智能体或链条意图是技术支持 → 路由到访问故障排除指南的链条或升级到人工意图不清楚 → 路由到澄清子智能体或提示词链。你看这里没有一刀切的回复路径而是像路由器一样把不同的请求分发给不同的出口。二、路由的四条实现思路路由模式的核心组件是做评估、指方向的那套机制。书中给出了四种主流实现方式各有取舍实现方式原理特点基于 LLM 的路由让语言模型分析输入输出一个指示目的地的标识符如订单状态/产品信息/技术支持/其他灵活、能理解复杂语义有推理成本基于嵌入的路由把输入转成向量嵌入与各路由的嵌入比较相似度路由到最相似的那个适合语义路由决策依据是含义而非关键词基于规则的路由用关键词、模式、结构化数据配合 if-else / switch 判断快、确定性高但对细微或新颖输入缺乏灵活性基于机器学习模型的路由训练一个判别式分类器把路由逻辑编码进模型权重是监督微调出来的专门组件注意它与基于 LLM 的路由不同——它不在推理时跑提示词这里有个容易混淆的点值得留意基于 ML 模型的路由和基于 LLM 的路由不是一回事。前者是微调出来的一个判别分类器路由逻辑固化在权重里后者是推理时用生成式模型跑提示词来输出决策。虽然可以从 LLM 生成合成数据来增强前者的训练集但两者的决策主体完全不同。另外路由机制并不是只能放在最前面。书里强调它可以在操作周期的多个节点实现——可以在开始给主任务分类、可以在处理链中间决定后续动作、也可以在子程序期间从一组工具里挑选最合适的一个。三、应用场景人机交互虚拟助手、AI 导师先解析自然语言意图决定是调信息检索工具、升级到人工、还是切换到课程下一个模块——突破线性对话做上下文响应。自动化数据/文档管道把邮件、支持工单、API 载荷按内容/元数据/格式分类分发到销售线索、数据转换、升级等不同工作流。多工具/多智能体系统充当高级调度器。比如一个由搜索、总结、分析等不同智能体组成的研究系统用路由器按当前目标分派任务AI 编码助手也用路由来识别编程语言和意图调试/解释/翻译再把代码片段交给对的工具。一句话总结它的作用路由把智能体从预定义序列的静态执行器升级成能在变化条件下决策最有效方式的动态系统。四、代码实战一用 LangChainLangGraph 风格实现路由书中给出两种实现。第一种用 LangChain 的RunnableBranch搭建一个协调器 三个模拟子智能体的结构按意图booker / info / unclear分发请求。pipinstalllangchain langgraph google-cloud-aiplatform langchain-google-genai google-adk deprecated pydantic## Copyright (c) 2025 Marco Fago## 此代码根据 MIT 许可证授权。fromlangchain_google_genaiimportChatGoogleGenerativeAIfromlangchain_core.promptsimportChatPromptTemplatefromlangchain_core.output_parsersimportStrOutputParserfromlangchain_core.runnablesimportRunnablePassthrough,RunnableBranch llmChatGoogleGenerativeAI(modelgemini-2.5-flash,temperature0)## --- 定义模拟子智能体处理程序 ---defbooking_handler(request:str)-str:returnf预订处理程序处理了请求{request}。结果模拟预订操作。definfo_handler(request:str)-str:returnf信息处理程序处理了请求{request}。结果模拟信息检索。defunclear_handler(request:str)-str:returnf协调器无法委托请求{request}。请澄清。## --- 定义协调器路由链判断委托给谁---coordinator_router_promptChatPromptTemplate.from_messages([(system,分析用户的请求并确定哪个专家处理程序应处理它。 - 如果请求与预订航班或酒店相关输出 booker。 - 对于所有其他一般信息问题输出 info。 - 如果请求不清楚或不适合任一类别输出 unclear。 只输出一个词booker、info 或 unclear。),(user,{request})])coordinator_router_chaincoordinator_router_prompt|llm|StrOutputParser()## --- 定义委托逻辑 ---branches{booker:RunnablePassthrough.assign(outputlambdax:booking_handler(x[request][request])),info:RunnablePassthrough.assign(outputlambdax:info_handler(x[request][request])),unclear:RunnablePassthrough.assign(outputlambdax:unclear_handler(x[request][request])),}delegation_branchRunnableBranch((lambdax:x[decision].strip()booker,branches[booker]),(lambdax:x[decision].strip()info,branches[info]),branches[unclear]# 默认分支)coordinator_agent{decision:coordinator_router_chain,request:RunnablePassthrough()}|delegation_branch|(lambdax:x[output])## --- 示例用法 ---defmain():print(--- 运行预订请求 ---)print(coordinator_agent.invoke({request:给我预订去伦敦的航班。}))print(\n--- 运行信息请求 ---)print(coordinator_agent.invoke({request:意大利的首都是什么}))print(\n--- 运行不清楚的请求 ---)print(coordinator_agent.invoke({request:告诉我关于量子物理学的事。}))main()这套代码的逻辑coordinator_router_chain先用提示词让 LLM 把请求分类成 booker / info / unclear 三者之一RunnableBranch拿到 LLM 的决策后把原始请求交给对应的 handler。整个coordinator_agent 先路由出决策 → 再把请求分发给选中的处理程序 → 抽出最终输出。它模仿了多智能体框架里中央协调器按意图把任务委托给专门智能体的基本模式。五、代码实战二用 Google ADK 实现第二种实现走的是 Google智能体开发工具包ADK的路子。ADK 的哲学和显式计算图不太一样路由通常通过定义一组离散的“工具”来实现选择哪个工具由框架内部逻辑用底层模型去匹配。fromgoogle.adk.agentsimportAgentfromgoogle.adk.runnersimportInMemoryRunnerfromgoogle.adk.toolsimportFunctionTooldefbooking_handler(request:str)-str:returnf已模拟对 {request} 的预订操作。definfo_handler(request:str)-str:returnf对 {request} 的信息请求。结果模拟信息检索。booking_toolFunctionTool(booking_handler)info_toolFunctionTool(info_handler)booking_agentAgent(nameBooker,modelgemini-2.0-flash,description处理所有航班和酒店预订请求。,tools[booking_tool])info_agentAgent(nameInfo,modelgemini-2.0-flash,description提供一般信息并回答用户问题。,tools[info_tool])coordinatorAgent(nameCoordinator,modelgemini-2.0-flash,instruction(# 定义委托指令你是主协调器。你唯一的任务是分析传入的用户请求并将它们委托给适当的专家智能体。不要尝试直接回答用户。\n- 对于任何与预订相关的请求委托给 Booker 智能体。\n- 对于所有其他一般信息问题委托给 Info 智能体。),sub_agents[booking_agent,info_agent]# 子智能体的存在默认启用 LLM 驱动的自动流)runnerInMemoryRunner(coordinator)# 然后通过 runner.run(...) 处理用户的预订/信息请求并提取最终响应关键区别在于ADK 里定义sub_agents后委托自动由自动流机制驱动不需要像 LangChain 那样手写分支逻辑。这种开箱即用的委托对明确定义了离散操作集的系统更简单而 LangGraph 的图结构则更适合路由逻辑本身就很复杂的场景。六、速览问题背景智能体要频繁响应各种输入和情况单一线性流程应付不来。没有选择正确工具/子流程的机制系统就僵化、无自适应能力。解决方案通过把条件逻辑引入运行框架让系统先分析查询意图再动态把控制流导向最合适的专门工具/函数/子智能体决策可由 LLM、预定义规则或嵌入相似性驱动。实践建议当智能体必须根据用户输入或当前状态、在多个不同工作流/工具/子智能体之间做决策时使用路由模式。典型如客服机器人区分销售、技术支持与账户管理问题。可视化总结图 1路由模式——使用 LLM 作为路由器把输入分派给不同的专门处理流程。关键要点路由让智能体能根据条件动态决定工作流的下一步它突破线性执行让系统能处理多样输入并自适应调整行为路由逻辑可用 LLM、规则系统或嵌入相似度实现LangGraph、Google ADK 等框架用不同架构为路由提供了结构化实现方式。结语与个人思考如果说提示词链解决的是怎么把一件事按顺序做好那么路由解决的就是面对一件不确定的事该先往哪条路走。两者通常会在一个真实系统里配合使用先路由定方向再用链条把选定的子流程做扎实。整套书的主线其实就是这样一层层叠加的——单看每个模式都不复杂难的是把它们合理地编排进一个系统。值得留意的工程取舍LLM 路由 vs 规则路由规则路由快且确定性强但碰到没学过的说法就抓瞎LLM 路由灵活但每多一次推理就多一份延迟与成本。实践中常做成规则兜底 LLM 兜语义的组合。注意路由外溢LLM 是概率模型分类偶尔会飘。工程上要给分类不确定留后路比如unclear分支、重试、置信度阈值这正是书里那个如果意图不清楚→路由到澄清子智能体的用意。下一步建议阅读第 3 章并行化Parallelization——当多个子任务互不依赖时如何让它们同时跑以提升性能和路由/链条形成完整的工作流三件套。本文基于开源书籍《Agentic Design Patterns》https://github.com/xindoo/agentic-design-patterns 在线阅读 https://adp.xindoo.xyz/ 整理供学习交流版权归原作者所有。