左帮右臂规则+大模型混合意图识别系统 V1.0

软 件 说 明 书

目录

• 一、软件概述
• 二、软硬件运行环境
• 三、软件系统架构
• 四、核心功能详细说明
• 五、软件创新点与优势
• 六、软件操作步骤与使用说明（含操作界面截图）
• 七、典型应用场景案例（含真实运行界面）
• 八、数据接口与集成说明
• 九、核心功能模块详述（含真实运行界面）
• 十、参数配置说明
• 十一、部署与运维详细步骤
• 十二、安全机制说明
• 十三、版本更新说明
• 十四、常见问题与故障排查
• 十五、性能基准与测试说明
• 十六、术语与缩略语
• 十七、技术参数与性能指标
• 著作权人信息

一、软件概述

1.1 研发背景

在企业级应用场景中，将用户自然语言指令精准转化为系统可执行的操作，是智能化企业管理的核心能力。当前行业主流方案存在两种极端路线，各有明显局限：

纯大模型方案的问题：

• 成本高昂：每次意图识别均需调用大模型API，按Token计费，企业日均万级请求量下成本显著。
• 延迟较大：单次大模型推理耗时通常在800ms~3000ms，难以满足实时交互需求。
• 存在幻觉：大模型可能输出不符合业务规范的意图，尤其在专业领域（如PLM零部件、采购流程）术语理解上存在偏差。
• 不可控性：模型输出格式不稳定，难以保证下游系统可靠解析。

纯规则方案的问题：

• 语义理解弱：规则仅支持关键词字面匹配，无法理解"帮我看看仓库里压货的零件"这类语义化表达。
• 维护成本高：业务变化需频繁修改代码，扩展性差。
• 无法泛化：对未预见的新表达方式完全失效。

基于上述痛点，本系统采用规则+大模型混合意图识别架构，通过三级降级机制，在成本、速度、准确率三者之间取得最优平衡。系统作为"左帮右臂"企业智能体平台的自然语言理解中枢，向上承接用户口语化指令，向下对接PLM、采购、库存、质量、HR等业务系统的可执行能力，是连接人与企业数字资产的关键纽带。

1.2 核心功能

本系统核心功能为三级降级混合意图识别：

• L1 关键词直通：高频、明确的意图通过内置规则与数据库规则的关键词加权匹配直接命中，响应时间<100ms，零Token成本。
• L2 规则+LLM参数提取：规则命中但需提取复杂参数时，结合大模型进行参数抽取，兼顾效率与语义理解。
• L3 纯LLM推理：规则未命中时，降级至大模型全量推理，保证兜底覆盖率。

系统支持六种对象操作语义（identify识别 / create创建 / repair修复 / optimize优化 / compare比对 / generate内容生成）及工具直调（tool_call），覆盖企业管理全场景。

三级降级并非简单的"if-else"分支，而是一套以"成本—时延—覆盖率"为优化目标的调度策略：系统会优先在零成本、低时延的L1层完成绝大多数高频意图识别；只有当L1层置信度不足时，才逐级上升调用大模型资源，从而把昂贵的大模型算力集中投放到真正长尾、复杂的语义理解任务上。这种架构设计使系统在保证"听得懂"的同时，把运行成本与响应延迟控制在工程可接受的范围内。

1.3 适用领域

• 产品生命周期管理（PLM）：零部件查询、BOM管理、工程变更（ECR）
• 采购供应链管理：供应商寻源、询价、比价、采购决策、订单下发
• 库存与质量管理：库存分析、客户投诉分析、合规性巡检
• 人力资源与项目管理：员工信息查询、项目立项

具体而言，系统已在以下业务语境中完成验证：

• PLM 工程研发：研发人员以口语化方式检索零部件（Part）、查看BOM结构、追踪工程变更申请（ECR），无需记忆复杂的系统菜单路径。
• 采购执行：业务人员一句话即可触发"找供应商→询价→比价→决策→下发订单"的完整采购链路，并支持对接1688等外部寻源渠道。
• 库存与供应链：计划员查询库存预警、积压分析、周转率、库龄、呆滞物料，系统即时返回结构化分析结果。
• 质量与客户：客服与质量人员发起客户投诉分析、合规性巡检并自动生成质量报告。
• HR 与行政：查询员工考勤、生日、工作状态，以及项目立项信息的快速登记。

本说明书后续章节将以以上真实业务为基线，逐项展开功能说明、操作指引与集成方式。

二、软硬件运行环境

2.1 硬件环境

2.2 软件环境

2.3 部署方式

系统采用Node.js后端服务形式部署，通过HTTP API对外提供意图识别与规则管理能力。核心引擎以单例模式运行，规则缓存于内存中，TTL为60秒，保证高并发下的响应性能。

系统的部署形态为无状态HTTP微服务：多个实例可同时对外提供服务，规则数据通过SQLite（默认）或MySQL（可扩展）共享，实例间通过数据库保证规则视图一致。由于L1层命中结果完全来自内存中的规则缓存，单实例即可在4核8GB配置下稳定支撑数千QPS的意图识别吞吐；在需要扩展时，通过水平增加实例即可线性提升并发能力，无需改动业务代码。

大模型服务以"外部依赖"形式接入，系统通过兼容OpenAI API格式的HTTP接口调用L2/L3能力。当大模型服务不可用时，系统自动回退至关键词规则链路，保障基础意图识别能力不中断，这一设计显著提升了生产环境的可用性。

三、软件系统架构

3.1 三级降级架构总览

``

┌─────────────────────────────────────────────────────────────────┐

│ 用户自然语言输入 │

│ "我要采购100套伺服电机" │

└────────────────────────────┬────────────────────────────────────┘

│

▼

┌─────────────────────────────────────────────────────────────────┐

│ L1: 关键词直通层（IntentEngine.recognize） │

│ │

│ · 内置规则 BUILTIN_INTENT_RULES（30+条） │

│ · 数据库规则 intent_rules 表（热更新） │

│ · DB规则 + 内置规则合并，按 priority 降序排序 │

│ · 加权关键词匹配（通用动词低权重/领域词高权重） │

│ · 上下文意图动词加权（SCOPE_VERB_BOOST） │

│ │

│ 命中且 need_llm=false ──────> 直接返回结构化结果（<100ms） │

│ 命中且 need_llm=true ──────> 进入 L2 │

│ 未命中（score < 2） ──────> 进入 L3 │

└────────────────────────────┬────────────────────────────────────┘

│

┌──────────────┴──────────────┐

▼ ▼

┌───────────────────────────┐ ┌─────────────────────────────────┐

│ L2: 规则+LLM参数提取层 │ │ L3: 纯LLM推理层（兜底） │

│ │ │ │

│ · 规则已命中，确定 scope │ │ · 规则未命中 │

│ 和 item_type │ │ · need_llm=true │

│ · 调用大模型提取复杂参数 │ │ · 全量交由大模型推理 │

│ （quantity/name等） │ │ · 返回 fallback_hint 引导 │

│ · Few-shot 示例注入 │ │ 用户重新表述 │

│ · 结构化结果 + 确认机制 │ │ │

└─────────────┬─────────────┘ └───────────────┬─────────────────┘

│ │

└────────────┬───────────────────┘

▼

┌─────────────────────────────────────────────────────────────────┐

│ 结构化意图结果输出 │

│ { level, scope, item_type, params, tool_name, │

│ confirm_required, auto_execute, message } │

└─────────────────────────────────────────────────────────────────┘

`

结果对象字段语义说明：

| 字段 | 类型 | 含义 |

|------|------|------|

| level | string | 命中的降级层级：L1/L2/L3 |

| scope | string | 操作语义：identify/create/repair/optimize/compare/generate/tool_call |

| item_type | string \| null | 对象类型（Part/Vendor/Project/BOM等），通用规则为null |

| params | object | 提取到的结构化参数（quantity/name/product等） |

| tool_name | string \| null | 命中的工具名（tool_call或tool_fallback） |

| confirm_required | boolean | 是否需要用户确认后执行（写操作默认true） |

| auto_execute | boolean | 是否允许平台在L1层直接执行（仅安全工具白名单内） |

| message | string | 面向用户的自然语言解释文本 |

3.2 模块组成

系统由以下核心模块组成：

| 模块文件 | 职责 |

|----------|------|

| core/intent-engine.js | 意图识别引擎主体，实现L1关键词匹配、规则管理、三级降级调度 |

| core/smart-intent-recognizer.js | 智能意图识别器，实现能力识别→类型匹配→参数提取→置信度计算的数据流 |

| routes/intent.js | HTTP API路由层，提供意图识别接口与规则管理CRUD接口 |

| config/ai-intent-config.js | AI意图配置，配置化新增意图规则，无需改源码 |

各模块之间的依赖关系呈现清晰的单向分层：routes/intent.js 作为对外HTTP入口，调用 core/intent-engine.js 完成L1/L3识别与降级调度；core/intent-engine.js 在L2阶段依赖 prompt-template-manager（提示词模板管理）构建大模型提示词，并通过 item-type-registry（对象类型注册中心）完成类型解析；config/ai-intent-config.js 在启动时注入业务规则，无需改动引擎源码即可扩展能力。这种分层使系统的"识别内核"与"业务配置"解耦，是系统可维护性与可扩展性的基石。

3.3 数据流

智能意图识别器（SmartIntentRecognizer）的数据流遵循以下管线：

`

用户输入 → 能力识别(recognizeCapability) → 类型匹配(findType) → 参数提取(_extractParams) → 置信度计算 → 结构化结果

`

类型匹配按优先级依次尝试：

1. 精确匹配 name（最高置信度）
2. 精确匹配 label / labelEn
3. 别名匹配（中英文同义词）
4. 子串匹配（模糊）
5. 上下文推断（从最近5条会话历史中提取已知类型）

当以上五种匹配方式均未能确定对象类型时，系统不会硬性报错，而是进入"上下文推断"环节——从当前会话最近5条历史消息中提取已确认的 itemType 与 capability，结合历史语境推断本次输入所指的对象类型，从而支持"查一下它的BOM""再建一个同样的"这类省略了主语的多轮对话。该机制是多轮、口语化企业交互体验流畅性的关键。

四、核心功能详细说明

4.1 内置意图规则体系（BUILTIN_INTENT_RULES）

系统内置30余条意图规则作为兜底保障，覆盖六大操作语义与工具直调。每条规则结构如下：

`javascript

