【Agent智能体】41TaskHandler设计实现

章节四十一TaskHandler设计与实现一、TaskHandler设计1.1 设计理念在电商客服系统中很多业务任务都不是一轮对话就能完成的。比如用户说我要退单系统可能需要继续追问订单号、退款原因然后再给出处理结果。这类任务天然是一个多步骤过程系统把这类多步骤任务定义成flow。flow被设计成可配置形式使用YAML文件描述业务流程。这样新增或调整业务流程时优先修改配置而不是直接改代码。TaskHandler的职责是推进flow的执行支持以下能力能力说明打断当前正在处理一个flow时用户可以临时切换到另一个flow恢复被打断的flow可以从之前的位置继续取消用户不想继续时可以取消当前flow1.2 Flow配置语法设计思想一个flow由一系列steps组成每个step表示流程中的一个节点通过next指向下一个step。顶层字段flows根节点、flow_id唯一标识如refund_request、name可读名称、description能力说明、steps步骤列表。基础step类型type作用startflow的入口next指向第一个处理业务的stependflow的终点next写空列表action执行一个动作action_response向用户回复消息。有三种回复模式static直接把text渲染后回复rephrase先渲染text再用prompt让大模型改写generate不依赖固定text直接用prompt让大模型生成action_response支持变量引用slots已收集的信息、context系统上下文。action_listen等待用户下一轮输入通常跟在询问信息的action_response后面。自定义action处理项目自己的业务逻辑如查询订单状态、查询物流信息、推荐相似商品。通常负责查询业务数据后续再用action_response把结果回复给用户。next跳转静态跳转直接指定下一个step的id条件跳转根据条件读取slots、context、flow_id、step_id决定下一步多个条件按顺序判断命中第一个成立的分支collect step用来表达当前流程需要某个slot。如果slot已有值直接进入next指定的step如果没有值询问用户并等待输入。collect把问等的细节封装起来让配置更关注业务需要什么信息。1.3 SystemFlowSystemFlow用来描述系统级交互SystemFlow作用system_collect_information收集缺失的slot信息system_task_started新任务开始时通知用户system_task_resumed恢复暂停任务时通知用户system_task_interrupted任务被打断时通知用户system_task_canceled任务被取消时通知用户system_task_completed任务完成时通知用户system_cannot_handle系统无法处理时通知用户二、TaskHandler实现2.1 实现思路TaskHandler是任务轨道的入口。不负责理解用户自然语言也不负责读写数据库。只接收已经解析好的commands和当前DialogueState然后推进任务流程。内部依赖三个对象对象职责CommandProcessor处理命令修改DialogueStateFlowExecutor根据当前状态推进flowActionRunner执行flow中声明的action实现顺序Flow定义和加载 - Command定义和解析 - CommandProcessor - ActionRunner - FlowExecutor - TaskHandler。2.2 Flow定义与加载Flow配置对应的核心模型包括FlowsList所有flow和slot的集合、Flow单个流程、FlowSlot槽位定义、FlowStep步骤基类包含StartFlowStep、CollectSlotStep、ActionFlowStep、EndFlowStep等子类、FlowStepLink跳转链接基类包含StaticLink、ConditionalLink、FallbackLink、ResponseDefinition回复定义、SlotValidation槽位校验。FlowLoader从多个YAML配置文件加载配置得到FlowsList对象。2.3 Command定义与解析Command由TurnPlanner调用LLM输出常见类型StartFlowCommand启动任务指定要启动的flow_id和初始slotsSetSlotsCommand写入槽位设置要更新的槽位键值对CancelFlowCommand取消任务指定要取消的flow_idResumeFlowCommand恢复任务指定要恢复的flow_idCommandParser将LLM返回的JSON字符串解析为对应的Command对象列表。2.4 CommandProcessorCommandProcessor把Command应用到DialogueState上主要修改三类状态active_task、paused_tasks、active_system_flow。各命令的处理逻辑start_flow启动任务第一步如有active_task将其压入paused_tasks。第二步创建新的TaskContext设置flow_id和初始slots。第三步将新的TaskContext设为active_task。第四步生成system_task_started通知如有被打断的任务同时生成system_task_interrupted。set_slots写入槽位第一步找到当前active_task。第二步将slots更新到active_task.slots中。第三步如果当前step是collect类型将step_id推进到next指定的步骤。cancel_flow取消任务第一步找到要取消的任务active_task或paused_tasks中的某个。第二步从状态中移除。第三步如果取消的是active_task从paused_tasks中恢复最后一个任务。第四步生成system_task_canceled通知。resume_flow恢复任务第一步从paused_tasks中找到目标任务。第二步将当前active_task压入paused_tasks。第三步将目标任务设为active_task。第四步生成system_task_resumed通知。2.5 ActionRunnerActionRunner负责执行flow step中声明的action。核心概念ActionRegistryaction注册表维护name到Action实例的映射Action动作基类每个action有唯一name需实现run()方法ActionCall一次action调用请求ActionResult包含messages机器人消息和slot_updates槽位更新内置action_response根据mode选择不同回复策略static直接渲染模板rephrase模板渲染后交给LLM改写generate直接由LLM根据prompt生成。支持Jinja2模板变量插值。2.6 FlowExecutorFlowExecutor根据当前DialogueState推进flow第一步读取active_task获取当前flow_id和step_id。第二步从FlowsList中找到对应的Flow。第三步找到当前step执行对应的动作或收集逻辑。第四步根据step的next配置决定下一步进入哪个step。第五步更新active_task的step_id。2.7 TaskHandler总入口TaskHandler是任务轨道的总入口处理流程第一步接收commands和DialogueState。第二步调用CommandProcessor.run()处理命令修改状态。第三步调用FlowExecutor.run()推进流程。第四步调用ActionRunner.run()执行动作。第五步收集生成的BotMessage返回。