企业官网建设流程全解析

erp生产管理系统,wordpress seo优化插件,wordpress网頁,手机建站系统源码本文详细介绍了使用LangGraph框架实现多智能体协作的实践案例#xff0c;通过状态图管理四个智能体节点和条件边#xff0c;利用MemorySaver实现上下文记忆#xff0c;构建支持多轮对话的高考信息查询助手#xff0c;并与AgentScope框架进行了对比分析#xff0c;展示了La…本文详细介绍了使用LangGraph框架实现多智能体协作的实践案例通过状态图管理四个智能体节点和条件边利用MemorySaver实现上下文记忆构建支持多轮对话的高考信息查询助手并与AgentScope框架进行了对比分析展示了LangGraph在大模型应用开发中的优势。本文基于同样的业务场景和案例采用LangGraph框架进行对比实践和验证以便更深入地理解。 多智能体协作实现逻辑首先回顾一下业务场景和上篇文章保持一致还是支撑用户进行高考信息查询并且要支持多轮对话后续会基于以下案例来进行验证第一轮提问2016年考生人数有多少第二轮追问年份2018年呢第三轮追问其他录取人数呢针对该业务场景四个智能体之间的协作逻辑和AgentScope案例也完全保持一致1用户输入问题2TemplateAgent判断是否有上下文历史如果没有则转4有则进一步匹配历史问题模板如未匹配到则转3如匹配到则基于模板SQL从用户当前问题中提取查询参数植入模板SQL执行后带查询结果转53有上下文历史但没有匹配的历史问题则进入意图识别改写RewriteAgent利用上下文对话背景对用户当前问题做改写然后进入SQLAgentRAG检索元数据、生成SQL、查询数据最后进入AnalysisAgent分析回答4无上下文历史代表用户是首次提问则直接进入SQLAgentRAG检索元数据、生成SQL、查询数据最后进入AnalysisAgent分析回答5根据查询结果直接进入AnalysisAgent分析回答这个协作逻辑基于 LangGraph框架的自定义状态图StataGraph实现# # 路由函数# def route_to_next_agent(state: State) - Literal[sql, analysis, rewrite, __end__]: if state.get(next_agent) sql: return sql if state.get(next_agent) analysis: return analysis if state.get(next_agent) rewrite: return rewrite return __end__ workflow StateGraph(State)workflow.add_node(template, template_agent)workflow.add_node(rewrite, rewrite_agent) # 新增改写智能体workflow.add_node(sql, sql_agent)workflow.add_node(analysis, analysis_agent)workflow.add_edge(START, template)# Template 之后根据条件流向workflow.add_conditional_edges( template, route_to_next_agent, { rewrite: rewrite, # 新增 rewrite 分支 sql: sql, analysis: analysis, __end__: END })# 改写智能体完成后交给 SQLworkflow.add_edge(rewrite, sql)# SQL 执行后流向分析workflow.add_edge(sql, analysis)workflow.add_edge(analysis, END)# # ▶️ 主流程# if __name__ __main__: from uuid import uuid4 print( 智能数据助手支持追问、多轮上下文) print( *80) print( 输入问题开始对话输入 exit 退出。) print( *80) # 每次启动生成唯一 thread_id上下文记忆关键 thread_id str(uuid4()) config {configurable: {thread_id: thread_id}} while True: user_input input(\n 你: ).strip() if not user_input: continue if user_input.lower() in {exit, quit}: print( 再见会话已结束。) break # 构造输入 input_data { messages: [HumanMessage(contentuser_input)], } try: # 流式执行 for chunk in app.stream(input_data, configconfig): if analysis in chunk: msg chunk[analysis][messages][0] print(f 助手: {msg.content.strip()}) print(- *60) elif sql in chunk and messages in chunk[sql]: # SQL 生成失败的情况 for m in chunk[sql][messages]: if isinstance(m, AIMessage): print(f 助手: {m.content.strip()}) print(- *60) elif __end__ in chunk: print(✅ 对话结束) except json.JSONDecodeError: print(⚠️ JSON 解析失败可能是 LLM 返回了非结构化内容。) except KeyboardInterrupt: print(\n⏹️ 中断。输入 exit 可退出。) except Exception as e: print(f 出错{e})如以上代码所示通过“workflow.add_node”方式添加四个Node节点template、rewrite、sql、analysis分别代表四个智能体。通过“workflow.add_edge”方式添加对应节点之间的跳转关系其中“workflow.add_conditional_edges”是添加条件边通过调用route_to_next_agent()路由函数根据智能体返回的next_agent字段决定流转到哪一个节点。多轮对话之上下文记忆和状态机LangGraph上下文记忆的相关机制主要通过官方提供的 MemorySaver() 实现# 启用记忆支持多轮对话memory MemorySaver()app workflow.compile(checkpointermemory)MemorySaver会将每一个节点执行后的 State 存储到检查点checkpoint中使得下一次调用可以从之前的对话状态继续执行。其特点是原样存 储state状态机不裁剪、不删减、不合并历史真正关键的是你在 State 状态机中设计的业务逻辑。使用“ StateGraph(State)”方式在状态图StateGraph初始化时就将自定义State状态机对象注入并绑定# # 增强状态定义# class State(TypedDict): messages: Annotated[list[BaseMessage], add_messages] original_intent: Optional[str] # 如 考生人数 known_table_struct: Optional[List] # 已确认的表结构 last_sql_template: Optional[str] # 带占位符的 SQL 模板如 SELECT ... WHERE year {year} query_result: Optional[list] # 最近一次查询结果 next_agent: str每轮对话都会在全局统一状态机中保存以下信息key含义messages历史消息列表original_intent用户的核心意图如“考生人数”known_table_struct已识别的数据表结构last_sql_template参数化 SQL 模板便于复用query_result查询结果next_agent下一步路由方向其中当我们使用 Annotated[list[BaseMessage], add_messages] 来定义 State 中的 messages 字段时新的消息会自动被追加到现有的消息列表之后这是 LangGraph 为管理对话历史等序列化数据提供的一种便捷且强大的状态更新机制。LangGraph所有智能体Agent都要遵循统一规范将Stata对象作为输入输出对象如以下“模板匹配智能体”templateAgent的代码所示# # 模板匹配 智能体支持追问模板复用# def template_agent(state: State): print( Template Agent ) current_query state[messages][-1].content # ─────────────────────────────────────── # 情况1无上下文 → SQL Agent # ─────────────────────────────────────── if (not state.get(known_table_struct) or not state.get(original_intent) or not state.get(last_sql_template)): print(⚠️ 不存在上下文进入SQL Agent流程) return { messages: state[messages], next_agent: sql } # ─────────────────────────────────────── # 情况2已有上下文 → 尝试参数化追问处理 # ─────────────────────────────────────── print( 检测到历史上下文尝试参数化追问) try: # 具体业务代码跳过 plaintext print(f✅ 追问查询成功进入分析流程) return { query_result: result, next_agent: analysis } plaintext except Exception as e: print(f参数提取失败: {e}) print(⚠️ 追问处理失败进入改写流程) return { messages: state[messages], next_agent: rewrite }案例测试结果我们测试一下LangGraph实现多智能体协作的效果 智能数据助手支持追问、多轮上下文 输入问题开始对话输入 exit 退出。 你: 2016年考生人数有多少 Template Agent ⚠️ 不存在上下文进入SQL Agent流程 Sql Agent 启动完整查询流程调用大模型llama2向量化2016年考生人数有多少 匹配表结构: [{表名: college_entrance_examination, 表备注: 考生人数与复读人数信息表包含字段高考年份(主键)、考生人数(万人)、复读人数(万人), 字段列表: [{字段名: examination_year, 字段类型: int, 字段备注: 高考年份}, {字段名: candidates_count, 字段类型: decimal(10,2), 字段备注: 考生人数(万人)}, {字段名: retake_count, 字段类型: decimal(10,2), 字段备注: 复读人数(万人)}]}] 原始意图: 2016年考生人数有多少 保存 SQL 模板: SELECT candidates_count AS 考生人数 FROM college_entrance_examination WHERE examination_year {year}; Analysis Agent 助手: **2016年高考考生人数分析报告** **事实陈述** 2016年高考考生人数为 **940.00万人**数据来源考生人数与复读人数信息表。**简要洞察** 当前数据仅包含单一时间点的记录暂无法直接推导趋势变化。若需分析考生人数增减规律建议结合相邻年份数据如2015年及2017年进行对比。**备注** 数据单位为“万人”数值保留两位小数统计口径可能包含应届生与复读生。如需进一步解读可补充复读人数或分省数据辅助分析。--- 报告基于提供的数据生成内容简洁客观避免过度推测。------------------------------------------------------------ 你: 2018年呢 Template Agent 检测到历史上下文尝试参数化追问 提取参数: {year: 2018}️ 生成新 SQL: SELECT candidates_count AS 考生人数 FROM college_entrance_examination WHERE examination_year 2018;✅ 追问查询成功返回 1 行 Analysis Agent 助手: **2016年高考考生人数分析报告** **事实陈述** 2016年高考考生人数为 **975.0万人**数据来源考生人数与复读人数信息表。**简要洞察** 1. 当前数据仅包含单一时间点的记录暂无法分析趋势变化。若需观察考生人数增减趋势建议补充相邻年份数据如2015年及2017年数据。 2. 表中还包含“复读人数”字段若需进一步分析复读对考生总数的影响可提供对应数据后补充说明。**备注** 数据单位为“万人”实际考生人数为9,750,000人。如需更深入的统计分析如增长率、区域对比等请提供扩展数据集。--- **报告说明**本报告基于提供的数据直接呈现核心结论避免对单一数据点进行推测性解读。------------------------------------------------------------ 你: 录取人数呢 Template Agent 检测到历史上下文尝试参数化追问 提取参数: {}⚠️ 年份参数提取失败进入改写流程 Rewrite Agent ✍️ 改写后问题: 2018年全国高考录取人数是多少 Sql Agent 启动完整查询流程调用大模型llama2向量化2018年全国高考录取人数是多少 匹配表结构: [{表名: college_entrance_admission, 表备注: 录取人数与普通高校数信息表包含字段录取年份(主键)、录取人数(万人)、招生高校数、本科录取人数(万人)、专科录取人数(万人), 字段列表: [{字段名: admission_year, 字段类型: int, 字段备注: 录取年份}, {字段名: admission_count, 字段类型: decimal(10,2), 字段备注: 录取人数(万人)}, {字段名: university_count, 字段类型: int, 字段备注: 招生高校数}, {字段名: undergraduate_admission_count, 字段类型: decimal(10,2), 字段备注: 本科录取人数(万人)}, {字段名: specialty_admission_count, 字段类型: decimal(10,2), 字段备注: 专科录取人数(万人)}]}] 原始意图: 2018年全国高考录取人数是多少 保存 SQL 模板: SELECT admission_count AS 考生人数 FROM college_entrance_admission WHERE admission_year {year}; Analysis Agent 助手: **2018年全国高考录取人数分析报告** **事实陈述** 根据数据表 college_entrance_admission 记录**2018年全国高考录取人数为 790.99 万人**。**简要洞察** 1. **数据背景**该数据反映当年普通高校含本科及专科录取总规模但未提供与考生人数、录取率的对比信息。 2. **趋势参考**若结合近年数据需补充可进一步分析录取人数变化趋势当前单一数据点建议谨慎用于预测。 3. **结构细化**表中包含本科与专科分层数据字段未在本次结果中体现后续可针对学历层次结构进行深入分析。**注意事项** - 当前数据为单一数值分析需避免过度推论。 - 如需评估录取竞争程度需补充同年高考报名人数或招生计划数据。--- **报告说明**本分析基于提供的数据表结构及查询结果确保表述与原始数据一致。------------------------------------------------------------ 你:第一轮问题2016年考生人数有多少第一轮没有上下文也没有全局变量模板所以直接走SQL Agent Analysis AgentRAG检索、生成SQL、查数、分析。同时SQL Agent生成成功后记录SQL模板到全局state。第二轮问题2018年呢第二轮我们追问2018年这时存在全局变量模板所以走模板匹配提取年份参数直接查数然后通过业务判断存在数据走Analysis Agent分析。第三轮问题录取人数呢第三轮我们追问录取人数但是匹配不到模板所以上层业务判断走Rewrite Agent SQL Agent Analysis Agent改写问题完善条件。改写时参考Memory中上下文2016和2018年回答改写为2018年全国高考录取人数是多少然后走RAG检索、生成SQL、查数、分析。LangGraph实现小结本文使用LangGraph的Custom图模式实现我们的多智能体协作处理业务通过StataGraph状态图来管理Node节点对应智能体Agentedge边对应执行路径通过Checkpoint Memory实现长时记忆管理上下文和结构化参数消息、SQL 模板、表结构、查询结果等所有agent都要遵循一定规范将状态机作为输入和输出。相对来说上一篇文章中介绍AgentScope框架更松散其多Agent协作机制是通过自定义控制逻辑管道pipeline来串联通过框架提供的memory只能管理多轮对话的上下文多智能体多轮次之间的参数传递需要通过自定义全局变量来实现。附录LangGraph几种典型协作模式LangGraph 是基于LangChain生态构建它强调「状态图StateGraph」和「可追溯记忆Checkpoint Memory」它提出了几种Multi-Agent模式适用于不同的调用逻辑和控制流需求网络Network模式各Agent节点彼此多对多通信每个Agent有权限决定接下来调用哪个其他Agent。适用于“没有固定顺序”“较灵活的调用关系”的场景。代码示例中Agent agent_1、agent_2、agent_3 均可跳转至其他两个或结束。主管Supervisor模式一个“主管Agent”负责决定下一步调用哪个子Agent。子Agent执行后再回到主管。适用于“中央调度控制”“明确谁来决定流程”的场景。示例supervisor 决定调用 agent_1 或 agent_2。主管Supervisor as Tools 工具调用模式是“主管”模式的一个特例子Agent被暴露为“工具”tool主管Agent像工具调用系统一样决定调用哪个工具子Agent。典型流程主管以 ReAct 思考→行动→思考方式循环调用工具直到决策结束。提供了 create_react_agent 等预置组件。分层Hierarchical模式当Agent数量增多、流程更复杂时用“主管的主管”来管理团队子系统形成层级结构。每个团队内有自己的主管子Agent再由顶层主管决定调用哪个团队。适合更大规模、跨领域、多团队协作的系统。自定义Custom Workflow模式对应本文案例你也可以手动定义Agent节点及其顺序显式控制流或部分由 LLM 决定动态控制流。显式控制流在图中预先定义边 agent_1 → agent_2 → agent_3。适合需要「强控制流」「复杂状态管理」「上下文复用」的场景。​最后我在一线科技企业深耕十二载见证过太多因技术更迭而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我整理出这套 AI 大模型突围资料包✅AI大模型学习路线图✅Agent行业报告✅100集大模型视频教程✅大模型书籍PDF✅DeepSeek教程✅AI产品经理入门资料完整的大模型学习和面试资料已经上传带到CSDN的官方了有需要的朋友可以扫描下方二维码免费领取【保证100%免费】​​为什么说现在普通人就业/升职加薪的首选是AI大模型人工智能技术的爆发式增长正以不可逆转之势重塑就业市场版图。从DeepSeek等国产大模型引发的科技圈热议到全国两会关于AI产业发展的政策聚焦再到招聘会上排起的长队AI的热度已从技术领域渗透到就业市场的每一个角落。智联招聘的最新数据给出了最直观的印证2025年2月AI领域求职人数同比增幅突破200%远超其他行业平均水平整个人工智能行业的求职增速达到33.4%位居各行业榜首其中人工智能工程师岗位的求职热度更是飙升69.6%。AI产业的快速扩张也让人才供需矛盾愈发突出。麦肯锡报告明确预测到2030年中国AI专业人才需求将达600万人人才缺口可能高达400万人这一缺口不仅存在于核心技术领域更蔓延至产业应用的各个环节。​​资料包有什么①从入门到精通的全套视频教程⑤⑥包含提示词工程、RAG、Agent等技术点② AI大模型学习路线图还有视频解说全过程AI大模型学习路线③学习电子书籍和技术文档市面上的大模型书籍确实太多了这些是我精选出来的④各大厂大模型面试题目详解⑤ 这些资料真的有用吗?这份资料由我和鲁为民博士共同整理鲁为民博士先后获得了北京清华大学学士和美国加州理工学院博士学位在包括IEEE Transactions等学术期刊和诸多国际会议上发表了超过50篇学术论文、取得了多项美国和中国发明专利同时还斩获了吴文俊人工智能科学技术奖。目前我正在和鲁博士共同进行人工智能的研究。所有的视频教程由智泊AI老师录制且资料与智泊AI共享相互补充。这份学习大礼包应该算是现在最全面的大模型学习资料了。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。智泊AI始终秉持着“让每个人平等享受到优质教育资源”的育人理念‌通过动态追踪大模型开发、数据标注伦理等前沿技术趋势‌构建起前沿课程智能实训精准就业的高效培养体系。课堂上不光教理论还带着学员做了十多个真实项目。学员要亲自上手搞数据清洗、模型调优这些硬核操作把课本知识变成真本事‌​​​​如果说你是以下人群中的其中一类都可以来智泊AI学习人工智能找到高薪工作一次小小的“投资”换来的是终身受益应届毕业生‌无工作经验但想要系统学习AI大模型技术期待通过实战项目掌握核心技术。零基础转型‌非技术背景但关注AI应用场景计划通过低代码工具实现“AI行业”跨界‌。业务赋能 ‌突破瓶颈传统开发者Java/前端等学习Transformer架构与LangChain框架向AI全栈工程师转型‌。获取方式有需要的小伙伴可以保存图片到wx扫描二v码免费领取【保证100%免费】**​