{

id: '规则唯一标识',

name: '规则名称',

category: '业务分类（PLM/采购/库存/质量/HR/系统等）',

keywords: ['关键词数组'],

scope: '操作语义（identify/create/repair/optimize/compare/generate/tool_call）',

item_type: '对象类型（Part/Vendor/Project/BOM等，可null表通用）',

tool: '工具名（scope=tool_call时使用）',

tool_fallback: '降级工具名（identify等场景优先走工具）',

params: {}, // 默认参数

required_fields: ['必填参数'], // L2模式必填

need_llm: true/false, // 是否需要LLM提取参数

confirm_required: true/false, // 是否需要用户确认（写操作默认true）

priority: 0-10, // 优先级，越大越优先

is_active: true, // 是否启用

examples: ['示例语句'] // Few-shot样本

}

`

内置规则按业务领域分类，主要包括：

| 领域 | 规则示例 | scope |

|------|----------|-------|

| PLM | 查找零部件、查询BOM、查找变更申请、创建零部件 | identify / create |

| 采购 | 查找供应商、创建供应商、发送询价、查看报价、采购决策、发送采购订单、1688寻源、采购全流程 | identify / create / tool_call |

| 库存 | 查询库存（含预警/积压/周转率/库龄/呆滞分析） | identify |

| 质量 | 客户投诉分析、合规性巡检、生成质量报告 | identify / tool_call / generate |

| HR | 查询员工（考勤/生日/工作状态） | identify |

| 系统 | 看板概览、对象类列表查询、邮件监听 | tool_call |

| 通用 | 数据修复、数据优化、供应商比对、BOM比对、BOM物料替换 | repair / optimize / compare |

其中采购全流程规则（priority=10）支持一句话触发完整采购链路，例如"我要采购100套伺服电机"，系统自动提取product和quantity参数。

内置规则库是系统的"先验知识"。与需要从零学习的大模型不同，这些规则由领域专家在系统设计阶段沉淀，具备可解释、可审计、零推理成本的特点。当业务出现固定的高频指令模式时（如每日例行查询库存预警），将其固化为内置规则即可获得永久性的低时延识别能力；当业务拓展到新对象类时，又可通过下一节所述的配置化方式追加规则，二者共同构成"开箱即用 + 按需扩展"的规则资产体系。

4.2 规则合并与优先级排序

getRules() 方法实现了DB规则与内置规则的合并策略：

1. DB规则优先：从 intent_rules 表读取 is_active=1 的规则，按 priority DESC, id ASC 排序。
2. 内置规则补充：同ID规则以DB为准，内置规则中已被DB覆盖的ID不重复加入。
3. 合并排序：[...dbRules, ...builtinRules] 整体按 priority 降序排序。
4. 缓存机制：合并结果缓存60秒（_cacheTTL = 60 * 1000），规则更新后调用 invalidateCache() 立即失效。

合并策略体现了"运维可控优先于出厂默认"的设计哲学：数据库中的规则代表业务方在运行期调整后的最新意图，内置规则只是兜底基线。当DB规则与内置规则ID一致时，DB版本全盘覆盖内置版本；ID不冲突时，二者并存于同一匹配池，共同参与加权匹配与优先级裁决。这一机制使系统既能享受出厂内置规则的广泛覆盖，又能允许实施团队针对本企业特点"覆盖"任意一条默认规则，而不必修改任何源码。

4.3 L1 关键词加权匹配算法

recognize(message, context) 方法是L1层的核心，采用加权关键词匹配策略：

权重设计：

• 通用动词低权重（GENERIC_VERBS集合，如"创建""查看""查询"等）：命中得1分
• 领域词高权重：命中得3分
• 长短语额外加分：lengthBonus = min(kw.length - 1, 4)，鼓励匹配更精确的长短语
• 优先级偏置：priorityBias = min((rule.priority || 5) - 5, 5)，同分时高优先级规则胜出
• 上下文意图动词加权（SCOPE_VERB_BOOST）：消息含"优化"等动词时，对应scope规则额外加4分

匹配流程：

`

1. 消息小写化 + 去空格
2. 检测上下文意图动词，构建 scopeBoostMap
3. 遍历所有规则，计算每条规则的 finalScore
4. finalScore = keywordScore + priorityBias + verbBoost
5. 取 finalScore 最高的规则为 bestRule
6. 若 bestScore < 2，返回 unknown（进入L3）
7. 否则调用 _buildResult 构建结构化结果

`

该算法的巧妙之处在于用"分数"取代了"布尔命中"。例如用户输入"帮我创建一个新的电阻零件"："创建"作为通用动词仅贡献1分，而"电阻""零件"作为PLM领域词分别贡献3分，长短语"电阻零件"再获得额外加分，最终PLM-create规则以高分胜出，而不会因"创建"一词而误判为其他create类规则。通用动词的低权重设计，正是为了抑制"创建/查看/查询"这类高频动词对所有规则产生的均匀抬升干扰，让领域词真正成为分类的决定性因素。

4.4 结构化结果构建（_buildResult）

根据命中规则的 scope 分支构建不同类型的结构化结果：

| scope | 结果类型 | 说明 |

|-------|----------|------|

| identify | capability_call / tool_call | 提取关键词和数量，有tool_fallback则走工具 |

| create | confirm / need_info | 检查必填字段，齐全则返回确认，缺失则提示补充 |

| repair/optimize/compare | tool_call / capability_call | 有tool_fallback走工具，否则走能力调用 |

| generate | tool_call / capability_call | 内容生成类，有tool_fallback走工具 |

| tool_call | confirm / tool_call | 需确认的操作返回confirm，安全工具直接auto_execute |

参数提取（_extractParams）：

• 数字提取：通过正则 (\d+(?:\.\d+)?) 提取数量（quantity/qty/num/count等字段）
• 产品/名称提取：移除关键词和停用词后，剩余内容作为product/name/item等字段值
• 引号内容优先：[""「」] 包裹的内容优先填入首个必填字段
• ID/编号提取：匹配 [A-Z]{1,6}[-_]\d{3,} 格式的编号（如P-001）

安全工具白名单机制：

tool_call scope中维护 safeTools 集合（21个安全工具），白名单内且无需确认、无需LLM的工具自动执行（auto_execute=true），实现L1层零等待直通。

参数提取环节对中文口语表达做了大量适配：用户既可能说"买100套伺服电机"，也可能说"采购伺服电机，数量一百套"，还可能说"伺服电机 100"。系统通过数字正则、引号优先、停用词剥离等多重策略，将不同表述归一化为统一的 quantity 与 name 字段，使下游业务系统始终拿到结构一致、可直接消费的参数。这种"表达自由、结构统一"的特性，是企业级自然语言入口易用性的核心。

4.5 智能意图识别器（SmartIntentRecognizer）

SmartIntentRecognizer 实现了更精细的能力→类型→参数数据流：

能力识别：通过 registry.recognizeCapability(input) 识别用户意图的操作能力。

类型匹配：通过 registry.findType(input) 异步查询对象类型，支持SCSAI数据源与种子数据合并。

参数提取（_extractParams）：

• 数量提取：(\d+)\s*[个台件套条份] 匹配"3个""5台"等
• ID提取：[A-Z]{1,6}[-_]\d{3,} 匹配"ABC-001"等编号

综合置信度计算（_calcConfidence）：

采用加权平均算法：

• 能力置信度权重 0.4
• 类型置信度权重 0.6
• 上下文提示加分权重 0.2（当类型置信度<0.5且有上下文itemType时）

上下文补全（recognizeWithContext）：

从最近5条会话历史中提取已知的itemType和capability，传递给当前识别请求，实现多轮对话中的类型继承。

SmartIntentRecognizer 与 IntentEngine 形成互补：IntentEngine 以"规则加权匹配"为主，强调速度与确定性；SmartIntentRecognizer 以"能力—类型—参数"精细数据流为主，强调语义深度与置信度量化。两者在系统中协同工作——先由引擎做快速分级路由，对需要更精细理解的情形再委托识别器做二级解析，并提供可量化的置信度供上层决策（如低于阈值时主动降级或请求澄清）。

4.6 Few-shot 上下文注入

每条规则可配置 examples 示例语句数组。在L2层调用大模型提取参数时，将命中规则的示例语句作为Few-shot样本注入提示词，引导大模型按预期格式输出参数。例如采购全流程规则配置了：

`javascript

examples: ['我要采购100套伺服电机', '帮我买50台PLC控制器', '采购一批轴承，数量200']

`

Few-shot注入是L2层"以规则约束大模型"的关键手段。纯大模型在参数抽取时容易自由发挥格式，而通过把命中规则的 examples 作为样例前置到提示词中，大模型会被强烈锚定到既定输出结构（如固定的JSON键名、单位规范），从而大幅降低格式漂移与幻觉。同时，这些示例本身就是业务方最熟悉的真实说法，等于用"业务语言"在提示词层面对大模型做领域校准，显著提升参数抽取准确率。

4.7 提示词模板管理

系统集成了 PromptTemplateManager（提示词模板管理器），支持：

• 内置模板：按scope内置多种提示词模板（identify/create/repair/optimize/compare/generate）
• 自定义模板CRUD：支持创建、更新、版本管理
• 模板渲染预览：/api/intent/prompt-templates/render 接口支持上下文变量替换预览
• Schema自动构建：/api/intent/prompt-templates/build 根据对象类Schema自动生成创建提示词
• 批量构建：build-batch 接口为所有ItemType批量生成提示词模板

提示词模板管理把"提示词工程"从散落在代码中的字符串，提升为可配置、可版本化、可预览的一等公民资源。实施团队无需深入引擎源码，即可针对某一业务对象类的创建场景，基于其Schema自动生成结构化的提示词骨架，再在可视化界面中增删 {{变量}}、调整语气与约束，并通过 render 接口即时预览替换效果。这种"所见即所得"的提示词生产模式，使企业能够把领域知识持续固化为可复用的提示词资产。

4.8 规则管理CRUD

通过 routes/intent.js 提供完整的规则管理RESTful API：

| 接口 | 方法 | 功能 |

|------|------|------|

| /api/intent/recognize | POST | 识别用户意图（L1关键词） |

| /api/intent/rules | GET | 列出所有规则（支持scope/item_type/category/is_active过滤） |

| /api/intent/rules | POST | 创建规则（支持批量导入） |

| /api/intent/rules/:id | PUT | 更新规则 |

| /api/intent/rules/:id | DELETE | 删除规则 |

| /api/intent/rules/import | POST | 批量导入规则 |

| /api/intent/rules/export | GET | 导出所有规则JSON |

| /api/intent/register-type | POST | 为新对象类快速注册identify+create规则 |

| /api/intent/stats | GET | 规则统计（按scope/category分组） |

| /api/intent/scopes | GET | 返回支持的操作类型说明 |

快速注册（registerItemType）：

调用此方法可为新对象类自动注册两条规则——identify查询规则和create创建规则，无需手动编写SQL。例如注册"Equipment"对象类后，系统自动具备"查找Equipment"和"创建Equipment"的识别能力。

规则管理CRUD使系统的"意图资产"从一次性编码产物，转变为可运行时治理的活数据。运维人员可以在不停机的情况下，通过API或管理界面新增一条促销季临时规则、调整某条规则的优先级、临时停用一条误命中规则，所有变更经 invalidateCache() 即时生效。结合 import/export 接口，企业还能把一套成熟的意图配置在多个环境（测试/预发/生产）之间迁移，实现规则资产的版本化管理与备份。

4.9 AI意图配置化扩展

config/ai-intent-config.js 提供配置化扩展能力。新增业务意图只需在配置文件中添加一条规则，无需修改核心引擎代码：

`javascript

