深入理解上下文模式：从context-mode到模式路由的工程实践

最近有朋友问我，为什么同一个AI工具，有时候回复精准得像在预判我的心思，有时候又离谱得让人想把键盘拆了。我的回答是：八成是上下文模式（context-mode）没打好。

“context-mode”这个词近段时间在AI圈里被反复提起，它指向一个非常务实的问题：AI面对完全不同的处境，却总想用同一套手法应对。你问它“帮我看看这段代码哪里卡住了”和“今天出门要不要带伞”，它理应进入完全不同的工作状态——一个是代码调试，一个是联网检索。可如果工具本身没有上下文模式，它就很难准确区分这两种场景，要么硬着头皮乱答，要么把能用到的工具全部调用一遍，又慢又不稳。

这篇文章，我打算把这个话题一次讲透：什么是context-mode、它解决什么痛点、底层机制如何运转，以及我在实际项目里是怎么把一套可用的上下文模式路由逻辑搭出来的。无论你是普通AI用户、提示词工程师，还是做AI应用开发的开发者，都能在这里找到参照。如果看完这篇文章，你还只是停留在“疯狂调prompt”的阶段，那这篇就算白写了。

1. 为什么同一个AI“时神时鬼”：一切从上下文模式说起

关于“时神时鬼”的典型体验

我先描述一个每个用户都遇到过的画面。你在AI对话框里输入了一句：“帮我看看这段代码怎么回事”。这句看似简单的话，落到不同场景里，期待完全不一样：

• 如果你正盯着IDE里的一行红色报错，你期待的是AI定位堆栈、指出根因，最好还能给出可以直接粘贴的修复代码。
• 如果你是在复盘一次线上故障，你期待的是一份完整的排查报告，包含日志分析、配置检查和可能的触发条件。
• 如果你是在做代码评审，你期待的则是代码逻辑问题、边界条件和风格建议。

同样的“帮我看看这段代码”，因为没有给出更多上下文，如果工具没有上下文模式，AI就很难判断到底该切入哪种姿态。于是干脆输出一版“面面俱到却也面面空洞”的回答，把报错、评审、日志分析全都讲了一遍，结果哪一条都不够深入，自然让人觉得“这个AI也就那样”。

没有上下文模式的AI：一条流水线走到黑

我接触过不少把AI接入到工作流里的团队。他们普遍会犯一个错误：以为设计一个很长、很全的“万能系统提示词”就能搞定所有问题。他们把它写成了五页纸的《AI使用规范》，然后让模型对所有输入都走同一套生成逻辑。结果是什么？

• 需要实时数据的问题，AI凭训练记忆硬编，编出了“北京今天28度”这种离谱回答。
• 不需要联网的问题，系统强行触发检索工具，响应时间直接翻倍，还带回来一堆无关搜索片段。
• 需要分析日志的问题，AI因为没有获得足够的文件上下文，开始瞎猜报错原因，最后给了一个看似颇有道理实际完全走偏的结论。
• 需要向用户追问澄清的问题，AI反而自信满满地给出一个错误答案。

这四种情况，归根到底是一件事：AI没有先判断“当前处在什么场景”，就直接执行了那个“什么都掺一点”的默认行为。或者说，它欠缺对“处境”的感知和对“行为姿态”的选择能力。

context-mode给出的解：先判定场景，再分配行动

上下文模式的做法很直白：在AI接收到用户输入之后、真正开始生成回答之前，增加一个“模式判定”环节。系统先根据当前全部可用上下文——用户最近的输入、历史对话的关键片段、当前可调用的工具列表、已知的项目信息等——判断此时应该进入哪一种工作模式，然后按该模式注入对应的提示词、开放对应的工具、调整对应的推理参数。

打个比方：你走进一家公司，前台会根据你找谁、办什么事，让你去不同楼层、见不同部门。没有前台的公司，访客只能随便找个工位把事情复述一遍，效率自然一塌糊涂。context-mode里的“模式”就是这家公司的各个部门，而“上下文”则是前台做判断的线索。

需要特别说明的是，这里谈的context-mode并不是某个具体产品的按钮。它是AI应用设计层面的通用概念：上下文感知 + 模式路由 + 差异化执行。你可以把“模式”理解成不同的“工作流”或“人格”，而“上下文”是触发这些工作流生效的依据。理解了这三个词，你就算摸清了context-mode的地基。

2. 上下文模式的底层拆解：上下文感知、模式路由与差异化执行

