1. 从“context-mode”说起一个被低估的工程概念第一次看到“context-mode”这个词很多人会以为是某个新出的框架或者库。其实不是。它更像是一种设计思路、一种状态管理策略甚至可以说是一种编程哲学。我在实际项目里接触这个概念最早是在做多轮对话系统的时候——用户说了一句话系统需要记住前面聊了什么、当前处于什么任务阶段、下一步该走哪个分支。那时候还没有现在这么多成熟的方案大家都是硬编码状态机代码写得像意大利面条。后来慢慢提炼出来一套模式核心就是把“上下文”当作一等公民来管理而不是散落在各个变量里。所谓 context-mode直白地讲就是定义一套规则让程序知道“现在处于什么情境下应该用哪套逻辑去响应”。它解决的问题很具体同一个输入在不同上下文里含义完全不同。比如用户说“取消”在购物车里是取消订单在表单填写中是取消编辑在游戏里可能是取消技能释放。如果没有 context-mode你就得写一堆 if-else 去判断当前场景有了它你只需要切换模式后续逻辑自动适配。这套东西适合谁我觉得三类人最需要一是做交互式应用的开发者比如聊天机器人、智能客服、游戏 NPC 对话系统二是做复杂前端状态管理的同学页面有多个步骤、多个角色、多种权限状态乱成一锅粥三是做工作流引擎或规则引擎的工程师需要根据外部条件动态切换处理策略。哪怕你只是写一个多步骤表单理解 context-mode 也能让你的代码干净不少。接下来我会从设计思路、核心细节、实操落地、问题排查几个角度把我在实际项目中积累的经验完整拆开。文章里提到的代码示例以 Python 和 JavaScript 为主但思路是跨语言的。你不需要跟我用一样的工具重点是理解那层“模式切换”的逻辑。2. 整体设计思路为什么需要 context-mode2.1 从“状态爆炸”到“模式收敛”先看一个反面例子。假设你在做一个智能家居控制面板用户可以通过语音或文字控制灯、空调、窗帘。最初代码可能是这样的def handle_command(text, device_states): if 开灯 in text: device_states[light] True elif 关灯 in text: device_states[light] False elif 调高温度 in text: device_states[ac_temp] 1 elif 调低温度 in text: device_states[ac_temp] - 1 elif 打开窗帘 in text: device_states[curtain] open # ... 还有几十个 elif这还只是单轮指令。如果用户说“太暗了”你得结合当前灯光状态、时间、是否在观影模式才能决定是开灯还是调亮。如果用户说“有点冷”你得知道空调当前温度、是否在制热模式。这些判断逻辑如果全部塞进一个函数很快就会变成几百行的 if-else 地狱。context-mode 的思路是把“当前情境”抽象成一个模式对象每个模式只关心自己范围内的输入和状态迁移。比如“照明模式”只处理灯光相关指令“温控模式”只处理温度相关指令“场景模式”负责协调多个设备。模式之间可以嵌套、可以切换但每个模式的逻辑是独立的。这样做的好处很明显新增一个设备类型只需要新增一个模式类不用动原有代码修改某个模式的逻辑不会影响其他模式测试的时候可以单独测试每个模式不用构造全局状态。2.2 模式切换的触发条件设计模式不会自己切换需要有触发机制。常见的触发条件有三类显式指令用户直接说“切换到温控模式”或点击了某个按钮。隐式推断根据输入内容自动判断。比如检测到“温度”“冷热”等关键词自动进入温控模式。状态驱动当前模式执行完某个动作后自动迁移到下一个模式。比如订单支付完成后从“支付模式”切换到“完成模式”。我在实际项目里通常会把这三类结合起来。显式指令优先级最高隐式推断作为补充状态驱动用于流程性任务。这里有个关键设计点模式切换必须是有向的不能随意跳转。比如从“照明模式”不能直接跳到“支付模式”中间必须经过“主菜单模式”。这样可以避免状态混乱也方便做权限控制。注意隐式推断的准确率直接决定用户体验。如果用户说“今天天气怎么样”系统误判为温控模式那就很尴尬。我的经验是隐式推断只作为“建议”最终切换前给用户一个确认提示或者设置一个置信度阈值低于阈值就不切换。2.3 上下文数据的存储与隔离context-mode 里的“context”到底存什么我一般分三层全局上下文用户 ID、会话 ID、设备列表、权限信息。这些数据所有模式共享只读为主。模式上下文当前模式内部的临时变量。比如温控模式里的“目标温度”“当前风速”。这些数据只在当前模式内有效切换模式时可以选择保留或丢弃。历史上下文用户最近几轮的操作记录。用于隐式推断和回退功能。存储方式取决于你的运行环境。如果是单机脚本用字典或对象就行如果是 Web 服务可以放在 Redis 或内存缓存里如果是前端用状态管理库如 Redux、Pinia配合 context 对象。关键原则是模式上下文必须与全局上下文隔离避免一个模式的内部状态污染另一个模式。我踩过的一个坑早期把模式上下文直接挂在全局对象上结果两个模式同时运行时互相覆盖变量。后来改成每个模式实例持有自己的 context 字典问题才解决。所以如果你打算用 context-mode一定要在架构层面把数据边界划清楚。3. 核心细节解析模式定义、切换与生命周期3.1 如何定义一个模式一个模式至少包含四个要素名称、进入条件、处理逻辑、退出动作。用伪代码表示class Mode: name: str def can_enter(self, context) - bool: 判断当前上下文是否允许进入此模式 pass def handle(self, input_text, context) - Mode: 处理输入返回下一个模式可以是自身 pass def on_enter(self, context): 进入模式时的初始化 pass def on_exit(self, context): 退出模式时的清理 passcan_enter用于隐式推断和权限校验。比如“支付模式”的can_enter会检查购物车是否非空、用户是否登录。handle是核心它接收输入和上下文返回下一个模式实例。如果返回自身表示留在当前模式返回其他模式表示切换。on_enter和on_exit用于资源准备和释放比如进入温控模式时读取当前温度退出时保存用户偏好。这里有个细节handle返回的是模式实例还是模式类型我建议返回实例因为实例可以携带自己的上下文数据。如果返回类型切换后还得重新初始化容易丢失状态。当然如果你的模式是无状态的返回类型也可以但那样就失去了 context-mode 的一部分优势。3.2 模式切换的三种方式在实际编码中模式切换有三种常见实现方式各有适用场景第一种返回值驱动。handle方法直接返回下一个模式对象。这种方式最直观适合模式数量不多、切换逻辑简单的场景。缺点是模式之间的依赖关系硬编码在handle里新增模式需要修改原有代码。第二种事件驱动。模式不直接返回下一个模式而是发布一个事件由中央调度器决定切换到哪个模式。这种方式解耦更彻底适合大型系统。但引入事件总线后调试会变复杂因为调用链不再直观。第三种状态机驱动。用状态机库如 Python 的transitions、JavaScript 的xstate定义状态和迁移规则。这种方式最规范可视化程度高但学习成本也最高。如果你的模式切换逻辑非常复杂涉及并行状态、历史状态用状态机库是值得的。我个人的选择是中小型项目用返回值驱动大型项目用事件驱动流程性极强的用状态机。不要为了追求“架构优雅”而过度设计。我见过一个项目总共就五个模式非要用 xstate结果配置文件写了三百行维护起来比 if-else 还痛苦。3.3 模式的生命周期管理模式的生命周期包括创建、进入、处理、退出、销毁。大部分情况下模式实例可以复用不需要频繁创建销毁。但有两种情况需要注意模式携带大量上下文数据比如一个“报表生成模式”需要加载几万条数据。这种模式退出时应该及时释放内存或者把数据序列化到外部存储。模式有外部资源依赖比如“数据库连接模式”持有连接池。退出时必须关闭连接否则会泄漏。我的做法是给模式加一个is_heavy标记轻量模式常驻内存重量模式按需创建、用完销毁。同时用on_exit统一做资源清理避免遗漏。提示模式切换时旧模式的on_exit和新模式的on_enter执行顺序很重要。我通常先执行旧模式的on_exit再执行新模式的on_enter。这样可以确保旧模式释放的资源如锁、文件句柄在新模式使用前已经可用。4. 实操过程从零搭建一个 context-mode 框架4.1 环境准备与项目结构我用 Python 做一个演示因为 Python 的类机制清晰适合讲解。实际项目中你可以用任何语言思路是一样的。先建一个目录mkdir context-mode-demo cd context-mode-demo python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate不需要额外安装依赖标准库就够了。项目结构如下context-mode-demo/ ├── main.py ├── modes/ │ ├── __init__.py │ ├── base.py │ ├── idle.py │ ├── light.py │ ├── temperature.py │ └── scene.py └── context.pybase.py定义模式基类idle.py是空闲模式light.py和temperature.py是具体功能模式scene.py是场景模式。context.py定义上下文数据结构。4.2 定义上下文与模式基类先写context.pyclass Context: def __init__(self, user_id): self.user_id user_id self.global_data {} # 全局共享数据 self.mode_data {} # 当前模式的私有数据 self.history [] # 操作历史 self.current_mode_name idle def log(self, action): self.history.append(action) if len(self.history) 20: self.history.pop(0)global_data存设备状态、用户偏好等mode_data存当前模式的临时变量history保留最近 20 条操作用于隐式推断。接着写base.pyclass BaseMode: name base def can_enter(self, context): return True def on_enter(self, context): context.mode_data {} context.current_mode_name self.name def on_exit(self, context): pass def handle(self, text, context): raise NotImplementedError def __repr__(self): return fMode: {self.name}注意on_enter里重置了mode_data这是为了隔离不同模式的数据。如果你希望某些数据跨模式保留可以放在global_data里。4.3 实现具体模式空闲模式idle.pyfrom .base import BaseMode class IdleMode(BaseMode): name idle def handle(self, text, context): text text.lower() if 灯 in text or 照明 in text: from .light import LightMode return LightMode() elif 温度 in text or 空调 in text or 冷 in text or 热 in text: from .temperature import TemperatureMode return TemperatureMode() elif 场景 in text or 模式 in text: from .scene import SceneMode return SceneMode() else: print(我没听懂你可以说开灯、调温度或场景模式) return self照明模式light.pyfrom .base import BaseMode class LightMode(BaseMode): name light def on_enter(self, context): super().on_enter(context) context.mode_data[light_on] context.global_data.get(light_on, False) print(f进入照明模式当前灯状态{开 if context.mode_data[light_on] else 关}) def handle(self, text, context): text text.lower() if 开 in text: context.mode_data[light_on] True context.global_data[light_on] True print(灯已打开) elif 关 in text: context.mode_data[light_on] False context.global_data[light_on] False print(灯已关闭) elif 退出 in text or 返回 in text: from .idle import IdleMode return IdleMode() else: print(照明模式下你可以说开灯、关灯或退出) return self温控模式temperature.py类似这里省略重复代码。场景模式scene.py可以协调多个设备比如“观影模式”同时关灯、关窗帘、开投影仪。4.4 主循环与模式调度main.pyfrom context import Context from modes.idle import IdleMode def main(): ctx Context(user_iduser_001) current_mode IdleMode() current_mode.on_enter(ctx) print(智能家居控制台已启动输入退出结束程序。) while True: text input( ).strip() if text 退出: current_mode.on_exit(ctx) print(再见) break ctx.log(text) next_mode current_mode.handle(text, ctx) if next_mode is not current_mode: current_mode.on_exit(ctx) next_mode.on_enter(ctx) current_mode next_mode if __name__ __main__: main()运行这个程序你可以输入“开灯”它会自动从空闲模式切换到照明模式然后你再说“关灯”它会在照明模式内处理。输入“退出”回到空闲模式。整个过程模式切换清晰每个模式的逻辑独立。4.5 参数选择与性能考量上面的例子是单用户、单会话的。如果要做成多用户并发服务需要考虑几个参数模式实例缓存每个用户当前模式实例可以缓存在内存里用user_id做 key。但要注意内存占用如果用户量很大需要设置过期时间。上下文序列化如果服务重启内存中的上下文会丢失。可以把Context对象序列化成 JSON 存到 Redis重启后恢复。序列化时注意排除不可序列化的字段如文件句柄。模式切换频率如果用户频繁切换模式on_enter和on_exit会被频繁调用。确保这两个方法里不要做耗时操作比如网络请求。可以把耗时操作异步化或者加缓存。我实测下来单机 Python 处理一千个并发会话每个会话每秒一次输入CPU 占用不到 10%。瓶颈通常不在模式切换而在输入解析和外部服务调用。所以 context-mode 本身的性能开销可以忽略不计。5. 常见问题与排查技巧实录5.1 模式切换后上下文丢失这是最常见的问题。表现是从模式 A 切换到模式 B再切回模式 A发现之前的数据没了。原因通常是on_enter里重置了mode_data或者模式实例被重新创建了。解决方法有两种一是把需要保留的数据放到global_data里二是让模式实例常驻切换时只调用on_enter和on_exit不销毁实例。我倾向于第二种因为模式实例本身很轻量常驻内存没问题。但如果模式持有大量数据就要用第一种。注意如果多个用户共享同一个模式实例千万不要把用户数据存在实例属性里。实例属性是全局的会串数据。用户数据必须存在Context对象里每个用户一个 Context。5.2 隐式推断误触发用户说“今天好热”系统自动进入温控模式但用户其实只是想闲聊。这种误触发会打断用户。我的解决方案是加一个“确认层”隐式推断出目标模式后不立即切换而是问一句“你是想调节温度吗”用户确认后再切换。或者设置一个置信度阈值只有关键词匹配度超过 80% 才自动切换。另一个技巧是维护一个“黑名单”短语。比如“今天好热”如果出现在闲聊历史中就不触发温控模式。这个黑名单可以手动维护也可以用简单的统计方法自动生成。5.3 模式循环切换模式 A 的handle返回模式 B模式 B 的handle又返回模式 A导致死循环。这种情况通常发生在两个模式互相认为对方应该处理当前输入时。排查方法是打印每次切换的日志看是哪个输入触发了循环。预防措施在handle里加一个“切换计数器”如果连续切换超过 3 次就强制回到空闲模式并提示用户。另外设计模式时尽量让切换方向是单向的避免双向依赖。5.4 常见问题速查表问题现象可能原因排查方法解决方案切换后数据丢失on_enter重置了mode_data检查on_enter代码把数据移到global_data或常驻模式实例隐式推断误触发关键词匹配过于宽松打印匹配日志加确认层或提高阈值模式循环切换两个模式互相返回对方打印切换日志加切换计数器强制回退多用户数据串扰用户数据存在模式实例属性检查实例属性数据存到 Context 对象性能下降on_enter/on_exit有耗时操作打点计时异步化或加缓存5.5 独家避坑技巧第一个技巧给每个模式加一个debug方法返回当前模式的关键状态。这样出问题时直接调用debug就能看到内部数据不用加一堆 print。第二个技巧用配置文件定义模式切换规则。比如用一个 JSON 文件描述“空闲模式下输入包含‘灯’则切换到照明模式”。这样修改切换逻辑不用改代码重启服务即可。适合模式经常变动的项目。第三个技巧模式命名要统一。我见过一个项目模式名有LightMode、light_mode、light三种写法导致日志混乱。建议全部用小写加下划线比如light_mode简单一致。第四个技巧写单元测试时直接测试handle方法。构造一个 Context传入输入断言返回的模式类型。不需要启动整个服务。这样测试速度快覆盖率高。6. 扩展思路context-mode 还能用在哪里6.1 多步骤表单的步骤管理前端做多步骤表单时每一步可以看作一个模式。用户点击“下一步”触发模式切换on_exit校验当前步骤数据on_enter初始化下一步。如果用户点击“上一步”就切换到上一个模式数据从global_data里恢复。这样比用一个大对象管理所有步骤清晰得多。6.2 游戏 NPC 对话树游戏里的 NPC 对话天然适合 context-mode。每个对话节点是一个模式玩家的选择决定下一个模式。global_data存好感度、任务进度mode_data存当前对话的临时变量。用这套模式策划可以独立配置对话树程序只需要实现模式调度器。6.3 工作流引擎的状态流转审批流、订单流、工单流本质上都是状态机。用 context-mode 可以把每个状态封装成模式状态迁移规则写在handle里。相比传统的状态机库context-mode 更灵活因为模式可以携带自己的业务逻辑不只是一张状态迁移表。6.4 与现有框架的结合如果你在用 React可以把每个模式映射成一个组件用 Context API 传递全局数据。如果你在用 Vue可以用 Pinia 的 store 管理模式状态。如果你在用 Django可以把模式做成类视图用中间件处理模式切换。核心思想不变只是换了个壳。我在实际项目里最大的体会是context-mode 不是银弹它解决的是“状态和逻辑耦合”的问题。如果你的项目状态很简单用 if-else 就够了没必要引入模式。但如果你的项目有多个交互场景、多种用户角色、多个流程分支context-mode 能帮你把代码组织得清清楚楚。判断标准很简单当你发现一个函数里超过五个 if-else 都在判断“当前是什么场景”时就该考虑用 context-mode 了。最后分享一个小技巧刚开始用 context-mode 时不要一次性把所有逻辑都迁移过去。先选一个最复杂的模块试点跑通了再推广。我当初就是全盘重构结果模式之间依赖太多调试了一周才稳定。后来学乖了一个模块一个模块地改风险小很多。 
长河君 · 2026/10/29 12:46:18 · 阅读 1.2k context-mode：多轮对话与状态管理的工程实践指南
1. 从“context-mode”说起一个被低估的工程概念第一次看到“context-mode”这个词很多人会以为是某个新出的框架或者库。其实不是。它更像是一种设计思路、一种状态管理策略甚至可以说是一种编程哲学。我在实际项目里接触这个概念最早是在做多轮对话系统的时候——用户说了一句话系统需要记住前面聊了什么、当前处于什么任务阶段、下一步该走哪个分支。那时候还没有现在这么多成熟的方案大家都是硬编码状态机代码写得像意大利面条。后来慢慢提炼出来一套模式核心就是把“上下文”当作一等公民来管理而不是散落在各个变量里。所谓 context-mode直白地讲就是定义一套规则让程序知道“现在处于什么情境下应该用哪套逻辑去响应”。它解决的问题很具体同一个输入在不同上下文里含义完全不同。比如用户说“取消”在购物车里是取消订单在表单填写中是取消编辑在游戏里可能是取消技能释放。如果没有 context-mode你就得写一堆 if-else 去判断当前场景有了它你只需要切换模式后续逻辑自动适配。这套东西适合谁我觉得三类人最需要一是做交互式应用的开发者比如聊天机器人、智能客服、游戏 NPC 对话系统二是做复杂前端状态管理的同学页面有多个步骤、多个角色、多种权限状态乱成一锅粥三是做工作流引擎或规则引擎的工程师需要根据外部条件动态切换处理策略。哪怕你只是写一个多步骤表单理解 context-mode 也能让你的代码干净不少。接下来我会从设计思路、核心细节、实操落地、问题排查几个角度把我在实际项目中积累的经验完整拆开。文章里提到的代码示例以 Python 和 JavaScript 为主但思路是跨语言的。你不需要跟我用一样的工具重点是理解那层“模式切换”的逻辑。2. 整体设计思路为什么需要 context-mode2.1 从“状态爆炸”到“模式收敛”先看一个反面例子。假设你在做一个智能家居控制面板用户可以通过语音或文字控制灯、空调、窗帘。最初代码可能是这样的def handle_command(text, device_states): if 开灯 in text: device_states[light] True elif 关灯 in text: device_states[light] False elif 调高温度 in text: device_states[ac_temp] 1 elif 调低温度 in text: device_states[ac_temp] - 1 elif 打开窗帘 in text: device_states[curtain] open # ... 还有几十个 elif这还只是单轮指令。如果用户说“太暗了”你得结合当前灯光状态、时间、是否在观影模式才能决定是开灯还是调亮。如果用户说“有点冷”你得知道空调当前温度、是否在制热模式。这些判断逻辑如果全部塞进一个函数很快就会变成几百行的 if-else 地狱。context-mode 的思路是把“当前情境”抽象成一个模式对象每个模式只关心自己范围内的输入和状态迁移。比如“照明模式”只处理灯光相关指令“温控模式”只处理温度相关指令“场景模式”负责协调多个设备。模式之间可以嵌套、可以切换但每个模式的逻辑是独立的。这样做的好处很明显新增一个设备类型只需要新增一个模式类不用动原有代码修改某个模式的逻辑不会影响其他模式测试的时候可以单独测试每个模式不用构造全局状态。2.2 模式切换的触发条件设计模式不会自己切换需要有触发机制。常见的触发条件有三类显式指令用户直接说“切换到温控模式”或点击了某个按钮。隐式推断根据输入内容自动判断。比如检测到“温度”“冷热”等关键词自动进入温控模式。状态驱动当前模式执行完某个动作后自动迁移到下一个模式。比如订单支付完成后从“支付模式”切换到“完成模式”。我在实际项目里通常会把这三类结合起来。显式指令优先级最高隐式推断作为补充状态驱动用于流程性任务。这里有个关键设计点模式切换必须是有向的不能随意跳转。比如从“照明模式”不能直接跳到“支付模式”中间必须经过“主菜单模式”。这样可以避免状态混乱也方便做权限控制。注意隐式推断的准确率直接决定用户体验。如果用户说“今天天气怎么样”系统误判为温控模式那就很尴尬。我的经验是隐式推断只作为“建议”最终切换前给用户一个确认提示或者设置一个置信度阈值低于阈值就不切换。2.3 上下文数据的存储与隔离context-mode 里的“context”到底存什么我一般分三层全局上下文用户 ID、会话 ID、设备列表、权限信息。这些数据所有模式共享只读为主。模式上下文当前模式内部的临时变量。比如温控模式里的“目标温度”“当前风速”。这些数据只在当前模式内有效切换模式时可以选择保留或丢弃。历史上下文用户最近几轮的操作记录。用于隐式推断和回退功能。存储方式取决于你的运行环境。如果是单机脚本用字典或对象就行如果是 Web 服务可以放在 Redis 或内存缓存里如果是前端用状态管理库如 Redux、Pinia配合 context 对象。关键原则是模式上下文必须与全局上下文隔离避免一个模式的内部状态污染另一个模式。我踩过的一个坑早期把模式上下文直接挂在全局对象上结果两个模式同时运行时互相覆盖变量。后来改成每个模式实例持有自己的 context 字典问题才解决。所以如果你打算用 context-mode一定要在架构层面把数据边界划清楚。3. 核心细节解析模式定义、切换与生命周期3.1 如何定义一个模式一个模式至少包含四个要素名称、进入条件、处理逻辑、退出动作。用伪代码表示class Mode: name: str def can_enter(self, context) - bool: 判断当前上下文是否允许进入此模式 pass def handle(self, input_text, context) - Mode: 处理输入返回下一个模式可以是自身 pass def on_enter(self, context): 进入模式时的初始化 pass def on_exit(self, context): 退出模式时的清理 passcan_enter用于隐式推断和权限校验。比如“支付模式”的can_enter会检查购物车是否非空、用户是否登录。handle是核心它接收输入和上下文返回下一个模式实例。如果返回自身表示留在当前模式返回其他模式表示切换。on_enter和on_exit用于资源准备和释放比如进入温控模式时读取当前温度退出时保存用户偏好。这里有个细节handle返回的是模式实例还是模式类型我建议返回实例因为实例可以携带自己的上下文数据。如果返回类型切换后还得重新初始化容易丢失状态。当然如果你的模式是无状态的返回类型也可以但那样就失去了 context-mode 的一部分优势。3.2 模式切换的三种方式在实际编码中模式切换有三种常见实现方式各有适用场景第一种返回值驱动。handle方法直接返回下一个模式对象。这种方式最直观适合模式数量不多、切换逻辑简单的场景。缺点是模式之间的依赖关系硬编码在handle里新增模式需要修改原有代码。第二种事件驱动。模式不直接返回下一个模式而是发布一个事件由中央调度器决定切换到哪个模式。这种方式解耦更彻底适合大型系统。但引入事件总线后调试会变复杂因为调用链不再直观。第三种状态机驱动。用状态机库如 Python 的transitions、JavaScript 的xstate定义状态和迁移规则。这种方式最规范可视化程度高但学习成本也最高。如果你的模式切换逻辑非常复杂涉及并行状态、历史状态用状态机库是值得的。我个人的选择是中小型项目用返回值驱动大型项目用事件驱动流程性极强的用状态机。不要为了追求“架构优雅”而过度设计。我见过一个项目总共就五个模式非要用 xstate结果配置文件写了三百行维护起来比 if-else 还痛苦。3.3 模式的生命周期管理模式的生命周期包括创建、进入、处理、退出、销毁。大部分情况下模式实例可以复用不需要频繁创建销毁。但有两种情况需要注意模式携带大量上下文数据比如一个“报表生成模式”需要加载几万条数据。这种模式退出时应该及时释放内存或者把数据序列化到外部存储。模式有外部资源依赖比如“数据库连接模式”持有连接池。退出时必须关闭连接否则会泄漏。我的做法是给模式加一个is_heavy标记轻量模式常驻内存重量模式按需创建、用完销毁。同时用on_exit统一做资源清理避免遗漏。提示模式切换时旧模式的on_exit和新模式的on_enter执行顺序很重要。我通常先执行旧模式的on_exit再执行新模式的on_enter。这样可以确保旧模式释放的资源如锁、文件句柄在新模式使用前已经可用。4. 实操过程从零搭建一个 context-mode 框架4.1 环境准备与项目结构我用 Python 做一个演示因为 Python 的类机制清晰适合讲解。实际项目中你可以用任何语言思路是一样的。先建一个目录mkdir context-mode-demo cd context-mode-demo python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate不需要额外安装依赖标准库就够了。项目结构如下context-mode-demo/ ├── main.py ├── modes/ │ ├── __init__.py │ ├── base.py │ ├── idle.py │ ├── light.py │ ├── temperature.py │ └── scene.py └── context.pybase.py定义模式基类idle.py是空闲模式light.py和temperature.py是具体功能模式scene.py是场景模式。context.py定义上下文数据结构。4.2 定义上下文与模式基类先写context.pyclass Context: def __init__(self, user_id): self.user_id user_id self.global_data {} # 全局共享数据 self.mode_data {} # 当前模式的私有数据 self.history [] # 操作历史 self.current_mode_name idle def log(self, action): self.history.append(action) if len(self.history) 20: self.history.pop(0)global_data存设备状态、用户偏好等mode_data存当前模式的临时变量history保留最近 20 条操作用于隐式推断。接着写base.pyclass BaseMode: name base def can_enter(self, context): return True def on_enter(self, context): context.mode_data {} context.current_mode_name self.name def on_exit(self, context): pass def handle(self, text, context): raise NotImplementedError def __repr__(self): return fMode: {self.name}注意on_enter里重置了mode_data这是为了隔离不同模式的数据。如果你希望某些数据跨模式保留可以放在global_data里。4.3 实现具体模式空闲模式idle.pyfrom .base import BaseMode class IdleMode(BaseMode): name idle def handle(self, text, context): text text.lower() if 灯 in text or 照明 in text: from .light import LightMode return LightMode() elif 温度 in text or 空调 in text or 冷 in text or 热 in text: from .temperature import TemperatureMode return TemperatureMode() elif 场景 in text or 模式 in text: from .scene import SceneMode return SceneMode() else: print(我没听懂你可以说开灯、调温度或场景模式) return self照明模式light.pyfrom .base import BaseMode class LightMode(BaseMode): name light def on_enter(self, context): super().on_enter(context) context.mode_data[light_on] context.global_data.get(light_on, False) print(f进入照明模式当前灯状态{开 if context.mode_data[light_on] else 关}) def handle(self, text, context): text text.lower() if 开 in text: context.mode_data[light_on] True context.global_data[light_on] True print(灯已打开) elif 关 in text: context.mode_data[light_on] False context.global_data[light_on] False print(灯已关闭) elif 退出 in text or 返回 in text: from .idle import IdleMode return IdleMode() else: print(照明模式下你可以说开灯、关灯或退出) return self温控模式temperature.py类似这里省略重复代码。场景模式scene.py可以协调多个设备比如“观影模式”同时关灯、关窗帘、开投影仪。4.4 主循环与模式调度main.pyfrom context import Context from modes.idle import IdleMode def main(): ctx Context(user_iduser_001) current_mode IdleMode() current_mode.on_enter(ctx) print(智能家居控制台已启动输入退出结束程序。) while True: text input( ).strip() if text 退出: current_mode.on_exit(ctx) print(再见) break ctx.log(text) next_mode current_mode.handle(text, ctx) if next_mode is not current_mode: current_mode.on_exit(ctx) next_mode.on_enter(ctx) current_mode next_mode if __name__ __main__: main()运行这个程序你可以输入“开灯”它会自动从空闲模式切换到照明模式然后你再说“关灯”它会在照明模式内处理。输入“退出”回到空闲模式。整个过程模式切换清晰每个模式的逻辑独立。4.5 参数选择与性能考量上面的例子是单用户、单会话的。如果要做成多用户并发服务需要考虑几个参数模式实例缓存每个用户当前模式实例可以缓存在内存里用user_id做 key。但要注意内存占用如果用户量很大需要设置过期时间。上下文序列化如果服务重启内存中的上下文会丢失。可以把Context对象序列化成 JSON 存到 Redis重启后恢复。序列化时注意排除不可序列化的字段如文件句柄。模式切换频率如果用户频繁切换模式on_enter和on_exit会被频繁调用。确保这两个方法里不要做耗时操作比如网络请求。可以把耗时操作异步化或者加缓存。我实测下来单机 Python 处理一千个并发会话每个会话每秒一次输入CPU 占用不到 10%。瓶颈通常不在模式切换而在输入解析和外部服务调用。所以 context-mode 本身的性能开销可以忽略不计。5. 常见问题与排查技巧实录5.1 模式切换后上下文丢失这是最常见的问题。表现是从模式 A 切换到模式 B再切回模式 A发现之前的数据没了。原因通常是on_enter里重置了mode_data或者模式实例被重新创建了。解决方法有两种一是把需要保留的数据放到global_data里二是让模式实例常驻切换时只调用on_enter和on_exit不销毁实例。我倾向于第二种因为模式实例本身很轻量常驻内存没问题。但如果模式持有大量数据就要用第一种。注意如果多个用户共享同一个模式实例千万不要把用户数据存在实例属性里。实例属性是全局的会串数据。用户数据必须存在Context对象里每个用户一个 Context。5.2 隐式推断误触发用户说“今天好热”系统自动进入温控模式但用户其实只是想闲聊。这种误触发会打断用户。我的解决方案是加一个“确认层”隐式推断出目标模式后不立即切换而是问一句“你是想调节温度吗”用户确认后再切换。或者设置一个置信度阈值只有关键词匹配度超过 80% 才自动切换。另一个技巧是维护一个“黑名单”短语。比如“今天好热”如果出现在闲聊历史中就不触发温控模式。这个黑名单可以手动维护也可以用简单的统计方法自动生成。5.3 模式循环切换模式 A 的handle返回模式 B模式 B 的handle又返回模式 A导致死循环。这种情况通常发生在两个模式互相认为对方应该处理当前输入时。排查方法是打印每次切换的日志看是哪个输入触发了循环。预防措施在handle里加一个“切换计数器”如果连续切换超过 3 次就强制回到空闲模式并提示用户。另外设计模式时尽量让切换方向是单向的避免双向依赖。5.4 常见问题速查表问题现象可能原因排查方法解决方案切换后数据丢失on_enter重置了mode_data检查on_enter代码把数据移到global_data或常驻模式实例隐式推断误触发关键词匹配过于宽松打印匹配日志加确认层或提高阈值模式循环切换两个模式互相返回对方打印切换日志加切换计数器强制回退多用户数据串扰用户数据存在模式实例属性检查实例属性数据存到 Context 对象性能下降on_enter/on_exit有耗时操作打点计时异步化或加缓存5.5 独家避坑技巧第一个技巧给每个模式加一个debug方法返回当前模式的关键状态。这样出问题时直接调用debug就能看到内部数据不用加一堆 print。第二个技巧用配置文件定义模式切换规则。比如用一个 JSON 文件描述“空闲模式下输入包含‘灯’则切换到照明模式”。这样修改切换逻辑不用改代码重启服务即可。适合模式经常变动的项目。第三个技巧模式命名要统一。我见过一个项目模式名有LightMode、light_mode、light三种写法导致日志混乱。建议全部用小写加下划线比如light_mode简单一致。第四个技巧写单元测试时直接测试handle方法。构造一个 Context传入输入断言返回的模式类型。不需要启动整个服务。这样测试速度快覆盖率高。6. 扩展思路context-mode 还能用在哪里6.1 多步骤表单的步骤管理前端做多步骤表单时每一步可以看作一个模式。用户点击“下一步”触发模式切换on_exit校验当前步骤数据on_enter初始化下一步。如果用户点击“上一步”就切换到上一个模式数据从global_data里恢复。这样比用一个大对象管理所有步骤清晰得多。6.2 游戏 NPC 对话树游戏里的 NPC 对话天然适合 context-mode。每个对话节点是一个模式玩家的选择决定下一个模式。global_data存好感度、任务进度mode_data存当前对话的临时变量。用这套模式策划可以独立配置对话树程序只需要实现模式调度器。6.3 工作流引擎的状态流转审批流、订单流、工单流本质上都是状态机。用 context-mode 可以把每个状态封装成模式状态迁移规则写在handle里。相比传统的状态机库context-mode 更灵活因为模式可以携带自己的业务逻辑不只是一张状态迁移表。6.4 与现有框架的结合如果你在用 React可以把每个模式映射成一个组件用 Context API 传递全局数据。如果你在用 Vue可以用 Pinia 的 store 管理模式状态。如果你在用 Django可以把模式做成类视图用中间件处理模式切换。核心思想不变只是换了个壳。我在实际项目里最大的体会是context-mode 不是银弹它解决的是“状态和逻辑耦合”的问题。如果你的项目状态很简单用 if-else 就够了没必要引入模式。但如果你的项目有多个交互场景、多种用户角色、多个流程分支context-mode 能帮你把代码组织得清清楚楚。判断标准很简单当你发现一个函数里超过五个 if-else 都在判断“当前是什么场景”时就该考虑用 context-mode 了。最后分享一个小技巧刚开始用 context-mode 时不要一次性把所有逻辑都迁移过去。先选一个最复杂的模块试点跑通了再推广。我当初就是全盘重构结果模式之间依赖太多调试了一周才稳定。后来学乖了一个模块一个模块地改风险小很多。