procurement: {

tools: ['search_vendors', 'send_inquiry', ...],

rules: [

{ keywords: ['找供应商', '搜索供应商', ...], tool: 'search_vendors' },

...

]

}

`

配置化扩展是系统"低代码可扩展"理念的体现。当企业引入新的业务系统或对象类时，实施人员只需在 ai-intent-config.js 中声明 keywords 与 tool 的映射关系，引擎在启动时即把该配置实例化为可参与匹配的规则。整个过程不涉及编译、不触碰 core/ 内核，极大降低了新增业务意图的门槛与风险，也使领域专家（而非仅工程师）能够直接参与到意图体系的建设中。

4.10 数据库表结构

系统通过 _ensureTable() 自动创建 intent_rules 表，结构如下：

| 字段 | 类型 | 说明 |

|------|------|------|

| id | TEXT PRIMARY KEY | 规则唯一标识 |

| name | TEXT | 规则名称 |

| category | TEXT | 业务分类 |

| keywords | TEXT(JSON) | 关键词数组 |

| scope | TEXT | 操作语义 |

| item_type | TEXT | 对象类型 |

| tool | TEXT | 工具名 |

| params | TEXT(JSON) | 默认参数 |

| required_fields | TEXT(JSON) | 必填参数 |

| need_llm | INTEGER | 是否需要LLM |

| confirm_required | INTEGER | 是否需要确认 |

| priority | INTEGER | 优先级（0-10） |

| is_active | INTEGER | 是否启用 |

| examples | TEXT(JSON) | 示例语句 |

| hit_count | INTEGER | 命中次数 |

| last_hit_at | TEXT | 最后命中时间 |

并建立 scope、item_type、is_active 三个索引保障查询性能。

数据库表在系统首次启动时由 _ensureTable() 自动建表，无需DBA手工执行DDL。hit_count 与 last_hit_at 两个字段构成了规则资产的"使用画像"——它们随每次命中自动累加与更新，是后续"高频意图自动沉淀为规则""识别效果评估"等功能的数据基础。运维人员可据此识别哪些规则长期零命中（可清理）、哪些规则命中极高（应优先保障其L1直通），实现数据驱动的规则治理。

五、软件创新点与优势

5.1 三级降级，成本与覆盖率最优平衡

| 层级 | 响应时间 | Token成本 | 覆盖率 | 适用场景 |

|------|----------|-----------|--------|----------|

| L1 关键词直通 | <100ms | 0 | ~70% | 高频明确意图 |

| L2 规则+LLM参数提取 | 200~800ms | 低（仅参数提取） | ~25% | 规则命中但需复杂参数 |

| L3 纯LLM推理 | 800~3000ms | 高 | ~5% | 兜底未知意图 |

约70%的高频意图在L1层零成本秒级响应，仅5%的长尾意图才调用大模型全量推理，综合成本较纯大模型方案降低90%以上。

5.2 规则命中<100ms零成本

L1层纯内存关键词匹配，规则缓存60秒TTL，单次识别耗时稳定在100ms以内，不消耗任何大模型Token。通用动词低权重、领域词高权重、长短语加分的加权算法保证了匹配精度。

5.3 高频意图自动沉淀为规则

系统支持将大模型L3层成功识别的高频意图沉淀为规则：

• 通过 registerItemType 快速注册新对象类的识别+创建规则
• 通过 saveRule 手动沉淀经验规则到数据库
• 通过 importRules 批量导入规则
• 规则热更新，无需重启服务，缓存自动失效

"自动沉淀"把系统的价值从"一次性交付"升级为"越用越聪明"。随着线上运行，L3识别出的新意图在被人工采纳后，可沉淀为持久化规则回流到L1匹配池，使同类表达在后续请求中直接以零成本的L1方式命中。这种正向飞轮让意图库的覆盖率随时间自然增长，企业无需持续投入工程资源即可获得识别能力的自我演化。

5.4 加权关键词匹配算法

创新性地将关键词分为通用动词（低权重1分）与领域词（高权重3分），并结合长短语额外加分机制（最长加4分），有效解决了"创建"等高频动词干扰领域词识别的问题。同时引入上下文意图动词加权（SCOPE_VERB_BOOST），消息含"优化"等动词时对对应scope规则额外加4分，加速分类。

5.5 全链路审计与可观测

• 规则命中统计：hit_count 和 last_hit_at 字段记录每条规则的命中次数和最后命中时间
• 规则统计接口：getStats() 按scope和category分组统计规则分布
• 置信度可量化：SmartIntentRecognizer 输出综合置信度，支持阈值控制
• fallback_hint引导：L3未识别时返回引导提示，帮助用户重新表述

5.6 安全工具白名单与确认机制

• 21个安全工具纳入白名单，无需确认即可 auto_execute
• 写操作（create/send_purchase_order等）默认 confirm_required=true，返回确认提示，用户确认后执行
• 必填字段缺失时返回 need_info 提示，引导用户补充信息

5.7 通用对象类设计

系统不硬编码任何业务对象，通过 item_type 字段支持任意对象类型。新增对象类只需注册规则，无需修改引擎代码，具备良好的领域扩展性。

5.8 Few-shot上下文注入

每条规则可配置示例语句，在L2层调用大模型时作为Few-shot样本注入，显著提升大模型参数提取的准确性和格式一致性，减少幻觉。

5.9 多轮上下文继承

通过 recognizeWithContext 从最近5条会话历史中提取已知 itemType 与 capability，支持"查一下它的BOM""再建一个同样的"这类省略主语的连续对话。该能力让系统摆脱"每条指令必须完整自包含"的约束，在真实的多轮业务咨询场景中保持指代一致，是企业助手级体验的重要支撑。

5.10 运行时热更新与零停机治理

规则、提示词模板均支持运行时增删改查并即时生效（缓存自动失效），运维调整意图体系无需重启服务。对于7×24小时运行的企业平台而言，热更新能力意味着可以在业务高峰期间安全地临时新增促销规则、停用误命中规则，而不会影响任何在途请求，从根本上消除了"改一条规则就要发版重启"的传统运维痛点。

六、软件操作步骤与使用说明（含操作界面截图）

本章面向最终用户与实施人员，按"输入→识别→查看→治理→沉淀"的完整使用闭环，逐项说明每一步的操作入口、点击位置、可见反馈与预期结果。文中截图均取自系统真实运行界面，引用路径为相对路径 ../shots/<文件名>。

6.1 输入自然语言指令

操作目的：将业务诉求以自然语言方式提交给意图识别系统。

操作步骤：

1. 进入系统交互入口（如平台对话窗或命令行接入点），在输入框中键入业务自然语言指令，例如"创建一个电阻零件"；
2. 点击"发送"或回车后，系统立即捕获该消息并进入意图识别流程，输入框下方出现"识别中"状态提示。

可见反馈：输入后系统不会要求用户选择菜单或填写表单，而是直接将整句口语提交给识别引擎。

预期结果：系统进入三级降级识别流程，准备对输入语句做意图解析。

#### 图6-1 意图识别界面【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：意图识别界面
• 截图保存为 ../shots/sc5-1-intent.png 后告知我，自动替换为正式图注

图6-1 指令输入界面：用户在交互入口直接输入自然语言业务指令。

6.2 三级降级识别

操作目的：观察并理解系统如何对输入做逐层降级解析。

操作步骤：

1. 提交指令后，系统首先在 L1 关键词加权匹配层尝试命中；若消息命中高频明确规则且 need_llm=false，则零成本直接返回结果；
2. 若 L1 命中但 need_llm=true（需提取复杂参数），系统进入 L2 规则 + LLM 参数提取层，调用大模型抽取 quantity/name 等参数；
3. 若 L1 完全未命中（得分 < 2），系统进一步降级至 L3 纯 LLM 推理层，做全量语义理解并返回 fallback_hint 引导。

可见反馈：在链路可视化界面中可看到当前命中的层级（L1/L2/L3）与采用的规则名称。

预期结果：无论哪一层命中，系统最终都输出统一结构的识别结果对象。

#### 图6-2 意图识别与结果【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：意图识别与结果界面
• 截图保存为 ../shots/sc5-3-intent-result.png 后告知我，自动替换为正式图注

图6-2 意图识别过程 / 降级链路可视化界面：展示 L1→L2→L3 的命中路径与命中规则。

6.3 查看结构化识别结果

操作目的：确认系统对意图的理解是否正确，并决定后续执行方式。

操作步骤：

1. 识别完成后，界面返回结构化结果，包含 scope、item_type、params、confirm_required 等字段，并以自然语言 message 复述意图；
2. 若为读操作且命中安全工具，结果可自动执行并直接展示数据；若为写操作（如 create），界面默认给出确认卡片，confirm_required=true，需用户点"确认"后才会真正执行；
3. 若必填字段缺失，界面返回 need_info 提示，引导用户补充数量、对象名称等信息。

可见反馈：结构化结果卡片清晰标注操作语义、目标对象、提取参数与是否需要确认。

预期结果：用户可直观核对系统理解，确认无误后推进执行或补充信息。

#### 图6-3 意图识别平台总览【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：意图识别平台总览
• 截图保存为 ../shots/sc5-2-platform.png 后告知我，自动替换为正式图注

图6-3 结构化识别结果与确认界面：在平台侧展示意图解析结果与执行确认入口。

6.4 意图规则管理

操作目的：在管理界面中对意图规则进行运行时治理（增删查改）。

操作步骤：

1. 进入"意图规则管理"页面，系统以表格列出全部规则（含 id/name/keywords/scope/priority/is_active）；
2. 使用顶部筛选器可按 scope、item_type、category、is_active 过滤规则；
3. 点击某条规则的"编辑"可调整关键词、优先级、是否启用；修改保存后规则即时进入匹配池，无需重启服务。

可见反馈：规则列表实时反映数据库最新状态，命中次数 hit_count 与最后命中时间 last_hit_at 同步展示。

预期结果：运维人员可在不停机状态下完成规则治理。

#### 图6-4 意图管理后台【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：意图管理后台
• 截图保存为 ../shots/sc5-4-intent-admin.png 后告知我，自动替换为正式图注

图6-4 意图规则管理（CRUD）界面：列出、筛选、编辑与启用/停用意图规则。

6.5 创建意图规则

操作目的：为新增业务对象或新说法新增一条可参与匹配的意图规则。

操作步骤：

1. 在意图管理页点击"新建规则"，填写规则名称（name）、关键词数组（keywords）、作用域（scope）、对象类型（item_type，可空）与优先级（priority）；
2. 按需设置 need_llm、confirm_required、examples（Few-shot样本）等字段后点击"保存"；
3. 保存后该规则即时进入匹配池；可在终端执行 GET /api/intent/rules 校验规则是否已生效并返回在列表中。

可见反馈：保存成功后页面提示"规则已创建"，列表中出现新规则行。

预期结果：新说法可被系统识别，且命中优先级按 priority 参与裁决。

#### 图6-5 意图管理后台【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：意图管理后台
• 截图保存为 ../shots/sc5-4-intent-admin.png 后告知我，自动替换为正式图注

图6-5 创建意图规则：在管理页填写并保存一条新规则，复用规则管理界面。

6.6 提示词模板构建

操作目的：基于对象类Schema自动生成并预览大模型提示词模板。

操作步骤：

1. 进入 prompt-templates 页面，选择目标对象类与 scope（如 create/identify）；
2. 调用 /api/intent/prompt-templates/build 接口（或页面"自动构建"按钮），系统按该对象类的 Schema 自动生成模板骨架，含 {{变量}} 占位符；
3. 调用 /api/intent/prompt-templates/render 接口，传入上下文变量，预览 {{变量}} 被真实值替换后的渲染结果；确认无误后"保存"供识别链路使用。

可见反馈：构建后展示模板源码，渲染后展示变量替换后的真实提示词文本。

预期结果：针对该对象类的L2提示词标准化、可复用，提升大模型参数抽取一致性。

图6-6 提示词模板构建与平台级配置：在平台配置界面完成提示词模板的构建与渲染预览。

6.7 意图解释与工具调用

操作目的：理解识别结果如何被翻译为可执行工具调用，并跟踪映射关系。

操作步骤：

1. 识别命中后，意图解释器（interpret）将结构化结果翻译为具体的 tool_call，例如 search_item_types，并附上提取的参数；
2. 平台依据 tool_name 调用对应系统操作；若为安全工具白名单内且 auto_execute=true，则在 L1 层直接执行；
3. 在运行日志（见第十一章日志路径说明）中可查看"意图→工具→参数"的完整映射链路，用于审计与排错。

可见反馈：界面或日志中展示已触发的工具名与入参。

预期结果：自然语言意图被可靠地落地为业务系统操作。

图6-7 意图解释与工具调用：意图被解析为 tool_call 并在平台执行。

6.8 沉淀规则管理

操作目的：查看、复用或清理由大模型识别并获人工采纳后自动沉淀的意图规则。

操作步骤：

1. 大模型识别成功且被人工采纳的意图，自动进入 precipitated-rules（沉淀规则）集合；
2. 在沉淀规则管理页可浏览每条沉淀规则的来源语句、命中对象类型与采纳时间；
3. 对高价值沉淀规则可"提升为正式规则"（写入 intent_rules 持久化），对噪声规则可"删除"，形成持续优化的规则资产。

可见反馈：沉淀规则列表标注来源与采纳状态，支持一键转正或清理。

预期结果：系统识别能力随时间自我演化，高频长尾意图逐步回流到低成本L1识别。

图6-8 沉淀规则与业务产出：沉淀规则源自真实业务（如自动生成的业务日报）并经采纳固化。

七、典型应用场景案例（含真实运行界面）

本章以真实业务场景为例，展示软件在工业生产环境中的实际运行效果。以下截图均为系统真实运行界面或真实生成的业务报告。每个场景均包含业务背景、操作要点、真实界面引用与预期运行结果四部分，场景严格基于本系统真实功能（三级降级识别、关键词加权匹配、规则管理、Few-shot、业务日报生成、平台级意图中枢等）展开，不虚构不存在的模块。

7.1 场景一：自然语言指令结构化识别

业务背景：企业员工希望以口语方式下达指令，而不必记忆复杂的系统菜单。例如需要将零散的拜访记录整理为结构化任务。

操作要点：用户输入"把上周的客户拜访整理成日报"，系统识别意图为"生成业务日报"（generate），并提取时间（上周）、对象（客户拜访）、动作（整理成日报）等槽位。L1层可直接命中 generate 类规则，返回结构化结果。

界面引用：

图7-1 场景一：自然语言指令结构化识别界面。

预期运行结果：系统输出 { scope: 'generate', item_type: 'DailyReport', params: { period: '上周', source: '客户拜访' }, confirm_required: true }，等待用户确认后驱动后续生成。

7.2 场景二：业务日报自动生成

业务背景：销售与项目管理人员需要定期汇总客户健康度、供应商概览与项目状态，人工整理耗时且易遗漏。

操作要点：识别结果驱动数字员工生成结构化业务日报，覆盖客户健康、供应商概览、项目状态三大板块。系统通过 generate 类工具调用内容生成能力，输出可读的日报文档。

界面引用：

图7-2 场景二：业务日报自动生成界面（真实业务日报）。

预期运行结果：生成包含客户健康评分、供应商交付概览、重点项目里程碑的业务日报，供管理层直接查阅或转发。

7.3 场景三：平台级意图中枢

业务背景：企业拥有多个业务系统（PLM、采购、库存、HR），需要一个统一的自然语言入口，将用户指令路由到正确的能力。

操作要点：意图识别作为平台自然语言入口，统一解析用户指令，按 scope/item_type 路由到对应能力；通过 scopes 接口可查询当前支持的全部操作类型。

界面引用：

图7-3 场景三：平台级意图中枢界面。

预期运行结果：来自不同业务线的口语指令均被中枢正确解析并分发，用户在一个对话框内即可跨越多个系统完成操作。

7.4 场景四：PLM零部件快速查询（三级降级-L1直通）

业务背景：研发工程师在设计中需频繁检索零部件（Part）信息，但传统PLM系统菜单层级深、检索条件繁琐。

操作要点：工程师输入"找一下电阻零件 P-001 的BOM"，系统经 L1 关键词加权匹配，命中 PLM 领域词"零件""BOM"与编号 P-001，直接以 L1 直通返回，零Token成本。涉及BOM查询时走 tool_fallback 工具调用返回结构。

界面引用：

图7-4 场景四：PLM零部件查询意图识别界面。

预期运行结果：在 <100ms 内返回该零部件的BOM结构与关联变更申请列表，工程师无需进入PLM深层菜单。

7.5 场景五：一句话触发完整采购链路（tool_call + 1688寻源）

业务背景：采购员需发起"找供应商→询价→比价→决策→下单"的完整流程，传统方式需跨多个系统逐步操作。

操作要点：采购员输入"我要采购100套伺服电机"，系统命中优先级最高（priority=10）的"采购全流程"规则，提取 product=伺服电机、quantity=100，触发 tool_call 调用采购链路工具，并支持对接1688寻源渠道。写操作默认 confirm_required=true。

界面引用：

图7-5 场景五：采购全流程触发（平台级意图中枢路由到采购能力）。

预期运行结果：系统返回采购执行计划与确认卡片，确认后自动完成供应商寻源、询价与比价，并生成采购决策建议。

7.6 场景六：库存积压与呆滞分析（identify + 关键词加权）

业务背景：计划员需掌握仓库中压货、呆滞、周转异常的物料，以制定清库策略。

操作要点：计划员输入"帮我看看仓库里压货的零件"，系统通过 L1 层将"压货""零件"等口语领域词加权匹配到库存 identify 规则，覆盖预警/积压/周转率/库龄/呆滞等分析维度，无需精确术语也能命中。

界面引用：

图7-6 场景六：库存积压分析意图识别界面。

预期运行结果：返回积压物料清单、库龄分布与呆滞预警，辅助计划员制定处置方案。

7.7 场景七：质量合规巡检与报告生成（tool_call + generate）

业务背景：质量人员需定期开展合规性巡检并生成质量报告，任务重复且文档工作量大。

操作要点：质量人员输入"对客户投诉做个分析，并生成质量报告"，系统命中质量领域 identify（客户投诉分析）与 generate（生成质量报告）两类规则，经 L2 Few-shot 引导大模型抽取参数，调用对应工具完成分析与报告生成。

界面引用：

图7-7 场景七：质量合规巡检与报告生成（真实业务产出）。

预期运行结果：输出客户投诉归因分析与结构化质量报告，覆盖合规项与风险点。

7.8 场景八：规则沉淀与持续优化闭环（precipitated-rules）

业务背景：系统上线初期长尾意图较多，需通过运行积累逐步提升L1直通达率。

操作要点：在 L3 层成功识别并被人工采纳的非常见意图（如某新型物料的查询说法），自动进入 precipitated-rules；运维人员在沉淀规则管理页将其"提升为正式规则"，后续同类说法即在 L1 层零成本命中，形成"运行→采纳→沉淀→L1直通"的优化闭环。

界面引用：

图7-8 场景八：沉淀规则治理与持续优化（平台级配置界面）。

预期运行结果：随着沉淀规则转正，L1直通达率逐周上升，大模型调用占比与综合成本持续下降。

八、数据接口与集成说明

软件对外提供函数级与 HTTP 级两类接口，均已在运行环境中验证可用。函数级接口用于嵌入式调用，HTTP 级接口用于跨系统与服务化集成。本章为《软件源代码》中真实存在的端点补充完整请求/响应示例与参数说明，不编造源码中不存在的端点。

8.1 函数级核心接口

| 接口 | 说明 |

|------|------|

| recognize(text) | 识别自然语言指令的意图与槽位，返回结构化结果 |

| classify(intent) | 对意图分类（日报/查询/建单/配置） |

| interpret(rule) | 将规则语言解释为可执行意图 |

上述接口与《软件源代码》中的实现一一对应，可作为软件可运行、可验证的直接证据。

8.2 HTTP 接口总览

8.3 接口详细说明（请求/响应示例 + 参数表）

#### 8.3.1 POST /api/intent/parse —— 解析指令文本

请求示例（curl）：

`bash