2.1 第一步：感知上下文，把“处境”变成结构化信号

所谓感知上下文，本质上是把眼前“这一个回合”的各种信息，整理成可以被程序读取的结构化数据。这一步看似基础，其实最容易被人忽略。我至少会抽取四类信息：

实战里我经常用一个小技巧：把上下文抽取的结果拼成一个结构化的“上下文快照”，在每次路由前打印出来。别看这一步简单，它能帮你一眼看出系统到底漏掉了哪些关键信息。以前我在做某个问答机器人时，发现路由结果忽好忽坏，打印了上下文快照才意识到，历史对话被不加限制地塞进了快照里——里面有大量闲聊内容，直接把路由逻辑带偏了。后来我把快照限制为“最近5轮有效对话 + 用户当前输入 + 结构化标签”，准确率立刻上来了。

2.2 第二步：模式路由，让AI决定“用什么姿态干活”

模式路由是上下文模式机制中承上启下的关键环节。一般有两条技术路线，外加一条推荐路线：

• 规则匹配路由。适合稳定性要求较高、判断维度非常清晰的场景。比如检测到输入里有“报错”加代码片段，就进入debug模式；检测到“最新”“新闻”“实时”“今天天气”等词，就进入web_search模式。优势是快、可控、容易调试，不会出现模型抽风选错模式的情况。
• 大模型推理路由。适合场景复杂、用户表达多样的场景。把当前的上下文快照塞进一条路由提示词，让模型从预定义的模式列表中选出最合适的一个。它可以辨别“帮我看看这段同步代码的线程问题”和“帮我写一份同步代码的diff”，这种精细场景规则很难覆盖。
• 混合路由。先用规则快速命中，命不中的情况再交给模型兜底。我实际做项目时最推荐这种方式，兼顾响应速度和召回率。正常流量里，约七成请求能被规则直接带走，剩下三成复杂意图交给模型推理，整体延迟稳定在毫秒级到一秒以内。

我用一个餐厅类比来理解路由：规则路由是看菜单点菜，你点“红烧肉”，后厨就知道这桌是吃家常菜的；模型路由是服务员听完你对“口味偏好、用餐人数、预算”的整体描述后，替你推荐“主厨套餐”。两者可以并存，服务员既能按菜单做判断，也能凭经验帮顾客选菜。

2.3 第三步：按模式差异化执行，把差异落到工具和参数上

路由做完，真正的价值在于执行阶段。不同模式应该在至少四个维度上有明确的差异：

• 可用工具集。debug模式下开放文件读取与代码执行工具；direct对话模式下关闭一切工具；web_search模式下只开放搜索相关工具，避免模型四处翻文件。
• 推理参数。需要严谨分析的场景把temperature调低到0.1～0.3，生成创意文案时可以放宽到0.8～1.0。这一点很多文档不会强调，但实测对输出质量影响极大。
• 上下文策略。联网检索模式要把搜索结果摘要临时插入上下文；代码调试模式要先让AI查看相关文件片段，而不是把整个仓库一次喂进去；对话模式则只需要保留最近几轮关键对话。
• 输出格式。客服模式要求简短、口语化；技术导师模式要有结构化结论、排查步骤和代码示例；文档生成模式则要完整章节和目录索引。

如果不做这些差异化执行，只有模式判断，那和“换一套更长的提示词”没有本质区别。上下文模式之所以有效，恰恰在于它把“模式判断”变成了“系统配置切换”，让AI从“知道该怎么办”到“真的按这个方式办”。

3. 不在纸上谈兵：手写一个context-mode路由模块

3.1 系统设计：三层结构、路由优先

如果我要在应用里落地context-mode，我会先用一个最简架构验证效果：

用户输入 -> 上下文快照打包 -> 模式判定 -> 模式执行 -> 输出

其中“模式判定”单独抽成一个模块。它输入打包好的上下文快照，输出一个模式名。模式执行模块再根据模式名去选择对应的提示词模板、工具集、参数配置。整个架构不复杂，但有一个核心原则：路由优先，执行跟随。

我为什么强调路由优先？因为在一个真实项目里，你常常会遇到“当你不知道用户要什么时，AI给出的答案无论多精致都是无效的”。先花0.2秒判断清方向，比花5秒钟生成一段错方向的万字长文划算得多。

3.2 代码实现：规则分类器，先跑起来

先写一个规则版本的实现。它便于理解，也方便快速部署到生产环境做基线。

