context-mode：上下文驱动架构如何解决多场景行为切换难题

1. 从“context-mode”这个词说起：它到底在解决什么问题

第一次看到“context-mode”这个标题，很多人会下意识地把它当成某个框架里的配置项，或者某个编辑器插件的开关。但如果你真正在工程一线待过，就会明白这个词背后指向的是一类非常具体、非常高频的痛点：同一个系统，在不同上下文里需要表现出完全不同的行为，而传统的“全局模式”写法根本扛不住这种复杂度。

举个最直观的例子。你写一个对话式应用，用户可能在“闲聊”上下文里说“帮我推荐一部电影”，也可能在“排障”上下文里说“帮我看看这段日志为什么报错”。如果系统只有一种全局模式，它要么把排障请求当成闲聊来敷衍，要么把闲聊请求当成排障来过度分析。两种结果都很难看。context-mode 要做的，就是把“当前处于什么上下文”这件事显式地建模出来，让系统根据上下文切换行为策略，而不是靠一堆 if-else 硬编码。

我在实际项目里踩过最深的坑，就是早期版本把所有逻辑塞进一个巨大的状态机，结果每加一个场景就要动核心分支，改到第三个月已经没人敢碰那段代码了。后来我们把“上下文”抽成独立维度，行为策略按上下文注册，核心调度层只负责识别和分发，维护成本直接降了一个数量级。这也是我为什么认为 context-mode 值得单独拿出来讲——它不是语法糖，而是一种把上下文当作一等公民的架构思路。

这篇文章适合三类人看：一是正在做对话系统、Agent 调度、多场景交互的开发者；二是被“全局状态”折磨过、想找更清晰组织方式的后端或前端工程师；三是对架构模式感兴趣、想理解“上下文驱动”到底怎么落地的人。我会从核心概念拆到实操步骤，再讲清楚选型理由和踩坑经验，尽量让你看完就能在自己的项目里试起来。

2. context-mode 的核心概念拆解：上下文、模式与调度层

2.1 什么是“上下文”，它和普通参数有什么区别

很多人会把上下文和普通函数参数混为一谈，觉得“不就是多传几个字段吗”。这两者的关键区别在于生命周期和影响范围。普通参数通常只影响当前这一次调用，而上下文会在一段时间内持续影响系统的行为决策。

打个比方：你去餐厅点菜，点的“宫保鸡丁”是参数，只影响这一道菜；而你“正在吃午饭”这个状态是上下文，它会影响服务员给你推荐什么、上菜顺序怎么排、要不要给你倒茶。context-mode 里的上下文，就是后者这种“持续生效的环境信息”。

在实际建模中，上下文通常包含几类信息：场景标识（当前是闲聊还是排障）、用户意图的粗粒度分类、历史交互的摘要、当前可用的能力集合。注意最后一点很关键——上下文不仅描述“现在是什么情况”，还决定了“现在能用哪些工具”。这比单纯传一个 scene 字段要强大得多。

2.2 “模式”不是枚举，而是行为策略的集合

初学者最容易犯的错误，是把模式理解成一个枚举值，然后到处写if mode == 'A'。这样做的结果是模式越加越多，分支越来越乱。正确的理解是：一个模式是一组行为策略的绑定，包括提示词模板、可用工具列表、输出格式约束、错误处理方式。

我习惯用一个简单的结构来描述模式：

class Mode: def __init__(self, name, prompt_template, tools, output_schema, fallback): self.name = name self.prompt_template = prompt_template self.tools = tools self.output_schema = output_schema self.fallback = fallback

这样定义之后，新增一个模式就是新增一个配置对象，而不是去改调度逻辑。调度层只负责“识别当前上下文 → 找到对应模式 → 执行”，完全不关心模式内部长什么样。这就是 context-mode 能扛住复杂度的根本原因。

2.3 调度层：识别、切换与兜底

调度层是整个 context-mode 的心脏，它要做三件事：识别当前上下文、切换到对应模式、在识别失败时兜底。