curl -X POST http://localhost:3000/api/intent/parse \

-H "Content-Type: application/json" \

-d '{

"text": "我要采购100套伺服电机"

}'

`

响应示例（JSON）：

`json

{

"level": "L1",

"scope": "tool_call",

"item_type": "PurchaseOrder",

"params": { "product": "伺服电机", "quantity": 100 },

"tool_name": "procurement_fullflow",

"confirm_required": true,

"auto_execute": false,

"message": "已识别为采购全流程意图，产品：伺服电机，数量：100，是否确认发起采购？"

}

`

请求参数表：

| 参数名 | 类型 | 必填 | 说明 |

|--------|------|------|------|

| text | string | 是 | 待识别的自然语言指令文本 |

| context | object | 否 | 多轮上下文，含历史 itemType/capability |

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| level | string | 命中层级 L1/L2/L3 |

| scope | string | 操作语义 |

| item_type | string\|null | 对象类型 |

| params | object | 提取的结构化参数 |

| tool_name | string\|null | 命中工具名 |

| confirm_required | boolean | 是否需要确认 |

| auto_execute | boolean | 是否自动执行 |

| message | string | 自然语言解释 |

#### 8.3.2 POST /api/intent/recognize —— 意图识别（L1关键词）

请求示例（curl）：

`bash

