1. 问题定义

传统 ChatBot 的意图识别是 LLM-First 的：每次对话都调用 LLM 做分类。但实际场景中存在大量高频、可预判的意图模式——"报修""查设备""看工单"——这些意图用静态规则匹配即可达到 95% 准确率，完全不需要 LLM。

EAMX 的 IntentAgent 设计原则是 渐进式策略：能用静态规则就不用 DB，能用缓存的模式就不用 LLM。每一层都是"如果命中就立即返回，未命中才下沉到下一层"。

2. 三层策略架构

`` preprocessIntent(message, tenantId) │ ├─ Step 1: 别名解析 (lookupAliases) │ entity_aliases DB 查询 → "3号机" → "3号注塑机" │ 同时扫描 equipments.aliases JSONB 字段 │ ├─ Step 2a: 静态关键词规则 (matchStaticRule) │ 12 条规则，纯内存匹配，0ms │ "处于故障的设备" → list_equipments + operationalStatus:"fault" │ ├─ [未命中] Step 2b: 本地意图模式 (lookupPattern) │ intent_patterns DB，关键词重叠度评分 │ "3号机没劲了" → 匹配历史模式 → create_fault_report │ ├─ [仍低置信度] Step 3: LLM 兜底 (classifyWithLLM) │ AI_FAST_MODEL，整体管线的最后保障 │ └─ 输出: IntentPreprocessResult 含 primaryIntent / confidence / contextBlock / needsConfirmation ``

整个流程有 100ms 超时保护，防止 LLM 调用阻塞主对话管道。

3. Step 1：别名解析

3.1 entity_aliases 表

``sql CREATE TABLE entity_aliases ( id UUID PRIMARY KEY, tenant_id UUID NOT NULL, alias TEXT NOT NULL, -- "3号机" entity_type TEXT NOT NULL, -- "equipment" | "spare_part" | "location" entity_id UUID NOT NULL, canonical_name TEXT NOT NULL, -- "3号注塑机" usage_count INT DEFAULT 0, created_at TIMESTAMPTZ, updated_at TIMESTAMPTZ ); ``

3.2 查找逻辑

```typescript async function lookupAliases(message: string, tenantId: string) { // 1. 查询高频别名（TOP 100，按 usageCount 降序） const storedAliases = await db .select().from(entityAliasesTable) .where(eq(entityAliasesTable.tenantId, tenantId)) .orderBy(desc(entityAliasesTable.usageCount)) .limit(100);

// 2. 字符串包含匹配 → 命中后异步 usageCount +1 for (const alias of storedAliases) { if (message.includes(alias.alias)) { results.push({ original: alias.alias, entityType, entityId, canonicalName }); // 异步增加使用次数 db.update(entityAliasesTable) .set({ usageCount: alias.usageCount + 1 }) .where(eq(entityAliasesTable.id, alias.id)) .catch(console.error); } }

// 3. 降级扫描：entity_aliases 未命中时查询 equipments.aliases JSONB 字段 // 用户可能在设备录入时手动填写过别名字段 } ```

关键设计：

usageCount 自增使高频别名始终排在 TOP 100，低质量别名自然淘汰
降级扫描确保即使别名未写入 entity_aliases 表，也能在设备表的 aliases 字段中找到
异步更新不阻塞主流程

4. Step 2a：静态关键词规则

```typescript const STATIC_RULES: StaticRule[] = [ // 设备列表 + 运行状态过滤 { keywords: ["故障状态", "处于故障", "故障的设备", "故障设备列表"], intent: "list_equipments", entities: { operationalStatus: "fault" }, confidence: 0.95 },

// 故障上报 { keywords: ["报修", "上报故障", "提交故障"], intent: "create_fault_report", confidence: 0.93 },

// 我的工作 { keywords: ["我的工作", "我的任务", "我的工单", "我的维修"], intent: "list_my_work", confidence: 0.95 },

// 库存查询 { keywords: ["备件库存", "库存查询", "查询库存", "库存情况"], intent: "query_spare_part_stock", confidence: 0.93 }, // ... 共 12 条规则 ];

function matchStaticRule(message: string) { const lower = message.toLowerCase(); for (const rule of STATIC_RULES) { if (rule.keywords.some(kw => lower.includes(kw.toLowerCase()))) return rule; } return null; } ```