识别方式有很多种，最简单的规则匹配，复杂一点的用分类模型。我在项目里通常采用“规则优先 + 模型兜底”的混合策略：先用关键词和结构化信号做快速判断，命中就直接用；没命中再走一个轻量分类器。这样既保证了常见场景的响应速度，又不会在边界情况上完全失效。

切换时要特别注意状态清理。不同模式的工具集和输出格式不一样，如果切换时不清掉上一个模式的临时状态，很容易出现“用排障模式的工具去处理闲聊请求”这种诡异问题。我的做法是每次切换都重置一个 session 级的 context 对象，只保留必要的跨模式信息（比如用户身份）。

兜底策略同样重要。当系统无法判断上下文时，不要硬猜，而是进入一个“澄清模式”，主动向用户确认意图。这比猜错之后让用户反复纠正要友好得多。

3. 为什么不能只用全局状态：三种典型翻车场景

3.1 场景一：提示词污染导致的“人格分裂”

早期我做过一个客服机器人，所有场景共用一套系统提示词。结果用户问“你们几点下班”，机器人回答得挺好；用户接着问“帮我查下订单”，机器人突然开始用非常正式的法律腔调回复，因为提示词里混了太多合规话术。这就是典型的提示词污染——全局提示词为了兼容所有场景，被迫塞进大量互相冲突的指令，最终哪个场景都做不好。

context-mode 的解法是按模式隔离提示词。闲聊模式用轻松的语气模板，排障模式用严谨的技术模板，两者互不干扰。实测下来，用户对回复自然度的满意度提升非常明显，因为每个场景都拿到了“量身定制”的指令。

3.2 场景二：工具集膨胀导致的误调用

第二个坑更隐蔽。当系统只有几个工具时，把所有工具都暴露给模型问题不大。但当工具增加到几十个，模型开始频繁误调用——明明用户在闲聊，模型却调用了“查询数据库”工具。这不是模型笨，而是工具集本身构成了上下文的一部分，工具太多会稀释模型的注意力。

按模式裁剪工具集之后，这个问题基本消失。闲聊模式只暴露“讲笑话”“推荐内容”这类轻量工具，排障模式才暴露“读日志”“查监控”这类重工具。模型在每种模式下看到的选项都很少，选择准确率自然上去了。

3.3 场景三：输出格式冲突导致的解析失败

第三个坑是输出格式。有些场景需要结构化 JSON，有些场景需要自然语言。如果全局只定义一种输出格式，要么结构化场景解析失败，要么自然语言场景被强行塞进 JSON 里变得很别扭。

context-mode 允许每个模式绑定自己的输出 schema。排障模式输出带字段的结构化结果，闲聊模式输出纯文本。下游解析器根据模式选择对应的解析逻辑，整个链路就顺了。

4. 落地实操：从零搭一个 context-mode 调度骨架

4.1 第一步：定义上下文的数据结构

动手之前先把上下文的结构定清楚，不然后面会反复改。我的建议是最小化起步，只放三类字段：场景标识、会话级状态、能力开关。

from dataclasses import dataclass, field from typing import Any @dataclass class Context: scene: str = "unknown" session_state: dict = field(default_factory=dict) capabilities: set = field(default_factory=set) history_summary: str = ""

这里scene是核心，session_state放跨轮次需要保留的信息，capabilities决定当前能用哪些工具。history_summary是可选的，用于给模型提供历史背景，但要注意控制长度，别把整个对话历史都塞进去。

4.2 第二步：注册模式与行为策略

模式注册我推荐用字典加装饰器的方式，既直观又方便扩展：

MODES = {} def register_mode(name): def wrapper(cls): MODES[name] = cls() return cls return wrapper @register_mode("chat") class ChatMode: prompt_template = "你是一个轻松的聊天助手..." tools = ["recommend", "joke"] output_schema = None

这样新增模式只需要写一个类加一个装饰器，完全不用动调度代码。我在项目里用这套结构加了七八个模式，核心调度层一行没改过，这就是解耦带来的好处。

4.3 第三步：实现识别与切换逻辑

