做技术的人大概都遇到过这种场景同一个系统里给A业务用的会话逻辑和给B业务用的会话逻辑长得很像但细节上就是不一样。今天想聊的这个项目标题叫“context-mode”说白了就是一套把上下文按模式整理、按场景切换的管理机制。它不是什么新框架、新语言更像是一种组织代码和状态的思路配合一个轻量的管理内核落地。这个思路解决的痛点非常具体上下文串台、状态混乱、权限越界、会话之间的干扰以及最要命的——项目越做越大之后新同学根本不敢动上下文相关的代码。这篇文章主要面向后端开发者、前端做状态管理的同学以及所有在给AI能力做封装的人。我会按设计思路、核心实现、实操接入、问题排查四个部分展开尽量把能直接落地的细节都讲清楚。1. 先想清楚context-mode到底在解决什么问题1.1 没有模式管理时的“上下文灾难”我先举一个真实发生过的场景。某个内部项目同时接了多个业务方每个业务方都要求自己的对话能带一点私有记忆比如A业务要记住用户上次选的套餐B业务要记住用户当前的填单进度C业务只允许查询公开资料不许碰任何用户隐私字段。刚开始的时候大家觉得这没什么就是一个全局Map存一下反正对话结束就清掉。但实际跑起来之后问题立刻暴露业务A的会话里莫名其妙出现了业务B的字段前端渲染炸了。业务C本来应该是只读的但因为上下文里带着某个标记AI模型直接帮用户把已提交的申请单撤销了。某个异步任务在后台跑着把上下文里的临时变量改了主流程拿到的数据对不上。这些问题本质上不是“代码写错了”而是上下文没有边界。没有边界就意味着任何代码在任何时刻都能读到任何数据也意味着你没法保证“这个模式下的行为是确定的”。1.2 模式拆分的核心思路context-mode的核心思路很简单把上下文从“一个大口袋”拆成“一组带标签的小口袋”。每个小口袋对应一种模式比如“套餐咨询模式”“订单处理模式”“只读问答模式”。每个模式声明自己能访问哪些数据域能调用哪些工具生命周期是长是短。这样做有三层好处第一层隔离。模式与模式之间的数据互不可见即便底层是同一个缓存也不会互相污染。第二层可控。模式切换的时候系统明确知道现在要卸载什么、加载什么、哪些状态要保留、哪些状态必须丢弃不会出现“上一轮对话的残留数据流到下一轮”的情况。第三层可审计。因为每次切换都走统一入口日志里能清楚看到“什么时候切到了什么模式、带上了哪些上下文”排查问题的时候不用靠猜。打个不太严谨的比方以前做菜是一口大锅什么料都往里扔现在context-mode是分格便当盒每格就是一道菜吃哪格开哪格。2. 模式定义与切换策略的设计细节2.1 模式的数据结构设计要说落地我建议先把模式本身建模成一个对象而不是散落在代码里的零散判断。我习惯用类似下面这种结构字段作用示例modeId模式唯一标识product_consultdataScope允许访问的数据域集合[product, user_public]toolScope允许调用的工具或函数集合[query_product, calc_price]ttl上下文存活时间30 * 60 * 1000parentMode父模式用于继承公共信息baseonEnter进入模式时的钩子加载基础信息onExit退出模式时的钩子清理临时变量这样建模的直接好处是判断“当前能不能做某件事”从一串散落的if-else变成了一次配置查表。你不需要在业务代码里反复写“如果当前模式是xx才允许yy”只需要在注册阶段把权限和数据边界描述清楚。再说说继承。我建议所有模式都继承一个base模式base模式里放一些通用的东西比如用户ID、请求ID、全局设置。这样公共信息只需要处理一次子模式只需要关注自己特有的数据。继承不是万能的但能省掉大量重复的初始化逻辑。2.2 切换策略显式、自动与混合模式切换是整个机制里最容易出错的地方。我的经验是先明确切换是由谁触发的才好决定怎么做状态清理。显式切换是最常见的比如用户在界面里点了“切换到订单处理”前端调接口后端把当前上下文从product_consult切到order_handle。这种切换逻辑清晰适合产品流程固定的场景。自动切换适合那种“用户没说切换但系统能判断该切了”的情况。比如用户问“我要退掉刚才那个订单”系统语义识别出意图是“退款”此时自动切到退款模式。自动切换的难点在于“判断的时机”切早了用户还没确认就容易误判切晚了又可能让AI读到不该读的数据。混合策略是我自己用得最多的先用规则或模型判断一个“候选模式”但不立刻生效而是进入一个“预备态”等用户或业务逻辑确认后再完成切换。这个预备态在实现上很简单就是在模式管理器里加一个pendingModeId字段。这里我放一张三种策略的对比表策略优点缺点适用场景显式切换逻辑简单、可控性强需要业务方配合传参流程固定的业务自动切换体验好、无感知判断错代价高意图明确的高频场景混合切换兼顾准确与体验实现成本略高对准确性要求高的场景2.3 切换时如何决定状态保留还是销毁这是很多项目做不好的点。一种极端是切换就清空一切导致来回切换时用户体验断裂另一种极端是永远不清导致内存越积越多、上下文串味。我的原则是保留可恢复的销毁不可恢复的。具体来说把上下文数据分成三类请求级数据比如当前正在处理的一个请求参数切换后必须销毁。会话级数据比如用户在本会话内的选择记录切换后建议保留。全局级数据比如服务配置、公共字典任何模式共享永远保留。实现上可以给每个数据项打一个persist标记。切换模式时扫描当前模式的所有数据项persistfalse的直接丢弃persisttrue的移入公共层。3. 核心实现一个简洁的context-mode管理器3.1 代码骨架我用TypeScript写了一个非常精简的版本核心设计思路是用一个注册表保存所有模式定义用一个运行时对象记录当前状态。完整代码不算长但该有的功能都有注册模式、切换模式、数据读写、监听器、日志。type DataScope Recordstring, any; interface ModeDefinition { modeId: string; dataScope: DataScope; toolScope: string[]; ttl?: number; parentMode?: string; onEnter?: (ctx: ContextRuntime) Promisevoid | void; onExit?: (ctx: ContextRuntime) Promisevoid | void; } interface ContextRuntime { modeId: string; data: DataScope; dump: () DataScope; } class ContextModeManager { private modes new Mapstring, ModeDefinition(); private runtime: ContextRuntime { modeId: base, data: {} }; private history: string[] []; private listeners new Mapstring, Function[](); registerMode(def: ModeDefinition) { if (this.modes.has(def.modeId)) { throw new Error(Mode ${def.modeId} already registered); } this.modes.set(def.modeId, def); } async switchTo(modeId: string, payload?: DataScope) { if (!this.modes.has(modeId)) { throw new Error(Mode ${modeId} not found); } const currentDef this.modes.get(this.runtime.modeId); if (currentDef?.onExit) { await currentDef.onExit(this.runtime); } const targetDef this.modes.get(modeId)!; // 合并继承数据 let mergedData: DataScope {}; if (targetDef.parentMode this.modes.has(targetDef.parentMode)) { mergedData { ...this.modes.get(targetDef.parentMode!)!.dataScope, ...targetDef.dataScope, }; } else { mergedData { ...targetDef.dataScope }; } // 保留可持久化的旧数据 for (const [key, value] of Object.entries(this.runtime.data)) { const persist (value as any)?.__persist; if (persist) { mergedData[key] value; } } // 应用payloadpayload优先级最高 if (payload) { mergedData { ...mergedData, ...payload }; } this.history.push(this.runtime.modeId); this.runtime { modeId, data: mergedData, dump: () JSON.parse(JSON.stringify(this.runtime.data)), }; if (targetDef.onEnter) { await targetDef.onEnter(this.runtime); } this.emit(change, { from: this.history[this.history.length - 1], to: modeId }); } getData(): DataScope { return this.runtime.dump(); } setData(key: string, value: any, persist false) { if (persist) { value { ...value, __persist: true }; } this.runtime.data[key] value; } get modeId(): string { return this.runtime.modeId; } on(event: string, handler: (payload: any) void) { if (!this.listeners.has(event)) { this.listeners.set(event, []); } this.listeners.get(event)!.push(handler); } undo() { if (this.history.length 0) return; const prev this.history.pop()!; this.switchTo(prev); } private emit(event: string, payload: any) { this.listeners.get(event)?.forEach((handler) handler(payload)); } } export const contextMode new ContextModeManager();注意一点dump()这里我直接用了JSON.parse(JSON.stringify(...))简单粗暴地实现深拷贝避免外部拿到引用之后乱改内部数据。但在数据量大或存在复杂对象时建议换成结构化克隆或者只读代理生产环境要按需优化。3.2 关键实现细节防抖、事务、日志、回滚代码骨架只是第一步真正让这个管理器“稳”的是几个边界处理。防抖如果自动切换触发很频繁比如用户的输入每敲一个字就触发一次意图识别那么模式切换可能在一个瞬间连续发生多次。我的做法是给switchTo加一个去重逻辑连续300毫秒内如果目标模式相同就只执行第一次丢弃后续调用。实现上就是在方法入口检查一下if (this.runtime.modeId modeId Date.now() - lastSwitchTime 300) return;。事务切换过程涉及“退出旧模式”和“进入新模式”两个阶段如果onExit里报了错是继续切换还是回滚我推荐的做法是先把旧模式的数据快照保存下来然后执行新模式的onEnter如果中途失败自动回滚到旧模式并把错误记录到日志里。等于是给切换操作加了异常保护避免“半切换”状态。日志每次切换时至少要记录这么几个字段切换时间、模式id、触发来源是用户请求还是程序内自动、payload里带的数据域。这个日志的价值在排查“是谁改了上下文数据”的时候非常明显。回滚undo()方法虽然简单但在UI层面非常好用比如用户连续切换了三次模式第四步想退回第三步的状态可以直接调用。要注意的是回滚时如果目标模式已经不在注册表里要捕获异常防止脏数据。3.3 与前端状态管理、后端请求上下文、AI会话的集成context-mode不能独立存在它一定会嵌入到某个宿主环境。我分享三个我实际做过的集成点。前端集成以前端React为例可以把模式id存进一个全局状态里配合useMode这个自定义Hook。当模式切换时前端把模式id作为请求头传给后端后端根据这个模式id决定加载哪块上下文。这个做法的好处是前后端的“模式”是同一个词不会出现前端展示A但后端用的是B的错位。实现上也简单拦截器里统一加上header就行。后端请求上下文在服务端处理一个请求时从请求头里取出模式id一路传到底层服务。我推荐把模式管理器做成一个请求级别的实例而不是全局单例避免多个请求并发时互相串数据。如果你是用Node.js可以用异步本地存储比如AsyncLocalStorage来实现每个请求都有自己的context-mode实例互不干扰。AI会话管理在给大模型做封装的时候context-mode天然适合作为“Prompt前缀管理器”的底层。每种模式对应一套系统提示词和一批工具函数白名单。切换模式的本质就是换Prompt、换工具集、换记忆上限。比如“咨询模式”只调搜索工具“写码模式”只调代码解释器这样哪怕模型本身能力很强也不会因为上下文里存在不该有的工具而产生越权行为。4. 实操过程与核心环节实现4.1 从零到一接入一个实际项目的完整步骤我用一个虚构的案例来模拟完整接入过程。假设某团队在做“内部智能客服系统”要求支持产品咨询、订单处理、售后工单三个核心业务。最初版本是全耦合的单体上下文现在已经乱到改一个字段就得翻三处代码。第一步梳理业务模式。和产品、业务各自过了一遍流程确定三个模式product_info产品咨询只读公开产品库允许查价格、查参数。order_process订单处理需要读写当前用户的订单草稿允许调下单接口。after_sale售后工单需要创建工单、查询工单状态不允许触碰未完成订单的支付信息。第二步设计数据域。这里我们列了一张权限矩阵表明确每个模式能访问哪些数据集合比如数据域product_infoorder_processafter_sale产品公开信息允许读允许读允许读用户基本信息允许读允许读允许读订单草稿禁止允许读写禁止支付流水禁止禁止禁止工单记录禁止禁止允许读写第三步注册模式。用上文代码里的registerMode把三个模式注册进去同时注册一个base模式放公共的用户身份信息。每个模式都写上onEnter和onExit比如进入after_sale时会自动创建工单草稿退出时自动保存草稿状态。第四步接入口改造。把原来所有直接读写“全局上下文”的地方统一改成通过contextMode.getData()和contextMode.setData()访问。这一步是侵入性最大的但必须做否则绕开管理器直接改数据所有隔离效果都会失效。第五步加日志和监控。每切换一次模式就输出一条结构化日志。上线后观察一周重点看两类异常一类是“不该出现在该模式的数据”有没有出现另一类是“切换失败”的频率高不高。第六步灰度上线。先让内部测试组用自己的账号体验一周确认所有切换场景符合预期后再放开全量。千万不要第一天就全量上下文这种问题往往比功能bug更难发现。4.2 参数计算与模式生命周期管理有些人对“上下文该保留多久”没概念结果内存里残留了一堆几天前的数据。我的经验是给每个模式设置一个ttl生存时间到期后自动重置为初始状态。计算公式很简单如果这个模式是短交互型的比如“填单”ttl设置为5到10分钟就够。如果是中长会话型比如“售后咨询”建议30分钟。如果是跨天场景比如“购物车”可以设置到24小时但每次切换前都要先校验用户身份避免串号。在实现上ttl不需要单独起线程扫描我采用懒过期策略每次getData或switchTo时检查一下当前时间是否超过ttl点超过就自动执行onExit并重新初始化。这样既能清理过期数据又不会增加额外的CPU负担。4.3 实际踩过的坑三个典型问题第一个坑是切换顺序。曾经有一版代码里onExit和onEnter里都会异步加载数据结果“退出A”和“进入B”的异步操作并发执行B加载的数据先返回A加载的数据后返回直接把B模式的数据覆盖了。后来把所有切换操作都改成串行队列才彻底解决。这个坑非常隐蔽因为不是必现只有数据稍微慢一点的时候才触发。第二个坑是敏感字段误带。有一次做权限收敛发现product_info模式里居然能读到用户的手机号查了好一会儿才发现是早些时候“顺手存进去的”。现在我在setData接口里强制要求每个数据项打上安全等级标签凡是敏感字段且当前模式不包含对应dataScope的一律拒绝写入。第三个坑是忘记清理监听器。模式切换是一个高频事件如果每次切换都注册一个新监听器且不注销内存泄漏会非常严重。我建议在switchTo事件处理时使用“发布订阅管理器”的off方法或者强制要求监听器返回一个取消函数。5. 上线前检查清单与团队协作规范5.1 Review时我会问的八个问题每次有项目要接入context-mode我都会带着一张问题清单去做Code Review帮你省掉大部分低级问题每个模式是否都明确了dataScope和toolScope有没有存在“不注册也生效”的数据写入路径切换模式时旧的请求级数据是否已经清空onEnter和onExit是否可能抛出异常会导致切换卡住模式id是否全局唯一有没有可能两个业务用了同一个id日志是否记录了切换触发来源有没有给运行时数据做深拷贝避免外部引用篡改敏感数据的存储是否做了脱敏处理这些问题回答不上来说明设计还没有闭环。5.2 团队协作时的命名与职责约定多人在一个仓库上开发时最怕的是每个人凭感觉起模式名。我的建议是模式命名遵循业务域_场景的格式比如order.submit、order.refund、product.detail避免叫mode1、mode2这种没信息量的名字。所有模式定义必须集中在同一个文件或目录里不许散落在业务代码里。新增模式前先看已有模式能不能复用或继承。谁新增模式谁就要同步维护权限矩阵表并写清楚这个模式的出现场景和退出条件。这套规范不是约束人的而是让新同学接手时能快速理解“什么场景下该开什么模式”不需要去翻几个月前的聊天记录才能搞懂上下文机制。6. 从context-mode延展出去的几个方向做完这个基础版本之后实际使用中还可以继续往两个方向扩展。第一个方向是与可观测性结合。模式切换日志不只是用来排查故障的它还能反映业务分布一天里哪个模式被切入最多、平均停留时间多久、哪些模式切了立刻又切回来。这些数据对产品决策非常有价值。比如“订单处理”模式停留时间很短说明用户可能只是进来查一下状态并没有完成下单。第二个方向是模式快照与恢复。我现在会定期给模式的运行时数据做快照存在独立存储里。如果服务崩溃重启可以按用户维度和模式维度恢复到最近一次快照避免用户体验断档。这个功能对长流程业务尤其重要比如用户填了二十个字段的表单不能因为服务重启就全部重来。还有个小技巧是预加载根据用户当前所处模式提前把他下一个最可能切换的模式的数据预加载到缓存等真正切换时延迟可以降低一个数量级。我做过一个简单的实现效果很理想从300毫秒左右降到了50毫秒以下。当然这个预加载必须严格控制数据可见性不能因为预加载就把数据暴露出去。7. 一些个人体会和总结性建议做context-mode这类机制最难的不是写代码而是跟团队达成一致上下文不是“顺手存一下”的东西它是一个有边界、有生命周期、有权限约束的正式资源。我第一次把这套机制引入项目时被问得最多的一个问题就是“这有什么必要一个全局对象而已”。后来是线上出过一次串数据的事故才让所有人达成共识。那次事故本身不大但排查过程极其痛苦因为问题不是必现的而是依赖若干次异步调用的先后顺序。从那之后团队里再没人嫌模式切换“多了一道工序”。从务实角度说我给几条建议不要追求一次性设计出“完美模式树”从两三个模式开始就够。先把“切换入口”统一再慢慢收编那些散落在各处的数据读写。日志和监控一定要早做不然后面出问题只能抓瞎。如果团队已经习惯了直接操作全局状态改造的时候建议先做一段时间的“读写代理模式”让他们通过manager的API读写而不是直接删掉原来的全局变量。context-mode并不是银弹它不能帮你解决业务逻辑本身的复杂度但它能把“上下文管理”这块最难追溯、最难测试的复杂度收敛到一个可配置、可审计、可回滚的机制里。只要模式定义和切换策略是清晰的系统的状态就是可控的状态可控了排错、优化、扩展就有了基础。希望这篇分享能帮你少走一些弯路。如果你也在做类似的问题欢迎按这套思路先搭个最小骨架跑起来。 
长河君 · 2026/10/20 16:01:15 · 阅读 1.2k context-mode：上下文按模式管理的设计思路与落地实践
做技术的人大概都遇到过这种场景同一个系统里给A业务用的会话逻辑和给B业务用的会话逻辑长得很像但细节上就是不一样。今天想聊的这个项目标题叫“context-mode”说白了就是一套把上下文按模式整理、按场景切换的管理机制。它不是什么新框架、新语言更像是一种组织代码和状态的思路配合一个轻量的管理内核落地。这个思路解决的痛点非常具体上下文串台、状态混乱、权限越界、会话之间的干扰以及最要命的——项目越做越大之后新同学根本不敢动上下文相关的代码。这篇文章主要面向后端开发者、前端做状态管理的同学以及所有在给AI能力做封装的人。我会按设计思路、核心实现、实操接入、问题排查四个部分展开尽量把能直接落地的细节都讲清楚。1. 先想清楚context-mode到底在解决什么问题1.1 没有模式管理时的“上下文灾难”我先举一个真实发生过的场景。某个内部项目同时接了多个业务方每个业务方都要求自己的对话能带一点私有记忆比如A业务要记住用户上次选的套餐B业务要记住用户当前的填单进度C业务只允许查询公开资料不许碰任何用户隐私字段。刚开始的时候大家觉得这没什么就是一个全局Map存一下反正对话结束就清掉。但实际跑起来之后问题立刻暴露业务A的会话里莫名其妙出现了业务B的字段前端渲染炸了。业务C本来应该是只读的但因为上下文里带着某个标记AI模型直接帮用户把已提交的申请单撤销了。某个异步任务在后台跑着把上下文里的临时变量改了主流程拿到的数据对不上。这些问题本质上不是“代码写错了”而是上下文没有边界。没有边界就意味着任何代码在任何时刻都能读到任何数据也意味着你没法保证“这个模式下的行为是确定的”。1.2 模式拆分的核心思路context-mode的核心思路很简单把上下文从“一个大口袋”拆成“一组带标签的小口袋”。每个小口袋对应一种模式比如“套餐咨询模式”“订单处理模式”“只读问答模式”。每个模式声明自己能访问哪些数据域能调用哪些工具生命周期是长是短。这样做有三层好处第一层隔离。模式与模式之间的数据互不可见即便底层是同一个缓存也不会互相污染。第二层可控。模式切换的时候系统明确知道现在要卸载什么、加载什么、哪些状态要保留、哪些状态必须丢弃不会出现“上一轮对话的残留数据流到下一轮”的情况。第三层可审计。因为每次切换都走统一入口日志里能清楚看到“什么时候切到了什么模式、带上了哪些上下文”排查问题的时候不用靠猜。打个不太严谨的比方以前做菜是一口大锅什么料都往里扔现在context-mode是分格便当盒每格就是一道菜吃哪格开哪格。2. 模式定义与切换策略的设计细节2.1 模式的数据结构设计要说落地我建议先把模式本身建模成一个对象而不是散落在代码里的零散判断。我习惯用类似下面这种结构字段作用示例modeId模式唯一标识product_consultdataScope允许访问的数据域集合[product, user_public]toolScope允许调用的工具或函数集合[query_product, calc_price]ttl上下文存活时间30 * 60 * 1000parentMode父模式用于继承公共信息baseonEnter进入模式时的钩子加载基础信息onExit退出模式时的钩子清理临时变量这样建模的直接好处是判断“当前能不能做某件事”从一串散落的if-else变成了一次配置查表。你不需要在业务代码里反复写“如果当前模式是xx才允许yy”只需要在注册阶段把权限和数据边界描述清楚。再说说继承。我建议所有模式都继承一个base模式base模式里放一些通用的东西比如用户ID、请求ID、全局设置。这样公共信息只需要处理一次子模式只需要关注自己特有的数据。继承不是万能的但能省掉大量重复的初始化逻辑。2.2 切换策略显式、自动与混合模式切换是整个机制里最容易出错的地方。我的经验是先明确切换是由谁触发的才好决定怎么做状态清理。显式切换是最常见的比如用户在界面里点了“切换到订单处理”前端调接口后端把当前上下文从product_consult切到order_handle。这种切换逻辑清晰适合产品流程固定的场景。自动切换适合那种“用户没说切换但系统能判断该切了”的情况。比如用户问“我要退掉刚才那个订单”系统语义识别出意图是“退款”此时自动切到退款模式。自动切换的难点在于“判断的时机”切早了用户还没确认就容易误判切晚了又可能让AI读到不该读的数据。混合策略是我自己用得最多的先用规则或模型判断一个“候选模式”但不立刻生效而是进入一个“预备态”等用户或业务逻辑确认后再完成切换。这个预备态在实现上很简单就是在模式管理器里加一个pendingModeId字段。这里我放一张三种策略的对比表策略优点缺点适用场景显式切换逻辑简单、可控性强需要业务方配合传参流程固定的业务自动切换体验好、无感知判断错代价高意图明确的高频场景混合切换兼顾准确与体验实现成本略高对准确性要求高的场景2.3 切换时如何决定状态保留还是销毁这是很多项目做不好的点。一种极端是切换就清空一切导致来回切换时用户体验断裂另一种极端是永远不清导致内存越积越多、上下文串味。我的原则是保留可恢复的销毁不可恢复的。具体来说把上下文数据分成三类请求级数据比如当前正在处理的一个请求参数切换后必须销毁。会话级数据比如用户在本会话内的选择记录切换后建议保留。全局级数据比如服务配置、公共字典任何模式共享永远保留。实现上可以给每个数据项打一个persist标记。切换模式时扫描当前模式的所有数据项persistfalse的直接丢弃persisttrue的移入公共层。3. 核心实现一个简洁的context-mode管理器3.1 代码骨架我用TypeScript写了一个非常精简的版本核心设计思路是用一个注册表保存所有模式定义用一个运行时对象记录当前状态。完整代码不算长但该有的功能都有注册模式、切换模式、数据读写、监听器、日志。type DataScope Recordstring, any; interface ModeDefinition { modeId: string; dataScope: DataScope; toolScope: string[]; ttl?: number; parentMode?: string; onEnter?: (ctx: ContextRuntime) Promisevoid | void; onExit?: (ctx: ContextRuntime) Promisevoid | void; } interface ContextRuntime { modeId: string; data: DataScope; dump: () DataScope; } class ContextModeManager { private modes new Mapstring, ModeDefinition(); private runtime: ContextRuntime { modeId: base, data: {} }; private history: string[] []; private listeners new Mapstring, Function[](); registerMode(def: ModeDefinition) { if (this.modes.has(def.modeId)) { throw new Error(Mode ${def.modeId} already registered); } this.modes.set(def.modeId, def); } async switchTo(modeId: string, payload?: DataScope) { if (!this.modes.has(modeId)) { throw new Error(Mode ${modeId} not found); } const currentDef this.modes.get(this.runtime.modeId); if (currentDef?.onExit) { await currentDef.onExit(this.runtime); } const targetDef this.modes.get(modeId)!; // 合并继承数据 let mergedData: DataScope {}; if (targetDef.parentMode this.modes.has(targetDef.parentMode)) { mergedData { ...this.modes.get(targetDef.parentMode!)!.dataScope, ...targetDef.dataScope, }; } else { mergedData { ...targetDef.dataScope }; } // 保留可持久化的旧数据 for (const [key, value] of Object.entries(this.runtime.data)) { const persist (value as any)?.__persist; if (persist) { mergedData[key] value; } } // 应用payloadpayload优先级最高 if (payload) { mergedData { ...mergedData, ...payload }; } this.history.push(this.runtime.modeId); this.runtime { modeId, data: mergedData, dump: () JSON.parse(JSON.stringify(this.runtime.data)), }; if (targetDef.onEnter) { await targetDef.onEnter(this.runtime); } this.emit(change, { from: this.history[this.history.length - 1], to: modeId }); } getData(): DataScope { return this.runtime.dump(); } setData(key: string, value: any, persist false) { if (persist) { value { ...value, __persist: true }; } this.runtime.data[key] value; } get modeId(): string { return this.runtime.modeId; } on(event: string, handler: (payload: any) void) { if (!this.listeners.has(event)) { this.listeners.set(event, []); } this.listeners.get(event)!.push(handler); } undo() { if (this.history.length 0) return; const prev this.history.pop()!; this.switchTo(prev); } private emit(event: string, payload: any) { this.listeners.get(event)?.forEach((handler) handler(payload)); } } export const contextMode new ContextModeManager();注意一点dump()这里我直接用了JSON.parse(JSON.stringify(...))简单粗暴地实现深拷贝避免外部拿到引用之后乱改内部数据。但在数据量大或存在复杂对象时建议换成结构化克隆或者只读代理生产环境要按需优化。3.2 关键实现细节防抖、事务、日志、回滚代码骨架只是第一步真正让这个管理器“稳”的是几个边界处理。防抖如果自动切换触发很频繁比如用户的输入每敲一个字就触发一次意图识别那么模式切换可能在一个瞬间连续发生多次。我的做法是给switchTo加一个去重逻辑连续300毫秒内如果目标模式相同就只执行第一次丢弃后续调用。实现上就是在方法入口检查一下if (this.runtime.modeId modeId Date.now() - lastSwitchTime 300) return;。事务切换过程涉及“退出旧模式”和“进入新模式”两个阶段如果onExit里报了错是继续切换还是回滚我推荐的做法是先把旧模式的数据快照保存下来然后执行新模式的onEnter如果中途失败自动回滚到旧模式并把错误记录到日志里。等于是给切换操作加了异常保护避免“半切换”状态。日志每次切换时至少要记录这么几个字段切换时间、模式id、触发来源是用户请求还是程序内自动、payload里带的数据域。这个日志的价值在排查“是谁改了上下文数据”的时候非常明显。回滚undo()方法虽然简单但在UI层面非常好用比如用户连续切换了三次模式第四步想退回第三步的状态可以直接调用。要注意的是回滚时如果目标模式已经不在注册表里要捕获异常防止脏数据。3.3 与前端状态管理、后端请求上下文、AI会话的集成context-mode不能独立存在它一定会嵌入到某个宿主环境。我分享三个我实际做过的集成点。前端集成以前端React为例可以把模式id存进一个全局状态里配合useMode这个自定义Hook。当模式切换时前端把模式id作为请求头传给后端后端根据这个模式id决定加载哪块上下文。这个做法的好处是前后端的“模式”是同一个词不会出现前端展示A但后端用的是B的错位。实现上也简单拦截器里统一加上header就行。后端请求上下文在服务端处理一个请求时从请求头里取出模式id一路传到底层服务。我推荐把模式管理器做成一个请求级别的实例而不是全局单例避免多个请求并发时互相串数据。如果你是用Node.js可以用异步本地存储比如AsyncLocalStorage来实现每个请求都有自己的context-mode实例互不干扰。AI会话管理在给大模型做封装的时候context-mode天然适合作为“Prompt前缀管理器”的底层。每种模式对应一套系统提示词和一批工具函数白名单。切换模式的本质就是换Prompt、换工具集、换记忆上限。比如“咨询模式”只调搜索工具“写码模式”只调代码解释器这样哪怕模型本身能力很强也不会因为上下文里存在不该有的工具而产生越权行为。4. 实操过程与核心环节实现4.1 从零到一接入一个实际项目的完整步骤我用一个虚构的案例来模拟完整接入过程。假设某团队在做“内部智能客服系统”要求支持产品咨询、订单处理、售后工单三个核心业务。最初版本是全耦合的单体上下文现在已经乱到改一个字段就得翻三处代码。第一步梳理业务模式。和产品、业务各自过了一遍流程确定三个模式product_info产品咨询只读公开产品库允许查价格、查参数。order_process订单处理需要读写当前用户的订单草稿允许调下单接口。after_sale售后工单需要创建工单、查询工单状态不允许触碰未完成订单的支付信息。第二步设计数据域。这里我们列了一张权限矩阵表明确每个模式能访问哪些数据集合比如数据域product_infoorder_processafter_sale产品公开信息允许读允许读允许读用户基本信息允许读允许读允许读订单草稿禁止允许读写禁止支付流水禁止禁止禁止工单记录禁止禁止允许读写第三步注册模式。用上文代码里的registerMode把三个模式注册进去同时注册一个base模式放公共的用户身份信息。每个模式都写上onEnter和onExit比如进入after_sale时会自动创建工单草稿退出时自动保存草稿状态。第四步接入口改造。把原来所有直接读写“全局上下文”的地方统一改成通过contextMode.getData()和contextMode.setData()访问。这一步是侵入性最大的但必须做否则绕开管理器直接改数据所有隔离效果都会失效。第五步加日志和监控。每切换一次模式就输出一条结构化日志。上线后观察一周重点看两类异常一类是“不该出现在该模式的数据”有没有出现另一类是“切换失败”的频率高不高。第六步灰度上线。先让内部测试组用自己的账号体验一周确认所有切换场景符合预期后再放开全量。千万不要第一天就全量上下文这种问题往往比功能bug更难发现。4.2 参数计算与模式生命周期管理有些人对“上下文该保留多久”没概念结果内存里残留了一堆几天前的数据。我的经验是给每个模式设置一个ttl生存时间到期后自动重置为初始状态。计算公式很简单如果这个模式是短交互型的比如“填单”ttl设置为5到10分钟就够。如果是中长会话型比如“售后咨询”建议30分钟。如果是跨天场景比如“购物车”可以设置到24小时但每次切换前都要先校验用户身份避免串号。在实现上ttl不需要单独起线程扫描我采用懒过期策略每次getData或switchTo时检查一下当前时间是否超过ttl点超过就自动执行onExit并重新初始化。这样既能清理过期数据又不会增加额外的CPU负担。4.3 实际踩过的坑三个典型问题第一个坑是切换顺序。曾经有一版代码里onExit和onEnter里都会异步加载数据结果“退出A”和“进入B”的异步操作并发执行B加载的数据先返回A加载的数据后返回直接把B模式的数据覆盖了。后来把所有切换操作都改成串行队列才彻底解决。这个坑非常隐蔽因为不是必现只有数据稍微慢一点的时候才触发。第二个坑是敏感字段误带。有一次做权限收敛发现product_info模式里居然能读到用户的手机号查了好一会儿才发现是早些时候“顺手存进去的”。现在我在setData接口里强制要求每个数据项打上安全等级标签凡是敏感字段且当前模式不包含对应dataScope的一律拒绝写入。第三个坑是忘记清理监听器。模式切换是一个高频事件如果每次切换都注册一个新监听器且不注销内存泄漏会非常严重。我建议在switchTo事件处理时使用“发布订阅管理器”的off方法或者强制要求监听器返回一个取消函数。5. 上线前检查清单与团队协作规范5.1 Review时我会问的八个问题每次有项目要接入context-mode我都会带着一张问题清单去做Code Review帮你省掉大部分低级问题每个模式是否都明确了dataScope和toolScope有没有存在“不注册也生效”的数据写入路径切换模式时旧的请求级数据是否已经清空onEnter和onExit是否可能抛出异常会导致切换卡住模式id是否全局唯一有没有可能两个业务用了同一个id日志是否记录了切换触发来源有没有给运行时数据做深拷贝避免外部引用篡改敏感数据的存储是否做了脱敏处理这些问题回答不上来说明设计还没有闭环。5.2 团队协作时的命名与职责约定多人在一个仓库上开发时最怕的是每个人凭感觉起模式名。我的建议是模式命名遵循业务域_场景的格式比如order.submit、order.refund、product.detail避免叫mode1、mode2这种没信息量的名字。所有模式定义必须集中在同一个文件或目录里不许散落在业务代码里。新增模式前先看已有模式能不能复用或继承。谁新增模式谁就要同步维护权限矩阵表并写清楚这个模式的出现场景和退出条件。这套规范不是约束人的而是让新同学接手时能快速理解“什么场景下该开什么模式”不需要去翻几个月前的聊天记录才能搞懂上下文机制。6. 从context-mode延展出去的几个方向做完这个基础版本之后实际使用中还可以继续往两个方向扩展。第一个方向是与可观测性结合。模式切换日志不只是用来排查故障的它还能反映业务分布一天里哪个模式被切入最多、平均停留时间多久、哪些模式切了立刻又切回来。这些数据对产品决策非常有价值。比如“订单处理”模式停留时间很短说明用户可能只是进来查一下状态并没有完成下单。第二个方向是模式快照与恢复。我现在会定期给模式的运行时数据做快照存在独立存储里。如果服务崩溃重启可以按用户维度和模式维度恢复到最近一次快照避免用户体验断档。这个功能对长流程业务尤其重要比如用户填了二十个字段的表单不能因为服务重启就全部重来。还有个小技巧是预加载根据用户当前所处模式提前把他下一个最可能切换的模式的数据预加载到缓存等真正切换时延迟可以降低一个数量级。我做过一个简单的实现效果很理想从300毫秒左右降到了50毫秒以下。当然这个预加载必须严格控制数据可见性不能因为预加载就把数据暴露出去。7. 一些个人体会和总结性建议做context-mode这类机制最难的不是写代码而是跟团队达成一致上下文不是“顺手存一下”的东西它是一个有边界、有生命周期、有权限约束的正式资源。我第一次把这套机制引入项目时被问得最多的一个问题就是“这有什么必要一个全局对象而已”。后来是线上出过一次串数据的事故才让所有人达成共识。那次事故本身不大但排查过程极其痛苦因为问题不是必现的而是依赖若干次异步调用的先后顺序。从那之后团队里再没人嫌模式切换“多了一道工序”。从务实角度说我给几条建议不要追求一次性设计出“完美模式树”从两三个模式开始就够。先把“切换入口”统一再慢慢收编那些散落在各处的数据读写。日志和监控一定要早做不然后面出问题只能抓瞎。如果团队已经习惯了直接操作全局状态改造的时候建议先做一段时间的“读写代理模式”让他们通过manager的API读写而不是直接删掉原来的全局变量。context-mode并不是银弹它不能帮你解决业务逻辑本身的复杂度但它能把“上下文管理”这块最难追溯、最难测试的复杂度收敛到一个可配置、可审计、可回滚的机制里。只要模式定义和切换策略是清晰的系统的状态就是可控的状态可控了排错、优化、扩展就有了基础。希望这篇分享能帮你少走一些弯路。如果你也在做类似的问题欢迎按这套思路先搭个最小骨架跑起来。