基于Langchain构建多选项引导式网站聊天bot的技术实现咨询

一、对话阶段识别的核心逻辑 #

ConversationSummaryMemoryBuffer 不会自动识别对话阶段，它仅负责存储和总结对话历史。你需要主动维护对话状态，两种可靠方式：

• 在内存中新增current_stage字段，初始值设为greeting，用户选择服务后更新为awaiting_website，完成调研后可重置或切换到confirmation阶段
• 不要依赖对话总结推导阶段，直接存储明确的状态字段能避免LLM总结带来的歧义，稳定性更高

二、路由与对话流的实现路径 #

SequentialChain 和 MultiPromptChain 不适合你的场景——前者是无分支的线性执行，后者仅适合多Prompt切换。你的需求是带条件分支的引导式对话，推荐两种更适配的方案：

1. 轻量规则式路由（优先推荐） #

这种方式可控性强、成本低：

• 初始化时设定current_stage = "greeting"，并将该状态存入 ConversationSummaryMemoryBuffer
• 每次接收用户输入时，先从内存读取当前状态：
  • 若处于greeting阶段：匹配用户输入的"1"或"services"，更新状态为awaiting_website，输出"请提供您的网站地址"
  • 若处于awaiting_website阶段：提取用户输入的网址，传入调研Agent执行任务，返回结果后更新状态（比如进入确认环节）
• 所有状态变更和对话历史都同步存入内存，确保多轮对话的上下文连贯性

2. LLM驱动的路由（进阶方案） #

如果需要处理更灵活的用户输入（比如用户用自然语言表达需求），可以用LLM做路由判断：

• 编写路由Prompt，引导LLM根据对话历史判断当前应进入的分支（例如："根据以下对话历史，判断用户当前处于哪个阶段：1. 初始问候选阶段；2. 等待网站地址；3. 其他"）
• 使用LLMRouterChain将对话路由到对应子链：GreetingChain负责初始引导，ServiceInquiryChain负责请求网站地址并调用调研Agent，AppointmentChain处理预约逻辑等
• 每个子链内部维护自己的状态，并将状态同步到内存中

三、内存组件的正确结合方式 #

ConversationSummaryMemoryBuffer 的核心作用是保留对话上下文，你需要：

• 将自定义的current_stage作为额外变量存入内存，每次调用链时将该状态传入Prompt，让LLM明确当前的任务目标
• 定期同步状态变更到内存，确保多轮对话中状态不丢失

四、避坑提醒 #

• 不要用SequentialChain处理带用户交互的分支流程，它无法中断等待用户输入
• MultiPromptChain仅适合根据问题类型切换Prompt，不适合带状态的多轮引导
• 对于明确的选项输入（如"1"/"services"），优先用规则判断，比LLM路由更稳定且节省Token

内容的提问来源于stack exchange，提问作者Abenil