识别逻辑我建议分两层：快速规则层和模型兜底层。快速规则层用关键词和正则，覆盖 80% 的常见情况；模型兜底层处理剩下的模糊情况。

def detect_scene(user_input, context): if any(kw in user_input for kw in ["报错", "日志", "异常"]): return "troubleshoot" if any(kw in user_input for kw in ["推荐", "聊聊", "随便"]): return "chat" return classify_with_model(user_input)

切换时记得清理状态：

def switch_mode(context, new_scene): if context.scene != new_scene: context.session_state.clear() context.scene = new_scene mode = MODES[new_scene] context.capabilities = set(mode.tools)

注意：清理状态时不要清掉用户身份这类跨模式必需的信息，建议把它们放在一个单独的persistent字段里，切换时保留。

4.4 第四步：接入执行链路并验证

最后把调度层接到实际执行链路上。执行时根据context.scene取对应模式，用模式的提示词、工具集和输出 schema 去调用模型。验证阶段重点看三件事：识别准确率、切换后行为是否符合预期、兜底是否生效。

我一般会准备一组覆盖各场景的测试用例，跑一遍看识别结果。如果某个场景识别率低，就补充规则或调整分类器。这个过程通常要迭代两三轮才能稳定。

5. 识别策略的取舍：规则、模型还是混合

5.1 纯规则方案的适用边界

纯规则方案最大的优点是可解释、可调试、零延迟。你写了一条规则，命中就是命中，没命中就是没命中，排查问题非常直接。对于场景边界清晰、关键词明确的系统，纯规则完全够用。

但纯规则的边界也很明显：它处理不了表达多样性。用户说“这东西怎么不动了”和“系统无响应”，在规则眼里可能是两回事，但语义上是一回事。规则写多了会互相冲突，写少了覆盖不全，维护成本会随着场景增加而快速上升。

我的经验是：场景数量少于 5 个、关键词区分度高的情况下，纯规则是最优解。超过这个规模，就该考虑引入模型了。

5.2 模型分类方案的收益与代价

模型分类的优点是泛化能力强，能处理各种花式表达。代价是需要标注数据、有推理延迟、结果不完全可解释。对于延迟敏感的场景，每次请求都跑一次分类模型可能不可接受。

我的折中做法是：用模型做离线评估和规则挖掘。先跑一批真实数据让模型分类，然后看哪些表达被分到了同一类，据此提炼规则。这样既享受了模型的泛化能力，又保持了线上推理的轻量。

5.3 混合策略的工程实现要点

混合策略的关键是规则的优先级要高于模型，且规则命中时要跳过模型调用。这样常见场景走快路径，模糊场景走慢路径，整体延迟可控。

def detect_scene_hybrid(user_input, context): scene = match_rules(user_input) if scene: return scene, "rule" scene = classify_with_model(user_input) return scene, "model"

另外建议记录每次识别的来源（rule 还是 model），方便后续分析规则覆盖率。如果发现模型调用占比过高，说明规则需要补充；如果规则误判率高，说明规则写得太激进，需要收紧。

6. 踩坑实录：我在 context-mode 上栽过的四个跟头

6.1 坑一：模式切换时的状态残留

这个坑我印象最深。当时系统从闲聊切到排障，结果排障模式里居然带着闲聊时缓存的“推荐列表”，导致模型在排障时莫名其妙地推荐起了电影。排查了半天才发现是切换时没清 session_state。

修复方案很简单，但教训很深刻：切换模式必须显式清理非持久状态。后来我干脆把状态分成persistent和transient两部分，切换时只清 transient，从结构上杜绝这类问题。

6.2 坑二：兜底模式被当成万能模式

有段时间我们的兜底模式做得太“能干”，结果识别失败时用户也能得到看似合理的回复，导致识别问题被掩盖了很久。直到做数据分析时才发现，兜底模式的调用占比高达 30%，远超预期。

这件事让我明白：兜底模式应该“笨”一点，它的职责是澄清意图，而不是假装自己能处理一切。后来我们把兜底模式改成主动提问“您是想聊聊天，还是遇到了问题需要排查”，识别准确率的数据才真实反映出来。

