DialogManager不能直接运行规则引擎，因其仅调度状态、转发消息、维护上下文，不解析业务逻辑；规则必须在on_message、on_enter、on_exit等钩子中手动触发，并显式return以阻断默认流程。
为什么 DialogManager 不能直接跑规则引擎
因为 DialogManager 本身不解析业务逻辑，它只调度状态、转发消息、维护上下文；规则引擎要介入对话流，必须在状态跳转或消息处理的钩子中手动触发。常见错误是试图把规则判断写进 on_enter 但忘了返回 True 阻断默认流程，结果规则跑了，状态也照常切换了，行为错乱。
-
DialogManager的switch_to和show_message是纯控制流操作，不带语义拦截能力 - 真正能插规则的地方只有：用户消息回调（
on_message）、状态进入前（on_enter）、状态退出后（on_exit） - 如果规则要修改下一步状态，必须在钩子里调用
manager.switch_to(...)并显式return，否则会继续走默认路径
RuleEngine 如何接入 aiogram 对话状态机
最稳的方式是把规则引擎封装成一个可调用对象，在每个状态的 handler 里主动调用它，而不是让它反向驱动状态机。比如用户发来“我要改地址”，不是让规则引擎决定跳去 AddressState，而是 handler 先喂给 rule_engine.evaluate()，拿到结果后再调 manager.switch_to(AddressState)。
- 规则输入建议固定为
{'intent': str, 'entities': dict, 'context': dict}，避免每次适配不同结构 - 不要在规则函数里直接调
manager.show_message()—— 这会让 UI 逻辑和业务逻辑耦合，应该只返回动作指令（如{'action': 'ask_phone', 'message': '请留手机号'}） - 注意
aiogram的DialogManager是异步的，规则引擎若含 IO（比如查 DB），得用await rule_engine.arun(...)，否则阻塞事件循环
规则条件里访问对话上下文的坑
很多人直接在规则表达式里写 context['user']['level'] > 5，结果报 KeyError: 'user' —— 因为 context 默认只存当前 state 的数据，全局对话数据得从 manager.middleware_data 或 manager.bg().data 拿。
-
manager.current_context().state只返回当前状态名，不是数据容器 - 推荐统一从
manager.middleware_data.get('user_data', {})读用户级上下文，这个字典在对话生命周期内持久存在 - 如果规则需要历史消息，别硬塞进 context，用
manager.bg().get_history(limit=3)更安全，避免 context 膨胀
性能敏感场景下规则加载与缓存
每次消息都重新 parse 规则字符串（比如 "intent == 'cancel' and context['cart'].size > 0"）会明显拖慢响应。RuleEngine 类型如 jsonpath-ng 或 simpleeval 不自带编译缓存，得自己加。
立即学习“Python免费学习笔记（深入）”；
- 用
functools.lru_cache缓存rule_engine.compile(rule_str)结果，key 用rule_str+version（比如配置文件 hash） - 避免在
on_message里做规则热重载 —— 文件变化监听 + 原子替换编译后规则对象即可，不用 reload 模块 - 如果规则分支超过 20 条，考虑按 intent 前缀分组，先用字典查表路由到子规则集，别全量遍历
规则引擎和对话管理器之间没有隐式契约，所有数据流动、时机控制、错误回退都得你亲手连起来。最容易被忽略的是：规则执行失败时，DialogManager 不会自动 rollback 状态，得你自己 catch 异常并调 manager.switch_to(previous_state)。