from dataclasses import dataclass, field @dataclass class Context: text: str history: list = field(default_factory=list) available_tools: list = field(default_factory=list) timestamp: str = "" def detect_mode_by_rules(ctx: Context) -> str: t = ctx.text.lower() # 1. 实时信息类：需要联网搜索的意图 realtime_kw = ["最新", "新闻", "天气", "实时", "股价", "汇率", "今天几号"] if any(k in t for k in realtime_kw): return "web_search" # 2. 代码调试类：报错/异常关键词 + 代码特征 debug_kw = ["报错", "error", "traceback", "bug", "崩溃", "异常"] if any(k in t for k in debug_kw): if any(code_mark in t for code_mark in ["def ", "import ", "```", "File \"", ".py"]): return "code_debug" return "need_file" # 3. 闲聊类：短句、感叹、问候 if len(t.split()) < 6 and any(k in t for k in ["你好", "厉害", "谢谢", "哈哈", "在吗"]): return "chat" # 4. 未命中，交给上层兜底 return "unknown"

这套规则的逻辑很简单，但已经足够处理我遇到过的六成以上请求。举个例子，用户输入“我的Flask服务突然报Connection refused了，帮我看看”：

• 代码里先命中“报错”，然后往下检查有没有代码特征，这里有“Flask”和“Connection refused”，虽然没有“import”或“File”，但明显属于故障排查。为了让规则更聪明，我会把“服务”“端口”“连接”“部署”这类词也加进代码特征判断里，让它进入code_debug模式。

规则路由的精髓在于“保守”：宁可多命中，不要漏命中。对于不确定的情况，交给unknown，让上层模型兜底，而不是硬选一个模式误判方向。这里还有一个经验：初版规则不要追求一次写全，先跑几天，把命中不了、命中错误的路由日志收集起来，再迭代第二版规则。我是这么做的，效果比一开始搬一套复杂NLP逻辑好得多。

3.3 LLM推理式路由：用prompt让大模型自己选模式

仅仅靠规则覆盖不了所有用户表达，尤其当你面对的是五花八门的长文本输入时。这时我会上模型推理路由。

mode_choices = ["direct", "web_search", "code_debug", "clarify"] ROUTING_PROMPT = """ 请根据用户的输入判断当前最适合的处理模式，只输出一个模式名。 可选模式说明： - direct：直接回答，无需外部工具，适合通用知识问答、写作、翻译。 - web_search：需要联网获取最新、实时信息，适合新闻、天气、股价、时效事件。 - code_debug：需要查看代码文件或执行代码来定位问题，适合报错排查、性能分析、代码审查。 - clarify：输入信息不足，需要向用户追问澄清，适合需求描述模糊、缺少必要信息的情况。 用户输入：{query} """ def detect_mode_by_llm(ctx: Context) -> str: resp = llm.chat( messages=[ {"role": "system", "content": ROUTING_PROMPT.format(query=ctx.text)} ], temperature=0.2, max_tokens=8, ) mode = resp.strip().lower() return mode if mode in mode_choices else "direct"

这段代码有几个关键点值得讲。

第一，temperature设置成0.2。路由判断不需要创造性，它需要的是稳定和确定。设置成1.0会让模型偶尔给你输出“web_search或许不错”这种废话。

第二，max_tokens限制为8个。我需要的是一个模式名而不是小作文。限制token既能节省成本，也能倒逼模型输出简洁答案，减少格式解析出错的概率。

第三，模式列表里的描述非常关键。你给每个模式写的说明，本质上就是一种“小型的领域分类器”。描述里如果能包含“什么时候用、什么场景不用”，模型命中率会显著上升。比如把web_search描述从“联网搜索”改成“当用户需要获取最新或实时信息时，如新闻动态、今日天气、股价汇率，选择此模式”，效果完全不同。

3.4 混合路由方案：规则打底 + 模型兜底

最后给出我生产环境中实际使用的混合方案：

def route(ctx: Context) -> str: mode = detect_mode_by_rules(ctx) if mode != "unknown": return mode return detect_mode_by_llm(ctx)

这里需要注意：不能把“unknown”直接当作direct输出。因为direct是我的兜底模式，如果用户的需求实际上需要web_search，而规则没命中，模型也没追上，那就会导致“该搜的没搜”的失败。我的做法是，把unknown情况里的一个子集交给“clarify”模式，用一句“我先确认一下，你是想让我直接解释，还是需要实时的信息？”来化解模糊性。这比让AI盲目输出强得多。

