规则引擎
第一代AI助手技术，基于预设规则和固定模板响应用户输入，以早期Siri为代表，无法处理表达变化。
核心事实
时间轴 (近 90 天)
是否支持规则与模型混合编排、能否对单条策略做 A/B 实验，是区分规则引擎与决策平台的重要分界线。
理想的例外处理边界设计需要结合规则引擎的细粒度（如金额阈值、客户等级、操作类型）和AI的自我评估能力，使人类介入既安全又不成为瓶颈。
两类模型输出的结构化信息再经过规则引擎或大语言模型整合，形成可供评估人员快速审阅的报告。
垃圾短信常伪装成快递通知、银行提醒或熟人问候，语义上接近正常信息，使规则引擎难以兼顾低误伤与全面拦截
有些场景用规则引擎或传统软件即可完成，硬上AI模型反而会增加成本和不确定性。
规则引擎天然提供基于规则的证明路径（如推导树），而语言模型的内部推理过程通常是不透明的。
在混合系统中，当模型作为事实生成器时，其输出的可信度需要被规则引擎验证，否则会引入不可追溯的错误。
文章以面向对象设计模式目录的形式，定义了13种将语言模型与可执行规则语言耦合的模式。
规则引擎基于预定义条件-动作对进行监控，确定性强、延迟低，但难以枚举AI代理组合爆炸的行为空间。
当前趋势是采用分层监控：规则引擎处理高置信度威胁，大模型监控器负责语义推理，二者协同以平衡实时性与准确性。
还有 40 条时间轴事件
全部知识事实 (20)
样本过于简单则模型无学习价值，过于困难则可能引入噪声学习信号干扰训练，最有效的学习发生在略高于当前能力但仍可企及的区域
65%已验证微调适合让模型学习特定输出风格或领域语气，而RAG通过外挂知识库实现即改即用，两者在工程中常结合使用
65%待验证规则引擎是一类把业务规则从应用代码中抽离出来、以可声明方式表达并集中执行的软件组件。
60%待验证是否支持规则与模型混合编排、能否对单条策略做 A/B 实验，是区分规则引擎与决策平台的重要分界线。
50%待验证理想的例外处理边界设计需要结合规则引擎的细粒度（如金额阈值、客户等级、操作类型）和AI的自我评估能力，使人类介入既安全又不成为瓶颈。
50%待验证两类模型输出的结构化信息再经过规则引擎或大语言模型整合，形成可供评估人员快速审阅的报告。
50%待验证垃圾短信常伪装成快递通知、银行提醒或熟人问候，语义上接近正常信息，使规则引擎难以兼顾低误伤与全面拦截
50%待验证有些场景用规则引擎或传统软件即可完成，硬上AI模型反而会增加成本和不确定性。
50%待验证规则引擎天然提供基于规则的证明路径（如推导树），而语言模型的内部推理过程通常是不透明的。
50%待验证在混合系统中，当模型作为事实生成器时，其输出的可信度需要被规则引擎验证，否则会引入不可追溯的错误。
50%待验证文章以面向对象设计模式目录的形式，定义了13种将语言模型与可执行规则语言耦合的模式。
50%待验证规则引擎基于预定义条件-动作对进行监控，确定性强、延迟低，但难以枚举AI代理组合爆炸的行为空间。
50%待验证实务中往往采用启发式算法或规则引擎近似求解。
50%待验证传统规则引擎擅长处理确定性逻辑（如温度超阈值触发报警），但面对模糊关联（如材料湿度影响流动性导致填充不足）往往无能为力。
50%待验证工程上常见的规则引擎（如 Drools、JSON Logic）和策略语言（如 OPA/Rego）都以谓词为核心构件：每条规则即一个条件表达式，匹配则触发动作。
50%待验证常见落地做法是用规则引擎承载核心业务流程，把模型生成的 agent 用于边缘的、低风险的重复任务。
50%待验证最初失败的原因是规则「前台有其他应用，把展示界面拉回来」在模型被咨询前就触发，导致智能体错误干扰用户操作，成功率为0/20。
50%待验证在棋类游戏中，规则引擎的输出是确定性的、可复现的、可测试的，不会因提示词或模型版本变化而漂移。
50%待验证Sidekick 内置的国际象棋游戏使用规则引擎拒绝非法走法，演示中系统提示“王翼易位在这个局面不合法”。
50%待验证规则适合边界清晰、变化少的场景；检索适合需要引用私有知识、要求可追溯的场景；纯生成适合开放式、容错率高的任务。
50%