1. 为什么需要context-mode：从“无状态对话”到“模式感知”
1.1 大模型应用里最容易被低估的问题：上下文失控
过去一年多，我做过不少基于大语言模型的应用，从简单的问答机器人到多步骤的复杂任务编排，踩得最深、返工最多的坑，几乎都集中在同一个地方——上下文管理。
很多人第一反应是：上下文不就是把聊天记录拼起来传给模型吗？窗口不够就截断，太多就摘要，这有什么可做的？但真正动手做产品就会发现，问题远没那么简单。
举个我实际遇到的场景。做一个面向运营团队的内容助手，需要支持三种任务：写营销文案、分析用户反馈、生成周报数据解读。最开始用的是“一锅烩”方案，所有对话历史、知识库内容、工具返回值全部塞进同一个上下文。结果是什么？用户在聊文案时，模型突然把之前数据分析里的口径拿过来用；写周报时，又莫名其妙沿用营销文案的语气。更烦的是，上下文里塞了太多无关内容，真正重要的指令被淹没，模型开始“忘记”用户最初的要求。
这不是模型能力不够，而是我的架构没有做上下文治理。
1.2 context-mode 解决的三个核心痛点
我整理了一下，所有问题归根结底是三类：
痛点一：上下文混用导致任务漂移。不同任务对上下文的需求完全不同——写文案需要风格指南和竞品参考，做分析需要数据口径和历史结论，处理代码需要项目结构和依赖说明。把它们全部堆在一起，模型无法判断当前应该优先遵循哪一组指令，表现就是行为不稳定、输出风格飘忽。
痛点二：token 预算永远不够用。上下文窗口是有上限的，就算用 200K 长度的模型，也不可能把无限多的历史记录都装进去。更关键的是，真正有用的上下文可能只占 20%，剩下 80% 是噪音，却一样要付 token 成本，一样占用窗口空间。
痛点三：无法迁移。用户切换任务时，旧任务产生的大量中间信息没有清理机制，新任务被迫带着一堆“历史包袱”启动。这不仅拖慢响应，还可能造成新任务的输出被旧任务的语境污染。
context-mode 不是一个具体的开源库，而是一套设计思路：把上下文按照“模式”进行划分和管理，每个模式下定义清晰的上下文边界、存储结构、切换规则。这就像给一个人配了不同的工作台——写代码一个台面，写文档一个台面，每个台面上的工具和资料是明确摆好的，切换工作内容时换台面就行，不需要每次把整个办公室都搬一遍。
1.3 它与常见方案的边界在哪
你可能想问：这个和 LangChain 的 memory 模块、向量数据库召回、历史消息摘要有什么区别？
区别在于层位不同。向量召回解决的是“从外部知识库找相关资料”，摘要解决的是“压缩历史对话”，memory 模块解决的是“历史信息怎么存”。而 context-mode 解决的是“当前这次任务应该把哪些东西组装成上下文、以什么结构呈现给模型”——它是更上层的组装逻辑，决定了上述那些组件在什么时机、以什么组合、按什么优先级被使用。
简单说，向量库是仓库，摘要是压缩机，memory 是记事本，而 context-mode 是工作台的管理者。它不替代那些工具，而是调度它们。
2. 模式的核心组成：一份上下文不再只有“聊天记录”
2.1 一个模式最少需要定义五类元素
我在实践里把每个 context-mode 定义为五个组成部分，缺一个都会在实际使用中暴露出问题。
| 组成元素 | 作用 | 典型内容 |
|---|---|---|
| 角色预设 | 限定模型的行为立场和输出风格 | 你是资深运营专家，输出使用简洁书面语 |
| 任务目标 | 当前模式要达成的核心结果 | 生成一篇小红书风格的产品种草文案 |
| 知识范围 | 允许引用的外部资料集合 | 产品卖点库、竞品文案库、禁用词表 |
| 行为约束 | 明确的边界和禁忌 | 不编造数据、不评价竞品、不改动价格信息 |
| 对话留痕 | 与该模式相关的历史对话记录 | 本次任务在文案模式下产生的 6 轮历史 |
关键点在于：这五类元素不是模棱两可的软提示词，而是结构化数据。角色预设和行为约束是固定配置，写死在配置文件中；任务目标是每次调用时的变量；知识范围通过引用标识符指向不同的知识库切片；对话留痕按照模式分别存储，互不混用。
2.2 上下文的结构化：从“一大段文本”到“折叠区块”
传统做法是把所有内容拼成一段超长 prompt 扔给模型。context-mode 的做法是先把上下文定义为多个区块，每个区块有独立类型，前缀带有明确的结构化标记：
[ROLE] 你是本项目的高级数据分析师... [OBJECTIVE] 本次任务：分析用户反馈数据，输出 TOP5 高频问题... [KNOWLEDGE: product_manual] （引用产品手册相关章节） [KNOWLEDGE: feedback_tags] （引用反馈分类标签体系） [RULES] - 只基于给定数据输出结论 - 如果数据不足以支撑判断，明确说明 [HISTORY: mode=analysis] （本模式下的历史对话，最多保留 12 轮）这种写法的好处非常直接：模型不需要在长文本中自行推断当前应该做什么，它的注意力可以被引导到明确的区块上。实测下来，在同样 token 预算下，结构化上下文的指令遵循率比纯拼接文本有明显的可感知提升，尤其在多步骤任务中的稳定性改善非常明显。
2.3 模式切换的触发设计
模式切换不能靠用户手动指令硬切，也不能每轮都靠模型自行判断——这两种方式我都试过，前者体验割裂，后者开销高且不稳定。最终采用的方案是“意图识别 + 显式确认”的组合：
- 用户发送新请求时，先用一个轻量分类器（可以是一个专门用于意图识别的小模型，也可以是一个极小 prompt 的快速调用）判断请求属于哪个模式；
- 如果分类置信度足够高，自动切换；
- 置信度模棱两可时，返回候选模式列表让用户确认，确认后记住该用户在此类请求上的偏好，下次直接沿用。
这套机制配合显式的模式切换命令（比如/mode analysis）双通道并行，既照顾了自动化的流畅，也保留了用户的可控权。
3. 关键工程取舍：上下文窗口、token 成本与“模式垃圾桶”
3.1 为什么“塞满窗口再截断”是最差策略
很多人调 API 时的默认思路是：把能塞的全塞进去，碰上限就把最旧的对话截掉。这个做法的问题，我是在一次真实事故里有深刻体会的。
那次是一个客服工单分类工具。工单内容很长，加上历史对话，很快就碰到了窗口上限。我的截断逻辑是“从最早的消息开始丢”，结果用户发的整段问题描述里的核心信息被丢了一半，分类准确率从 88% 掉到 71%，而且没有明显报错，只是结果悄悄变差。
这里有三个决策层面的错误，大家引以为戒：
- 没有区分“高价值上下文”和“低价值上下文”。原始工单文本中的关键实体、诉求描述是绝对高价值，寒暄性历史和重复状态更新是低价值。按时间先后截，等于把高价值内容先丢掉。
- 没有为模式设置“必须保留区块”。每个模式都应有最低限度的不可裁剪内容——角色预设、任务目标、当前任务描述中的关键参数。
- 没有做压缩替代。当上下文超过限制，不应该直接丢弃，而应该尝试用摘要提取关键信息后再替换原内容。
3.2 token 预算的硬性计算：一个可以直接照搬的公式
我给项目定了一个“三总二保”的 token 预算规则，简单说就是三次计算总量、两次保证底线：
第一次计算：模式固定开销。角色预设 + 行为约束 + 知识范围的前缀描述，这部分是常量，用 tiktoken 或对应 tokenizer 实测得出。假设为 A。
第二次计算：历史动态开销。当前模式下的对话留痕，按轮次依次计算并逐轮累加，保留最近 N 轮的 token 总和。假设为 B。
第三次计算：本次请求开销。当前用户输入 + 可能需要新追加的知识库内容。假设为 C。
预算分配公式：
可用历史预算 = 窗口上限 × 0.9 - A - C 实际保留历史 = 截至满足 可用历史预算 的最近 N 轮对话为什么要乘 0.9？留出 10% 的缓冲给模型的生成输出，避免生成过程中 token 超限被强制截断。
第一次保证：B 如果超过可用历史预算，则从最早的历史开始逐轮摘要，使摘要压缩后的 token 总量控制在可用历史预算的 60% 以内，剩下 40% 留给最近两轮完整对话——因为最近两轮往往承载了用户当前的真实意图。
第二次保证：无论窗口多么紧张，角色预设和任务目标区块不允许被裁剪。这两个区块被挤出窗口时，模型就会“忘本”。
3.3 模式切换时的上下文迁移策略
模式切换时最忌讳的是直接清空历史，也别一股脑全部带入。我用的方法是三步迁移：
- 沉淀：旧模式产生的本轮结论与关键数据，写入旧模式的结构化记忆库，做成索引化的思考摘要；
- 携带：把摘要中的关键结论，作为新模式的“前置背景”放在上下文中，用一个小区块标记来源；
- 隔离：旧模式的完整原始对话，默认不进入新模式上下文，仅在需要时通过工具显式拉取。
举个例子，用户在“数据分析”模式下完成了销售数据的异常归因，然后切到“周报撰写”模式。旧模式沉淀下来的是结论：华东区销售额下跌 12%，主因是新品上市推迟两周。新模式携带的也是这条结论，但不会把数据分析过程中的 30 轮详细追问、中间表格全都带到写周报的上下文里。这样既保留了信息价值，又避免了噪音。
4. 最小可落地的 context-mode 实现：配置文件 + 组装器 + 切换器
4.1 配置文件怎么写：以 JSON 格式定义模式
不引入复杂框架，一个 JSON 文件就能解决模式的静态定义。我项目里的实际结构如下：
{ "modes": [ { "name": "analysis", "description": "数据分析与归因", "role": "你是一名严谨的数据分析师，只基于给定数据说话", "objective_template": "分析以下数据的异常原因：{query}", "knowledge_refs": ["data_dict", "metric_definitions"], "rules": [ "不允许编造数据", "当数据不足时明确说明，不要猜测", "输出结论必须附带对应的数据表格片段" ], "history_limit": 12, "summary_threshold_tokens": 1800, "priority": 1 }, { "name": "copywriting", "description": "营销文案生成", "role": "你是一名资深的品牌内容创作者，输出风格偏轻快小众", "objective_template": "根据以下产品信息生成推广文案：{query}", "knowledge_refs": ["product_faq", "style_guide", "banned_words"], "rules": [ "不使用夸张的绝对化用词", "每条文案必须包含一个明确的行动指令", "不提及竞品名称" ], "history_limit": 8, "summary_threshold_tokens": 1200, "priority": 2 } ] }4.2 组装器的核心流程：三步拼装一个可用的上下文
组装器负责把配置文件 + 当前会话状态 + 外部知识引用拼成一个最终发送给模型的 prompt。核心逻辑就三步，我贴一下伪代码实现思路：
# 伪代码，展示组装逻辑 def assemble_prompt(mode_name, user_input, history_store, knowledge_store): mode = load_mode_config(mode_name) # 第一步：加载不可裁剪区块 role_block = f"[ROLE]\n{mode.role}" objective_block = f"[OBJECTIVE]\n{mode.objective_template.format(query=user_input)}" rules_block = f"[RULES]\n" + "\n".join(f"- {r}" for r in mode.rules) # 第二步：按需加载知识区块，并做 token 预算裁剪 optional_blocks = [] budget_left = MAX_CONTEXT_TOKENS * 0.9 - count_tokens(role_block + objective_block + rules_block) for ref in mode.knowledge_refs: content = knowledge_store.retrieve_top_k(ref, user_input, k=3) block_text = f"[KNOWLEDGE: {ref}]\n{content}" if count_tokens(block_text) < budget_left * 0.5: optional_blocks.append(block_text) budget_left -= count_tokens(block_text) # 第三步：加载历史区块，按预算保留，超限则先摘要 history_block = build_history_block(mode.name, history_store, budget_left) return "\n\n".join([role_block, objective_block] + optional_blocks + [rules_block, history_block])有几个细节值得单独说明：
知识区块的半额策略。每个知识区块最多占用当前剩余预算的 50%，避免三个知识库把预算全部吃光。如果每个只取前 3 条相关片段，实际占用并不会太大，但这一道保险能让组装器在极端情况下的行为更可预测。
历史的预清洗。在进入 budget_left 计算之前，历史记录中会先剔除空轮次、纯状态消息、工具内部日志，只保留用户消息、助手回复和关键工具结果。这个预清洗能省下不少 token，且不影响质量。
4.3 切换器的状态流转：防止“模式串味”
切换器需要维护一个会话级的模式状态机。我踩过的坑是：只靠一个 current_mode 变量，结果在异步处理时，两个并发请求来回切换模式导致状态错乱。后来改成栈结构，支持嵌套模式：
class ModeStack: def __init__(self, default_mode): self.stack = [default_mode] def switch(self, new_mode): # 记录切换前的模式用于回溯 self.stack.append(new_mode) def back(self): # 返回上一个模式 if len(self.stack) > 1: self.stack.pop() return self.current() def current(self): return self.stack[-1]嵌套模式的实际价值在于：模式 A 执行过程中，用户插入一个临时问题（模式 B），回答完之后还能回到模式 A 的上下文，而不是从零重启。这个体验上的差别，用户感知是非常明显的。
5. 实测中的意外与踩坑记录：说几个真实发生的案例
5.1 模式串味事故：知识引用标识符冲突
第一次上线时，我用了带前缀的知识库命名，比如product_manual、feedback_tags。看起来没有问题，直到有一次分析用户反馈时，模型反复引用产品手册中的描述，造成了输出逻辑混乱。
排查之后发现原因：知识库检索阶段，我用的是同一个向量集合，没有按knowledge_refs做集合隔离。结果在“分析模式”下检索feedback_tags时，top3 结果里混进了product_manual的段落。虽然标识符指定了[KNOWLEDGE: feedback_tags]，但内容本身已经不纯净了。
修复方案是在检索阶段强制加入模式过滤标签，给每个知识文档打上允许被哪个模式引用的元数据。教训很简单：组装器的知识来源必须是隔离的，不能只靠 prompt 里的标识符规范模型行为，要从源头把水搅浑的问题解决掉。
5.2 token 预算失控：一个真实的计算复盘
某次线上事故，用户反馈响应越来越慢，且输出质量明显下降。查了日志，发现一个会话的上下文已经悄悄膨胀到接近窗口上限，而压缩策略没有触发。原因是我把摘要阈值设置在数据结构里，但历史写入时没有实时检查阈值，只有组装时才检查，而组装前已经发生了多轮会话，每轮生成的长文本把上下文撑满了。
这次事故的根因是：预算控制应该在每次写入历史时就执行，而不是在读取组装时才执行。事后我把历史写入逻辑加上了实时检查，当超过模式设定的 summary_threshold_tokens 时，立即触发对该模式下较早历史的异步摘要重算。这也是我在实践中最深刻的教训之一——检查点越早，修复代价越低。
5.3 意图识别器的置信度困境
模式切换依赖意图识别，而意图识别不是 100% 可靠的。我遇到过用户问“这个数据你帮我看看”却触发了文案模式的尴尬情况。
后来在分类器和用户确认之外，加了一道“输出后校验”的逻辑：模型生成完回复后，用分类器再次判断回复内容是否符合当前模式的气质。如果严重偏离，会在界面上提示“该回答可能不太符合当前模式，是否需要切换到更合适的模式”。这个提示给用户带来了很大好感，等于是系统自己承认了可能的不完美，反而建立了信任感。
6. context-mode 的进阶思路与可能的延伸方向
6.1 模式随使用数据演进：基于反馈微调角色预设
静态的配置文件只是起步。把每次调用后的隐式反馈（用户是否修改了输出、是否复制走了结果、是否点了赞）和显式反馈收集起来，定期回灌到模式定义中，就能形成持续演进的模式库。具体做法是在配置文件中增加字段，记录该模式的最近有效案例，组装上下文时从中挑选 1-2 个高相似度案例作为 few-shot 示例，实测对生成质量的提升非常明显。
6.2 多级模式树：从“切换”到“编排”
当业务复杂到一定程度，模式之间不再是平行切换，而是“主模式 + 子模式”的层级结构。比如主模式是“营销策略生成”，子模式包括“用户画像分析”“竞品调研”“文案产出”三个子模式。子模式产生的结论会自动上抛到主模式上下文，最终汇总成策略报告。这种编排方式比平面切换更接近人类工作的咨询流程，也使上下文边界更清晰。
6.3 上下文审计与回放：为每一次输出留下完整证据链
因为上下文的组装不会百分之百完美，出现过模型输出了不确定结论的情况。我的做法是每一次模型调用的完整 prompt 都做结构化留痕，包括加载了哪些模式区块、哪些知识文档、哪几轮历史被压缩或删除。这样做的价值有两个层面：既能让用户推送到“为什么这样回答”的溯源信息，也给后续优化模式配置提供了第一手数据。
7. 落实到你自己的项目：起步建议与避坑清单
7.1 从最小闭环开始：两周内跑通一个可用版本
如果你也想在自己的项目里落地 context-mode，我建议不要一步到位做全套。两周内做到以下这些就够了：
- 在代码里定义一个 mode 的配置结构体，把角色、目标、约束三个字段先立起来；
- 按模式分流用户请求，每个模式下有独立的历史存储 key；
- 写一个最精简的组装函数，把角色块、目标块、历史块拼好；
- 切模式时做一次摘要沉淀，不直接清空。
上面四步做完，你就能感受到“模式感知”带来的变化。
7.2 避坑清单：我整理的五条最核心经验
- 上下文预清洗一定要做，且要放在 token 预算计算之前，否则预算结果全是虚的；
- 历史摘要是“缓存”，不是“知识库”，别把摘要当作唯一的事实来源，关键数据要保留原始引用路径；
- 每个模式都要定义“不可裁剪区块”，否则冲突发生时你的保护优先级根本无从谈起；
- 模式切换必须显式可回退，用户永远有权返回上一个模式，别让系统流程替用户做决定；
- 所有组装过程要留日志，线上出问题时没有日志，你连复盘都无从下手。
7.3 关于“过度设计”的一句忠告
context-mode 这套东西，做浅了只是多点分流，做深了会涉及向量检索、意图识别、摘要策略、审计系统等一系列叠加。我的建议是：你的项目场景里如果确实能分清楚三到四类任务，且不同类型任务之间上下文差异巨大，才值得做模式化；如果所有请求高度同质，那用统一的固化 prompt 就够了。模式化不是为了炫技，是为了在复杂度真正出现时，让你的系统仍然可以被理解和控制。
以我自己的体会来说，把 context-mode 真正跑顺之后，最明显的变化不是我那些应用的质量指标提升了多少，而是排查问题时的心态完全不一样了——因为你能明确说出模型是在什么模式下回答的，它回答了基于哪些依据，出问题时不再是从头到尾翻日志瞎猜，而是直接定位到具体模式区块的配置或数据。这种感觉对工程团队来说，是最值钱的东西。