4. 模式模板与提示词工程：不同的“上下文”要配不同的prompt骨架

4.1 按模式配置系统提示词

提示词不能一套通用到底，这是我做过无数实验后最深的体会。一个统一的“万能prompt”看似省事，但会让模型在回答“帮我看看这个报错”时，依然用写营销文案的口吻。所以我在每个模式里都配了一套独立的系统提示词骨架：

web_search模式： 你是一个信息检索助手。你只能基于搜索工具返回的最新结果作答。 禁止凭训练记忆推断时效信息，必须明确引用来源。 code_debug模式： 你是一个资深调试工程师。请先查看用户提供的相关文件与日志， 复现问题路径，给出根因分析和最小修复方案。不要跳过排查过程。 clarify模式： 你是一个耐心的需求确认员。当信息不足时，明确告诉用户你还需要什么， 并给出具体的问题样例。不要猜测用户意图。

这套提示词和路由模块是联动设计的。路由负责选择“思维脚手架”，提示词负责把模型带到对应的工作环境和思维路径上。两者配合，才叫完整的context-mode。

4.2 温度参数、工具开关、输出格式的联动

模式不只是提示词不同，很多执行参数也需要跟着变。下面是我常用的配置组合：

这张表是上下文模式“差异化执行”最直观的体现。如果你做了模式路由，却没有同步调整参数和工具，那模式就只是个空壳。我促成的团队实践是：把这类映射写在配置中心或一个mode_config.json里，新加模式时只改配置文件，不碰代码。

4.3 一个完整案例：把同一问题扔给三种模式

用用户一句话来演示差异：“我的服务老是Connection refused，帮我看看为什么。”

• 没有context-mode的AI：直接输出一篇“Connection refused常见原因汇总”，列了防火墙、端口占用、数据库连接数等八条原因，每条两句话。你是看完了，但也只是看完，因为这个回答没有结合你的服务类型、代码和日志。
• 有context-mode的AI：路由检测到“Connection refused”和“帮我看看”，命中code_debug。系统随即注入调试工程师提示词，开放文件读取工具。AI优先查看被引用的配置文件、启动日志和连接池相关代码，然后给出针对这个具体服务的排查链路，比如“端口8080被1883进程占用，建议检查最近一次部署变更”。

两者的差别一目了然。前者是“知识的搬运”，后者是“问题的拆解”。context-mode把AI从一个背课文的学生，变成了一个会按流程办事的员工。

如果你在调教自己的AI，也想验证context-mode的作用，我建议你找一个存在了很久、但一直处理不好的高频问题，分别用“通用prompt”和“模式化prompt”跑一遍，对照两个回答的可用度。这种实验会让你对模式切换的力量有深刻体会。

5. 我实测中的坑：上下文污染、模式震荡与上下文窗口过窄

5.1 上下文污染：当前对话混入历史垃圾

第一个我踩得最深也最典型的坑，是上下文污染。

早期我做的机器人会保存用户最近20轮对话，全量塞进上下文快照。结果用户前几轮在聊“周末去哪玩”，第四轮突然问“我的Python脚本为什么一直报ModuleNotFoundError”，系统却因为历史上下文里充满了“餐厅”“门票”这些词，把新问题误判成闲聊，直接进入了chat模式。最终回答自然是“周末出去玩也要注意安全哦”这种完全跑偏的话。

问题的根源是：在做模式路由时，我用了完整的原始对话作为输入，而忽略了“当前这轮提问的核心意图应该被优先放大”这个原则。

解决办法分两层：

• 路由窗口收窄。只取“最后一条用户消息 + 最近3～5轮对话摘要”，并且给当前输入更高的权重。
• 历史降噪。路由前先对历史对话做一个简单摘要，把“话题标签”抽出来，而不是把原文全部传给路由。比如前几轮聊过“北京周末亲子活动”，就只需要保留一个“话题：亲子活动”标签，而不是把完整对话塞进去。

我还养成了一个习惯：路由日志。每一条请求的路由输入、输出、最终响应都打日志。当出现一次误判时，你能很快回放当时的上下文快照，看清是哪一段历史垃圾污染了判断。没有日志，出问题就只能瞎猜。

5.2 模式震荡：AI在两种模式间反复横跳

第二种坑是模式震荡，也是做混合路由时会遇到的一种典型现象。

