做技术的人大概都遇到过这种场景：同一个系统里，给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父模式，用于继承公共信息"base"onEnter进入模式时的钩子加载基础信息onExit退出模式时的钩子清理临时变量这样建模的直接好处是：判断“当前能不能做某件事”从一串散落的if-else变成了一次配置查表。你不需要在业务代码里反复写“如果当前模式是xx，才允许yy”，只需要在注册阶段把权限和数据边界描述清楚。再说说继承。我建议所有模式都继承一个base模式，base模式里放一些通用的东西，比如用户ID、请求ID、全局设置。这样公共信息只需要处理一次，子模式只需要关注自己特有的数据。继承不是万能的，但能省掉大量重复的初始化逻辑。2.2 切换策略：显式、自动与混合模式切换是整个机制里最容易出错的地方。我的经验是，先明确切换是由谁触发的，才好决定怎么做状态清理。显式切换是最常见的，比如用户在界面里点了“切换到订单处理”，前端调接口，后端把当前上下文从product_consult切到order_handle。这种切换逻辑清晰，适合产品流程固定的场景。自动切换适合那种“用户没说切换，但系统能判断该切了”的情况。比如用户问“我要退掉刚才那个订单”，系统语义识别出意图是“退款”，此时自动切到退款模式。自动切换的难点在于“判断的时机”，切早了用户还没确认就容易误判，切晚了又可能让AI读到不该读的数据。混合策略是我自己用得最多的：先用规则或模型判断一个“候选模式”，但不立刻生效，而是进入一个“预备态”，等用户或业务逻辑确认后再完成切换。这个预备态在实现上很简单，就是在模式管理器里加一个pendingModeId字段。这里我放一张三种策略的对比表：策略优点缺点适用场景显式切换逻辑简单、可控性强需要业务方配合传参流程固定的业务自动切换体验好、无感知判断错代价高意图明确的高频场景混合切换兼顾准确与体验实现成本略高对准确性要求高的场景2.3 切换时如何决定状态保留还是销毁这是很多项目做不好的点。一种极端是切换就清空一切，导致来回切换时用户体验断裂；另一种极端是永远不清，导致内存越积越多、上下文串味。我的原则是：保留可恢复的，销毁不可恢复的。具体来说，把上下文数据分成三类：请求级数据：比如当前正在处理的一个请求参数，切换后必须销毁。会话级数据：比如用户在本会话内的选择记录，切换后建议保留。全局级数据：比如服务配置、公共字典，任何模式共享，永远保留。实现上可以给每个数据项打一个persist标记。切换模式时，扫描当前模式的所有数据项，persist=false的直接丢弃，persist=true的移入公共层。3. 核心实现：一个简洁的context-mode管理器3.1 代码骨架我用TypeScript写了一个非常精简的版本，核心设计思路是用一个注册表保存所有模式定义，用一个运行时对象记录当前状态。完整代码不算长，但该有的功能都有：注册模式、切换模式、数据读写、监听器、日志。type DataScope = Record<string, any>; interface ModeDefinition { modeId: string; dataScope: DataScope; toolScope: string[]; ttl?: number; parentMode?: string; onEnter?: (ctx: ContextRuntime) => Promise<void> | void; onExit?: (ctx: ContextRuntime) => Promise<void> | void; } interface ContextRuntime { modeId: string; data: DataScope; dump: () => DataScope; } class ContextModeManager { private modes = new Map<string, ModeDefinition>(); private runtime: ContextRuntime = { modeId: "base", data: {} }; private history: string[] = []; private listeners = new Map<string, 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; } } // 应用payload，payload优先级最高 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并不是银弹，它不能帮你解决业务逻辑本身的复杂度，但它能把“上下文管理”这块最难追溯、最难测试的复杂度收敛到一个可配置、可审计、可回滚的机制里。只要模式定义和切换策略是清晰的，系统的状态就是可控的；状态可控了，排错、优化、扩展就有了基础。希望这篇分享能帮你少走一些弯路。如果你也在做类似的问题，欢迎按这套思路先搭个最小骨架跑起来。
做技术的人大概都遇到过这种场景：同一个系统里，给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父模式，用于继承公共信息"base"onEnter进入模式时的钩子加载基础信息onExit退出模式时的钩子清理临时变量这样建模的直接好处是：判断“当前能不能做某件事”从一串散落的if-else变成了一次配置查表。你不需要在业务代码里反复写“如果当前模式是xx，才允许yy”，只需要在注册阶段把权限和数据边界描述清楚。再说说继承。我建议所有模式都继承一个base模式，base模式里放一些通用的东西，比如用户ID、请求ID、全局设置。这样公共信息只需要处理一次，子模式只需要关注自己特有的数据。继承不是万能的，但能省掉大量重复的初始化逻辑。2.2 切换策略：显式、自动与混合模式切换是整个机制里最容易出错的地方。我的经验是，先明确切换是由谁触发的，才好决定怎么做状态清理。显式切换是最常见的，比如用户在界面里点了“切换到订单处理”，前端调接口，后端把当前上下文从product_consult切到order_handle。这种切换逻辑清晰，适合产品流程固定的场景。自动切换适合那种“用户没说切换，但系统能判断该切了”的情况。比如用户问“我要退掉刚才那个订单”，系统语义识别出意图是“退款”，此时自动切到退款模式。自动切换的难点在于“判断的时机”，切早了用户还没确认就容易误判，切晚了又可能让AI读到不该读的数据。混合策略是我自己用得最多的：先用规则或模型判断一个“候选模式”，但不立刻生效，而是进入一个“预备态”，等用户或业务逻辑确认后再完成切换。这个预备态在实现上很简单，就是在模式管理器里加一个pendingModeId字段。这里我放一张三种策略的对比表：策略优点缺点适用场景显式切换逻辑简单、可控性强需要业务方配合传参流程固定的业务自动切换体验好、无感知判断错代价高意图明确的高频场景混合切换兼顾准确与体验实现成本略高对准确性要求高的场景2.3 切换时如何决定状态保留还是销毁这是很多项目做不好的点。一种极端是切换就清空一切，导致来回切换时用户体验断裂；另一种极端是永远不清，导致内存越积越多、上下文串味。我的原则是：保留可恢复的，销毁不可恢复的。具体来说，把上下文数据分成三类：请求级数据：比如当前正在处理的一个请求参数，切换后必须销毁。会话级数据：比如用户在本会话内的选择记录，切换后建议保留。全局级数据：比如服务配置、公共字典，任何模式共享，永远保留。实现上可以给每个数据项打一个persist标记。切换模式时，扫描当前模式的所有数据项，persist=false的直接丢弃，persist=true的移入公共层。3. 核心实现：一个简洁的context-mode管理器3.1 代码骨架我用TypeScript写了一个非常精简的版本，核心设计思路是用一个注册表保存所有模式定义，用一个运行时对象记录当前状态。完整代码不算长，但该有的功能都有：注册模式、切换模式、数据读写、监听器、日志。type DataScope = Record<string, any>; interface ModeDefinition { modeId: string; dataScope: DataScope; toolScope: string[]; ttl?: number; parentMode?: string; onEnter?: (ctx: ContextRuntime) => Promise<void> | void; onExit?: (ctx: ContextRuntime) => Promise<void> | void; } interface ContextRuntime { modeId: string; data: DataScope; dump: () => DataScope; } class ContextModeManager { private modes = new Map<string, ModeDefinition>(); private runtime: ContextRuntime = { modeId: "base", data: {} }; private history: string[] = []; private listeners = new Map<string, 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; } } // 应用payload，payload优先级最高 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并不是银弹，它不能帮你解决业务逻辑本身的复杂度，但它能把“上下文管理”这块最难追溯、最难测试的复杂度收敛到一个可配置、可审计、可回滚的机制里。只要模式定义和切换策略是清晰的，系统的状态就是可控的；状态可控了，排错、优化、扩展就有了基础。希望这篇分享能帮你少走一些弯路。如果你也在做类似的问题，欢迎按这套思路先搭个最小骨架跑起来。