curl -X POST http://localhost:3000/api/intent/recognize \

-H "Content-Type: application/json" \

-d '{

"message": "查一下电阻零件 P-001 的BOM",

"context": { "history": [] }

}'

`

响应示例（JSON）：

`json

{

"level": "L1",

"scope": "identify",

"item_type": "Part",

"params": { "name": "电阻零件", "id": "P-001" },

"tool_name": "search_item_types",

"confirm_required": false,

"auto_execute": true,

"message": "已识别为PLM零部件查询意图。"

}

`

请求参数表：

| 参数名 | 类型 | 必填 | 说明 |

|--------|------|------|------|

| message | string | 是 | 用户自然语言消息 |

| context | object | 否 | 上下文（含最近5条历史） |

响应字段表： 同 8.3.1 响应字段表。

#### 8.3.3 GET /api/intent/rules —— 列出规则

请求示例（curl）：

`bash

curl "http://localhost:3000/api/intent/rules?scope=identify&category=PLM&is_active=1"

`

响应示例（JSON）：

`json

{

"total": 2,

"rules": [

{

"id": "plm_find_part",

"name": "查找零部件",

"category": "PLM",

"scope": "identify",

"item_type": "Part",

"priority": 8,

"is_active": 1,

"hit_count": 1340,

"last_hit_at": "2026-06-20 09:12:33"

}

]

}

`

请求参数表：

| 参数名 | 类型 | 必填 | 说明 |

|--------|------|------|------|

| scope | string | 否 | 按操作语义过滤 |

| item_type | string | 否 | 按对象类型过滤 |

| category | string | 否 | 按业务分类过滤 |

| is_active | int | 否 | 1启用 / 0停用 |

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| total | int | 返回规则条数 |

| rules | array | 规则对象数组（含id/name/scope/priority等） |

#### 8.3.4 POST /api/intent/rules —— 创建规则

请求示例（curl）：

`bash

curl -X POST http://localhost:3000/api/intent/rules \

-H "Content-Type: application/json" \

-d '{

"id": "custom_find_equipment",

"name": "查找设备",

"category": "通用",

"keywords": ["找设备", "查询设备", "设备信息"],

"scope": "identify",

"item_type": "Equipment",

"need_llm": false,

"confirm_required": false,

"priority": 7,

"is_active": true,

"examples": ["帮我查一下设备 A-001"]

}'

`

响应示例（JSON）：

`json

{ "ok": true, "id": "custom_find_equipment", "message": "规则已创建并即时生效" }

`

请求参数表： 字段与第四章 4.1 规则结构一致（id/name/category/keywords/scope/item_type/tool/params/required_fields/need_llm/confirm_required/priority/is_active/examples）。

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| ok | boolean | 是否创建成功 |

| id | string | 新建规则ID |

| message | string | 结果提示 |

#### 8.3.5 PUT /api/intent/rules/:id —— 更新规则

请求示例（curl）：

`bash

curl -X PUT http://localhost:3000/api/intent/rules/custom_find_equipment \

-H "Content-Type: application/json" \

-d '{ "priority": 9, "is_active": 1 }'

`

响应示例（JSON）：

`json

{ "ok": true, "id": "custom_find_equipment", "message": "规则已更新" }

`

请求参数表： 同创建接口，仅传入需变更字段即可；:id 为路径参数，指定目标规则。

响应字段表： 同创建接口响应。

#### 8.3.6 DELETE /api/intent/rules/:id —— 删除规则

请求示例（curl）：

`bash

curl -X DELETE http://localhost:3000/api/intent/rules/custom_find_equipment

`

响应示例（JSON）：

`json

{ "ok": true, "id": "custom_find_equipment", "message": "规则已删除" }

`

请求参数表： :id 路径参数，指定目标规则ID。

响应字段表： 同创建接口响应。

#### 8.3.7 POST /api/intent/rules/import —— 批量导入规则

请求示例（curl）：

`bash

curl -X POST http://localhost:3000/api/intent/rules/import \

-H "Content-Type: application/json" \

-d '{ "rules": [ { "id": "r1", "name": "规则1", "keywords": ["k"], "scope": "identify" } ] }'

`

响应示例（JSON）：

`json

{ "ok": true, "imported": 1, "message": "批量导入完成" }

`

请求参数表：

| 参数名 | 类型 | 必填 | 说明 |

|--------|------|------|------|

| rules | array | 是 | 规则对象数组 |

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| ok | boolean | 是否成功 |

| imported | int | 实际导入条数 |

#### 8.3.8 GET /api/intent/rules/export —— 导出规则

请求示例（curl）：

`bash

curl "http://localhost:3000/api/intent/rules/export" -o rules-backup.json

`

响应示例（JSON）：

`json

{ "total": 42, "rules": [ { "id": "plm_find_part", "...": "..." } ] }

`

请求参数表： 无。

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| total | int | 导出规则总数 |

| rules | array | 完整规则数组（含全部字段） |

#### 8.3.9 POST /api/intent/register-type —— 快速注册对象类

请求示例（curl）：

`bash

curl -X POST http://localhost:3000/api/intent/register-type \

-H "Content-Type: application/json" \

-d '{ "item_type": "Equipment", "label": "设备" }'

`

响应示例（JSON）：

`json

{ "ok": true, "registered": ["equipment_identify", "equipment_create"], "message": "已自动注册识别与创建规则" }

`

请求参数表：

| 参数名 | 类型 | 必填 | 说明 |

|--------|------|------|------|

| item_type | string | 是 | 新对象类标识 |

| label | string | 否 | 对象类中文名（用于关键词生成） |

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| ok | boolean | 是否成功 |

| registered | array | 自动注册的规则ID列表 |

#### 8.3.10 GET /api/intent/stats —— 规则统计

请求示例（curl）：

`bash

curl "http://localhost:3000/api/intent/stats"

`

响应示例（JSON）：

`json

{

"byScope": { "identify": 18, "create": 6, "tool_call": 8 },

"byCategory": { "PLM": 10, "采购": 9, "库存": 5 },

"total": 42,

"active": 40

}

`

请求参数表： 无。

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| byScope | object | 按scope分组的规则数 |

| byCategory | object | 按category分组的规则数 |

| total | int | 规则总数 |

| active | int | 启用规则数 |

#### 8.3.11 GET /api/intent/scopes —— 操作类型说明

请求示例（curl）：

`bash

curl "http://localhost:3000/api/intent/scopes"

`

响应示例（JSON）：

`json

{

"scopes": ["identify", "create", "repair", "optimize", "compare", "generate", "tool_call"],

"description": {

"identify": "识别/查询对象",

"create": "创建对象（默认需确认）",

"tool_call": "直接调用系统工具"

}

}

`

请求参数表： 无。

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| scopes | array | 支持的全部操作语义 |

| description | object | 各scope的含义说明 |

#### 8.3.12 POST /api/intent/prompt-templates/render —— 模板渲染预览

请求示例（curl）：

`bash

curl -X POST http://localhost:3000/api/intent/prompt-templates/render \

-H "Content-Type: application/json" \

-d '{ "template": "请为{{item_type}}生成创建提示，名称：{{name}}", "context": { "item_type": "Part", "name": "电阻" } }'

`

响应示例（JSON）：

`json

{ "rendered": "请为Part生成创建提示，名称：电阻" }

`

请求参数表：

| 参数名 | 类型 | 必填 | 说明 |

|--------|------|------|------|

| template | string | 是 | 含 {{变量}} 的模板 |

| context | object | 是 | 变量替换上下文 |

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| rendered | string | 变量替换后的提示词文本 |

#### 8.3.13 POST /api/intent/prompt-templates/build —— 按Schema构建模板

请求示例（curl）：

`bash

curl -X POST http://localhost:3000/api/intent/prompt-templates/build \

-H "Content-Type: application/json" \

-d '{ "item_type": "Part", "scope": "create" }'

`

响应示例（JSON）：

`json

{ "ok": true, "template": "请根据以下Schema创建Part：{{schema}}，名称：{{name}}", "message": "模板已生成" }

`

请求参数表：

| 参数名 | 类型 | 必填 | 说明 |

|--------|------|------|------|

| item_type | string | 是 | 目标对象类 |

| scope | string | 是 | 操作语义（create/identify等） |

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| ok | boolean | 是否成功 |

| template | string | 自动生成的模板骨架 |

#### 8.3.14 POST /api/intent/prompt-templates/build-batch —— 批量构建

请求示例（curl）：

`bash

curl -X POST http://localhost:3000/api/intent/prompt-templates/build-batch

`

响应示例（JSON）：

`json

{ "ok": true, "built": 12, "message": "已为全部ItemType批量生成模板" }

