AI工厂管家多Agent多轮对话工程实践：从意图路由到槽位收敛与漂移控制的完整设计
三级意图识别、槽位收集与 pending 延续、意图漂移控制、只读不遗留机制，基于 v6.84.1 全功能测试 20 场景实测
AI 工厂管家 v6.84.1 全功能测试以 20 个场景矩阵在真实 PostgreSQL 与 doubao-seed-2-1 意图识别模型上取得 20/20 通过，验证了多轮对话系统的三条工程主线：槽位收集与 pending 延续收敛、意图漂移与发散控制、只读查询不遗留。本文基于《AI工厂管家 测试报告_v6.84.1_全功能测试》，详解三级意图识别、25 秒预识别看门狗、request_info 槽位收集与漂移判定逻辑，并给出完整对话记录中的真实数据。
一、多轮对话的工程挑战
制造业 LLM 工作流系统的对话复杂度远高于通用聊天：同一个入口（POST /api/chat）要服务销售、仓储、生产、质检、财务、技术、HR、知识 8 个 Agent 域，每条用户输入既要判断"现在该做什么意图"，又要判断"是不是上一轮未完成任务的延续"。v6.84.1 测试前暴露的三类典型问题正来自这里：强模型推理不收敛时非流式接口会稳定挂死 200 秒以上（T14）；"核算一下生产成本"被财务查询意图吞并导致子意图跑偏（T12）；缺参分支未传 request_info 动作导致只读意图不挂 pending、多轮断裂（T12）。这些问题的共同根源是意图识别、路由与对话状态三者之间的衔接不够严密。
二、三级意图识别与 25 秒看门狗
意图识别采用三级递进结构（表 1）：确定性短语白名单（131 条整句精确匹配）保证"查库存/下订单/你好"等高频输入零延迟零歧义；数据库训练规则按 priority 优先于白名单，尊重用户显式训练；LLM 兜底负责开放域理解，并注入 few-shot 样本提升分类准确率。三级结构的关键是 LLM 兜底必须有超时兜底：v6.84.1 为 /api/chat 非流式分支增加 25 秒预识别看门狗，超时即回退规则层零延迟返回，彻底消除了 BOM 查询场景（T14）200 秒挂死的故障。
| 层级 | 机制 | 作用 | 实测示例 |
|---|---|---|---|
| 第一级 白名单 | 131 条确定性短语整句精确匹配 | 高频输入零延迟、零歧义 | "查库存"→query_inventory，"你好"→greeting |
| 第二级 训练规则 | DB training_data，priority 排序 | 用户显式训练优先于内置规则 | priority=5 的 custom_order_intent 命中"查询订单" |
| 第三级 LLM 兜底 | doubao-seed-2-1-turbo + few-shot 样本 | 开放域意图理解 | 复合句式、口语化表达的意图分类 |
| 看门狗 | 25s 预识别超时回退规则层 | 防推理不收敛挂死 | T14 BOM 查询从 200s+ 降到秒级返回 |
三、槽位收集与多轮延续收敛
业务动作类意图（下单、排产、收款、报工）往往需要多个参数，系统用 pending 机制挂起未完成意图，把后续输入消化为槽位补充。以销售下单为例（T1）：第 1 轮"帮我下个单"识别为 create_order 并引导"请提供产品型号、订购数量"；第 2 轮"A-202"补充 product_code 后继续追问数量；第 3 轮"100套"补全 quantity 后落库生成订单号 SO202608152698，三轮收敛完整。同一条主线在取消订单（T3，引导单号）、生产排产（T6）、8D 生成（T10）、财务收款（T11，5 万→PAY20260815163407）、成本核算（T12）上全部验证通过。
工程上需要三个细节才能让收敛可靠：一是缺参分支必须显式返回 action="request_info"，否则只读类意图不挂 pending 会直接导致多轮断裂（v6.84.1 修复项）；二是 pending 期间输入的槽位要能合并会话注入的附件等上下文；三是 _format_response 对 READONLY 意图与动作意图采取不同的 pending 策略，避免只读查询污染对话状态。
四、意图漂移与发散控制
多轮延续最大的风险是"误吞"：用户在手头任务未完成时突然转向另一个话题，系统必须识别为意图漂移而不是延续槽位。v6.84.1 测试专门设计了两组发散场景（图 1）：T18 在下单 pending 中输入"咱库存是不是快见底了"，系统脱离 create_order 路由到 query_inventory，并正确解析附加条件"数量 ≤ safety_stock"；T20 在排产 pending 中输入"帮我分析下这段数据"，识别为 unknown 后由知识 Agent 接管，不误路由生产 Agent。另一条纪律是只读不遗留（T19）：OEE 查询完成后不写 pending，下一轮库存查询立即正常路由。设计原则是"查询动词开头与明确新意图优先脱离 pending，业务动作类延续才被 pending 消化"。
图 1 AI 工厂管家多轮对话状态机（v6.84.1 全功能测试验证）
五、20 场景测试矩阵与修复对照
全功能测试覆盖 8 个 Agent 域的 20 个场景，三条主线与关键场景结论如下表，全部通过。
| 主线 | 场景 | 输入要点 | 结论 |
|---|---|---|---|
| 多轮延续收敛 | T1 销售下单 | 帮我下个单 → A-202 → 100套 → SO202608152698 | ✅ 三轮收敛落库 |
| 多轮延续收敛 | T11 财务收款 | 登记张三的收款 → 5万 → PAY20260815163407 ¥50,000 | ✅ 金额槽位换算正确 |
| 多轮延续收敛 | T12 财务成本 | 核算生产成本 → A-202 → cost_analysis 不跑偏 | ✅ 成本词拆分生效 |
| 意图漂移发散 | T18 下单中查库存 | 下单 pending 中「咱库存…」→ query_inventory | ✅ 脱离 pending 正常路由 |
| 意图漂移发散 | T20 排产中分析 | 排产 pending 中「帮我分析下这段数据」→ unknown | ✅ 知识 Agent 接管不误路由 |
| 只读不遗留 | T19 OEE→查库存 | OEE 查询完成后新一轮库存查询正常 | ✅ 只读不写 pending |
| 看门狗 | T14 BOM 查询 | 非流式接口 25s 预识别看门狗 | ✅ 超时回退规则层秒回 |
| 数据迁移 | T5 仓储入库 | A-202入库100个 → IM20260815163227 | ✅ 迁移 054/055/056 后落库成功 |
测试还暴露并修复了 4 个问题：非流式接口无看门狗导致 T14 挂死；成本词被财务查询吞并导致 T12 跑偏；缺参分支未传 request_info 导致多轮断裂；inventory_movements 存量 DDL 与代码事实列不一致（缺 quantity/operator/reference_no/created_at、movement_id 为整数拒业务流水号、qty NOT NULL），通过迁移 054（补代码事实列）、055（movement_id 改 VARCHAR(32)）、056（qty 解除 NOT NULL）解决。
结语
AI 工厂管家多轮对话的工程内核可以归纳为三条：三级意图识别加 25 秒看门狗，保证高频输入零延迟、开放域不挂死；request_info 动作加 pending 延续机制，让槽位收集在 8 个 Agent 域上可靠收敛；查询动词与明确新意图优先脱离 pending，配合只读不遗留纪律控制意图漂移。v6.84.1 的 20 场景 20/20 实测证明这套设计可稳定支撑制造业 LLM 工作流的多轮业务操作。
本文基于《AI工厂管家 测试报告_v6.84.1_全功能测试》（2026-08-15，HTTP /api/chat 非流式，PostgreSQL live，意图识别模型 doubao-seed-2-1-turbo-260628）整理优化。