6.3 坑三：工具集共享导致的权限越界

早期为了省事，所有模式共享一个工具池，只是通过提示词告诉模型“当前只能用某几个”。结果模型偶尔会无视提示词，调用不该调用的工具。这在涉及数据查询的场景里是严重问题。

正确做法是在代码层面裁剪工具集，而不是靠提示词约束。模型看不到的工具，它就不可能调用。这个改动虽然增加了配置工作量，但安全性提升是质的。

6.4 坑四：输出 schema 变更引发的下游崩溃

有一次我们给排障模式加了一个新字段，忘了同步更新下游解析器，结果线上直接报解析错误。这件事的根因是模式 schema 和下游解析逻辑耦合太紧。

后来我们引入了 schema 版本号，模式变更时版本号递增，下游根据版本号选择解析逻辑。同时加了契约测试，模式 schema 一改，测试就会失败，强制开发者同步更新下游。这套机制上线后，类似的崩溃再没出现过。

7. 性能与可维护性的平衡：几个实战优化点

7.1 上下文摘要的长度控制

history_summary如果无限增长，会拖慢推理速度并增加成本。我的做法是只保留最近 N 轮的关键信息，更早的历史压缩成一句话摘要。压缩可以用规则（提取关键实体）也可以用模型（生成摘要），看你的成本预算。

实测下来，把摘要控制在 200 字以内，既能提供足够的背景，又不会明显拖慢推理。超过 500 字之后，收益递减非常明显。

7.2 模式注册表的懒加载

模式多了之后，启动时全部初始化会拖慢冷启动。我改成懒加载：注册表里只存类引用，第一次用到某个模式时才实例化。对于模式多但单次会话只用到少数几个模式的系统，这个优化效果很明显。

7.3 识别结果的缓存

同一会话里，上下文通常不会频繁切换。可以把识别结果缓存起来，短时间内相同输入直接复用。但要注意设置合理的过期时间，避免用户意图已经变了还在用旧结果。

我一般设置 3 到 5 轮的缓存窗口，超过就重新识别。这个值需要根据实际场景调，交互密集的场景可以短一点，交互稀疏的可以长一点。

7.4 可观测性建设

context-mode 系统最怕的就是“不知道当前处于什么模式”。我在每个关键节点都打了日志：识别结果、识别来源、切换动作、模式执行耗时。这些日志汇总起来，能快速定位“为什么这次回复不对劲”这类问题。

建议至少监控三个指标：各模式的调用占比、识别来源分布、兜底触发率。兜底触发率突然升高，往往意味着有新的表达方式没被规则覆盖，需要及时补充。

8. 这套思路还能怎么扩展

context-mode 的适用范围其实比对话系统广得多。我在几个不同类型的项目里都用过类似思路，效果都不错。

一个是多租户后台系统。不同租户的权限、界面配置、数据隔离策略差异很大，用 context-mode 的思路把“租户上下文”抽出来，每个租户绑定一套行为策略，核心逻辑完全不用改。

另一个是多端适配。同一套业务逻辑要同时服务网页端、移动端和小程序端，各端的交互约束不一样。把“端类型”作为上下文维度，各端注册自己的渲染策略和交互约束，业务核心保持统一。

还有一个是工作流引擎。不同流程节点的处理逻辑差异很大，用模式来封装每个节点的行为，调度层只负责按流程推进，节点内部怎么实现完全解耦。

这些场景的共同点是：存在多个行为差异明显的上下文，且上下文切换频繁。只要符合这个特征，context-mode 的思路就能派上用场。

最后分享一个我个人的小习惯：每次新增模式之前，先问自己“这个模式的行为差异是否足够大，大到值得单独抽出来”。如果差异很小，硬塞进现有模式反而更简单。模式不是越多越好，恰到好处的粒度才是关键。我见过太多项目因为模式拆得太细，最后调度层比业务逻辑还复杂，那就本末倒置了。