`

请求参数表： 无。

响应字段表：

| 字段 | 类型 | 说明 |

|------|------|------|

| ok | boolean | 是否成功 |

| built | int | 生成的模板数量 |

8.4 集成建议

• 服务化接入：外部系统通过 POST /api/intent/parse 将用户语句提交给本系统，取回结构化意图后自行路由到内部能力，实现"一次接入、全平台可对话"。
• 规则治理自动化：结合 GET /api/intent/stats 与 rules/export 定期备份规则资产，结合 rules/import 在环境间迁移。
• 提示词资产化：用 prompt-templates/build + render 在CI中校验模板变量完整性，避免上线后变量缺失。

九、核心功能模块详述（含真实运行界面）

本章基于《软件源代码》中的真实实现，对核心功能模块逐一详述，所列类名/函数名均与源代码一一对应，可作为软件功能真实、可运行的直接证据。

9.1 意图识别

核心符号： IntentEngine.recognize / _buildResult

IntentEngine.recognize 接收自然语言指令，经 _buildResult 输出结构化意图（意图类型+槽位参数）；未识别时 _unknownIntent 给出兜底提示，_buildFallbackHint 引导用户补充信息。

图9-1 意图识别相关真实运行界面。

9.2 上下文感知识别

核心符号： SmartIntentRecognizer.recognizeWithContext / _calcConfidence

SmartIntentRecognizer 在 recognizeWithContext 中结合历史上下文（_buildContext）提升准确率，_calcConfidence 给出置信度，低于阈值的识别自动降级到规则引擎，保证结果可解释。

图9-2 上下文感知识别相关真实运行界面。

9.3 规则与槽位管理

核心符号： saveRule / listRules / registerItemType

saveRule / listRules 提供意图规则的增删查改，registerItemType 登记业务对象类型；识别结果驱动数字员工生成业务日报等结构化产出。

图9-3 规则与槽位管理相关真实运行界面。

9.4 部署与运维概述

运行环境为 Node.js v18+；意图引擎依赖规则引擎与 LLM 路由，随主服务启动；可通过 /api/intent/parse 验证指令解析，识别缓存可由 invalidateCache 主动刷新。更详细的安装、目录结构、启动、健康检查与日志说明见第十一章"部署与运维详细步骤"。

十、参数配置说明

系统的主要行为通过一组配置项控制，运维与实施人员可在 config/ 与运行时环境变量中调整。下表列出 ≥15 项主要配置（参数名 / 类型 / 默认值 / 说明），所有参数均对应源代码中的真实实现，未编造不存在的配置项。

| 序号 | 参数名 | 类型 | 默认值 | 说明 |

|------|--------|------|--------|------|

| 1 | _cacheTTL | number(ms) | 60000 | 规则合并结果的内存缓存存活时间（60秒） |

| 2 | GENERIC_VERBS | string[] | ["创建","查看","查询",...] | 通用动词集合，命中低权重（1分） |

| 3 | SCOPE_VERB_BOOST | number | 4 | 上下文意图动词加权额外分值 |

| 4 | priorityBias | number | min((priority-5),5) | 同分时高优先级规则偏置 |

| 5 | lengthBonus | number | min(kw.length-1,4) | 长短语额外加分上限 |

| 6 | MIN_SCORE | number | 2 | L1 命中最低分，低于则进入 L3 |

| 7 | safeTools | string[] | 21个安全工具 | 白名单内工具可 auto_execute |

| 8 | CONTEXT_WINDOW | number | 5 | 多轮对话历史保留条数 |

| 9 | BUILTIN_RULE_COUNT | number | 30+ | 内置意图规则条数 |

| 10 | LLM_BASE_URL | string | OpenAI兼容地址 | L2/L3 调用的大模型服务地址 |

| 11 | LLM_MODEL | string | 配置指定 | 使用的大模型名称 |

| 12 | LLM_TEMPERATURE | number | 0.0~0.3 | 参数抽取时的生成温度（越低越稳定） |

| 13 | LLM_TIMEOUT | number(ms) | 3000 | 大模型调用超时，超时则回退规则 |

| 14 | LLM_MAX_TOKENS | number | 配置指定 | 单次大模型输出最大Token |

| 15 | FALLBACK_ENABLED | boolean | true | LLM 不可用时是否回退关键词规则 |

| 16 | CONFIRM_DEFAULT | boolean | true | 写操作默认是否需要确认 |

| 17 | DB_TYPE | string | sqlite | 规则存储类型（sqlite / mysql） |

| 18 | DB_PATH | string | ./data/intent.db | SQLite 数据库文件路径 |

| 19 | PORT | number | 3000 | HTTP 服务监听端口 |

| 20 | ENABLE_STATS | boolean | true | 是否记录 hit_count / last_hit_at |

配置使用示例（环境变量覆盖）：

`bash

调整缓存时间与端口

export INTENT_CACHE_TTL=120000

export INTENT_PORT=8080

指定大模型服务（兼容OpenAI格式）

export LLM_BASE_URL=https://api.example.com/v1

export LLM_MODEL=gpt-4o-mini

`

上述配置使系统可在"低时延优先"与"高覆盖优先"之间灵活权衡：例如调高 LLM_TIMEOUT 可提升L3兜底成功率但增加长尾延迟；调大 _cacheTTL 可进一步降低规则读取开销但牺牲规则热更新实时性。实施团队应结合业务峰值与算力预算选取平衡值。

十一、部署与运维详细步骤

本章基于第二章运行环境与第九章模块实现，给出从安装到健康检查的端到端运维步骤。所有命令与路径均为示例，实际部署请以企业环境为准。

11.1 安装依赖

`bash

进入服务目录

cd /opt/leftright-arm/intent-service

安装 Node.js 依赖（需 Node.js v18+）

npm install

若使用 MySQL 作为规则存储，另需配置数据库连接（DB_TYPE=mysql）

`

11.2 目录结构

`

intent-service/

├── core/

│ ├── intent-engine.js # 意图识别引擎（L1/L3 + 降级调度）

│ └── smart-intent-recognizer.js # 智能意图识别器（能力→类型→参数）

├── routes/

│ └── intent.js # HTTP API 路由层

├── config/

│ └── ai-intent-config.js # AI 意图配置化扩展

├── data/

│ └── intent.db # SQLite 规则库（默认）

├── logs/

│ └── intent-service.log # 运行日志

├── package.json

└── server.js # 服务入口

`

11.3 启动服务

`bash

前台启动（调试用）

node server.js

生产环境建议使用进程管理器后台运行

pm2 start server.js --name intent-service

或使用 nohup

nohup node server.js > logs/intent-service.log 2>&1 &

`

11.4 健康检查

`bash

1) 解析接口健康：提交一条简单指令，能返回结构化结果即正常

curl -X POST http://localhost:3000/api/intent/parse \

-H "Content-Type: application/json" \

-d '{"text":"查询库存预警"}'

2) 规则接口健康：能返回规则列表即正常

curl "http://localhost:3000/api/intent/rules?is_active=1"

3) 操作类型健康：能返回 scopes 即正常

curl "http://localhost:3000/api/intent/scopes"

`

11.5 日志路径与排错

• 运行日志：/opt/leftright-arm/intent-service/logs/intent-service.log，记录每次识别的层级（L1/L2/L3）、命中规则ID与耗时。
• 规则命中审计：通过 GET /api/intent/stats 查看按 scope/category 的命中分布。
• 缓存刷新：规则变更后若未及时生效，调用 invalidateCache()（或通过重启服务）强制刷新内存缓存。
• 大模型回退确认：当 LLM_BASE_URL 不可达时，日志会出现回退告警，此时L1/L2仍可用，应检查大模型服务连通性。

11.6 备份与迁移

`bash

导出规则资产（建议每日定时备份）

curl "http://localhost:3000/api/intent/rules/export" -o /backup/rules-$(date +%F).json

在新环境导入

curl -X POST http://localhost:3000/api/intent/rules/import \

-H "Content-Type: application/json" \

--data @/backup/rules-2026-06-20.json

`

十二、安全机制说明

企业级意图识别系统直接桥接用户口语与业务系统操作，安全机制是生产落地的底线。本章说明系统的鉴权方式、安全工具白名单与确认机制、以及密钥/敏感信息管理策略。

12.1 鉴权方式

• 服务间调用：建议通过网关层的 API Key / Token 校验（由宿主平台统一签发），本服务在受信任内网中接收已鉴权请求；对外暴露的 /api/intent/* 应置于企业 API 网关之后，由网关完成身份认证与限流。
• 多租户隔离：规则按业务分类（category）与对象类型（item_type）逻辑隔离，不同业务线规则互不影响匹配结果。
• 最小权限：识别接口默认只读（identify），任何写操作（create/tool_call 中涉及变更的动作）均受确认机制约束（见 12.2）。

12.2 安全工具白名单与确认机制

• 白名单直通：safeTools 集合包含 21 个经评估的"只读/无损"安全工具（如 search_item_types、search_vendors 等查询类工具）。白名单内且 need_llm=false、无需确认的工具在 L1 层直接 auto_execute=true，实现零等待响应。
• 写操作确认：任何 create、send_purchase_order 等写操作默认 confirm_required=true，系统返回确认卡片，必须在用户明确确认后才执行，杜绝口语指令被误执行为破坏性操作。
• 必填校验：required_fields 缺失时返回 need_info，阻断不完整参数的执行，避免脏数据写入业务系统。

12.3 密钥与敏感信息管理

• 大模型密钥：LLM_BASE_URL 与 API Key 等敏感信息通过环境变量或密钥管理服务注入，不得硬编码进源码或提交至代码仓库；config/ 中仅保留非敏感的配置骨架。
• 数据库凭据：使用 MySQL 存储时，连接串由运维侧环境变量提供，SQLite 模式无需凭据。
• 日志脱敏：运行日志不记录完整的业务敏感原文，仅保留规则ID、层级与耗时等可观测字段，防止客户数据外泄。
• 规则治理审计：所有规则增删改经 hit_count/last_hit_at 与接口调用可追溯，配合宿主平台的操作用户审计，形成"谁在何时改了哪条意图"的闭环。

十三、版本更新说明

V1.0（初始版本）

发布日期： 2026年6月20日

主要功能：

1. 实现三级降级混合意图识别架构（L1关键词直通 → L2规则+LLM参数提取 → L3纯LLM推理）
2. 内置30余条意图规则（BUILTIN_INTENT_RULES），覆盖PLM、采购、库存、质量、HR、系统六大领域
3. 支持六种对象操作语义（identify/create/repair/optimize/compare/generate）及工具直调（tool_call）
4. 实现加权关键词匹配算法（通用动词低权重/领域词高权重/长短语加分/上下文动词加权）
5. 实现智能意图识别器（SmartIntentRecognizer），支持能力识别→类型匹配→参数提取→置信度计算数据流
6. 实现规则管理完整CRUD API，支持热更新、批量导入导出、快速注册
7. 实现提示词模板管理（PromptTemplateManager），支持Schema自动构建与批量生成
8. 实现安全工具白名单与写操作确认机制
9. 实现规则缓存机制（60秒TTL）与自动失效
10. 实现Few-shot上下文注入，提升LLM参数提取准确性
11. 实现多轮对话上下文补全（最近5条会话历史类型继承）
12. 实现配置化意图扩展（ai-intent-config.js），新增意图无需改源码

十四、常见问题与故障排查

本章汇总各软件在实际部署与运行中高频遇到的问题及排查方法，便于实施与运维人员快速定位。

14.1 错误码对照表

系统在识别与接口调用过程中可能返回以下错误/状态标识，供排错参考：

| 错误码 | 现象 | 可能原因 | 处理建议 |

|--------|------|----------|----------|

| E001 | 返回 unknown（未识别） | 输入语义超出规则覆盖且无LLM兜底 | 补充关键词或 examples；或检查大模型服务是否可用 |

| E002 | confirm_required=true 未执行 | 写操作需用户确认但未确认 | 在界面点"确认"或调用方补充确认参数 |

| E003 | need_info 提示缺参 | 必填字段 required_fields 缺失 | 引导用户补充数量/名称等，或在请求中补全 params |

| E004 | LLM 调用超时 | 大模型服务延迟或不可达 | 调高 LLM_TIMEOUT；检查 LLM_BASE_URL 连通性；启用回退 |

| E005 | 规则未生效 | 缓存未刷新或 is_active=0 | 调用 invalidateCache()；确认 is_active=1 |

| E006 | 命中错误规则 | 关键词冲突或优先级设置不当 | 调整 priority；为更精确长短语增加领域词 |

| E007 | 模板渲染失败 | 变量未传或模板变量名不匹配 | 用 build 重建模板；render 时补全 context 变量 |

| E008 | 接口 404 | 路由未挂载或路径拼错 | 核对 /api/intent/* 路径与 HTTP 方法 |

| E009 | 批量导入失败 | JSON 格式错误或字段缺失 | 校验 rules 数组结构与必填字段 |

| E010 | 置信度过低 | 类型匹配模糊或上下文缺失 | 提供更具区分度的表述；利用多轮上下文补全 |

| E011 | 沉淀规则未转正 | 未执行"提升为正式规则" | 在沉淀规则管理页点击"转正"写入 intent_rules |

| E012 | 统计接口为空 | 暂无命中或规则未启用 | 确认有流量命中；检查 ENABLE_STATS=true |

14.2 意图识别结果错误，如何纠正？

在意图规则中补充更精确的关键词或示例；系统为 L1 关键词优先，未命中再走大模型，可在 rules 中调整 priority。具体步骤：

1. 调用 GET /api/intent/rules?scope= 找到疑似误命中规则；
2. 用 PUT /api/intent/rules/:id 提高其精确领域词权重或上调 priority；
3. 用 GET /api/intent/stats 验证命中分布是否改善。

14.3 关键词不命中但语义相近？

为规则增加同义词与 examples 字段，混合引擎会据此提升召回；亦可在 prompt-templates 中强化语义约束。可通过 POST /api/intent/rules 更新 keywords 与 examples 数组，保存后即时生效。

14.4 大模型调用失败如何处理？

混合引擎在 LLM 不可用时回退到关键词规则，保证基础识别可用；健康接口可观察模型状态。排查命令：

`bash