12 条规则覆盖了最高频意图（设备故障查询、报修、工单查看、库存查询、技术标准推荐、资产概览）。匹配逻辑是简单的子串包含，O(n×m) 复杂度，但由于 n=12、m<10，实际耗时接近 0ms。

为什么不用更复杂的 NLP 分类器？ 因为 12 条高频规则已经有 95% 命中率。剩下的长尾意图交给 Step 2b 和 Step 3。

5. Step 2b：本地意图模式库

5.1 模式匹配算法

``typescript async function lookupPattern(message: string, tenantId: string) { const patterns = await db .select().from(intentPatternsTable) .where(and( eq(intentPatternsTable.tenantId, tenantId), sqlconfirmed_count >= 1`, )) .orderBy(desc(intentPatternsTable.confirmedCount)) .limit(50);

for (const p of patterns) { const expr = p.rawExpression.toLowerCase(); const msg = message.toLowerCase();

// 策略 1：字符串包含（最强信号） if (msg.includes(expr) || expr.includes(msg)) { score = minLength / maxLength; } // 策略 2：关键词重叠（至少 2 个公共词） else { const overlap = exprWords.filter(w => msgWords.includes(w)).length; if (overlap >= 2) score = overlap / maxWords * 0.7; } // 取最高分，阈值 ≥ 0.80 命中 } } ```

评分使用两种策略的加权最大值，阈值 0.80 保证匹配质量。

5.2 模式学习

每次 AI 对话后，coordinator 异步记录意图模式：

``typescript // orchestrator.ts — Phase 4 Learning recordIntentPattern({ tenantId, rawExpression: userMessage.slice(0, 200), resolvedIntent: toolName, confidence: 0.85, }).catch(() => {}); // fire-and-forget ``

如果同一表达多次出现，confirmedCount 递增；新表达则创建新记录。高频确认的模式会自然上升到 TOP 50，被 Step 2b 优先匹配。

6. Step 3：LLM 兜底分类

当前两层都未命中（或置信度不足以做决策），调用 LLM：

``typescript async function classifyWithLLM(message, resolvedAliases) { const prompt = 你是EAMX工业设备管理系统的意图分类专家。

可用操作列表

${ACTION_CATALOG} // 26 个 action 的完整列表

用户输入

${message} ${aliasContext} // 已解析的别名上下文

任务

分析用户意图并返回JSON： { "intent": "最匹配的action名称", "confidence": 0.95, "entities": { "equipmentName": "...", "assigneeName": "..." }, "reasoning": "一句话" }`;

const resp = await openai.chat.completions.create({ model: AI_FAST_MODEL, // DeepSeek-V3.2 ...FAST_OPTS, // enable_thinking: false max_completion_tokens: 300, temperature: 0, }); } ```

合并策略：如果本地模式命中但置信度偏低（<0.85），调用 LLM。若 LLM 结果与本地一致，置信度加权合并；若不一致，以 LLM 为准（更可靠）。

7. 置信度三分法与用户交互

``typescript // confidence >= 0.85 → 直接执行，不询问 // 0.60 <= confidence < 0.85 → 执行前确认 // confidence < 0.60 → 询问澄清 if (confidence >= 0.85) { needsConfirmation = false; } else if (confidence >= 0.60) { needsConfirmation = true; clarificationQuestion = 您是要「${intentLabel}」吗？; } else { needsConfirmation = true; clarificationQuestion = "您的意图不明确，请问您想要执行什么操作？"; } ``

8. 性能数据

| 层级 | 耗时 | 命中率（高频场景） | |---|---|---| | Step 1 别名解析 | 5-15ms (DB) | 60% | | Step 2a 静态关键词 | 0ms (内存) | 25%（高频意图中） | | Step 2b 本地模式 | 3-8ms (DB) | 10% | | Step 3 LLM 兜底 | ~200ms | 5% |

在高频场景（报修/查设备/看工单）中，95% 的请求在第一、二层就完成了,根本不会调用 LLM，整体延迟控制在 15ms 以内。

9. 核心文件索引

agents/intent.agent.ts（611 行）— 意图识别全逻辑
ai/orchestrator.ts L149-156 — Phase 4 意图学习触发
entity_aliases 表 — 别名字典
intent_patterns 表 — 意图模式库

下一篇：AI Pipeline 编排器——Coordinator 如何从 880 行巨石文件重构为 233 行的四阶段 Pipeline 编排器。