携程智能助手项目

1. 一段话总结

携程AI智能助手项目是基于LangGraph构建的多场景旅行服务智能系统，核心围绕旅行相关数据（航班、酒店、租车等）的管理与服务展开，首先需准备包含11张核心数据表（如flights、bookings、hotels等）的SQLite数据库，随后开发分类工具函数（安全只读工具、敏感数据修改工具）与工作流，通过用户确认机制（interrupt_before中断策略）保障敏感操作安全，进一步拆分为4个专业子助手（航班预订、酒店预订、租车、游览）及1个主助手实现任务路由，最终基于vLLM部署大模型并搭建WebUI测试页面，通过LangGraph服务器提供REST API接口供前端调用，完成从数据存储到用户交互的全流程。

---

2. 思维导图（mindmap）

---

3. 详细总结

一、项目概述与基础准备

1. 项目定位：基于LangGraph构建的旅行服务智能助手，覆盖航班、酒店、租车、游览等旅行场景，通过大模型与数据库交互，为用户提供查询、预订、变更等服务。
2. 数据库设计：
   • 核心目标：存储旅行全链路数据，支撑工具查询与业务操作。
   • 核心数据表清单（共11张）：

     数据表名称	核心用途	关键字段示例（以flights为例）
     aircrafts_data	飞机基础信息存储	aircraft_code（飞机代码）、model（型号）、range（航程）
     flights	航班信息存储	flight_id、flight_no、scheduled_departure/arrival等
     bookings	用户预订记录存储	booking_id、book_date、total_amount等
     hotels	酒店信息存储	hotel_id、name、location等
     car_rentals	租车订单存储	rental_id、pickup_location、dropoff_location等
     trip_recommendations	旅行推荐数据存储	recommendation_id、user_id、destination等

   • 数据库文件：
     • 主文件：travel_new.sqlite（业务核心库）
     • 备份文件：travel2.sqlite（测试环境重置用）
   • 初始化代码：init_db.py，含update_dates函数用于更新数据日期，保障数据时效性。

二、核心开发流程与设计

（1）工具函数开发

• 工具分类（按安全性与操作类型）：

  工具类型	定义	典型场景	是否需用户确认
  安全只读工具	仅查询数据，不修改存储内容	航班时间查询、酒店位置查询	否
  敏感修改工具	会变更数据库数据（如预订修改）	航班改签、酒店取消预订	是

• 辅助函数：
  • 消息格式化函数：调试图时美观打印对话消息，便于调试。
  • 错误处理函数：为工具节点提供异常捕获（如数据库连接失败、参数错误），保障流程稳定。

（2）工作流设计与优化

1. 基础工作流构建：

   • 核心步骤：start→fetch_user_info（获取用户信息）→assistant（助手逻辑处理）→tools（工具调用）→end。
   • 状态定义：采用类型化字典（TypedDict），含messages（对话历史）、user_info（用户信息）、dialog_state（对话状态）等字段。

2. 用户确认机制（中断策略）：

   • 核心逻辑：通过interrupt_before在敏感工具执行前暂停流程，将控制权交还给用户，需用户确认后再继续操作。
   • 状态修改：在fetch_user_info节点显式填充用户状态，避免AI通过工具重复获取用户信息，提升效率。

3. 专业子助手拆分：

   • 拆分目标：让每个助手专注单一领域，降低LLM混淆风险，提升服务精度。
   • 子助手类型：共4个，分别为航班预订助手、酒店预订助手、租车助手、游览助手，另设1个“主助手”负责任务路由。
   • 子工作流节点构成（每个子助手通用）：
     1. enter_*：入口节点（通过create_entry_node函数创建，含ToolMessage标记当前助手）；
     2. 助手节点：含提示词+LLM组合，处理领域内逻辑；
     3. *_safe_tools：该领域的安全只读工具节点；
     4. *_sensitive_tools：该领域的敏感修改工具节点（配置interrupt_before）；
     5. leave_skill：退出节点，重置dialog_state，交还控制权给主助手。

（3）关键技术应用

1. 闭包（Closure）：

   • 应用场景：实现create_entry_node函数，该函数接收assistant_name（助手名称）和new_dialog_state（新对话状态），返回entry_node函数。
   • 核心价值：
     • 封装信息：携带助手名称与对话状态，避免全局变量污染；
     • 延迟执行：在entry_node被调用时才生成ToolMessage，适配动态对话场景；
     • 复用逻辑：统一入口节点生成逻辑，无需为每个子助手重复编码。

2. 路由函数设计：
   项目需2个核心路由函数，职责分离且协同保障流程连贯：

   路由函数名称	核心作用	适用场景	关键逻辑
   route_primary_assistant	初次任务分配	用户首次请求或主助手处理后需委派任务时	根据工具调用（如“航班预订”）路由至对应子助手入口节点
   route_to_workflow	维护对话连贯性	用户与子助手交互后需返回当前工作流时	根据dialog_state判断激活的工作流，路由至对应节点