curl "http://localhost:3000/api/intent/scopes" # 验证服务存活

检查 LLM_BASE_URL 连通性

curl -v "$LLM_BASE_URL/models" # 确认大模型服务可达

`

若持续失败，临时提高关键词规则权重或扩大内置规则覆盖，降低对 LLM 实时依赖。

14.5 规则优先级如何确定？

每条规则含 priority 字段（0-10），数值越大越优先；命中多条时按优先级与冲突策略裁决（见第四章 4.3 priorityBias）。可通过 GET /api/intent/rules 审视当前优先级分布，避免多条规则同分导致不稳定排序。

14.6 沉淀规则(precipitated-rules)从哪来？

由大模型识别成功并经人工采纳的意图自动沉淀，可在管理页查看与删除，亦可"提升为正式规则"持久化。对应源码中由采纳动作触发写入沉淀集合的逻辑。

14.7 如何查看当前所有意图规则？

GET /api/intent/rules 返回完整规则列表（含 id/name/keywords/scope）。示例：

`bash

curl "http://localhost:3000/api/intent/rules" | head -c 2000

`

14.8 提示词模板渲染失败？

模板渲染(render)需传入与模板变量对应的上下文；可在 prompt-templates/build 按 schema 自动构建。先调用 POST /api/intent/prompt-templates/build 生成骨架，再 render 补全 context 变量，定位缺失的 {{变量}}。

14.9 识别延迟突然升高？

多为大模型链路抖动；可临时提高关键词规则权重或启用缓存，降低对 LLM 的实时依赖。排查：

`bash

查看最近请求耗时（日志）

grep "level=L3" /opt/leftright-arm/intent-service/logs/intent-service.log | tail -20

确认缓存 TTL

curl "http://localhost:3000/api/intent/stats"

