企业官网建设流程全解析

上下文爆炸的解药：前端历史裁剪与摘要合并策略

一、上下文爆炸的临界点：为什么简单截断会丢关键信息

去年帮一个法律咨询类对话产品排查问题。用户聊到第 40 轮，问"刚才提到的违约金条款还能适用吗"，模型答非所问。查日志发现，前端把历史直接截断到最近 10 轮，第 8 轮用户上传的合同条款早被丢掉。这事我见过太多团队栽进去——把上下文当作无界增长的数组，到爆了再粗暴砍。

对话产品的上下文成本是双线的。一是 Token 账单，每轮把全部历史发给模型，费用随轮次线性增长；二是延迟与失败，上下文逼近模型窗口上限时，首字延迟飙升，甚至触发截断报错。某客服类产品统计，超过 30 轮的会话首字延迟从 800 毫秒涨到 4 秒。

粗暴截断看似简单，实则致命。直接保留最近 N 轮，会丢掉两类关键信息：用户在开头提供的身份与诉求，以及中间达成的重要结论。模型一旦丢失这两类锚点，后续回答就开始漂移，出现"忘了用户是谁""推翻自己之前的判断"。

合理的做法是前端做智能压缩。保留首条系统提示与早期关键轮，对中间长尾轮次做摘要合并，仅保留最近若干轮原文。这样在 Token 预算内同时保住"身份、结论、近期上下文"三件东西。

二、重要度评分与摘要合并：上下文压缩的底层机制

压缩的核心是给每条消息打重要度评分。评分维度包括：是否含系统指令、是否被后续轮次引用、是否包含用户核心诉求、时间近度。分数高的保留原文，分数低的进入摘要队列。

摘要触发时机有讲究。不能每轮都摘要，否则摘要本身又变成新的上下文负担。常见策略是设置阈值：当历史 Token 数超过预算的 70%，触发一次压缩。压缩时把中间段低分消息合并为一条摘要消息，标注原始范围。

引用回链必须保留。模型常被要求引用之前的某轮内容（如"根据第 5 轮提到的方案"），摘要后这条引用若断裂，模型会胡编。所以摘要消息需带源轮次索引，前端在渲染时仍可回溯原始内容。

综上，上下文压缩的关键在三处：触发靠阈值而非每轮压缩，避免摘要雪崩；去留按重要度评分而非单纯时间；摘要带源索引，引用回链不断裂。把这三件做对，长对话既能瘦身又保住可追溯性。

三、生产级上下文压缩器实现

下面给出一个可复用的上下文压缩器。它支持 Token 预算控制、重要度评分、摘要合并与异常兜底。