三、部署与交互实现

1. 大模型部署：

   • 部署工具：vLLM（高性能推理框架）；
   • 支持模型：DeepSeek-R1-Distill-Qwen-7B、Qwen2.5-7B-Instruct；
   • 核心部署命令（以Qwen-7B为例）：

     python -m vllm.entrypoints.openai.api_server \
     --model /root/autodl-tmp/models/Qwen/Qwen2___5-7B-Instruct \
     --served-model-name Qwen-7B \
     --max-model-len=16384 \
     --host 0.0.0.0 \
     --port 6006 \
     --dtype float16 \
     --enable-auto-tool-choice \
     --tool-call-parser hermes
     

   • 关键参数：--max-model-len（上下文长度，最大16384）、--port（端口6006）、--enable-auto-tool-choice（自动工具选择）。

2. 前端交互与服务架构：

   • WebUI测试页面：访问127.0.0.1:7860，支持用户输入查询（如“我的航班是什么时间”）并返回结构化结果；
   • 服务架构：

     前端（HTML/Vue/移动端）→ 调用REST API → LangGraph服务器（运行工作流）→ 大模型/数据库 → 返回响应
     

---

4. 关键问题与答案

问题1：项目中设计“安全只读工具”与“敏感修改工具”分类的核心原因是什么？如何通过技术手段保障敏感工具的安全使用？

答案：

• 分类核心原因：平衡系统安全性与用户体验——安全只读工具（如航班查询、酒店位置查询）仅获取数据不修改存储，无需用户确认可提升效率；敏感修改工具（如航班改签、酒店取消）会变更数据库中用户预订数据，误操作可能导致损失，需严格控制。
• 安全保障技术：通过LangGraph的interrupt_before中断策略，在敏感工具执行前暂停工作流，将控制权交还给用户，仅当用户明确确认后，流程才继续执行；同时在工作流编译时，仅为*_sensitive_tools节点配置中断，*_safe_tools节点直接执行，实现“安全操作高效化、敏感操作可控化”。

问题2：项目拆分“主助手+4个专业子助手”的架构设计，相比单一助手有哪些优势？子助手的“入口节点（enter_*）”通过闭包实现的核心价值是什么？

答案：

• 多助手架构优势：
  1. 降低LLM认知负担：单一助手需处理全场景（航班、酒店、租车等），易混淆业务边界；专业子助手专注单一领域，提升回答精度与效率；
  2. 便于维护与扩展：新增场景（如“景点门票预订”）时，仅需新增对应子助手，无需修改主助手核心逻辑，降低耦合；
  3. 优化用户体验：子助手可针对领域特性定制提示词（如航班助手侧重时间/机场信息，酒店助手侧重位置/价格），输出更贴合用户需求的结果。
• 入口节点闭包核心价值：
  1. 状态封装：闭包可携带assistant_name（子助手名称）与new_dialog_state（对话状态），在entry_node被调用时生成ToolMessage（如“当前助手为航班预订助手，请提供出行日期”），明确任务边界；
  2. 逻辑复用：无需为每个子助手单独编写入口节点代码，通过create_entry_node函数统一生成，减少重复开发；
  3. 动态适配：对话状态随用户操作实时变化，闭包可延迟生成入口消息，确保消息与当前状态匹配（如用户切换子助手时，入口消息自动更新为对应领域提示）。

问题3：项目中route_primary_assistant与route_to_workflow两个路由函数的职责有何区别？为何需要同时存在这两个函数？

答案：

• 职责区别：

  维度	route_primary_assistant	route_to_workflow
  核心作用	初次任务分配	维护对话连贯性
  适用场景	用户首次请求/主助手处理后需委派任务时	用户与子助手交互后需返回当前工作流时
  路由依据	工具调用（如“预订酒店”工具）	对话状态（dialog_state）
  输出结果	对应子助手的入口节点（如enter_book_hotel）	当前激活的子助手节点/主助手节点

• 同时存在的原因：
  1. 职责分离：前者负责“任务分发”（从主助手到子助手的初次路由），后者负责“流程回归”（子助手交互后保持上下文连贯），避免单一函数逻辑过于复杂；
  2. 保障长对话连贯性：用户与子助手的交互可能跨多轮（如“修改航班日期→确认新日期→查询新航班余票”），route_to_workflow可根据dialog_state定位当前激活的子助手，避免用户每轮操作都需重新路由；
  3. 支持复杂场景扩展：若后续新增“跨场景服务”（如“航班+酒店套餐预订”），route_primary_assistant可新增路由规则分配任务，route_to_workflow保障多子助手协同后的状态一致性，提升系统扩展性。