混合调度机制的核心在于让规则引擎与大语言模型各尽其责。你是否也遇到过这样的场景：用户提问“冻结账户”，意图非常明确，直接走规则校验即可；但如果用户说的是“上次冻结后，我还能登录吗”，这类模糊问题就需要交给大模型，结合知识库进行语义推理才能给出准确答复。

在扣子平台中实现规则与大模型的协同调度，关键在于避免让单一模型包揽一切，而是将确定性逻辑与泛化推理分离管理。以下是具体的实现思路：

定义混合调度触发边界

首先在工作流编辑器中新建一个「意图预判」节点，类型选择「LLM分类器」，输入字段设置为用户的原始消息文本。该节点的任务是输出两个关键字段：【intent_confidence】（置信度）与【primary_intent】（主意图）。

阈值建议设为0.82——这是一个经过实践验证的经验值。若置信度低于此值，说明意图较为模糊，需要转交大模型进行深度处理；若高于或等于该值，则直接走规则引擎，以获取最高效率。

随后添加一个条件分支节点。判断逻辑非常简洁：当 intent_confidence ≥ 0.82 时，走规则引擎分支；否则，跳转至「RAG增强生成」节点。这一步是分流的关键，不可省略，否则规则与大模型的输出会相互覆盖，导致结果混乱。

规则引擎侧：高频确定性任务快速响应

方法一：采用「关键词+正则」双校验构建轻量规则集

以“密码重置”意图为例。在规则引擎模块中配置两条并行规则：① 匹配“重置密码|改密|忘记密码”等关键词；② 同时校验消息中是否包含11位手机号或邮箱格式的字符串。只有两条规则均命中时，才触发后续流程。这种方案简单可靠，能有效过滤大量模糊请求。

方法二：接入外部API进行实时状态校验

规则命中后，不要立即执行动作。中间插入一个「HTTP请求」节点，调用内部鉴权服务，接口为 /auth/status?uid={{user_id}}。仅当返回的 status=“active” 时，才允许进入下一步。这一设计可防止规则误触发已注销账户的重置流程——如果用户已经注销账户，再发送重置密码链接显然不合理。

大模型侧：模糊意图的语义理解与上下文补全

第一步：配置RAG增强节点

知识库源选择「FAQ向量库」与「工单历史摘要表」，相似度检索时 top_k 设为3即可。但需添加一项关键过滤条件：强制排除创建时间早于90天的条目。旧数据容易干扰当前业务逻辑，例如历史工单中的过时流程可能完全不适用于当前场景。

第二步：设计提示词模板

在系统指令中明确写入：“你只能基于以下检索结果回答，禁止编造未提及的流程步骤；若检索结果为空，回复‘我需要更多上下文，请说明具体场景’。”这能防止大模型自由发挥，确保输出结果可控。

第三步：启用「上下文窗口压缩」开关

将对话历史按角色分段后，仅保留最近2轮用户提问和1轮机器人回复参与本次生成。长对话会导致大模型忽略最新意图，压缩上下文相当于帮助模型聚焦当前重点。

联合状态同步：确保规则与模型共享同一上下文

在工作流全局变量中声明一个 session_state 的JSON对象，初始值设为 {"stage": "init", "pending_action": null, "last_rule_hit": ""}。这相当于一个全局状态本，让规则与大模型都能知晓当前执行到了哪一步。

每次规则引擎触发操作时，自动更新 session_state.last_rule_hit = “reset_password”。每次大模型生成回复后，检查其输出中是否包含 action_tag 字段（例如 {"action_tag": "escalate_to_human"}），如果有，则同步写入 session_state.pending_action。

后续所有节点均可读取 session_state.stage 来判断当前处于开户引导、投诉受理还是人工转接阶段。【该变量必须在所有分支节点中显式传递，不能依赖默认继承】——否则一旦分支路径不同，状态就会丢失。