AI Agent开发实战系列 - LangGraph(8): 构建基于状态路由的动态决策图

1. 动态决策图的核心价值想象一下你正在设计一个智能客服系统。当用户输入我的订单怎么还没到时系统需要自动识别这是物流查询问题然后路由到物流处理模块而当用户说我要投诉产品质量时系统又应该转向售后处理流程。这种根据实时输入动态调整执行路径的能力正是LangGraph条件图的拿手好戏。在LangGraph中add_conditional_edges方法就像交通指挥中心它通过三个关键组件实现智能路由决策函数相当于交警负责查看当前状态并做出判断条件映射表相当于路标指明每种判断结果对应的下一站节点网络相当于城市道路系统包含所有可能的目的地我最近在一个电商客服项目中实际应用了这个方法将用户问题的平均响应时间缩短了40%。关键在于我们设计了一个精准的状态判断机制能够识别7种不同的用户意图类型。2. 构建客服Agent的条件路由系统2.1 定义状态数据结构首先需要明确我们的交通规则依据什么来制定。在客服场景中状态数据应该包含from typing import TypedDict class CustomerServiceState(TypedDict): user_input: str # 原始用户输入 intent: str # 识别出的意图类型 session_id: str # 会话标识 response: str # 生成的响应内容这个结构就像交警手中的检查清单包含了做决策需要的所有信息。我在实际项目中还添加了user_level字段用来实现VIP用户的优先处理这种扩展性正是TypedDict的优势。2.2 创建处理节点接下来构建各个处理站点也就是具体的业务逻辑单元def order_query_handler(state: CustomerServiceState): # 这里是实际的订单查询逻辑 order_info query_database(state[user_input]) state[response] f您的订单状态是{order_info.status} return state def complaint_handler(state: CustomerServiceState): # 投诉处理流程 ticket_id create_support_ticket(state[user_input]) state[response] f已创建工单#{ticket_id}客服将尽快联系您 return state def fallback_handler(state: CustomerServiceState): # 默认回复 state[response] 抱歉我没理解您的问题请换种方式描述 return state每个处理节点都应该保持单一职责原则。我建议为每个业务场景创建独立的节点这样后期维护时会轻松很多。2.3 设计路由决策逻辑这是整个系统的大脑决定了请求的流向def route_based_on_intent(state: CustomerServiceState): user_text state[user_input].lower() if 订单 in user_text or 物流 in user_text: return order_query elif 投诉 in user_text or 质量 in user_text: return complaint elif 人工 in user_text: return human_agent else: return fallback在实际项目中我建议先用简单的关键词匹配快速实现原型再逐步替换为更精准的意图识别模型。这样可以在早期就验证流程的可行性避免一开始就陷入复杂的NLP模型调优。3. 组装完整工作流3.1 构建图结构现在把各个组件像拼积木一样组装起来from langgraph.graph import StateGraph, START, END workflow StateGraph(CustomerServiceState) # 添加所有节点 workflow.add_node(order_query, order_query_handler) workflow.add_node(complaint, complaint_handler) workflow.add_node(human_agent, connect_to_agent) workflow.add_node(fallback, fallback_handler) # 设置入口点 workflow.add_edge(START, intent_router) # 关键步骤添加条件路由 workflow.add_conditional_edges( intent_router, route_based_on_intent, { order_query: order_query, complaint: complaint, human_agent: human_agent, fallback: fallback } ) # 设置出口点 workflow.add_edge(order_query, END) workflow.add_edge(complaint, END) workflow.add_edge(human_agent, END) workflow.add_edge(fallback, END) # 编译成可执行应用 agent workflow.compile()这里有个容易踩坑的地方条件映射表中的键必须与决策函数的返回值完全一致。我曾经因为拼写错误调试了半天建议使用常量来避免这种问题。3.2 测试工作流实际运行一下看看效果# 测试订单查询 result agent.invoke({ user_input: 我的订单123456到哪里了, intent: , session_id: test123, response: }) print(result[response]) # 输出订单状态 # 测试投诉处理 result agent.invoke({ user_input: 我要投诉买到的商品有质量问题, intent: , session_id: test124, response: }) print(result[response]) # 输出工单信息在真实环境中我建议构建一个包含各种案例的测试集确保路由决策覆盖所有边界情况。特别是那些意图模糊的输入比如我的东西有问题这种既可能指物流也可能指质量的表述。4. 高级技巧与优化建议4.1 状态预处理节点在实际项目中我通常会添加一个预处理节点来处理一些通用逻辑def preprocess_state(state: CustomerServiceState): # 敏感信息过滤 state[user_input] filter_sensitive_words(state[user_input]) # 会话上下文整合 if state[session_id] in session_store: state.update(session_store[state[session_id]]) # 基础意图识别 state[intent] detect_intent(state[user_input]) return state # 在图中添加预处理节点 workflow.add_node(preprocessor, preprocess_state) workflow.add_edge(START, preprocessor) workflow.add_edge(preprocessor, intent_router)这样可以使主路由逻辑更清晰也方便后期扩展。比如要新增敏感词过滤功能时只需要修改预处理节点不会影响核心业务流程。4.2 多级路由策略对于复杂的业务场景可以采用分级路由策略def first_level_router(state): if state[user_input].startswith(订单): return order_related else: return other_issues def order_router(state): if 物流 in state[user_input]: return logistics elif 退货 in state[user_input]: return return else: return general_query # 构建多级路由图 workflow.add_conditional_edges( first_router, first_level_router, {order_related: second_router, other_issues: general_support} ) workflow.add_conditional_edges( second_router, order_router, {logistics: logistics, return: return, general_query: order_query} )这种设计就像电话菜单系统先区分大类再细分小类。我在一个银行客服项目中采用这种结构成功将用户问题的一次解决率提高了25%。4.3 可视化调试技巧LangGraph提供了可视化工作流的功能这在调试复杂路由时特别有用from IPython.display import Image # 生成并显示流程图 Image(agent.get_graph().draw_mermaid_png())当路由逻辑出现问题时这张图能帮你快速定位是哪个判断环节出了错。我习惯在文档中保存每个版本的工作流图示这样回溯问题时可以清楚地看到历次变更的影响。