【Agent智能体】40DialogueEngine设计实现

章节四十DialogueEngine设计与实现一、DialogueEngine设计1.1 设计定位DialogueEngine一轮消息处理的调度中心。接收用户消息和对话状态DialogueState判断本轮走哪条处理路径并返回机器人回复。它不负责具体业务逻辑不直接查询知识库也不直接执行flow。只负责判断本轮消息应该交给谁处理并把处理结果写入当前对话轮次。涉及的组件组件简要作用DialogueState保存会话、任务、聚焦对象和历史记录Turn保存本轮用户输入和机器人输出TurnPlanner根据文本消息和状态生成本轮计划TurnPlanValidator检查本轮计划是否可靠、是否可执行ClarifyResponder在计划不清晰时生成追问TaskHandler处理业务任务KnowledgeHandler处理知识问答ChitchatHandler处理闲聊1.2 完整流程步骤第一步准备会话核心问题是当前会话还能不能继续使用。如果会话超时超过1小时未活动引擎清理运行状态清空活跃任务、暂停任务、系统流程和聚焦对象然后关闭旧session开启新session。第二步创建本轮记录一条用户消息对应一轮对话Turn。处理过程中暂存于DialogueState.pending_turn本轮结束后写入当前Session.turns。第三步判断消息类型引擎区分消息是文本还是业务对象。文本消息需要理解用户想做什么对象消息如点击订单卡片记录用户当前关注的对象。第四步处理对象消息对象消息来自前端点击。引擎先把对象写入DialogueState.focused_object然后判断如果对象刚好能补齐当前任务需要的信息就继续业务任务。如果只能知道用户点了对象但不知道想做什么就追问用户意图。第五步处理文本消息文本消息交给TurnPlanner理解。理解时参考最近对话、active_task、paused_tasks、focused_object、系统支持的flows和knowledge_intents。TurnPlanner不是凭空理解而是在系统支持的能力范围内选择最合适的处理方向。本轮计划TurnPlan可以是业务任务启动/恢复/取消哪个工作流、设置哪个槽位知识问答问哪类知识问题闲聊用户不是办业务也不是问知识只需自然回复第六步检查理解结果TurnPlanner的理解结果需要TurnPlanValidator检查。常见需要澄清的情况意图不明确、缺少对象、多个方向冲突、表达太短或上下文不足。第七步澄清处理当系统无法确定用户目的时交给ClarifyResponder追问补齐关键信息。追问后本轮不会继续执行业务处理。第八步进入业务任务用户明确要办理业务时引擎把本轮交给TaskHandler。TaskHandler根据当前状态推进业务流程把回复写回本轮Turn。第九步进入知识问答用户问规则、政策、商品信息等问题时引擎把本轮交给KnowledgeHandler。进入前会先暂停active_task避免破坏原来的业务流程。第十步进入闲聊用户只是问候或简单聊天时交给ChitchatHandler。同样会先暂停active_task。第十一步提交本轮记录无论本轮是业务、知识、闲聊还是追问最后都要提交本轮记录成为会话历史的一部分。返回结果包含用户ID、消息ID和机器人回复。二、DialogueEngine实现2.1 初始化DialogueEngine通过构造函数依赖注入接收各核心组件TurnPlanner、TaskHandler、KnowledgeHandler、ChitchatHandler、ClarifyResponder、TurnPlanValidator。核心是依赖注入DialogueEngine不自己创建这些组件而是由外部组装好后传进来。好处是每个组件职责独立DialogueEngine只负责调度。2.2 process主流程process()是DialogueEngine的入口方法本身不处理具体业务只做分发第一步process(message, state)接收消息和状态。第二步_prepare_session准备会话检查是否超时处理session创建/重置。第三步_begin_turn开启本轮Turn。第四步判断消息类型。TEXT消息走_handle_text_messageOBJECT消息先记录focused_object再走_handle_object_message。第五步把返回的BotMessage列表写入pending_turn.assistant_messages。第六步commit_pending_turn提交本轮。第七步返回ProcessResult。2.3 TEXT消息处理_handle_text_message()的处理流程第一步调用TurnPlanner.predict()预测本轮计划。第二步调用TurnPlanValidator.validate()校验计划是否可执行。第三步如果校验不通过调用_clarify()生成澄清回复。第四步如果校验通过根据TurnPlan分发task不为None交给TaskHandlerknowledge不为None暂停当前任务交给KnowledgeHandler其他情况暂停当前任务交给ChitchatHandler2.4 OBJECT消息处理对象消息是用户发送的结构化对象如商品或订单。系统先记录聚焦对象到DialogueState.focused_object然后进入_handle_object_message()。两种处理结果当前任务正在收集这个对象ID就把对象转换成SetSlotsCommand交给TaskHandler继续推进。不能直接填槽就触发OBJECT_REQUIRES_INTENT澄清让用户说明想做什么。判断当前正在收集哪个槽位的方法先看active_system_task是否在收集再看active_task的当前step是否是CollectSlotStep。2.5 澄清回复DialogueEngine不自己写澄清话术只把reason交给ClarifyResponder。职责分工清晰TurnPlanValidator判断为什么不能执行DialogueEngine决定需要澄清ClarifyResponder生成具体回复。2.6 Builder组装DialogueEngine的组件由build_dialogue_engine()统一创建和组装主要完成四件事第一步加载flow配置user_flows.yml和system_flows.yml。第二步创建TaskHandler及其依赖CommandProcessor、FlowExecutor、ActionRunner。第三步创建KnowledgeHandler和知识Provider注册表ProductAPIProvider、OrderAPIProvider、FAQProvider、RAGProvider。第四步创建ChitchatHandler、ClarifyResponder、TurnPlanner、TurnPlanValidator并注入到DialogueEngine。Builder把对象创建逻辑集中到一个地方DialogueEngine本身只关心调度不关心组件如何创建。