案例思路解析整体思路 -- 五步构建法在正式开始编码之前我们需要先完整梳理出本次综合案例的实现思路。把整体逻辑理顺后后续编码我们就可以按照既定步骤分步执行整个开发过程会更加流畅。同时我们也能清晰把控编码进度明确当前所处的开发阶段、正在实现的子功能模块以及每个功能的依赖关系。先搭建好完整的流程框架和代码实现方案再动手编码能极大降低开发难度。构建LangGraph系统的核心是将流程分解为离散的节点通过共享的状态连接每个节点可读取和写入状态并自主决定后续路径。第一步工作流分解第一步明确项目核心需求与开发目标确定整体工作流的执行逻辑厘清整个程序的输入、输出规则。将流程拆分为独立步骤每个步骤成为一个节点。如有复杂操作可拆分为子图处理。绘制节点间连接关系第二步节点功能识别第二步对整体工作流进行拆解简单业务拆解为独立节点复杂业务则拆分为多个子图。每个子图、每个节点都对应专属的业务任务复杂系统通过子图拆分的方式实现功能的模块化处理我们需要明确主图和各个子图的核心职责。在完成功能拆解前我们需要先吃透本次系统的核心需求。此前我们已经完成了项目需求演示后续拆解环节我们会再次回顾需求细节。总而言之拆解的核心逻辑就是简单业务拆节点复杂业务拆子图。完成子图与节点的初步拆解后我们需要进一步分析每个模块的执行逻辑。明确每个子图需要通过哪些节点实现功能、执行何种流程判断模块是链式顺序执行、并行执行还是条件路由执行精准完成每个节点和子图的功能定位。LLM 节点用于理解、分析、生成文本或推理决策数据节点从外部源检索信息动作节点执行外部操作用户输入节点需要人工干预第三步状态设计功能定位完成后我们进入第三步核心设计工作。首先是全局状态state和上下文的设计这是贯穿整个流程图的核心数据支撑。状态是共享内存所有节点均可访问只存储原始数据不存储格式化文本或提示模板设计原则跨步骤需要持久化的数据才存入状态可从其他数据推导的信息不存储第四步节点实现其次是节点细化设计根据已定位的功能确定每个子图对应的组成节点明确每个节点的具体作用。每个节点是接收状态并返回更新的函数使用Command对象指定状态更新和下一节点错误处理策略瞬时错误网络问题自动重试LLM 可恢复错误将错误存入状态让 LLM 重试用户可修复错误使用interrupt()暂停等待人工输入意外错误抛出供调试第五步连接组装最后一步是节点组装通过配置节点之间的连接边将所有独立节点整合为完整的流程图。添加节点和必要边使用检查点器checkpointer实现持久化支持暂停 / 恢复编译为可执行应用以上五步是搭建所有流程图Line Graph的通用固定流程明确开发目标→拆解功能模块→定位模块功能→设计状态与节点→组装节点完成构图。遵循这个逻辑开发能让整个项目的代码结构清晰、逻辑规整。按功能模块拆分为多图接下来我们回归核心问题明确本次项目的开发目标。我们本次要开发的是对话式AI智能租房助手系统核心包含四大核心能力也是我们整个项目的核心业务模块。第一个核心能力是房源推荐。系统支持两种交互模式一是模糊咨询用户仅提出租房需求AI智能体主动追问用户具体租房偏好二是精准需求咨询用户明确租房要求AI直接匹配对应房源全程为对话式交互体验。第二个核心能力是房源预定。用户可以输入目标房源名称同时填写个人手机号、身份证号等身份信息智能助手接收用户信息后会自动生成预定工单完成房源预定流程。第三个核心能力是个人信息查询。用户可以随时查询自己的历史房源预定记录同时系统会自动记录用户的租房预算等偏好数据支持用户随时调取查看。第四个核心能力是常规智能问答。抛开租房专属业务该AI助手同时具备通用问答能力可响应各类日常普通问题实现基础的人机对话交互。所以根据案例需求房源推荐、房源预定、查询我的、常规问答可以将不同的能力拆分为不同的子图完成。如recommended_graph推荐子图负责进行房源推荐包括查询数据库根据条件推荐合适的房源。reserve_graph预定子图负责房源预定生成工单。extend_graph其它子图负责其它问题处理如常规问答等。除此之外我们还需要一个主图负责路由判定用户请求该路由到哪个子图中去执行具体逻辑处理。主图 -- 智能分流明确四大核心能力后我们来设计整体流程图的实现逻辑。本项目属于对话式AI系统整体输入统一为用户的提问内容整体输出统一为对应问题的标准答案遵循一问一答的对话逻辑。用户的输入问题类型十分多样包括房源推荐咨询、房源预定申请、个人历史信息查询以及各类普通日常问题。但开发中需要严格把控答案的准确性杜绝业务逻辑错乱比如用户咨询房源推荐不能错误路由到房源预定逻辑中处理。为解决路由错乱问题我们需要单独设计一个用户问题识别节点这是整个工作流的首个核心节点。该节点的核心作用是通过大模型能力智能识别用户输入的问题类型将问题精准分类为房源推荐、房源预定、个人信息查询、常规问答四类。节点识别出的问题类型属于临时数据我们会将其存储在全局状态state中后续通过条件边读取state中的问题类型实现业务逻辑的智能路由。不同类型的问题会自动进入对应的业务处理链路房源推荐问题进入推荐链路、房源预定问题进入预定链路、个人查询问题进入查询链路其余所有常规问题统一进入通用问答链路。各个业务链路独立处理对应逻辑处理完成后各自输出对应答案形成完整的一问一答闭环。这种设计从根本上保证了业务处理的精准性避免路由逻辑混乱这就是工作流中经典的路由模式也是我们本次项目代码的核心核心逻辑。确定整体路由逻辑后我们对各业务模块的实现形式进行规划。针对复杂业务我们采用子图的形式封装逻辑子图本质也是独立的流程图拥有专属的输入、输出和状态。本系统的对话交互主要依靠state中可更新、可迭代的消息列表message list实现数据流转。我们对四大业务模块进行拆分规划房源推荐、房源预定业务逻辑复杂需要对接数据库、筛选房源、执行业务校验必须单独封装为子图处理个人信息查询逻辑简单仅需读取state中存储的用户数据可直接作为主图中的独立节点常规问答模块逻辑待定可根据最终代码适配情况选择封装为子图或普通节点。其中房源推荐和房源预定的业务复杂度最高。房源推荐需要对接数据库筛选对应的数据表通过编写筛选逻辑、SQL语句匹配符合用户需求的房源整套流程步骤繁多拆分独立子图能让代码结构更清晰、更易扩展。房源预定同理后续编码我们会逐步细化其内部逻辑。综上项目主图的核心职责非常明确统一识别用户问题实现不同业务的智能路由将不同类型的问题分发到对应的子图或节点中处理。结合下面详细流程图我们进一步完善整体节点设计在原有路由逻辑基础上新增前置和后置核心节点完善全流程逻辑。节点设计如下get_store_info节点查询持久化消息例如用户历史偏好数据。identify_question节点识别用户输入的问题进行智能路由。recommended_graph子图节点路由 1进行房源推荐reserve_graph子图节点路由 2预定房源子图extend_graph子图节点路由 3其它问题处理如常规问答等。get_user_preferences节点路由 4用户查询自己的信息need_reserve节点是否需要预定房源。当推荐房源结束后主动咨询是否需要预定房源。首先是获取持久化信息节点这是整个工作流的首个执行节点。用户发起对话后系统会优先从持久化存储中读取用户的历史对话数据、租房偏好、历史预定记录等信息。这些用户偏好数据会贯穿整个业务流程无论是房源推荐、预定还是信息查询都可以基于历史偏好数据优化回答结果提升交互精准度。同时系统会在每一次工作流执行完成后自动更新、存储用户的最新偏好信息实现数据持久化迭代。读取持久化信息后进入问题识别节点identify question也就是我们之前规划的核心路由节点负责智能分类用户问题完成业务路由分发。路由分发后系统分别调用三大核心子图房源推荐子图、房源预定子图、常规问答子图同时搭配主图内的个人信息查询节点覆盖全部四大业务能力。其次是获取用户偏好信息节点主要服务于个人信息查询业务。系统从持久化存储中读取的用户数据为字典格式而最终需要输出给用户的是字符串格式的自然语言答案。因此该节点的核心作用是将读取到的字典数据与用户的查询问题结合整理、生成通俗易懂的标准化答案。最后是系统的交互式中断判断节点这是本次项目的特色核心能力主要用于房源推荐业务的后续联动。在AI为用户推荐完房源后不会直接结束流程输出答案而是自动触发交互询问“已为您推荐合适的房源是否需要帮您预定房源”该功能依靠工作流的中断机制实现。房源推荐子图执行完成后流程会中断等待用户输入反馈。用户的回复需要/不需要会被存入全局状态state系统通过条件边判断后续流程若用户回复“需要”流程自动进入房源预定子图继续完成预定业务若用户回复“不需要”流程直接终止输出最终回答结束本次对话。简单来说我们通过中断节点条件路由的组合逻辑实现了房源推荐与房源预定的联动交互式体验让整个AI助手的对话流程更智能、更贴合真实服务场景。以上就是本项目主图的完整工作链路。整体开发顺序为先搭建并调试主图整体路由流程保证整体链路通畅再逐一拆解、开发、调试各个子图的内部逻辑所有模块全部开发完成后整合联调最终实现完整的AI智能租房助手功能。下面我们会先详细拆解所有子图的设计逻辑再正式进入编码开发阶段。推荐子图 -- 构建自定义 SQL 代理接下来我们开始讲解第一个子图 —— 房源推荐子图。在设计这个子图、划分内部节点之前我们首先要明确房源推荐模块的核心作用。我们这套系统是对话式 AI 智能助手用户会用自然语言描述租房需求比如指定租房城市、所在区域、房屋户型、期望租金等内容智能系统接收需求后匹配并返回符合条件的房源信息。我们可以对比一下传统租房软件的实现逻辑帮助大家更好理解底层原理。普通的租房软件会在页面上设置筛选栏用户手动选择城市、输入租金预算、勾选其他需求后点击搜索按钮页面就会展示出所有符合筛选条件的房源。而我们的 AI 租房助手虽然交互形式变成了自然语言对话但底层的业务逻辑和传统软件是完全一致的。想要实现房源查询首先离不开数据库的支撑。数据库中会包含多张数据表其中核心使用的是房源表此外还会有用户表等其他业务表。传统后端开发中我们会编写 SQL 语句操作数据库指定要查询的数据表通过where子句拼接各类筛选条件最终数据库就会返回匹配条件的数据。这套通过 SQL 查询数据库的逻辑同样适用于我们基于 LangGraph 搭建的智能系统这也是房源推荐子图的核心底层逻辑。结合这套逻辑我们来一步步设计房源推荐子图的执行流程。整个流程的第一步就是解析用户需求。用户会用一段自然语言表达租房想法我们需要从文本中提取出关键信息比如租房城市、所在区域、租金预算、需要推荐的房源套数等。只有精准提取出这些核心参数后续才能顺利拼接查询条件、构建 SQL 语句。在执行数据库查询前还有一项基础准备工作就是建立数据库连接。这是所有数据库操作的前提具体的连接代码我们会在正式编码环节详细讲解。成功连接数据库后下一步要做获取并筛选数据表。一个数据库内通常存在多张数据表我们首先需要获取库中所有数据表的名称再结合用户的租房需求筛选出当前业务需要使用的数据表也就是房源表。这里的获取表、筛选表功能本质上都属于工具能力。结合之前学过的知识调用工具主要有两种实现方式第一种是将工具绑定到大语言模型上由模型自主判断是否需要调用工具第二种是代码层面手动调用工具。在 LangGraph 的流程图设计中调用工具一般会拆分为两个节点第一个节点负责绑定工具并调用大模型判断是否执行工具第二个节点才是真正执行工具逻辑。本次获取数据表的操作比较简单我们既可以选择手动调用工具也可以沿用 “模型判断 工具执行” 的双节点模式具体实现会参考之前做过的搜索引擎案例。筛选出目标房源表之后我们还需要获取表结构信息。数据表包含哪些字段、字段含义是什么、表内数据样例如何这些信息都必须明确。因为我们后续编写 SQL 语句时字段名称不能出错比如城市、区域、预算对应的数据库字段名都要和表结构保持一致否则 SQL 语句会执行失败。所以这一步是必不可少的。在代码实现上我们会把获取表结构的工具绑定到大模型并且设置强制调用参数。也就是说无论模型如何判断流程走到这里都必须执行该工具确保一定能拿到表结构与字段信息。拿到用户需求参数、目标数据表以及完整表结构后就进入核心环节生成 SQL 语句。我们将提取的筛选条件、数据表名称、合法字段进行整合交由大语言模型自动拼接出完整可执行的 SQL 查询语句。这个节点同样会绑定执行 SQL 的工具但不会设置强制调用因为后续流程存在分支走向。为了提升系统的鲁棒性避免因 SQL 语法错误、查询逻辑问题导致程序报错我们在生成 SQL 语句后新增SQL 语句检查节点。这个节点会对生成的 SQL 做双重校验一是检查语法是否规范关键字、语句格式是否存在错误二是模拟执行 SQL验证语句能否正常查询出数据。该节点也绑定了执行 SQL 的工具并且设置为强制调用只要进入该节点就一定会执行工具完成校验。校验通过后流程来到执行 SQL 语句节点。调用工具运行拼接好的 SQL数据库会返回符合条件的房源数据数据一般以列表形式呈现。最后一步是整合结果并返回。数据库返回的是原始数据格式无法直接展示给用户我们需要把原始数据整理成通顺、易懂的自然语言文本作为最终答案反馈给用户。以上就是房源推荐子图的基础执行链路整体围绕 “构建并执行 SQL 查询数据库” 这一核心目标展开。本次项目我们选用 MySQL 数据库LangGraph 也提供了配套的数据库交互工具比如获取数据表信息、执行 SQL 语句等现成工具后续编码我们会先熟悉这些工具的用法再完成整个工作流的搭建。再结合下面流程图我们补充说明一下细节差异与分支逻辑。节点设计如下collect_user_info节点收集用户希望推荐的房源关键信息list_tables节点调用 SQL 工具查询表有哪些call_get_schema节点LLM 绑定get_schema工具强制调用get_schema工具get_schema节点执行工具获取表的详细信息如表结构、示例数据等generate_query节点LLM 绑定run_query工具非强制工具调用。用来生成查询 SQL 或生成最终结果check_query节点LLM 绑定run_query工具强制调用run_query工具。run_query节点执行工具用来运行generate_query节点生成的 SQL检测 SQL 是否正确上图没有把 “整合结果” 单独设为节点而是将该能力合并到其他节点中。整个流程存在两条分支第一条分支是完成结果整合流程直接结束第二条分支是继续执行 SQL 检查、SQL 执行的完整链路。我们再回顾一下工具调用的核心逻辑帮助大家理清节点划分的思路。只要涉及工具调用常规都会拆分为两个节点第一个节点绑定工具并调用大模型模型根据上下文判断是否需要调用工具返回的消息中会携带工具调用标识第二个节点读取标识真正执行对应的工具函数。我们可以通过参数控制模型的调用规则一种是自由模式由大模型自主决定是否调用工具另一种是强制模式通过参数设置让模型必须触发工具调用。回到房源推荐子图的节点设计首先是收集并解析用户信息节点提取租房相关关键参数其次是手动调用工具的获取全量表节点拿到数据库内所有数据表接着是绑定工具且强制调用的获取表结构节点筛选出房源表并读取表字段、数据样例之后是生成 SQL 语句节点该节点绑定执行 SQL 工具采用非强制调用模式紧随其后的是SQL 检查节点同样绑定执行 SQL 工具并设置强制调用完成语句校验再往下就是执行 SQL 工具节点运行查询语句获取原始数据最后整合数据、生成自然语言答案完成整个子图的业务流程。整套子图的节点划分和流程设计都是基于数据库查询的底层逻辑延伸而来同时结合了 LangGraph 中工具绑定、模型调用、分支路由、强制执行等知识点。理解了每一个节点的作用和前后依赖后续编写代码就会更加顺畅。预定子图 -- 人工介入的预定系统接下来我们开始讲解房源预定子图的整体设计思路。首先回顾该模块的核心需求用户需要提供三类关键信息分别是想要预定的房源名称、本人手机号以及身份证号码。系统收集完这些准确信息后就会完成预定流程并最终向用户返回专属工单号。在信息收集的过程中有一个核心逻辑需要重点处理信息合法性校验。如果用户填写的内容不符合格式要求比如手机号输入了汉字、乱码或是无关字符系统就不能进入下一流程而是需要反复引导用户重新输入直到获取到格式正确的信息为止。这个循环采集信息的场景正是我们此前学习的中断机制的典型应用本次案例也会将该知识点落地实现。整体来看房源预定子图的业务流程并不复杂核心就是依靠中断循环获取合规的用户信息最后生成工单号。这里做一下简化说明本次开发仅实现工单号生成逻辑不会额外对接数据库做工单数据入库操作仅做流程演示。不过生成的工单号会进行持久化存储归入用户历史预定记录中后续用户查询个人信息时可以正常调取。结合节点划分来看房源预定子图首先设置三个核心节点且全部依托中断机制实现功能。第一个节点负责中断获取房源名称循环校验直到拿到有效的房源标题第二个节点中断获取用户手机号校验号码格式第三个节点中断获取身份证信息同样完成格式校验。这三个节点依次执行分步收集三类必要信息。完成全部信息采集后就进入工单生成环节。我们可以借助 UUID 来生成唯一的工单号这也是该模块的核心功能。在代码设计上会把 “生成工单” 封装为独立工具。按照 LangGraph 工具调用的规范调用工具前需要增设一个前置节点该节点加载大语言模型并绑定对应工具通过调用模型来判断是否需要执行工单生成工具。系统会依据判断结果走不同分支确定调用工具则进入工单生成环节无需调用则直接结束当前流程。工具执行后会返回纯工单号 ID但原始 ID 无法直接呈现给用户我们需要将其整合为通俗易懂的自然语言文本再输出。这里还要注意消息格式的适配问题通过中断机制获取到的房源名、手机号、身份证等信息会以参数形式存入字典结构并非标准的human message消息格式。但大语言模型的调用要求入参必须是规范的消息对象因此我们需要单独增设一个节点专门完成数据格式转换把字典数据转为标准human message保障后续模型正常调用。梳理完整消息流转链路首先将中断带回的用户信息组装为字典再通过格式转换节点生成human message之后调用大模型判断是否执行生成工单的工具确认调用后执行工具并得到工单号 ID对应产生tool message由于tool message也不是面向用户的最终消息流程会再次回到模型节点由模型整合信息生成标准AI message这才是展示给用户的最终回复至此预定子图流程全部结束。对照下面流程图再做总结流程里专门设置了消息整合节点完成human message的封装之后依靠大模型做工具调用判断分支执行工单生成工具工具执行完毕后再由模型生成最终回复文本。整个预定子图的核心考点一是中断循环采集用户信息二是各类消息格式的规范转换与流转。节点设计如下get_title节点中断获取要预定的房源标题get_phone节点中断获取预定人的电话get_id节点中断获取预定人的身份证add_reserve_message节点构造并添加预定消息call_orders节点LLM 绑定生成工单的工具tool_node节点生成工单的工具扩展子图 -- 除业务外的智能问答助手讲完预定子图我们再来看最后一个扩展子图 ——通用智能问答子图。该模块脱离租房专属业务用于响应用户的各类日常提问比如数学计算、常识问答、英语问题等。它的实现逻辑非常简单整个子图内部仅设置一个节点该节点直接调用大语言模型即可完成问答交互。虽然功能简易我们依旧按照统一规范将其定义为独立子图。节点设计如下extend_node节点LLM 对话助手到这里本综合案例所有的流程图设计工作就全部完成了。回顾我们最开始讲到的 LangGraph 五步构建法目前已经完成了前两大核心步骤第一是工作流拆分我们把整体系统拆分为 1 个主图外加房源推荐、房源预定、通用问答 3 个子图第二是功能与节点拆解我们逐一分析了主图和每一个子图的核心能力以及内部所有节点的作用、执行逻辑和流转规则。前期的需求分析、流程梳理、图与节点拆分等准备工作均已结束接下来我们正式进入代码开发阶段。开发的第一步就是结合前面梳理的所有业务流程统一设计全局状态state与上下文。无论是主图还是各个子图我们都会根据其运行所需的临时数据、持久化数据完成状态结构的定义。状态设计完成后就可以依次编写各个节点、配置节点之间的连接边逐步实现整套智能租房助手系统。