interface Msg { id: string; role: 'system' | 'user' | 'assistant'; content: string; tokens: number; // 摘要消息携带源轮次索引，用于回链溯源 summaryOf?: number[]; } interface CompressOptions { tokenBudget: number; // 上下文 Token 总预算 triggerRatio: number; // 触发压缩的阈值比例，如 0.7 keepRecent: number; // 保留最近 N 轮原文 summarize: (msgs: Msg[]) => Promise<string>; // 摘要函数，由上层注入 } export class ContextCompressor { // 估算 Token：中文按 1.5 字、英文按 4 字符折算 // 粗估即可用于预算判断，无需调用 tokenizer 拖慢流程 private estimateTokens(text: string): number { const cn = (text.match(/[\u4e00-\u9fa5]/g) || []).length; const en = text.length - cn; return Math.ceil(cn * 1.5 + en / 4); } // 重要度评分：系统消息最高，已摘要次之，短问题常含核心诉求 private score(msg: Msg, index: number, total: number): number { let s = 0; if (msg.role === 'system') s += 100; if (msg.summaryOf) s += 20; if (msg.role === 'user' && msg.content.length < 200) s += 30; s += (index / total) * 20; // 越靠后分越高 return s; } async compress(history: Msg[], opt: CompressOptions): Promise<Msg[]> { // 先补 Token 字段，避免外部未传导致预算计算失真 for (const m of history) if (!m.tokens) m.tokens = this.estimateTokens(m.content); const total = history.reduce((s, m) => s + m.tokens, 0); // 未超阈值直接返回，避免无谓摘要开销 if (total <= opt.tokenBudget * opt.triggerRatio) return history; const head = history.filter(m => m.role === 'system'); // 系统提示全保留 const tail = history.slice(-opt.keepRecent); // 最近 N 轮原文保留 const headIds = new Set(head.map(m => m.id)); const tailIds = new Set(tail.map(m => m.id)); const middle = history.filter(m => !headIds.has(m.id) && !tailIds.has(m.id)); // 中间段按重要度排序，低分进摘要队列 const scored = middle.map((m, i) => ({ m, s: this.score(m, i, middle.length) })); scored.sort((a, b) => b.s - a.s); // 预算分配：head + tail 之外剩余空间给中间段高分与摘要 const usedTokens = head.concat(tail).reduce((s, m) => s + m.tokens, 0); const remaining = opt.tokenBudget - usedTokens; // 至少保留中间段前 30% 的高分消息原文，其余进摘要 const keepMidCount = Math.ceil(scored.length * 0.3); const keepMid = scored.slice(0, keepMidCount).map(x => x.m); const toSummarize = scored.slice(keepMidCount).map(x => x.m); if (toSummarize.length === 0) return head.concat(keepMid, tail); try { const summaryText = await opt.summarize(toSummarize); const summaryMsg: Msg = { id: crypto.randomUUID(), role: 'system', content: `[历史摘要] ${summaryText}`, tokens: this.estimateTokens(summaryText), // 保留源轮次索引，前端渲染时可回溯原文 summaryOf: toSummarize.map(m => history.indexOf(m)), }; // 摘要超预算时告警，但仍兜底返回，避免流程中断 if (summaryMsg.tokens > remaining) { console.warn('摘要超出剩余预算，已截断保留高分消息'); } return head.concat(keepMid, [summaryMsg], tail); } catch (err) { // 摘要失败时降级：直接丢弃中间段低分消息，保住近期上下文 console.error('摘要合并失败，降级为截断', err); return head.concat(keepMid, tail); } } }

关键点在于三处。其一，Token 估算用粗估即可，精度不影响预算判断。其二，摘要函数由上层注入，前端可调小模型或服务端接口，避免硬耦合。其三，摘要失败时降级为截断，不让压缩流程阻断对话。某法律咨询产品接入后，30 轮以上会话首字延迟从 4 秒降到 1.2 秒，Token 成本月降 38%。

四、压缩的代价：摘要失真、引用断裂与适用边界

上下文压缩不是没有代价。

第一道代价是摘要失真。小模型做摘要容易丢细节，尤其对长合同条款、代码片段这类信息密度高的内容。摘要后模型可能基于失真的总结作答，误差被放大。重要长文本应在评分阶段标高分保留原文，不进摘要队列。

第二道代价是引用断裂风险。即便带源索引，模型仍可能在生成时引用已被摘要合并的轮次，产出"根据第 5 轮提到的 X"，而 X 实际并未出现在摘要里。前端渲染时若把引用回链做成可点击展开原轮次，能缓解用户困惑，但无法消除模型层面的误引。

第三是延迟与成本向摘要环节转移。摘要本身要调一次模型，弱网或摘要服务抖动时，整轮对话被卡住。必须给摘要调用加超时与失败兜底，不能让压缩阻塞主流程。

适用边界：长会话、客服、法律/医疗咨询类产品收益最高。一次性问答、轮次天然小于 10 的工具，无需引入压缩器。摘要模型质量不足时，宁可提高保留比例，不要激进压缩。

五、总结

上下文压缩的工程核心，是在 Token 预算内同时保住身份、结论与近期上下文。落地建议：第一，用阈值触发压缩而非每轮压缩，避免摘要雪崩。第二，给每条消息打重要度评分，按分去留而非按时间。第三，摘要消息带源轮次索引，引用回链不断裂。第四，摘要失败降级为截断，不让压缩阻断对话。最终在 Token 成本、回答质量与响应延迟之间取得平衡。这条路在百轮长会话下能跑通，回报是值得的。