1. 从“context-mode”这个词说起它到底指什么第一次看到“context-mode”这个标题很多人会愣一下——它不像“XX管理系统”“XX爬虫框架”那样一眼能看出用途。我最初接触这个词是在做对话系统上下文管理的时候当时团队里有人提了一句“把上下文切成 context-mode 来管”我才意识到它其实是一个描述“上下文处理模式”的抽象概念而不是某个具体的库或工具。简单说context-mode 指的是一套系统在处理“上下文”时所采用的策略与状态组织方式。这里的“上下文”可以是对话历史、请求链路中的会话数据、渲染管线里的环境变量、甚至是编译器在解析代码时维护的作用域栈。而“mode”强调的是同一套系统在不同场景下会切换不同的上下文处理模式每种模式对应不同的存储结构、生命周期和读写规则。它解决的问题很实际当上下文变得又长又杂时如何避免它拖垮性能、污染逻辑、造成内存泄漏。比如一个客服机器人如果每轮对话都把全部历史塞进模型token 会爆炸如果只保留最近三轮又可能丢掉用户早先说的关键信息。context-mode 就是用来定义“什么该留、什么该丢、什么时候切换策略”的那层机制。这篇文章适合三类人看一是正在做对话系统、Agent 或任何有状态服务的后端开发二是被“上下文越传越乱”折磨过的前端或全栈三是对架构设计感兴趣、想理解“状态管理”底层思路的工程师。我会从概念拆解讲到落地实现再讲我踩过的坑尽量让没接触过的人也能跟上。提示context-mode 不是某个官方标准术语不同团队对它的定义会有差异。本文讲的是我在实际项目中总结出的通用理解你可以把它当成一套设计思路来参考而不是照搬某个规范。2. 上下文为什么需要“模式”三种典型失控场景在讲具体怎么做之前得先搞清楚“不管上下文”会出什么事。我见过太多项目一开始图省事把所有状态往一个全局对象里塞等到出问题再回头改成本高得吓人。下面这三种场景基本涵盖了上下文失控的主要形态。2.1 场景一对话历史无限增长导致成本与延迟双爆做对话类应用最典型。假设你用一个语言模型做客服每轮请求都把完整历史拼进去。第一轮 100 token第十轮就 1000 token第五十轮直接 5000 token 起步。这带来两个直接后果API 调用成本线性上涨以及首 token 延迟越来越长。更麻烦的是历史里可能包含用户早先提供的订单号、地址如果被后续无关对话稀释模型反而抓不住重点。我实测过一个案例某内部问答机器人不做任何上下文裁剪平均单次请求 3200 token改成滑动窗口加摘要后降到 900 token 左右响应时间从 2.3 秒降到 0.8 秒。这不是模型变强了而是上下文模式变了——从“全量累积”切到“窗口摘要”。2.2 场景二请求链路中上下文被隐式污染后端服务里上下文经常以 ThreadLocal、AsyncLocalStorage、React Context 这类形式存在。问题在于如果一次请求处理中异步任务没清理干净下一个请求可能读到上一个请求的残留数据。我遇到过最离谱的一次用户 A 的购物车信息出现在用户 B 的页面上排查半天发现是某个中间件在异常分支里没重置上下文。这类问题的根因是上下文的生命周期边界不清晰。context-mode 要解决的就是明确“这个上下文属于谁、活多久、什么时候销毁”。2.3 场景三多轮工具调用中上下文结构频繁变形现在很多 Agent 会调用外部工具每调一次工具上下文里就多一段工具返回结果。如果结构不统一代码里到处是if (type tool)这种判断维护起来极其痛苦。我见过一个项目工具返回格式有五种每种都要单独解析最后上下文对象膨胀到 2000 多行代码。这三种场景指向同一个结论上下文不能“自然生长”必须有明确的模式来约束它。接下来我拆解 context-mode 的核心构成。3. context-mode 的四个核心维度存储、生命周期、裁剪、序列化把 context-mode 拆开看我认为它由四个维度共同定义。任何一个维度设计不当整套机制都会出问题。下面逐个讲每个都配上我实际用过的方案和取舍理由。3.1 存储维度内存、外部存储还是混合上下文放哪里决定了它的读写速度和容量上限。常见三种选择存储方式读写速度容量上限适用场景典型实现进程内存极快受内存限制单次请求内、短会话对象、Map、ThreadLocal外部缓存快可扩展跨请求、多实例共享Redis、Memcached持久化存储慢几乎无限需审计、长期回溯数据库、对象存储我的经验是单次请求内的上下文坚决放内存跨请求的会话上下文放外部缓存需要审计的才落库。不要一上来就全塞 Redis网络往返本身就是开销。曾经有个项目把所有上下文都放 RedisQPS 一高Redis 成了瓶颈后来把请求内上下文改回内存Redis 只存会话摘要压力直接降了 70%。3.2 生命周期维度请求级、会话级、全局级生命周期决定了上下文什么时候创建、什么时候销毁。我一般分三级请求级随一次 HTTP 请求或一次函数调用创建调用结束即销毁。用 try-finally 或框架的请求钩子保证清理。会话级跨多次请求存在通常有超时时间。比如用户登录后的会话30 分钟无操作自动过期。全局级应用启动时创建进程结束才销毁。只放配置类、只读类数据绝不放用户数据。注意全局级上下文是内存泄漏的重灾区。我踩过的坑是把用户偏好放进了全局 Mapkey 是用户 ID结果用户量涨到十万后内存直接爆了。后来改成会话级加 LRU 淘汰才解决。3.3 裁剪维度窗口、摘要、向量检索这是 context-mode 里最考验设计的一环。上下文不可能无限留怎么裁我常用三种策略组合滑动窗口最简单只保留最近 N 轮。优点是实现快缺点是会丢早期关键信息。我一般设 N6 到 10具体看单轮平均长度。摘要压缩是把早期对话用模型或规则总结成一段话。比如前 20 轮压成 200 字摘要后续请求带上摘要加最近几轮。成本是每次压缩要额外调一次模型但长期看省下的 token 更多。向量检索是把历史存进向量库每轮根据当前问题检索最相关的几条。适合知识密集型场景但引入向量库本身有运维成本。我的实际做法是窗口打底、摘要兜底、检索补充最近 5 轮原文保留5 轮之前压成摘要如果摘要里没有当前问题相关的信息再去向量库捞。这套组合在多个项目里跑下来token 消耗能控制在纯全量方案的 20% 到 30%。3.4 序列化维度结构统一才能少写判断上下文在传递过程中要序列化格式不统一就会到处是类型判断。我强制要求团队用统一的结构{ sessionId: abc-123, mode: windowsummary, messages: [ {role: user, content: ..., ts: 1700000000}, {role: assistant, content: ..., ts: 1700000001} ], summary: 用户咨询退款流程已告知需提供订单号, metadata: {userId: u-001, channel: web} }关键是mode字段——它显式记录了当前用的是哪种上下文模式。这样下游处理时不用猜直接按 mode 分支即可。这个设计是我从一次重构里总结出来的之前没有 mode 字段代码里靠if (summary) {...} else {...}判断加了新策略后判断逻辑爆炸补上 mode 后清爽很多。4. 落地实现从零搭一套可切换的 context-mode概念讲完进入实操。我以一个 Node.js 对话服务为例讲怎么把上面四个维度落地成可运行的代码。其他语言思路一致替换对应 API 即可。4.1 定义模式枚举与上下文结构先定义清楚有哪些模式以及上下文长什么样。这一步看似简单但模式枚举一旦定错后面改起来很痛所以要预留扩展位。// context-modes.js const ContextMode { FULL: full, // 全量保留仅调试用 WINDOW: window, // 滑动窗口 WINDOW_SUMMARY: windowsummary, // 窗口摘要 RETRIEVAL: retrieval // 向量检索 }; function createContext(sessionId, mode ContextMode.WINDOW_SUMMARY) { return { sessionId, mode, messages: [], summary: , metadata: {}, createdAt: Date.now(), updatedAt: Date.now() }; }我特意把FULL模式保留下来只在本地调试时用。生产环境绝不允许 FULL否则成本失控。这个“调试模式与生产模式分离”的习惯帮我避免过好几次线上事故。4.2 实现窗口裁剪与摘要触发窗口裁剪的核心是控制 messages 数组长度摘要触发则要设阈值。我的经验是不要每轮都触发摘要那样模型调用太频繁而是当被裁掉的消息累积到一定量时才压一次。const WINDOW_SIZE 6; const SUMMARY_TRIGGER 4; // 被裁消息累积到4条才触发摘要 function appendMessage(ctx, role, content) { ctx.messages.push({ role, content, ts: Date.now() }); ctx.updatedAt Date.now(); if (ctx.mode ContextMode.WINDOW || ctx.mode ContextMode.WINDOW_SUMMARY) { const overflow ctx.messages.length - WINDOW_SIZE; if (overflow 0) { const removed ctx.messages.splice(0, overflow); if (ctx.mode ContextMode.WINDOW_SUMMARY) { ctx.pendingSummary (ctx.pendingSummary || []).concat(removed); if (ctx.pendingSummary.length SUMMARY_TRIGGER) { ctx.summary compressSummary(ctx.summary, ctx.pendingSummary); ctx.pendingSummary []; } } } } return ctx; }这里有个细节我把待摘要的消息先放pendingSummary攒够再压。这样摘要调用频率从每轮一次降到每 4 条一次成本明显下降。compressSummary可以用模型也可以用规则拼接看你对摘要质量的要求。4.3 摘要压缩的两种实现与取舍摘要实现分两派模型摘要和规则摘要。我两个都用过各有适用场景。模型摘要质量高能抓住语义重点但每次调用有成本和延迟。规则摘要快且免费但只能做机械拼接或关键词提取容易丢信息。// 规则摘要简单拼接加截断 function ruleSummary(oldSummary, removed) { const text removed.map(m ${m.role}: ${m.content}).join( | ); const combined oldSummary ? ${oldSummary} || ${text} : text; return combined.slice(-500); // 保留最后500字符 } // 模型摘要调用语言模型压缩 async function modelSummary(oldSummary, removed) { const prompt 已有摘要${oldSummary}\n新增对话${JSON.stringify(removed)}\n请合并成一段不超过200字的摘要保留关键事实。; return await callLLM(prompt); }我的选择标准是对事实准确性要求高的场景用模型摘要对成本敏感的用规则摘要。有个项目为了省钱用规则摘要结果用户早先说的订单号被截断丢了导致重复询问体验很差。后来改成模型摘要虽然每轮多花几分钱但省掉了用户投诉。4.4 模式切换的触发条件context-mode 的精髓在于“可切换”。什么时候从 WINDOW 切到 WINDOW_SUMMARY我的触发条件有三个对话轮数超过 10 轮自动升级到 WINDOW_SUMMARY检测到用户重复提问说明早期信息丢了立即触发一次摘要上下文 token 估算超过阈值比如 2000强制裁剪function maybeSwitchMode(ctx) { const tokenEstimate estimateTokens(ctx); if (ctx.mode ContextMode.WINDOW ctx.messages.length 10) { ctx.mode ContextMode.WINDOW_SUMMARY; } if (tokenEstimate 2000 ctx.mode ! ContextMode.RETRIEVAL) { ctx.mode ContextMode.WINDOW_SUMMARY; } return ctx; }estimateTokens不用太精确按字符数除以 2 估算中文、除以 4 估算英文即可。精确计算反而增加开销得不偿失。5. 踩坑实录那些让我熬夜的上下文问题上面讲的是“应该怎么做”这一节讲“我实际怎么翻车的”。这些坑在文档里基本找不到但每一个都真实发生过。5.1 坑一异步任务里上下文串了最惨的一次用户 A 的会话摘要出现在用户 B 的响应里。排查了两天才定位到某个异步日志任务持有上下文引用请求结束后没释放下一个请求复用了同一个对象。根因是上下文对象被跨请求共享了。修复方式是每次请求创建全新上下文绝不复用异步任务里传值用深拷贝或只传必要字段。// 错误做法把整个 ctx 传给异步任务 setTimeout(() logContext(ctx), 1000); // 正确做法只传必要字段或深拷贝 const snapshot { sessionId: ctx.sessionId, mode: ctx.mode }; setTimeout(() logContext(snapshot), 1000);这个坑的教训是上下文对象要当成“请求私有财产”绝不外借。5.2 坑二摘要越压越丢最后答非所问有段时间用户反馈机器人“失忆”明明前面说过的信息后面就不认了。查了摘要逻辑发现规则摘要每次只保留最后 500 字符多轮压缩后早期信息被反复截断最后只剩最近的内容。修复方案是摘要保留关键实体而不是简单截断。我加了一个实体提取步骤把订单号、日期、金额这类结构化信息单独存进 metadata摘要只压叙述性内容。这样即使摘要被压缩关键事实也不会丢。function extractEntities(messages) { const entities {}; const orderPattern /订单号[:]?\s*(\w)/g; messages.forEach(m { let match; while ((match orderPattern.exec(m.content)) ! null) { entities.orderId match[1]; } }); return entities; }5.3 坑三模式切换没有回退机制有一次线上流量突增WINDOW_SUMMARY 模式下的摘要调用把模型配额打满了导致正常请求也被限流。问题在于模式切换是单向的没有降级路径。后来我加了降级逻辑摘要调用失败时自动回退到纯 WINDOW 模式并记录告警。宁可暂时丢点上下文也不能让整个服务不可用。async function safeSummary(oldSummary, removed) { try { return await modelSummary(oldSummary, removed); } catch (e) { console.warn(摘要失败降级为规则摘要, e.message); return ruleSummary(oldSummary, removed); } }这个“失败降级”的思路后来被我应用到所有外部依赖调用上成了团队规范。5.4 坑四上下文没设上限内存缓慢泄漏会话级上下文如果只创建不销毁内存会慢慢涨。我见过一个服务跑了一周后内存从 200M 涨到 2G就是因为会话 Map 没有淘汰机制。修复是加 LRU 加超时双保险超过 30 分钟未活动的会话自动删除Map 总量超过 1 万时按最久未使用淘汰。const sessionStore new Map(); const SESSION_TTL 30 * 60 * 1000; const MAX_SESSIONS 10000; function cleanupSessions() { const now Date.now(); for (const [id, ctx] of sessionStore) { if (now - ctx.updatedAt SESSION_TTL) { sessionStore.delete(id); } } if (sessionStore.size MAX_SESSIONS) { const oldest [...sessionStore.entries()] .sort((a, b) a[1].updatedAt - b[1].updatedAt) .slice(0, sessionStore.size - MAX_SESSIONS); oldest.forEach(([id]) sessionStore.delete(id)); } } setInterval(cleanupSessions, 60 * 1000);这个清理任务每分钟跑一次开销很小但能彻底避免内存泄漏。6. 不同场景下 context-mode 的选型建议context-mode 没有万能方案选型要看场景。我按几种常见业务类型给出建议都是实际项目验证过的。6.1 客服对话类窗口加摘要为主客服场景的特点是对话轮数多、事实信息密集订单号、地址、时间。我的配置是窗口 6 轮摘要用模型压缩实体单独提取存 metadata。这样既控制 token又不丢关键事实。实测数据某客服机器人接入这套方案后平均 token 从 2800 降到 750用户满意度没下降因为关键信息都保住了。6.2 代码助手类检索为主代码场景的上下文特点是“相关代码片段比对话历史更重要”。用户问一个函数怎么改需要的是相关文件内容而不是前面聊了什么。所以这类场景我以向量检索为主把代码库索引进向量库每轮根据问题检索 top-k 片段。窗口只保留最近 2 轮用于理解指代比如“它”指什么其余全靠检索。这套方案在内部代码问答工具上效果很好回答准确率比纯窗口方案高不少。6.3 多 Agent 协作类结构化上下文加显式传递多 Agent 场景下上下文要在 Agent 之间传递最容易乱。我的做法是每个 Agent 有独立的上下文空间Agent 之间只传结构化消息不共享整个上下文对象。// Agent 间消息格式 { from: planner, to: executor, task: 查询订单状态, params: { orderId: 12345 }, context: { relevantHistory: [...] } // 只传相关片段 }关键是context字段只传相关片段而不是全量。这样每个 Agent 的上下文都干净不会互相污染。6.4 选型对照表场景类型推荐模式窗口大小摘要方式存储位置客服对话windowsummary6模型摘要实体提取Redis代码助手retrieval2不摘要向量库内存多 Agent结构化传递按需不摘要消息队列单轮问答full仅调试不限无内存这张表可以直接拿去对照自己的项目。如果你的场景不在表里按“事实密度高就用摘要相关性要求高就用检索”的原则选。7. 监控与调优让 context-mode 持续可控上线不是终点context-mode 需要持续监控才能保持效果。我一般盯三个指标。7.1 上下文 token 分布统计每次请求的上下文 token 数看 P50、P95、P99。如果 P99 远高于 P50说明有长尾会话没被有效裁剪。我设的告警线是 P99 超过 3000 token。function recordTokenUsage(ctx, tokens) { metrics.histogram(context.tokens, tokens, { mode: ctx.mode, sessionId: ctx.sessionId }); }按 mode 打标签很重要这样能看出哪种模式在消耗资源针对性优化。7.2 摘要命中率摘要命中率指“用户后续提问所需信息是否在摘要里”。这个不好直接测我的土办法是统计“用户重复提问率”——如果用户反复问同一件事说明摘要丢了信息。重复提问率超过 5% 就要检查摘要逻辑。7.3 模式切换频率如果模式频繁切换说明触发条件设得不合理。比如一会儿 WINDOW 一会儿 WINDOW_SUMMARY会导致摘要反复重建浪费资源。我一般要求模式切换后至少稳定 5 轮才允许再切。function canSwitchMode(ctx) { const roundsSinceSwitch ctx.messages.length - (ctx.lastSwitchAt || 0); return roundsSinceSwitch 5; }这个“切换冷却期”的设计是从一次线上抖动里总结出来的。当时模式每轮都切摘要调用量翻了三倍加了冷却期后恢复正常。8. 我个人的几条实操心得写了这么多最后分享几条不成体系但很实用的心得都是踩坑换来的。第一条上下文结构尽早定别等业务复杂了再改。我经历过一次重构因为早期上下文结构太随意后期加字段要改几十处调用点花了两周。如果一开始就用统一结构加 mode 字段改起来会快很多。第二条摘要宁可多花点钱也别丢关键事实。用户对“机器人失忆”的容忍度极低一次丢订单号可能就流失一个客户。模型摘要的成本相比用户流失不值一提。第三条所有外部依赖都要有降级路径。摘要服务、向量库、缓存都可能挂挂了不能让主流程崩。降级到规则摘要、降级到纯窗口都比服务不可用好。第四条上下文清理要主动不能等 GC。会话 Map、缓存条目、异步引用都要有明确的清理时机。我现在的习惯是每个上下文对象创建时就登记清理任务到期自动执行。第五条监控要按 mode 维度拆。不拆的话你只知道整体 token 高不知道是哪种模式的问题。拆了之后能精准定位优化效率高很多。这套 context-mode 的思路我从最早的“全量塞”一路迭代到现在中间翻过不少车。它不是什么高深技术核心就是把上下文当成有生命周期的资源来管理而不是一个随便塞的容器。你如果在做类似的东西希望这些经验能帮你少走点弯路。