我最早意识到需要认真对待当前到底处于哪种上下文是在一个很普通的下午。当时我为一个内部项目写了一个处理工单的对话助手功能并不复杂用户描述问题它负责提取关键词、给出解决方案、记录工单状态。前两轮对话效果很好到第三轮用户问刚才那个方案和第一步冲突吗助手一本正经地回答没有冲突可根据它自己的记录两个步骤完全是互斥的。我花了一个晚上在代码里加临时变量、加 if 分支、把标志位传来传去结果第二天又冒出一个新的矛盾。问题不在模型也不在简单的代码逻辑而在整个系统缺少一个真正意义上的 context-mode——一套统一的、能随时回答当前这段交互处于什么模式、该按哪套规则执行的机制。这篇文章把我后来在这类问题上积累的实践经验整理出来包含三层上下文模型的搭建思路、显式传参与隐式推导的取舍、以及我在实际项目里踩过且修复过的三个典型坑适合正在做对话型应用、状态机系统或配置驱动工具的读者参考。1. context-mode要解决的真实问题会话分裂与行为漂移1.1 第一次踩坑助手在同一段对话里自我矛盾项目早期我把每个用户请求都当作独立任务处理。每次进来就 reset 一次看起来干净实际上代价很大。用户说把预算从五千改到八千助手记住了但用户接着问那上一版的方案还保留吗助手却完全不记得上一版是在讨论哪个方案。不是模型不好是我根本没有给它一个承载记忆的结构。我当时的反应跟大多数工程师一样加状态变量。定义了一个字典存预算、方案版本、审核状态传给每一个处理函数。一开始是有效的但很快函数越来越多共用的临时变量也越来越多。有的函数期望一个字符串形式的 mode 字段有的函数自己推断 mode 并直接覆盖掉还有好几个地方擅自修改全局状态。当我在代码里搜索mode到底在哪被赋值时搜索结果超过几十处。系统变成了一个靠注释强行解释的状态大杂烩任何人改一处都要担心连锁反应。1.2 行为漂移的本质缺失的上下文才是根源事后复盘我发现一个之前始终没想清楚的点状态变量堆得越多系统反而越不稳定行为漂移越严重。漂移的意思是用户明明在跟同一个系统连续对话系统却呈现出多个不同系统轮流接管的感觉。第一次回答是面向上级汇报的正式口吻第二次变成面向开发人员的调试口吻第三次又完全不记得前面在讨论什么背景。根因是上下文被拆散了。一部分塞在函数参数里一部分趴在全局变量里一部分干脆被格式化后的日志覆盖了。没有一个地方能回答当前这条消息对应的完整上下文究竟是什么。我需要的是把上下文当成一个一等公民显式地管理它并为它提供统一的入口——这就成了我做 context-mode 的起点。顺带说一句这不是某种特定框架或开源库的专属概念而是一种系统设计的思路任何语言、任何架构都能落地。1.3 澄清一个误区context-mode 不是缓存也不是配置中心我接触过的很多项目里开发者会把 context-mode 跟缓存历史消息混为一谈。缓存只负责把过去的东西存下来context-mode 要回答的是过去的东西对当前的行为有什么约束力。它也不完全是配置中心配置中心管理的是不同环境下的参数而 context-mode 管理的是同一套代码在不同交互阶段下的行为选择。说得更直白一点缓存解决的是我记得什么配置中心解决的是我在哪里运行context-mode 解决的是我此刻该怎么做才对。三者可以共存但职责必须分开。有几次线上事故就是因为在缓存里塞了模式标记结果缓存一过期整个系统的行为立刻跳回默认值用户当场看到两种完全不同的回复风格。2. 三层上下文模型我最终采用的实现骨架2.1 身份层定义我是谁、在替谁办事context-mode 的第一个层次是身份层。这里的身份不是指登录账号而是指系统当前服务的对象与立场。比如对话助手在面向普通用户时回答要讲步骤、讲操作面向审核人员时回答要讲依据、讲证据链面向开发者时回答要讲代码位置和排查方法。如果同一套逻辑不加区分地复用得到的回答必然四不像。我在实现里用了一个不可变的身份对象包含 role当前扮演角色、audience服务对象、scope权限范围。它只在会话开始或用户主动切换任务时更新不会随着每一轮对话的结束被清掉。这样保证了整个会话的立场稳定后续所有行为都从它派生。我见过不少团队把身份信息跟普通状态塞在一起后果是某轮对话里一个状态字段被误更新整个回答口径全变了。当初把身份单独拎出来就是为了避免这种蝴蝶效应。2.2 状态层区分可变事实与不可变事实状态层是我踩坑最多的地方。早期把所有字段混在一个大字典里经常出现这样的问题用户修改预算之后旧的预算字段还在一些函数读旧值另一些读新值系统内部自相矛盾。后来我改成两个容器immutable_facts不可变事实比如工单创建时间、提交人、项目编号一旦写入不再修改。mutable_state可变状态比如预算、版本、审核状态每次更新必须携带操作记录。这样设计之后函数的输入输出边界就清晰了函数可以读二者但写操作只允许针对 mutable_state并且必须通过统一的 update 接口完成。任何绕过接口直接改状态的代码都在 code review 阶段就被拦下来。这个约束看起来基础但实践中的收益非常大错误定位时间能缩短一半以上。因为你不需要再猜测这个字段到底是谁在什么时候改的只要查更新记录就行。2.3 规则层把切换条件显式写出来而不是散落在 if 里第三层是规则层也是 context-mode 切换行为的核心。我写了一个小型规则引擎每条规则由三个部分组成condition条件、enter进入时执行的初始化动作、exit离开时的清理动作。规则不再散落在业务代码里而是集中声明在一个配置文件里或者至少集中在一个模块中。class ContextSwitchRule: def __init__(self, name, condition, enter_action, exit_actionNone): self.name name self.condition condition self.enter_action enter_action self.exit_action exit_action典型规则举几个当用户输入包含重新开始时清空 mutable_state 并切到默认模式当用户输入包含详细日志时进入 debug 模式回复内容附带调试信息当系统连续三轮未检测到新的指令型关键词时自动降级到安静模式不再主动追问。规则层真正把何时切换、如何切换从代码逻辑里抽离出来后续加模式只需要加规则不需要改核心流程。有一次我在上线前临时加了一条用户提到合规审查时强制进入 conservative 模式的规则只改了一个配置文件半小时就完成了灰度验证。这在过去是不可想象的按以前的代码结构至少要在三个业务函数里分别打补丁。2.4 三层之间的协作方式用一个实例拆解完整流程为了让大家更直观地理解三层模型怎么协同我举一个实际场景。假定系统同时处理需求澄清与方案评审两类任务同一用户先做需求澄清再中途插入一个方案评审。身份层保持为用户身份、服务角色为产品顾问不会因为任务变化而改变。状态层先记录需求澄清产生的字段需求描述、预算、期望时间。切换任务时这些字段由 exit 动作标记为归档而不是直接删除。规则层检测到方案评审关键词后执行方案评审模式的 enter 动作创建一个新的上下文子空间加载该项目的历史方案列表作为参考。三层各司其职互不干扰。身份层管对谁负责状态层管还记得什么规则层管什么时候换挡。任何一层出问题另外两层能立刻提供交叉验证的信息。这个拆分方式我后来在好几个项目里复用每次收益都很稳定。3. 显式传参与隐式推导两条路线怎么选3.1 显式传入稳定、可控、适合底层复用显式传入的 context-mode就是把上下文对象当作函数参数一路传递。调用方负责创建和更新被调用方只负责读取。优点是行为稳定可测试性高函数的输入输出完全确定缺点是调用方压力大每次调用都要准备好一个完整的上下文否则底层函数可能拿到残缺数据。我实践中的做法是底层函数内部尽量不修改上下文只读取并返回结果。需要修改上下文时由上层业务逻辑统一调度。这个约定保证了底层代码是被动的、可复用的真正的自主性集中在少量模式切换点上。对于多人协作的项目这个约定能极大减少队友之间的隐式耦合。我见过一个团队把所有上下文更新逻辑都塞在底层函数里结果上层一旦多线程并发调用状态就被互相覆盖修了一周才稳定下来。3.2 隐式推导省事、灵活但要承担误判风险隐式推导则是不传参由代码根据当前输入和状态自己推断处于什么上下文。典型做法是用关键词匹配、统计特征或一个简单的分类模型判断当前话题类型然后按推断出的模式去执行。好消息是用户侧体验往往更自然不需要显式命令就能得到符合语境的回答坏消息是误判一旦发生整个会话会滑向一个错误方向。我在一个项目里试过用关键词判断用户是否在提问技术问题结果用户说可不可以约个时间被关键词误命中成时间转换模式回答变成了一长串时间格式说明用户当然不满意。那次之后我给隐式推导加了一道保险任何推导结果都要附带置信度低于某个阈值的推断不自动生效而是先向用户确认或者保持上一次的稳定模式。3.3 显式与隐式的对比什么场景选哪边对比维度显式传参隐式推导稳定性高输入输出可预期中依赖判断条件质量用户体验需要用户配合指令自然无需刻意配合可调试性好链路清晰较差需要记录推导依据实现成本低主要是约定约束高需要维护特征和规则典型场景审批流、工具链、内部系统对话助手、复杂文档问答这组对比不是让你二选一。我在大多数项目里都是混合使用底层逻辑显式接收上下文保证稳定入口层做一定程度的隐式推导照顾交互体验。关键是要把推导的结果明确落成一个 mode 字段并写入上下文让后面所有逻辑都只认这个字段避免每层私自再猜一次。3.4 一个最小可运行的 context-mode 示例给一个我会在内部工具里使用的最小实现方便读者直接上手理解。class ModeEngine: def __init__(self): self.current_mode default self.mode_config { default: {reply_style: full, max_tokens: 400}, concise: {reply_style: brief, max_tokens: 100}, debug: {reply_style: verbose, with_trace: True}, } def decide_mode(self, message: str) - str: # 隐式推导部分集中收敛方便事后查看 if 简单说 in message or 别啰嗦 in message: return concise if 详细点 in message or debug in message.lower(): return debug return self.current_mode def handle(self, message: str): self.current_mode self.decide_mode(message) conf self.mode_config[self.current_mode] return self._reply(message, conf) def _reply(self, message: str, conf: dict): # 实际业务逻辑省略只展示结构 return {mode: self.current_mode, config: conf, answer: f处理: {message}}这个例子里既有隐式推导根据输入自动切模式又有显式读取后续回复统一使用当前模式配置。真实项目里我会把决定逻辑单独抽到 decide_mode 函数中并记录推导依据方便事后退查。你可能会觉得这个例子过于简单但很多线上系统的 context-mode 核心逻辑本质上就是这样一个先定模式再按模式取配置的结构。复杂的是三层模型里状态和规则的配合而不是这个调度本身。4. 我踩过的三个坑遗忘、污染、回退4.1 上下文遗忘窗口截断导致的状态丢失对话类系统通常有长度窗口限制。早期我把所有历史消息都塞进上下文结果遇到超长会话时直接截掉前半段。用户问最早提到的那台服务器现在状态如何系统回答没有找到服务器信息——因为那段信息恰好被截掉了。这种问题特别隐蔽因为它不会报错只会给出一个逻辑上错误但看起来很正常的回答。我的修复方案是双层记忆。第一层是持久化摘要每若干轮对话后自动生成结构化摘要保留关键实体、关键决策和未解决问题第二层是当前窗口只放最近几轮原文和与当前模式强相关的字段。这样既不会丢重要上下文也不会因全文过长而触发截断。关键点在于摘要生成不能只在会话结束时做要周期性进行否则长会话中段照样丢失。我把摘要的时间粒度设成每五轮一次并且每次摘要都带上当时的 mode 标签这样回溯时能清楚知道某个结论是在什么模式下做出的。4.2 上下文污染旧模式残留导致的行为错乱第二个坑是上下文污染。用户上一秒在核对财务数据finance 模式突然切到另一个项目系统却还带着上一段的字段。比如把上个项目的预算当成本项目的预算算了一遍数字完全对不上。问题出在哪里模式切换只更新了 current_mode 标签没有清理旧状态。我后来规定任何模式切换必须调用 exit 动作将旧模式专属的状态字段标记为 invalid 或直接清空。def exit_finance(ctx): ctx.mutable_state.pop(finance_sheet, None) ctx.mutable_state.pop(report_period, None)不做清理就切换等于让新模式的代码背负着一段错误的记忆。恢复的手段不是更难写的代码而是更严格的切换纪律。每次切换都问一句新模式下哪些字段还在哪些字段应该消失这个问题如果答不上来说明模式边界还没定义清楚应该先把模式之间的差异矩阵列出来而不是急着写代码。4.3 回退策略宁可降级也不要带着错误上下文硬跑第三个坑与回退有关。有一回我在调试一个写邮件助手的模式切换时发现系统从冷静认真模式切到活泼轻松模式后错误地把所有内部调试信息也塞进了对外邮件里。我为了尽快修复在邮件生成函数里加了一个补充判断临时挡住调试信息。结果是邮件暂时正常了但整个系统的模式状态已经不一致后续当你试图手动修改邮件内容时它又按旧逻辑把调试信息带了出来。正确做法是设计一套降级链路当模式冲突无法自动解决时系统明确提醒用户当前状态不一致已切换为默认模式并保留一份完整的错误状态快照供排查。宁可功能降级也不能让系统在一个损坏的上下文上强行继续。确保回退路径不被频繁触发的一个技巧是把模式切换前后的状态差异打印出来每次切换都肉眼核对一遍直到新模式的字段集合稳定为止。我在线上加了这类差异日志后第一周就抓到了三个此前完全没意识到的状态残留问题。5. 什么场景真正需要 context-mode什么场景别硬上5.1 适合引入的典型场景我整理了一张容易受益的场景清单场景为什么需要主要收益多角色对话助手同一个系统要服务不同对象角色口径统一状态机驱动的业务流程审批、订单、工单流程有多阶段状态迁移可追溯配置驱动的工具链同一份代码在不同环境下行为不同避免环境耦合复杂文档生成同一模板要生成不同风格的版本风格切换可配置这些场景的共同点是行为不是固定的而是随上下文变化的且变化频率足以影响整体体验或稳定性。另一个判断信号是团队内部讨论问题时开始频繁出现这个模块在不同情况下要表现得不一样的说法且每种情况都有多个字段联动。这时就需要有一个显式的 context-mode 来承载这些分支。5.2 应该绕开的场景并非所有状态都需要上下文也有很多场景完全不需要上 context-mode。比如纯计算任务、无状态接口、一次性查询服务它们每次调用都独立引入上下文反而增加复杂度。我见过一个很典型的反面案例某个服务只是返回汇率换算结果开发者在函数里加了 context 参数然后每次调用都要新建一个上下文对象。这个上下文对象自始至终只有一个字段却承担了未来可能扩展的幻想责任代码变得又长又绕。我的建议很直接如果当前系统里不存在同一会话内行为需要连续一致的需求就别引入上下文模式。用最简单的方式处理等真的出现状态交叉时再重构。重构带来的收益那时会清晰可见团队成员也更容易理解为什么要这么做。提前过度设计反而会让方案变成新人的负担。5.3 我的取舍原则引入之前先回答三个问题最后分享一个我自己的决策流程。打算引入 context-mode 之前先回答三个问题是否存在同一份输入在不同时刻需要不同处理的场景如果没有说明不是上下文问题而是普通参数问题。模式切换是否能被用户或系统明确感知如果切换对用户完全无感、也不需要被记录那通常不值得专门做模式管理。多个状态字段之间是否相互制约比如预算变了要不要影响方案版本审核状态变了要不要影响输出格式。只要有这类联动就需要一个统一上下文来承载。三个问题至少两个回答是我才会动手设计和实现 context-mode。否则我会用普通参数表和少量条件分支解决问题省下来的复杂度留给更值得的地方。这套标准帮我挡掉过至少三次为了模式而模式的立项冲动每次都省下了不少维护成本。再分享一个我在实际项目里经常用的小技巧模式切换时永远把切换前后的关键字段差异打印到日志里线上环境也一样。不要只打印mode changed to xxx而是连旧值、新值、触发原因都记录下来。有一次我在排查一个用户反馈的奇怪行为时靠着这串切换日志只花了十几分钟就定位到问题出在某个规则条件写得太宽泛把我要查一下也误判成了切换指令。如果没有这层记录我估计又要花一个通宵。如果你正准备在自己的项目里落一个 context-mode 方案建议先从一个最小范围启动只管理当前模式标签和两个关键状态字段跑通之后再把身份层、规则层逐步加进去。这样投入最小又能尽早暴露真实的使用细节比一开始就想做成一个通用的组件要稳妥得多。 
长河君 · 2026/10/20 3:56:59 · 阅读 1.2k 上下文模式（Context Mode）设计：三层模型与状态切换实战
我最早意识到需要认真对待当前到底处于哪种上下文是在一个很普通的下午。当时我为一个内部项目写了一个处理工单的对话助手功能并不复杂用户描述问题它负责提取关键词、给出解决方案、记录工单状态。前两轮对话效果很好到第三轮用户问刚才那个方案和第一步冲突吗助手一本正经地回答没有冲突可根据它自己的记录两个步骤完全是互斥的。我花了一个晚上在代码里加临时变量、加 if 分支、把标志位传来传去结果第二天又冒出一个新的矛盾。问题不在模型也不在简单的代码逻辑而在整个系统缺少一个真正意义上的 context-mode——一套统一的、能随时回答当前这段交互处于什么模式、该按哪套规则执行的机制。这篇文章把我后来在这类问题上积累的实践经验整理出来包含三层上下文模型的搭建思路、显式传参与隐式推导的取舍、以及我在实际项目里踩过且修复过的三个典型坑适合正在做对话型应用、状态机系统或配置驱动工具的读者参考。1. context-mode要解决的真实问题会话分裂与行为漂移1.1 第一次踩坑助手在同一段对话里自我矛盾项目早期我把每个用户请求都当作独立任务处理。每次进来就 reset 一次看起来干净实际上代价很大。用户说把预算从五千改到八千助手记住了但用户接着问那上一版的方案还保留吗助手却完全不记得上一版是在讨论哪个方案。不是模型不好是我根本没有给它一个承载记忆的结构。我当时的反应跟大多数工程师一样加状态变量。定义了一个字典存预算、方案版本、审核状态传给每一个处理函数。一开始是有效的但很快函数越来越多共用的临时变量也越来越多。有的函数期望一个字符串形式的 mode 字段有的函数自己推断 mode 并直接覆盖掉还有好几个地方擅自修改全局状态。当我在代码里搜索mode到底在哪被赋值时搜索结果超过几十处。系统变成了一个靠注释强行解释的状态大杂烩任何人改一处都要担心连锁反应。1.2 行为漂移的本质缺失的上下文才是根源事后复盘我发现一个之前始终没想清楚的点状态变量堆得越多系统反而越不稳定行为漂移越严重。漂移的意思是用户明明在跟同一个系统连续对话系统却呈现出多个不同系统轮流接管的感觉。第一次回答是面向上级汇报的正式口吻第二次变成面向开发人员的调试口吻第三次又完全不记得前面在讨论什么背景。根因是上下文被拆散了。一部分塞在函数参数里一部分趴在全局变量里一部分干脆被格式化后的日志覆盖了。没有一个地方能回答当前这条消息对应的完整上下文究竟是什么。我需要的是把上下文当成一个一等公民显式地管理它并为它提供统一的入口——这就成了我做 context-mode 的起点。顺带说一句这不是某种特定框架或开源库的专属概念而是一种系统设计的思路任何语言、任何架构都能落地。1.3 澄清一个误区context-mode 不是缓存也不是配置中心我接触过的很多项目里开发者会把 context-mode 跟缓存历史消息混为一谈。缓存只负责把过去的东西存下来context-mode 要回答的是过去的东西对当前的行为有什么约束力。它也不完全是配置中心配置中心管理的是不同环境下的参数而 context-mode 管理的是同一套代码在不同交互阶段下的行为选择。说得更直白一点缓存解决的是我记得什么配置中心解决的是我在哪里运行context-mode 解决的是我此刻该怎么做才对。三者可以共存但职责必须分开。有几次线上事故就是因为在缓存里塞了模式标记结果缓存一过期整个系统的行为立刻跳回默认值用户当场看到两种完全不同的回复风格。2. 三层上下文模型我最终采用的实现骨架2.1 身份层定义我是谁、在替谁办事context-mode 的第一个层次是身份层。这里的身份不是指登录账号而是指系统当前服务的对象与立场。比如对话助手在面向普通用户时回答要讲步骤、讲操作面向审核人员时回答要讲依据、讲证据链面向开发者时回答要讲代码位置和排查方法。如果同一套逻辑不加区分地复用得到的回答必然四不像。我在实现里用了一个不可变的身份对象包含 role当前扮演角色、audience服务对象、scope权限范围。它只在会话开始或用户主动切换任务时更新不会随着每一轮对话的结束被清掉。这样保证了整个会话的立场稳定后续所有行为都从它派生。我见过不少团队把身份信息跟普通状态塞在一起后果是某轮对话里一个状态字段被误更新整个回答口径全变了。当初把身份单独拎出来就是为了避免这种蝴蝶效应。2.2 状态层区分可变事实与不可变事实状态层是我踩坑最多的地方。早期把所有字段混在一个大字典里经常出现这样的问题用户修改预算之后旧的预算字段还在一些函数读旧值另一些读新值系统内部自相矛盾。后来我改成两个容器immutable_facts不可变事实比如工单创建时间、提交人、项目编号一旦写入不再修改。mutable_state可变状态比如预算、版本、审核状态每次更新必须携带操作记录。这样设计之后函数的输入输出边界就清晰了函数可以读二者但写操作只允许针对 mutable_state并且必须通过统一的 update 接口完成。任何绕过接口直接改状态的代码都在 code review 阶段就被拦下来。这个约束看起来基础但实践中的收益非常大错误定位时间能缩短一半以上。因为你不需要再猜测这个字段到底是谁在什么时候改的只要查更新记录就行。2.3 规则层把切换条件显式写出来而不是散落在 if 里第三层是规则层也是 context-mode 切换行为的核心。我写了一个小型规则引擎每条规则由三个部分组成condition条件、enter进入时执行的初始化动作、exit离开时的清理动作。规则不再散落在业务代码里而是集中声明在一个配置文件里或者至少集中在一个模块中。class ContextSwitchRule: def __init__(self, name, condition, enter_action, exit_actionNone): self.name name self.condition condition self.enter_action enter_action self.exit_action exit_action典型规则举几个当用户输入包含重新开始时清空 mutable_state 并切到默认模式当用户输入包含详细日志时进入 debug 模式回复内容附带调试信息当系统连续三轮未检测到新的指令型关键词时自动降级到安静模式不再主动追问。规则层真正把何时切换、如何切换从代码逻辑里抽离出来后续加模式只需要加规则不需要改核心流程。有一次我在上线前临时加了一条用户提到合规审查时强制进入 conservative 模式的规则只改了一个配置文件半小时就完成了灰度验证。这在过去是不可想象的按以前的代码结构至少要在三个业务函数里分别打补丁。2.4 三层之间的协作方式用一个实例拆解完整流程为了让大家更直观地理解三层模型怎么协同我举一个实际场景。假定系统同时处理需求澄清与方案评审两类任务同一用户先做需求澄清再中途插入一个方案评审。身份层保持为用户身份、服务角色为产品顾问不会因为任务变化而改变。状态层先记录需求澄清产生的字段需求描述、预算、期望时间。切换任务时这些字段由 exit 动作标记为归档而不是直接删除。规则层检测到方案评审关键词后执行方案评审模式的 enter 动作创建一个新的上下文子空间加载该项目的历史方案列表作为参考。三层各司其职互不干扰。身份层管对谁负责状态层管还记得什么规则层管什么时候换挡。任何一层出问题另外两层能立刻提供交叉验证的信息。这个拆分方式我后来在好几个项目里复用每次收益都很稳定。3. 显式传参与隐式推导两条路线怎么选3.1 显式传入稳定、可控、适合底层复用显式传入的 context-mode就是把上下文对象当作函数参数一路传递。调用方负责创建和更新被调用方只负责读取。优点是行为稳定可测试性高函数的输入输出完全确定缺点是调用方压力大每次调用都要准备好一个完整的上下文否则底层函数可能拿到残缺数据。我实践中的做法是底层函数内部尽量不修改上下文只读取并返回结果。需要修改上下文时由上层业务逻辑统一调度。这个约定保证了底层代码是被动的、可复用的真正的自主性集中在少量模式切换点上。对于多人协作的项目这个约定能极大减少队友之间的隐式耦合。我见过一个团队把所有上下文更新逻辑都塞在底层函数里结果上层一旦多线程并发调用状态就被互相覆盖修了一周才稳定下来。3.2 隐式推导省事、灵活但要承担误判风险隐式推导则是不传参由代码根据当前输入和状态自己推断处于什么上下文。典型做法是用关键词匹配、统计特征或一个简单的分类模型判断当前话题类型然后按推断出的模式去执行。好消息是用户侧体验往往更自然不需要显式命令就能得到符合语境的回答坏消息是误判一旦发生整个会话会滑向一个错误方向。我在一个项目里试过用关键词判断用户是否在提问技术问题结果用户说可不可以约个时间被关键词误命中成时间转换模式回答变成了一长串时间格式说明用户当然不满意。那次之后我给隐式推导加了一道保险任何推导结果都要附带置信度低于某个阈值的推断不自动生效而是先向用户确认或者保持上一次的稳定模式。3.3 显式与隐式的对比什么场景选哪边对比维度显式传参隐式推导稳定性高输入输出可预期中依赖判断条件质量用户体验需要用户配合指令自然无需刻意配合可调试性好链路清晰较差需要记录推导依据实现成本低主要是约定约束高需要维护特征和规则典型场景审批流、工具链、内部系统对话助手、复杂文档问答这组对比不是让你二选一。我在大多数项目里都是混合使用底层逻辑显式接收上下文保证稳定入口层做一定程度的隐式推导照顾交互体验。关键是要把推导的结果明确落成一个 mode 字段并写入上下文让后面所有逻辑都只认这个字段避免每层私自再猜一次。3.4 一个最小可运行的 context-mode 示例给一个我会在内部工具里使用的最小实现方便读者直接上手理解。class ModeEngine: def __init__(self): self.current_mode default self.mode_config { default: {reply_style: full, max_tokens: 400}, concise: {reply_style: brief, max_tokens: 100}, debug: {reply_style: verbose, with_trace: True}, } def decide_mode(self, message: str) - str: # 隐式推导部分集中收敛方便事后查看 if 简单说 in message or 别啰嗦 in message: return concise if 详细点 in message or debug in message.lower(): return debug return self.current_mode def handle(self, message: str): self.current_mode self.decide_mode(message) conf self.mode_config[self.current_mode] return self._reply(message, conf) def _reply(self, message: str, conf: dict): # 实际业务逻辑省略只展示结构 return {mode: self.current_mode, config: conf, answer: f处理: {message}}这个例子里既有隐式推导根据输入自动切模式又有显式读取后续回复统一使用当前模式配置。真实项目里我会把决定逻辑单独抽到 decide_mode 函数中并记录推导依据方便事后退查。你可能会觉得这个例子过于简单但很多线上系统的 context-mode 核心逻辑本质上就是这样一个先定模式再按模式取配置的结构。复杂的是三层模型里状态和规则的配合而不是这个调度本身。4. 我踩过的三个坑遗忘、污染、回退4.1 上下文遗忘窗口截断导致的状态丢失对话类系统通常有长度窗口限制。早期我把所有历史消息都塞进上下文结果遇到超长会话时直接截掉前半段。用户问最早提到的那台服务器现在状态如何系统回答没有找到服务器信息——因为那段信息恰好被截掉了。这种问题特别隐蔽因为它不会报错只会给出一个逻辑上错误但看起来很正常的回答。我的修复方案是双层记忆。第一层是持久化摘要每若干轮对话后自动生成结构化摘要保留关键实体、关键决策和未解决问题第二层是当前窗口只放最近几轮原文和与当前模式强相关的字段。这样既不会丢重要上下文也不会因全文过长而触发截断。关键点在于摘要生成不能只在会话结束时做要周期性进行否则长会话中段照样丢失。我把摘要的时间粒度设成每五轮一次并且每次摘要都带上当时的 mode 标签这样回溯时能清楚知道某个结论是在什么模式下做出的。4.2 上下文污染旧模式残留导致的行为错乱第二个坑是上下文污染。用户上一秒在核对财务数据finance 模式突然切到另一个项目系统却还带着上一段的字段。比如把上个项目的预算当成本项目的预算算了一遍数字完全对不上。问题出在哪里模式切换只更新了 current_mode 标签没有清理旧状态。我后来规定任何模式切换必须调用 exit 动作将旧模式专属的状态字段标记为 invalid 或直接清空。def exit_finance(ctx): ctx.mutable_state.pop(finance_sheet, None) ctx.mutable_state.pop(report_period, None)不做清理就切换等于让新模式的代码背负着一段错误的记忆。恢复的手段不是更难写的代码而是更严格的切换纪律。每次切换都问一句新模式下哪些字段还在哪些字段应该消失这个问题如果答不上来说明模式边界还没定义清楚应该先把模式之间的差异矩阵列出来而不是急着写代码。4.3 回退策略宁可降级也不要带着错误上下文硬跑第三个坑与回退有关。有一回我在调试一个写邮件助手的模式切换时发现系统从冷静认真模式切到活泼轻松模式后错误地把所有内部调试信息也塞进了对外邮件里。我为了尽快修复在邮件生成函数里加了一个补充判断临时挡住调试信息。结果是邮件暂时正常了但整个系统的模式状态已经不一致后续当你试图手动修改邮件内容时它又按旧逻辑把调试信息带了出来。正确做法是设计一套降级链路当模式冲突无法自动解决时系统明确提醒用户当前状态不一致已切换为默认模式并保留一份完整的错误状态快照供排查。宁可功能降级也不能让系统在一个损坏的上下文上强行继续。确保回退路径不被频繁触发的一个技巧是把模式切换前后的状态差异打印出来每次切换都肉眼核对一遍直到新模式的字段集合稳定为止。我在线上加了这类差异日志后第一周就抓到了三个此前完全没意识到的状态残留问题。5. 什么场景真正需要 context-mode什么场景别硬上5.1 适合引入的典型场景我整理了一张容易受益的场景清单场景为什么需要主要收益多角色对话助手同一个系统要服务不同对象角色口径统一状态机驱动的业务流程审批、订单、工单流程有多阶段状态迁移可追溯配置驱动的工具链同一份代码在不同环境下行为不同避免环境耦合复杂文档生成同一模板要生成不同风格的版本风格切换可配置这些场景的共同点是行为不是固定的而是随上下文变化的且变化频率足以影响整体体验或稳定性。另一个判断信号是团队内部讨论问题时开始频繁出现这个模块在不同情况下要表现得不一样的说法且每种情况都有多个字段联动。这时就需要有一个显式的 context-mode 来承载这些分支。5.2 应该绕开的场景并非所有状态都需要上下文也有很多场景完全不需要上 context-mode。比如纯计算任务、无状态接口、一次性查询服务它们每次调用都独立引入上下文反而增加复杂度。我见过一个很典型的反面案例某个服务只是返回汇率换算结果开发者在函数里加了 context 参数然后每次调用都要新建一个上下文对象。这个上下文对象自始至终只有一个字段却承担了未来可能扩展的幻想责任代码变得又长又绕。我的建议很直接如果当前系统里不存在同一会话内行为需要连续一致的需求就别引入上下文模式。用最简单的方式处理等真的出现状态交叉时再重构。重构带来的收益那时会清晰可见团队成员也更容易理解为什么要这么做。提前过度设计反而会让方案变成新人的负担。5.3 我的取舍原则引入之前先回答三个问题最后分享一个我自己的决策流程。打算引入 context-mode 之前先回答三个问题是否存在同一份输入在不同时刻需要不同处理的场景如果没有说明不是上下文问题而是普通参数问题。模式切换是否能被用户或系统明确感知如果切换对用户完全无感、也不需要被记录那通常不值得专门做模式管理。多个状态字段之间是否相互制约比如预算变了要不要影响方案版本审核状态变了要不要影响输出格式。只要有这类联动就需要一个统一上下文来承载。三个问题至少两个回答是我才会动手设计和实现 context-mode。否则我会用普通参数表和少量条件分支解决问题省下来的复杂度留给更值得的地方。这套标准帮我挡掉过至少三次为了模式而模式的立项冲动每次都省下了不少维护成本。再分享一个我在实际项目里经常用的小技巧模式切换时永远把切换前后的关键字段差异打印到日志里线上环境也一样。不要只打印mode changed to xxx而是连旧值、新值、触发原因都记录下来。有一次我在排查一个用户反馈的奇怪行为时靠着这串切换日志只花了十几分钟就定位到问题出在某个规则条件写得太宽泛把我要查一下也误判成了切换指令。如果没有这层记录我估计又要花一个通宵。如果你正准备在自己的项目里落一个 context-mode 方案建议先从一个最小范围启动只管理当前模式标签和两个关键状态字段跑通之后再把身份层、规则层逐步加进去。这样投入最小又能尽早暴露真实的使用细节比一开始就想做成一个通用的组件要稳妥得多。