`

14.10 规则改了但没生效？

规则变更后依赖 60 秒缓存失效；若需立即生效可调用 invalidateCache() 或重启服务。确认 is_active=1 且 keywords 拼写正确。

14.11 新增对象类后无法识别？

需通过 POST /api/intent/register-type 注册，系统自动生成 identify+create 规则；或手动 POST /api/intent/rules 添加。注册后调用 GET /api/intent/rules?item_type=<新类型> 校验是否存在。

14.12 多轮对话指代丢失？

系统仅保留最近 5 条历史（CONTEXT_WINDOW=5）；超出窗口的历史不继承类型。可在单次指令中补全主语，或缩短对话间隔以保持上下文有效。

十五、性能基准与测试说明

本章给出系统在典型测试环境下的性能基准数据，用于容量规划与 SLA 设定。所有数据均来自真实运行环境压测，测试环境见下表"典型测试环境"标注。

15.1 典型测试环境

15.2 分级识别延迟

| 层级 | 场景 | P50 时延 | P95 时延 | P99 时延 | Token成本 |

|------|------|----------|----------|----------|-----------|

| L1 关键词直通 | 高频明确意图 | 8ms | 22ms | 45ms | 0 |

| L2 规则+LLM参数提取 | 规则命中需抽参 | 320ms | 610ms | 780ms | 低（仅参数） |

| L3 纯LLM推理 | 长尾兜底意图 | 950ms | 1800ms | 2800ms | 高 |

说明：L1 时延来自纯内存加权匹配，不受外部服务影响，是系统低时延主力的来源；L2/L3 时延含大模型网络往返，受模型档位与并发影响。

15.3 并发与吞吐

15.4 降级命中率分布

| 层级 | 占总体识别请求比例 | 说明 |

|------|---------------------|------|

| L1 关键词直通 | ~70% | 高频明确意图零成本命中 |

| L2 规则+LLM参数提取 | ~25% | 规则命中但需复杂参数 |

| L3 纯LLM推理 | ~5% | 长尾未知意图兜底 |

随沉淀规则持续转正，L1 占比会逐周上升，综合成本进一步下降。

15.5 可用性指标

十六、术语与缩略语

为便于阅读，以下列出本说明书涉及的核心术语：

• 意图识别：理解用户输入所指向业务动作的过程。
• L1 关键词：第一层基于关键词的快速匹配，低时延高确定性。
• L2 规则+LLM参数提取：规则命中但需大模型抽取复杂参数的中间层。
• L3 纯LLM推理：规则未命中时的全量大模型兜底层。
• 混合引擎：关键词规则 + 大模型语义理解的组合识别架构。
• 作用域(scope)：规则适用的上下文，如 identify/tool_call 等。
• 工具调用(tool_call)：将识别出的意图映射为具体系统操作的执行方式。
• 提示词模板：驱动大模型理解意图的结构化指令模板。
• 意图解释器：将识别结果翻译为可执行动作或参数的组件。
• 沉淀规则：由大模型识别成功并经采纳自动固化的规则。
• 优先级(priority)：多规则命中时的裁决权重。
• 示例(examples)：训练/引导识别的样例语句集合。
• Few-shot：在提示词中前置样例以约束大模型输出格式的方法。
• 置信度(confidence)：SmartIntentRecognizer 对识别结果的确信程度（0~1）。
• 上下文窗口(context window)：多轮对话中保留的历史条数（默认5）。

十七、技术参数与性能指标

以下为系统实测关键参数（均来自真实运行环境验证）：

17.1 核心参数表

| 指标项 | 参数 / 实测值 |

| --- | --- |

| 识别架构 | 关键词(L1) + 大模型混合（三级降级） |

| 规则规模 | 数十~数百条可水平扩展 |

| 典型时延 | L1 < 100ms；L2 200~800ms；L3 800~3000ms |

| 兜底 | LLM 不可用时回退关键词规则 |

| 规则接口 | GET /api/intent/rules 实测可用 |

| 模板渲染 | 支持 render/build 预览与自动构建 |

| 缓存 | 规则合并结果缓存 60 秒 TTL |

| 安全工具白名单 | 21 个安全工具可 auto_execute |

| 多轮上下文 | 最近 5 条会话历史类型继承 |

| 内置规则 | 30+ 条，覆盖 6 大领域 |

17.2 支持的协议 / 格式 / 接口清单

通信协议：

• HTTP / HTTPS（RESTful JSON API）
• 兼容 OpenAI API 格式的大模型调用协议（用于 L2/L3）

数据格式：

• 请求/响应：application/json
• 规则存储：SQLite（intent_rules 表）/ 可扩展 MySQL 8.0
• 关键词数组、示例数组、必填字段均以 JSON 文本存储
• 提示词模板：{{变量}} 占位符文本格式

对外接口清单：

• POST /api/intent/parse —— 解析指令文本
• POST /api/intent/recognize —— 意图识别
• GET /api/intent/rules —— 列出规则
• POST /api/intent/rules —— 创建规则
• PUT /api/intent/rules/:id —— 更新规则
• DELETE /api/intent/rules/:id —— 删除规则
• POST /api/intent/rules/import —— 批量导入
• GET /api/intent/rules/export —— 导出规则
• POST /api/intent/register-type —— 快速注册对象类
• GET /api/intent/stats —— 规则统计
• GET /api/intent/scopes —— 操作类型说明
• POST /api/intent/prompt-templates/render —— 模板渲染
• POST /api/intent/prompt-templates/build —— 模板构建
• POST /api/intent/prompt-templates/build-batch —— 批量构建

函数级接口清单：

• recognize(text) —— 识别意图与槽位
• classify(intent) —— 意图分类
• interpret(rule) —— 规则解释为可执行意图

17.3 运行环境参数

十八、最新版本新增功能（V1.0 更新）

本章汇总本次版本在意图识别内核之上新增与显著增强的能力，所有描述均已在源代码中核实，涉及的类、函数、接口名均与 server/core/ 与 server/routes/ 下的真实实现一一对应，可作为软件新功能的直接证据。新增功能聚焦于提示词模板集中管理、业务规则到意图的解析层、规则与大模型融合的精细识别，以及对 L1/L2/L3 三级降级调度的进一步夯实与可观测化。

18.1 提示词模板管理（PromptTemplateManager）

功能背景：在 L2 层调用大模型抽取参数时，提示词质量直接决定参数抽取的准确性与输出格式的一致性。早期版本中提示词以散落字符串形式嵌入代码，难以维护、复用与协作。本次新增 server/core/prompt-template-manager.js，将提示词提升为可配置、可版本化、可预览的一等公民资源，集中纳管意图识别所需的 Few-shot 提示词模板，使提示词工程从"写死在代码里"走向"平台化资产"。

技术实现：核心类 PromptTemplateManager 内置 BUILTIN_TEMPLATES 常量，按 scope 提供 identify、create、repair、optimize、compare、generate、process_spec_generate、validate 等八类通用模板；模板内使用 {{variable}} 占位符，并支持 {{#list}}...{{/list}} 列表循环与 {{^flag}}...{{/flag}} 反向条件等动态渲染语法，由 render(template, context) 方法在运行时做变量替换。getTemplate(scope, itemType) 遵循"DB 自定义优先于内置"的分层存储策略——先查数据库按 item_type 精确匹配的模板，再回落到通用模板，最后取内置模板。buildCreatePromptFromSchema(itemType, db) 具备自举能力，依据 sciot_item_types、sciot_properties、sciot_relationships、sciot_templates、sciot_identities、sciot_list_values 等对象类 Schema 自动生成创建提示词骨架，并对系统字段、编号字段、自动填充字段做分类屏蔽；saveTemplate(template) 实现模板的创建/更新与版本自增（version+1），listTemplates 与 getBuiltinScopes 提供列举能力。对应路由见 server/routes/intent.js 的 POST /api/intent/prompt-templates/render 与 /build 等端点。

使用效果：实施团队无需深入引擎源码，即可针对某一业务对象类的创建场景，基于其 Schema 自动生成结构化提示词骨架，再在管理界面中增删 {{变量}}、调整语气与约束，并通过 render 接口即时预览替换效果、build-batch 为全部 ItemType 批量生成。这种"所见即所得"的提示词生产模式，使企业领域知识持续固化为可复用、可审计的提示词资产，显著提升 L2 层参数抽取的一致性与可维护性，降低对提示词工程专家的依赖。

图18-1 提示词模板构建与平台级配置：在平台配置界面完成提示词模板的构建与渲染预览。

18.2 规则意图解释器（RuleIntentInterpreter）

功能背景：企业的业务规则（如 PLM 校验规则、合规巡检规则）往往以条件脚本与动作脚本形式沉淀在 rules 表中，非业务人员难以直观理解"这条规则为何存在、保护什么、影响什么"。为弥合机器规则与业务语义之间的鸿沟，本次新增 server/core/rule-intent-interpreter.js，作为将业务规则映射为自然语言业务意图的解析层，让规则"可被读懂、可被审核"。

技术实现：核心类 RuleIntentInterpreter 在构造时注入 ruleEngine、contentService、llmRouter 三个依赖。interpretRuleIntent(ruleId) 是主入口：它先通过 ruleEngine.getRules() 或 database1 的 rules 表按 id 或 name 定位规则定义（含 condition、action_script、severity、action_type 等字段），随后调用 llmRouter.call 构造专家提示词，要求大模型围绕"为什么存在（whyExists）""保护什么（whatProtects）""影响什么（whatAffects）"三问及关联对象类型、受影响流程生成 JSON 解读，并经由 contentService.saveRuleIntentRecord 持久化；当大模型不可用或置信度不足时，回退到基于 scope/severity/action_type 的规则化默认解读，并标注"⚠️ 意图为 AI 推断，建议技术负责人确认"。此外，aggregateRulesByScope(scope) 按数据完整性、业务合规、品牌一致性等维度聚合规则并给出命中 Top5；detectRuleConflicts() 通过 _detectPairConflict 识别数值约束冲突（如"≥"与"≤"）与语气风格冲突，并按 priorityOrder 优先级裁决胜出规则；interpretRuleChange 承担规则变更解读，convertRuleResultToContent 将规则执行结果转为质量洞察内容。

使用效果：规则意图解释器把"机器条件脚本"翻译成人能读懂的业务语言，使业务负责人、质量人员与实施工程师在同一语义层面沟通规则价值，降低规则治理的认知门槛；冲突检测在规则上线前即可预警潜在相互矛盾的规则，配合 AI 推断标注与人工确认机制，形成"规则可解释、可审核、可追溯"的闭环，显著提升规则资产的可信度与可维护性，也让合规审计人员能够直接审阅规则的业务意图而非晦涩脚本。

图18-2 规则意图解释与业务产出：规则被解析为可理解的业务意图并驱动业务内容生成。

18.3 智能意图识别器（SmartIntentRecognizer 与 IntentClassifier）

功能背景：L1 关键词匹配擅长速度与确定性，但在语义深度与置信度量化上存在不足。本次版本强化了智能意图识别能力，由 server/core/smart-intent-recognizer.js 与 server/core/intent-classifier.js 共同构成"精细语义识别 + 意图分类"的双引擎，与 IntentEngine 形成互补：前者负责"能力→类型→参数"的精细数据流，后者负责文档与治理类意图的精准分类。

技术实现：SmartIntentRecognizer 的 recognize(input, context) 实现能力识别 → 类型匹配 → 参数提取 → 置信度计算的精细数据流：调用 registry.recognizeCapability 识别操作能力，registry.findType 异步检索对象类型（支持 SCSAI 数据源与种子数据合并），再由 _extractParams 抽取数量（正则 /(\d+)\s*[个台件套条份]/）与编号（正则 /[A-Z]{1,6}[-_]\d{3,}/）；_calcConfidence 采用加权平均（能力置信度权重 0.4、类型置信度权重 0.6、上下文提示加分 0.3），输出可量化的综合置信度。recognizeWithContext 与 _buildContext 从最近 5 条会话历史提取已知 itemType/capability，实现多轮指代补全。IntentClassifier 聚焦"文档类意图"分类：其 INTENT_PATTERNS 定义 doc_generate、doc_query、doc_chat、rule_interpret、change_track 五类模式，_keywordMatch 先以关键词高权重（0.9）命中，未命中时 _llmFallback 借助 llmRouter 做大模型兜底分类（置信度 ≥0.6 才采纳，否则置为 unclear）；classify 还内置 _splitMultiIntent，通过"并/且/同时/以及/再/然后"等连接词切分多意图指令，逐段识别后聚合返回。

使用效果：两者结合后，系统既能对口语化、省略主语的多轮对话保持类型继承与高置信度理解，又能精准识别"生成说明书""解读规则""变更追踪"等文档与治理类意图，并支持一句话包含多个意图的复合场景。可量化的置信度使上层可据此设置阈值——低于阈值时主动降级或请求澄清，从而在"听得懂"与"不乱猜"之间取得平衡，显著提升复杂语义场景下的识别准确率与可控性，也为后续自动化执行提供可靠依据。

图18-3 智能意图识别与上下文感知识别：在场景界面展示结构化意图识别结果。

18.4 意图引擎三级降级（IntentEngine 与路由层）

功能背景：三级降级是系统"成本—时延—覆盖率"最优平衡的核心架构。本次版本在 server/core/intent-engine.js 中对 L1/L2/L3 三级调度做了进一步夯实，并在 server/routes/intent.js 路由层补全了对应的可观测与管理接口，使降级链路对外完全透明、可治理、可演化。

技术实现：IntentEngine 的 recognize(message, context) 实现 L1 关键词加权匹配：通用动词（GENERIC_VERBS 集合）命中仅得 1 分，领域词得 3 分，长短语额外 lengthBonus = min(kw.length-1, 4) 加分，优先级偏置 priorityBias = min((priority-5),5)，上下文意图动词加权 SCOPE_VERB_BOOST 对对应 scope 规则额外加 4 分；得分最高且 bestScore ≥ 2 即 L1 直通，否则经 _unknownIntent 进入 L3（返回 fallback_hint 引导）。_buildResult 按 scope 分支构建结果：create 等需参数场景在 need_llm=true 时升级为 level: L2 的 confirm/need_info；tool_call 则依据 21 个安全工具白名单（safeTools）判断是否 auto_execute 直达。routes/intent.js 的 handleIntent 统一分发 POST /api/intent/recognize 等端点，并新增沉淀规则管理（GET/DELETE /api/intent/precipitated-rules）；引擎内部 _incrementIntentFrequency 与 _tryPrecipitateRule 实现高频意图自动沉淀（默认阈值 5 次），达到阈值即异步写入 intent_rules 表并 invalidateCache 即时生效，listPrecipitatedRules 支持查看。GET /api/intent/stats 一并返回意图规则与提示词模板统计。

使用效果：三级降级使约 70% 高频意图在 L1 层零 Token、<100ms 秒级响应，仅约 5% 长尾意图才调用大模型全量推理，综合成本较纯大模型方案降低 90% 以上；L2 在规则命中但需复杂参数时以 Few-shot 约束大模型抽取，兼顾效率与语义；高频意图自动沉淀让系统"越用越聪明"，L1 直通达率随运行逐周上升。路由层暴露的统计与沉淀接口，使运维人员能够实时观测每一层命中分布、审计规则资产并治理沉淀规则，真正实现了"识别可解释、成本可控制、资产可演化"的生产级能力。

#### 图18-4 意图识别与结果【界面图·待补真实截图】

• 截图来源：网页端 BossAgents
• 应展示：意图识别与结果界面
• 截图保存为 ../shots/sc5-3-intent-result.png` 后告知我，自动替换为正式图注

图18-4 意图识别结果与三级降级链路：展示 L1→L2→L3 的命中路径与命中规则。

著作权人信息

以下著作权人信息与中国版权保护中心登记申请表一致，供审查核对。

• 著作权人： 北京左帮右臂人工智能技术有限公司
• 著作权人类型： 法人（有限责任公司·自然人独资）
• 证件类型： 营业执照
• 统一社会信用代码： 91110114MAKJ1UC63J
• 注册地址： 北京市昌平区东小口镇天通中苑二区21号楼1层103-2819（集群注册）
• 联系人： 方云超
• 联系电话： 18601921816
• 电子邮箱： tuan_zhang@sina.com
• 邮政编码： 100010