1. 从context-mode说起一个被低估的工程概念第一次看到context-mode这个词很多人会下意识地把它归到某个具体框架的API文档里觉得无非又是一个配置项。但如果你在工程一线待过几年尤其是在做AI应用、状态机、前端路由或者后端中间件这类系统时你会发现上下文模式其实是一个反复出现、却很少被系统讲清楚的设计母题。它描述的是一个系统在不同运行阶段如何切换自己理解和响应外部输入的方式。我最早接触这个概念是在做一个多轮对话系统的时候。当时系统只有一种模式用户说什么它就按固定流程回答。结果遇到用户中途改需求用户想查历史记录用户只是随口一问这几种情况时整个流程就乱了。后来我们引入了context-mode的思路把系统拆成任务执行模式信息检索模式闲聊模式三种上下文每种上下文对应不同的输入解析策略、不同的记忆读取范围、不同的输出格式。改完之后系统的可用性直接上了一个台阶。所以这篇博文我想把context-mode这个东西从概念到落地讲透。它不是一个具体的库也不是某个平台的专属名词而是一种架构层面的思考方式。适合谁看如果你正在做对话系统、工作流引擎、前端状态管理、插件系统或者任何需要根据当前处境改变行为的软件这篇内容应该能给你一些可以直接抄作业的思路。我会尽量用大白话把原理讲清楚再配上我实际项目里用过的参数、代码和踩坑记录。2. context-mode到底解决什么问题2.1 没有上下文模式时系统会变成什么样先说不好的情况这样你更容易理解它的价值。假设你做一个客服机器人没有context-mode的概念代码大概是这样写的收到用户输入走一遍意图识别然后根据意图查知识库返回答案。听起来没问题但实际跑起来会遇到几个典型症状。第一个症状是意图漂移。用户第一句问你们的退货政策是什么系统识别为政策咨询回答完毕。第二句用户说那我昨天买的那双鞋能退吗这句话里既有退货又有昨天买的鞋意图识别可能把它判成订单查询也可能判成政策咨询完全看模型当时的心情。结果就是答非所问。第二个症状是记忆污染。系统把前面所有对话都塞进上下文窗口导致后面回答时被无关信息干扰。用户前面聊过天气后面问退货模型可能莫名其妙地在退货回答里带一句今天天气不错。第三个症状是行为僵化。不管用户是在认真办事还是在随便问问系统都用同一套流程、同一个语气、同一个响应长度。用户想快速查个单号系统给他回了一大段政策说明。这些问题的根源都一样系统没有当前处于什么处境的显式判断。它把所有输入都当成同一种东西处理自然就乱套了。2.2 context-mode的核心定义与三个判断维度我给context-mode下的定义是一套用于识别当前交互处境并据此切换系统行为策略的机制。注意这里的关键词是识别和切换。识别是输入侧的事切换是输出侧的事。具体来说一个完整的context-mode设计需要回答三个问题。第一个问题当前是什么模式这需要一个模式判定器。判定依据可以来自用户输入的关键词、对话轮次、外部信号比如用户点击了哪个按钮、时间、用户身份等等。判定器的输出是一个模式标签比如tasksearchchatconfirm。第二个问题这个模式下系统读什么、不读什么这就是上下文窗口的管理。不同模式对历史信息的依赖程度完全不同。任务执行模式可能需要读取最近三轮的完整对话检索模式可能只需要读取用户当前这句话闲聊模式可能只需要读取用户画像。第三个问题这个模式下系统怎么回应包括响应格式、响应长度、是否调用工具、是否要求确认、语气风格。任务模式要结构化输出检索模式要带引用来源闲聊模式要短而自然。把这三个问题想清楚context-mode的骨架就出来了。我习惯把它画成一个三元组Mode (Detector, ContextPolicy, ResponsePolicy)。后面所有的实操都是围绕这三个组件展开的。2.3 为什么现在特别值得关注这个概念早几年大家做系统交互路径相对固定用户点按钮、填表单系统按流程走就行不太需要动态切换模式。但这几年情况变了。对话式交互、AI辅助操作、多模态输入越来越普遍用户可以在一次会话里做很多件不同的事系统必须能跟上这种变化。另一个原因是模型能力的提升。以前模型理解能力有限你给它复杂的模式切换指令它也执行不好。现在模型能较好地遵循当前处于X模式请按Y规则响应这类指令context-mode的落地成本大幅降低。还有一个现实原因上下文窗口虽然变大了但并没有免费。你把所有历史都塞进去成本高、延迟大、还容易干扰。context-mode本质上是一种上下文预算管理手段让你只在该读的时候读该读的东西。这一点在长会话场景里尤其重要。3. 核心组件拆解与设计取舍3.1 模式判定器规则、模型还是混合模式判定器是整个context-mode的入口它判错了后面全错。我试过三种方案各有适用场景。纯规则方案用关键词、正则、轮次阈值来判定。比如用户输入里出现帮我执行创建就进任务模式出现是什么怎么为什么就进检索模式。优点是快、可控、可解释缺点是覆盖不全用户换个说法就失效。纯模型方案把最近几轮对话丢给一个小模型让它输出模式标签。优点是泛化好缺点是慢、有成本、偶尔会抽风。我遇到过模型把帮我查一下天气判成闲聊模式的情况因为查天气在训练数据里经常出现在闲聊语境。混合方案这是我现在主要用的。先用规则做快速判定命中高置信度规则就直接出结果规则不确定时再调用模型做二次判定。这样既保证了常见情况的响应速度又保留了处理边界情况的能力。具体实现上我会维护一个规则表每条规则有权重。比如规则类型示例权重命中后动作强指令词帮我请执行立即0.9直接判为task疑问词是什么为什么怎么0.6候选search确认词好的可以确认0.8判为confirm轮次阈值连续3轮无任务动作0.5候选chat规则总分超过0.8就直接定模式0.5到0.8之间交给模型复核低于0.5默认走chat模式。这套阈值是我调了好几轮才定下来的你可以根据自己的业务先设一个初值再根据badcase慢慢调。注意模式判定器一定要记录判定依据。我早期没做这件事线上出问题时完全不知道系统为什么进了某个模式排查起来非常痛苦。后来每次判定都带上命中的规则ID和分数日志里一目了然。3.2 上下文策略读多少、读哪段、怎么压缩模式定下来之后接下来要决定给模型喂什么上下文。这里有个常见误区很多人觉得上下文越多越好其实不是。无关信息会稀释有效信息还会增加成本和延迟。我的做法是按模式定义不同的上下文策略。以对话系统为例task模式读取最近5轮完整对话 当前任务相关的槽位状态 用户历史偏好摘要。因为任务执行需要连贯性槽位信息必须完整。search模式只读取用户当前这句话 检索到的文档片段。历史对话基本不读避免干扰检索意图。chat模式读取用户画像 最近2轮对话。保持轻量响应要快。confirm模式读取待确认的操作详情 最近1轮对话。信息要精准不能带无关内容。这里的关键是上下文压缩。原始对话往往很长直接塞进去不现实。我一般用两级压缩第一级是摘要把超过5轮的对话压成一段话第二级是抽取只保留与当前模式相关的实体和意图。摘要用模型做抽取用规则做两者结合效果比较稳。还有一个细节上下文的顺序。我习惯把最重要的信息放在最前面和最后面因为模型对首尾位置的注意力更强。中间放次要信息。这个技巧在长上下文场景里效果明显。3.3 响应策略格式、长度、工具调用的差异化响应策略是context-mode最直观的体现。同一个问题在不同模式下回答方式应该完全不同。task模式下我要求输出结构化结果比如JSON或者带字段的文本方便下游系统解析。长度控制在必要信息内不废话。如果任务需要多步要输出步骤列表。search模式下输出要带来源引用格式是答案 参考片段。长度可以稍长因为用户是在查资料需要一定信息量。chat模式下输出要短、自然、口语化。我一般限制在50字以内避免长篇大论。confirm模式下输出要明确列出待确认的操作和影响要求用户给出明确回复。格式上会用列表把关键信息列出来。工具调用也是响应策略的一部分。task模式可能需要调用外部APIsearch模式需要调用检索chat模式基本不调用工具。这些都要在策略里写清楚不能让模型自己决定。我踩过的一个坑是早期没有区分响应策略所有模式都用同一套prompt结果task模式输出太啰嗦chat模式输出太正式用户体验很割裂。后来把响应策略独立出来每个模式一套prompt模板问题就解决了。4. 完整实操从零搭一个context-mode系统4.1 环境准备与基础结构我用Python做示例因为生态成熟、上手快。核心依赖就两个一个用于调用模型一个用于数据结构管理。实际项目里你可能还需要日志、监控、配置管理但为了讲清楚核心逻辑这里只保留最必要的部分。先定义模式枚举和数据结构from enum import Enum from dataclasses import dataclass, field from typing import List, Dict, Optional class Mode(Enum): TASK task SEARCH search CHAT chat CONFIRM confirm dataclass class Context: history: List[Dict] field(default_factorylist) slots: Dict field(default_factorydict) user_profile: Dict field(default_factorydict) current_input: str dataclass class ModeResult: mode: Mode confidence: float reason: str这段代码没什么花哨的但它是整个系统的地基。Context承载所有可能用到的信息ModeResult记录判定结果和依据。我特意把reason字段留着就是为了排查问题。4.2 模式判定器的代码实现判定器我分成规则层和模型层。规则层先跑模型层兜底。import re STRONG_TASK_PATTERNS [r帮我, r请执行, r立即, r创建, r删除, r修改] QUESTION_PATTERNS [r是什么, r为什么, r怎么, r如何, r哪些] CONFIRM_PATTERNS [r^好的$, r^可以$, r^确认$, r^没问题$] def rule_based_detect(text: str, history: List[Dict]) - Optional[ModeResult]: for p in STRONG_TASK_PATTERNS: if re.search(p, text): return ModeResult(Mode.TASK, 0.9, f命中强指令词:{p}) for p in CONFIRM_PATTERNS: if re.search(p, text.strip()): return ModeResult(Mode.CONFIRM, 0.85, f命中确认词:{p}) for p in QUESTION_PATTERNS: if re.search(p, text): return ModeResult(Mode.SEARCH, 0.6, f命中疑问词:{p}) if len(history) 6 and all(h.get(mode) chat for h in history[-3:]): return ModeResult(Mode.CHAT, 0.7, 连续多轮闲聊) return None规则层返回None时走模型层def model_based_detect(text: str, history: List[Dict]) - ModeResult: recent history[-3:] if history else [] prompt f根据以下对话判断当前应该进入哪种模式。 可选模式task执行任务、search检索信息、chat闲聊、confirm确认操作。 最近对话{recent} 当前输入{text} 只输出模式名称和置信度格式mode,confidence # 这里调用你的模型接口 raw call_model(prompt) mode_str, conf raw.split(,) return ModeResult(Mode(mode_str.strip()), float(conf), 模型判定)两层合起来def detect_mode(text: str, history: List[Dict]) - ModeResult: result rule_based_detect(text, history) if result and result.confidence 0.8: return result model_result model_based_detect(text, history) if result and result.confidence model_result.confidence: return result return model_result这套逻辑我用了大半年线上准确率在92%左右。剩下的8%主要是边界情况比如用户一句话里既有任务又有疑问这种确实难判我的做法是优先任务模式因为任务通常更紧急。4.3 上下文组装与压缩模式定下来后按策略组装上下文。我写了一个函数根据模式返回不同的上下文片段def build_context(mode: Mode, ctx: Context) - str: if mode Mode.TASK: recent ctx.history[-5:] slots_str str(ctx.slots) return f最近对话{recent}\n当前槽位{slots_str}\n用户输入{ctx.current_input} elif mode Mode.SEARCH: return f用户问题{ctx.current_input} elif mode Mode.CHAT: profile str(ctx.user_profile) recent ctx.history[-2:] return f用户画像{profile}\n最近对话{recent}\n用户输入{ctx.current_input} elif mode Mode.CONFIRM: pending ctx.slots.get(pending_action, ) return f待确认操作{pending}\n用户输入{ctx.current_input}压缩部分我单独写了一个摘要函数当历史超过5轮时触发def compress_history(history: List[Dict], max_rounds: int 5) - List[Dict]: if len(history) max_rounds: return history old history[:-max_rounds] recent history[-max_rounds:] summary summarize(old) # 调用模型做摘要 return [{role: system, content: f历史摘要{summary}}] recent这里有个经验摘要不要每次都重做可以缓存。我一般每3轮更新一次摘要避免频繁调用模型。4.4 响应生成与模式化prompt响应生成的核心是每个模式一套prompt模板。我整理了一个模板表模式prompt要点输出格式长度限制task强调结构化、步骤化JSON或列表200字内search强调引用来源、准确答案来源300字内chat强调自然、简短纯文本50字内confirm强调明确、列出影响列表150字内以task模式为例prompt大概长这样TASK_PROMPT 你当前处于任务执行模式。 要求 1. 输出结构化的执行结果使用JSON格式 2. 如果任务需要多步列出步骤 3. 不要输出与任务无关的内容 上下文{context} 用户输入{input} 输出search模式的prompt会强调必须基于提供的资料回答不要编造SEARCH_PROMPT 你当前处于信息检索模式。 要求 1. 基于以下资料回答问题 2. 如果资料中没有答案明确说未找到相关信息 3. 回答后附上参考片段 资料{docs} 用户问题{input} 输出这套模板我迭代了十几版最大的体会是prompt要短、要具体、要可验证。不要写一堆抽象要求直接告诉模型输出什么格式、什么长度、什么语气。4.5 把流程串起来最后把判定、组装、生成串成完整流程def handle(user_input: str, ctx: Context) - str: mode_result detect_mode(user_input, ctx.history) ctx.current_input user_input context_str build_context(mode_result.mode, ctx) prompt get_prompt(mode_result.mode).format( contextcontext_str, inputuser_input ) response call_model(prompt) ctx.history.append({ role: user, content: user_input, mode: mode_result.mode.value }) ctx.history.append({ role: assistant, content: response, mode: mode_result.mode.value }) ctx.history compress_history(ctx.history) return response这段代码不到20行但包含了context-mode的全部核心逻辑。你可以直接拿去改把call_model换成你自己的模型接口就行。5. 常见问题与排查技巧实录5.1 模式判定不准怎么办这是最高频的问题。我的排查顺序是先看日志里判定的reason字段确认是规则命中还是模型判定如果是规则命中但判错了说明规则太宽泛需要加约束条件如果是模型判定错了先看prompt是否清晰再看是否需要换更强的模型。有个具体案例用户说帮我看看这个规则命中帮我判为task但用户其实只是想让我看看一段文字有没有错别字属于search。后来我在规则里加了排除条件如果帮我后面跟的是看看瞧瞧这类弱动作词降权到0.5交给模型复核。改完之后这类误判基本消失了。5.2 上下文太长导致响应变慢这个问题在长会话里特别明显。我的解决方案是三级压缩第一级是轮次截断只保留最近N轮第二级是摘要把更早的对话压成一段话第三级是实体抽取只保留关键实体。三级下来上下文长度能控制在原来的20%左右。还有一个技巧是按需加载。不是所有模式都需要完整历史search模式基本不需要历史chat模式只需要最近两轮。按模式加载上下文能省下大量token。5.3 模式切换时上下文丢失用户从task模式切到chat模式再切回来任务状态丢了这是很常见的问题。我的做法是把任务状态存在slots里不依赖对话历史。slots是独立于对话的持久化状态模式切换不影响它。每次进入task模式时从slots里恢复状态。具体实现上slots用字典存key是任务IDvalue是任务详情。对话历史只用来理解当前输入不用来存状态。这个分离设计很关键我早期把状态混在对话里切换模式就丢后来拆开就好了。5.4 常见问题速查表问题现象可能原因排查方法解决方案模式判定频繁出错规则太宽或模型prompt不清看reason字段加约束条件或改prompt响应变慢上下文过长统计token数三级压缩按需加载模式切换丢状态状态存在对话历史里检查slots状态与对话分离输出格式不稳定prompt不够具体看badcase明确格式和长度要求模型不遵循模式指令prompt太长或矛盾精简prompt只保留核心要求提示这张表建议打印出来贴在工位上出问题时按顺序排查能省很多时间。5.5 几个我踩过的坑第一个坑是过度设计模式。我一开始定义了8种模式结果判定器复杂度爆炸维护成本极高。后来砍到4种覆盖了95%的场景反而更稳。模式不是越多越好够用就行。第二个坑是忽略模式切换的平滑性。用户从task切到chat如果系统语气突变体验很割裂。我的做法是在切换时加一个过渡比如task结束后先问一句还有其他需要吗再进chat模式过渡自然很多。第三个坑是没有兜底模式。判定器偶尔会返回None或者低置信度结果如果没有兜底系统就卡住了。我现在默认兜底到chat模式至少能保证有响应。6. 进阶玩法与扩展方向6.1 多模式并行与嵌套有些场景下一个输入可能同时触发多个模式。比如用户说帮我查一下昨天的订单然后退掉这既是search又是task。我的处理方式是允许模式嵌套外层是task内层先执行search获取订单信息再执行task完成退货。实现上我在ModeResult里加了一个sub_modes字段记录需要嵌套的子模式。执行时按顺序跑前一个的输出作为后一个的输入。这套机制稍微复杂一点但能处理很多真实场景。6.2 基于用户反馈的动态调整模式判定器可以学习。我加了一个反馈机制用户如果对响应不满意比如点了没用或者重新提问就把这次判定标记为badcase定期用这些数据微调判定规则或模型prompt。跑了一个月判定准确率从92%提到了96%。具体做法是维护一个badcase库每周review一次把高频错误模式提炼成新规则。这个循环跑起来后系统会越来越准。6.3 跨会话的模式记忆用户上次会话处于什么模式这次会话开始时可以参考。比如用户上次在做任务这次一进来就说继续系统应该直接进task模式而不是重新判定。我在Context里加了last_mode字段会话开始时如果用户输入很短且模糊就参考last_mode。这个功能对连续使用场景特别有用用户不用每次都说帮我做XX直接说继续就行。6.4 模式的可视化与调试调试context-mode最痛苦的是不知道系统内部发生了什么。我做了一个简单的可视化面板实时显示当前模式、判定依据、上下文长度、响应耗时。上线后排查问题的效率提升了好几倍。面板不用很复杂一个网页几个数字和标签就行。关键是要实时能边用边看。我用的方案是WebSocket推送状态前端用最简单的HTML渲染。7. 一些个人体会context-mode这个东西说起来概念不复杂但真正落地时细节特别多。我最大的体会是模式的数量要克制判定的依据要透明状态的存储要独立。这三点做到了系统基本就稳了。另外不要指望一次设计就完美。我的模式定义改了五六版判定规则改了十几版prompt更是天天在调。这是个持续迭代的过程先跑起来再根据badcase慢慢优化比一开始就追求完美要实际得多。最后分享一个小技巧每次改完判定规则或prompt一定要跑一遍回归测试。我维护了一个包含200条典型输入的测试集每次改动都跑一遍看准确率有没有下降。这个习惯帮我避免了好几次线上事故。测试集不用很大覆盖主要场景就行关键是每次都要跑。