用户问：“这个报错帮我修一下，顺便看看最新的第三方SDK版本”。这句话里有两个意图：修报错，需要code_debug；查最新版本，需要web_search。传统路由只能返回一个模式名，而我最初的设计是“只能返回一个”，结果系统经常在web_search和code_debug之间随机切换，导致体验极不稳定。

解决思路有三条，我在不同项目里都试过：

• 允许返回多个模式，并在执行层做优先级排序。主意图优先处理，次要意图放在回答末尾作为补充。
• 增加显式的“混合模式”。路由输出的不再是一个字符串，而是一个模式列表。
• 在路由提示词里加一句“如果存在多个意图，请按重要性依次输出两个模式名”，然后让解析逻辑支持逗号分隔。

我目前落地比较顺的是第三种：路由输出“code_debug, web_search”这样的字符串，解析模块能把它拆成有序任务。主任务先跑，再追加次要任务。用户得到的是“修复方案+最新SDK版本对比”，而不是“二选一”。

还要给一个防抖设计：同一轮对话中，如果路由结果在“web_search”和“code_debug”之间跳动，系统应该锁定第一次命中的模式，而不是每次重新路由。这个防抖能省掉大量不稳定的接口调用。

5.3 上下文窗口过窄：信息不够，路由再准也没用

第三类坑更加隐蔽：模式路由判断准了，但上下文窗口里根本没有足够的信息支撑有效执行。

比如说，用户报了一个Composer依赖冲突的错，只贴了一行错误信息。路由正确进入code_debug模式，AI也确实知道要排查，但它对项目里的composer.json、相关依赖版本和锁文件一无所知，于是只能泛泛地解释“建议检查依赖版本约束”。回答正确但没有任何可操作性。

这时需要配合上下文增强机制：

• 文件摘要索引。提前对仓库文件生成摘要，路由命中debug模式后，按错误关键词去检索相关文件，把片段动态注入上下文。
• RAG动态检索。知识库文档也类似，根据用户问题动态取回最相关的段落。
• 日志上下文提取。如果是故障排查，把最近的日志窗口切片，提取关键错误栈。

我实践下来有一个重要心得：上下文窗口有限时，不要一次性把所有文件都塞给AI。先让AI定位“可能相关的文件”，再按模式加载局部重要片段。这既能控制token消耗，又能提升关键信息的集中度。比如调试时，先把入口文件、配置文件、最近改动文件加载进去，而不是从头到尾把整个仓库读一遍。

5.4 几个关键检查项

最后整理一份我每次上线context-mode路由前都会过一遍的检查项：

• 路由延迟不能超过1秒。能用规则命中的情况，不要硬上大模型推理。混合路由里，规则层应该吃掉大部分请求。
• 对模型输出的模式名做严格校验。任何未识别的模式都必须回落direct，而不是用这个不明模式去选择提示词，否则会出现配置异常。
• 长期收集路由日志。没有数据支撑的规则迭代都是盲改。我一般每周拉一次路由日志，看误判集中的类型，然后针对性地补充规则或修改模式描述。
• 给“澄清模式”留出路。当输入模糊、信息不足时，不要硬答。明确的追问，比强行给一个“看起来完整”的回答更能赢回用户信任。
• 模式切换要有“人工可控”的旁路开关。生产环境出现大规模误判时，最快的方法是先手动锁死为direct模式，再慢慢调规则。这个开关救了我至少三次上线事故。

最后再说几句实际的

如果你只打算记住一个结论，那就是：AI产品输出质量的上限，很大程度取决于它能不能准确判断“当下该用哪种方式干活”。而context-mode就是这套“判断→切换→执行”机制的总称。它不是什么玄学，也不属于某一个具体产品，而是一套完全可以自己搭起来的工程方法：上下文快照、规则路由、模型兜底、差异化参数、日志反馈，缺一不可。

我自己的习惯是，每接到一个新AI应用需求时，先不急着写prompt，而是先花半天梳理用户可能的指令类型，把它们归成几个模式，再搭最小的路由。跑一周后看日志、调规则、改提示词描述。这种“先定框架、再磨细节”的做法，比一开始就试图把prompt写得完美无缺要高效得多。

如果你也在做类似的事，但感觉AI的表现总是不稳定，不妨从context-mode这个角度重新审视一下：是真的模型不行，还是你的应用没有告诉它“现在是什么处境、应该用哪套行为”。很多时候，答案就藏在这句话里。