企业官网建设流程全解析

这一章聊的是 AI 编程助手 CLI 里的对话压缩系统，也就是上下文窗口的生命周期管理。用过这类工具的人，多少都撞见过几个怪现象：长会话聊到一半，助手突然“失忆”，前面说好的技术方案后面又反复推翻；再不然就是同一轮对话拖到最后，响应越来越慢、费用肉眼可见地涨，甚至直接提示上下文已满。这些症状的根源，几乎都指向同一个地方——上下文窗口是有容量的，而它从创建到填满再到压缩重建，本身就是一条完整的生命周期。把这条生命周期的每个节点管好，就是对话压缩系统真正要做的事。

这一章不打算只讲概念，我会把窗口增长的规律、压缩方案的取舍、CLI 里的落地实现以及我调试时踩过的坑一起捋一遍。适合两类人看：一类是重度使用 AI 编程助手的开发者，读完你能理解为什么长会话会变笨，以及怎么通过主动换对话来降低踩坑概率；另一类是正在自己搭建类似工具、或者给内部系统接大模型能力的工程师，你会需要这里面的设计思路和代码骨架。

1. 为什么需要一套对话压缩系统

1.1 上下文窗口不是无限记事本

可以先建立一个基本印象：模型一次能处理的输入长度是有上限的，这个上限通常用 token 数来衡量。一个 token 大概相当于三分之一到二分之一个汉字，或四分之三个英文单词。上下文窗口就像一个固定行数的小黑板，写满之后，要么新的写不进去，要么最早的内容被挤掉。

在普通聊天场景里，窗口是不太容易写满的，但在 AI 编程助手的 CLI 环境下，情况完全不同。因为这里不只是“用户一问、助手一答”，背后还夹杂着大量工具调用：读文件要返回内容，执行测试要返回日志，搜索代码要返回匹配片段，运行命令要返回标准输出。我见过一次目录递归枚举直接吃进去上万 token 的，也见过一条测试失败信息带着完整堆栈占掉几千 token。工具调用返回的数据，才是撑爆窗口的头号元凶。

如果窗口被写满，模型提供商通常会直接拒绝请求，或者由 API 层自动截断最旧的消息。而截断既不区分信息价值，也不考虑任务进度，很可能把用户最初的约束、之前敲定的接口设计、某条关键命令直接丢进回收站。对话压缩系统要解决的第一件事，就是“别让窗口被无脑截断，而是有策略地压缩”。

1.2 生命周期不管理，问题会逐个找上门

很多开发者对“上下文窗口”的理解是静态的：给定一个模型，窗口大小是固定的，比如 200K token。但真正重要的是窗口里内容的动态变化，也就是生命周期。一次会话从输入第一条消息开始，内容就一直在增长，直到会话结束或被压缩。

我归纳下来，不去管理这个生命周期，问题会按顺序出现。早期阶段只是 token 消耗偏高，费用变多。到中期，窗口逼近上限，请求延迟上升，模型处理大段上下文的注意力会被稀释，回答质量肉眼可见地下滑。再往后就是硬性触顶——接口直接报错，或者工具层自动丢弃了最早的历史消息。

最容易被忽略的是“自动丢弃”带来的隐性风险。表面上看，丢弃旧消息后会话还能继续，但助手可能已经忘记用户最开始强调的技术栈、目录结构、命名规范。它依然在认真回答，但回答的基础已经缺了一块。这种状态下，助手会一本正经地给出与前期决策直接冲突的方案，用户如果没留意，就会被带偏。

1.3 压缩系统要解决的三件具体事

把需求拆开看，对话压缩系统其实只解决三件事。

第一，在有限的 token 预算里保住高价值信息。不是所有历史消息都值得保留，压缩要做的不是“少占空间”，而是“用更少 token 表达同样的关键信息”。

第二，让会话可以超长持续，不逼着用户频繁开新窗口。日常编码任务里，一个功能从讨论、设计、编码到调试可能要持续几十轮，如果中途重置对话，很多上下文就断了，重新说明的成本很高。

第三，在压缩过程中维持任务连续性。这意味着压缩后的上下文必须让模型知道“我们之前聊到了哪一步、已经确定了哪些约束、接下来要做什么”。丢失这部分，压缩就只是省了 token，没有解决根本问题。

理解了这三点，后面所有方案设计都有了解题方向。

2. 上下文窗口的生命周期拆解

2.1 从创建到结束，窗口经历了哪些阶段

我给上下文窗口划分了五个阶段，这套划分方式是设计压缩系统的基础。

初始化阶段：会话创建时，工具会向模型发送系统提示、工具声明、当前工作目录信息，可能还有代码索引片段。这些内容构成整个窗口的“地基”，一般不会在后续过程中被丢出窗口。

稳定增长阶段：随着用户提问、助手回答、工具执行结果不断叠加，窗口使用量稳定上升。这个阶段比较“平静”，但增长曲线并不平缓，因为工具输出常常带来尖峰。

压力阶段：窗口使用量达到某个百分比阈值，比如 70% 或 80%，此时虽然还能继续对话，但风险和成本都在上升。压力阶段是压缩系统介入的最佳时机，而不是等到满屏报错再处理。

压缩重构阶段：系统从现有对话中提取摘要、丢弃低价值消息、精简工具输出，把窗口使用量降回安全水位。这个过程可能重复多次。

恢复运行阶段：压缩后的上下文被重建，会话继续。如果压缩质量足够好，模型不会明显感觉到“记忆”被裁剪。

理解这个生命周期，你就知道压缩不是发生在某个随机时刻的操作，而是窗口成长到压力阶段之后的必然动作。

2.2 初始化阶段：固定开销比你想象的大

很多人以为上下文窗口里主要是对话内容，其实初始化阶段的固定开销相当可观。系统提示要说明助手的行为规范，工具定义要把每个工具的用途、参数、返回格式都写清楚，仅这一块就可能占到三五千 token。如果工具定义做得详细，分类多、参数多，那突破一万 token 也很常见。

再加上当前项目信息：工作目录路径、语言版本、构建命令、代码库的整体结构说明，这些都是每次请求都要带着的基础内容。也就是说，即使一句话都还没聊，你的可用预算就已经被扣掉了一块。

这部分内容应该被视为“不可压缩段”。因为它们承担的是定义助手能力边界和任务背景的角色。强行压缩系统提示会导致工具调用格式错乱，强行压缩项目背景会让助手对当前上下文一无所知。所以压缩系统在设计时，第一步就应该把角色为 system 且属于基础定义类的消息标记为不可压缩。

2.3 成长阶段：消息增长的不对称性

对话推进的过程中，不同消息类型的体积增长差异极大。我用一张表来展示典型情况：

真实场景里，用户输入 200 token，助手回复 1000 token，工具返回 6000 token，是很常见的一组数据。也就是说，十轮对话之后，真正积压的是工具输出和助手的长回复，而不是用户的话。

这一点决定了压缩策略要对消息类型区别对待：压缩工具的原始输出，永远比压缩用户的约束条件更重要。

2.4 压力阶段：窗口快满时的可观测信号

窗口快满时其实有迹可循。最直接的信号是 token 使用量，工具可以在每次发起模型请求前统计当前消息队列的总 token 数，并和窗口上限做对比。更直观的信号是响应速度：上下文越长，模型处理前序内容的耗时越高，用户会感觉到“越聊越慢”。

还有一种更隐蔽的信号是回答质量的下降。上下文过长时，模型对早期内容的关注度会减弱，尤其是夹在中间的工具日志会把关键信息“稀释”掉。我自己的观察是，当上下文占比超过 80% 后，助手开始出现重复强调近期内容、忽略早期约束的倾向。

CLI 工具应该在压力阶段就主动介入，而不是等模型接口报错。介入的方式就是下一节要讲的压缩方案选型。

3. 压缩方案选型：别一上来就想“剪掉旧消息”

3.1 最省事的方案：滑动窗口截断

最早期的实现大多是直接丢旧消息：保留最近 N 轮对话，更早的全部删掉。好处是简单、快、不需要额外的模型调用。很多轻量实现至今还在用这个策略。

但它的缺点太明显。早期对话里往往包含了用户的需求来源、技术栈选择、命名约束，这些信息一丢，助手后面就只能靠猜。而且截断是不可恢复的，删了就没了。我自己不太建议把它作为主压缩方案，最多作为系统初始兜底，也就是“实在没办法时保证程序不崩溃”的手段。

3.2 更体面的方案：消息级摘要压缩

比截断高级一些的做法，是把历史对话发给模型，让模型生成一段摘要，然后用这段摘要替换掉所有旧消息。这样窗口里保留的是“压缩后的长期记忆”，而不是被直接抹除的空白。

摘要压缩的关键在于提示词模板。模板不能只是“总结一下这段对话”，而要有结构化输出要求。我习惯让摘要包含五个部分：用户当前目标、已确定的技术决策、未完成的步骤、所有带“必须/不要”的约束条件、最近一次的错误信息。

下面是一段可参考的模板：

你是会话摘要器。请压缩以下对话，保留： 1. 用户当前目标与尚未完成的步骤； 2. 已经确定的技术决策，文件中明确出现的路径、常量、命令必须原样保留； 3. 所有带“必须”“不要”“禁止”语气的约束条件； 4. 最近一次工具返回的错误信息； 5. 下一步计划。 输出格式： 目标：... 决策：... 约束：... 错误：... 下一步：...

注意，摘要不是给用户看的，是给模型自己看的，所以术语要保留，语气要直接，别写成“用户希望”“用户提到”这类转述口吻。转述会把指令弱化成描述，后面会展开讲这个问题。

3.3 推荐做法：分层混合压缩

把整个上下文分成四层是我目前觉得最实用的结构：

L0 层是系统提示和工具定义，永远不压缩。L1 层是滚动摘要，保存长期记忆，每次压缩时增量更新。L2 层是最近的原始消息，保留最近几轮用户与助手的完整对话，因为最近的指令和状态最可能直接决定下一步操作。L3 层是工具输出区，这是压缩的重点，只保留摘要或者最后几行关键结果。

压缩执行时，优先压缩 L3 的原始输出，如果预算还不够，再压缩更早的对话轮次，把它们的细节合并进 L1 摘要里，而不是直接删掉。

这套分层逻辑的背后是一条信息价值判断原则：指令性信息大于事实性信息，事实性信息大于过程性细节，过程性细节大于原始输出。越靠后的内容，越可以被优先精简。

3.4 多轮压缩与信息衰减问题

一次长会话里，压缩很可能发生多次。第一轮压缩后，摘要成了新的长期记忆。等窗口再塞满，第二轮压缩需要对“摘要 + 新对话”再次概要。这时就出现信息衰减：原始对话里的细节经过多轮提炼，很容易丢失。

缓解信息衰减的办法有两个。一是摘要模板里强制包含“硬信息”字段，把文件路径、常量名、命令、版本号等不可变事实单独列出来，不允许模型用概括性的语言替代。二是在压缩次数达到上限后主动提醒用户开新会话，比如压缩超过三轮就提示：“当前对话已完成多次压缩，建议开启新会话以保持质量”。

承认压缩的极限，也是系统设计的一部分。

4. 实操：在 CLI 里落地生命周期管理

4.1 先会估算 token：不需要精确但要有手感

做压缩系统之前，你至少要能估算消息队列现在占了多少 token。精确的做法是接入模型自带的 tokenizer，但多数情况下不需要那么精细，一个快速估算函数就够用。

我常用的估算规则是：1 个 token 约等于 3 个字符。中英文混合场景下，这个系数有一定误差，但用来判断“是否接近阈值”完全足够。

function estimateTokens(text: string): number { return Math.ceil(text.length / 3); } function estimateMessagesTokens(messages: Message[]): number { let total = 0; for (const m of messages) { total += estimateTokens(m.content); } return total; }

等到系统上线后，如果预算允许，可以把估算函数替换成真实 tokenizer，但压缩逻辑的框架不用变。

4.2 设置双阈值触发压缩

压缩不能等到 100% 满再动手，那时候模型接口可能已经拒绝了请求。双阈值是我在实践中验证过比较稳的做法。

预警线设在 70%。超过这条线，不再只是记录日志，而是开始执行一些轻量处理，比如先压缩工具输出、合并重复消息。硬性线设在 85%。超过这条线，必须立刻进行一次完整压缩，否则下一轮请求就可能失败。

const WARN_THRESHOLD = 0.7; const HARD_THRESHOLD = 0.85; function getCompressionLevel(currentUsage: number, maxTokens: number): 'none' | 'warn' | 'hard' { const ratio = currentUsage / maxTokens; if (ratio >= HARD_THRESHOLD) return 'hard'; if (ratio >= WARN_THRESHOLD) return 'warn'; return 'none'; }

为什么预警线是 70% 而不是 50%？因为太早压缩会频繁触发模型摘要调用，增加耗时和成本。为什么硬性线是 85%？因为要给本轮请求留出生成回答的输出空间。输出 token 通常也计入窗口总预算，如果输入已经占到 95%，模型可能连写一句话的空间都不够。

4.3 压缩主流程：摘录、替换、重建

压缩操作的完整流程大概是：标记可压缩区间，调用模型生成结构化摘要，把旧消息替换成一条摘要消息，同时更新会话元信息。

我给出的核心伪代码如下：

interface Message { role: 'system' | 'user' | 'assistant' | 'tool'; content: string; isCompressible?: boolean; } interface SessionMeta { compressedRounds: number; lastCompressedAt?: number; } async function compressContext( messages: Message[], meta: SessionMeta ): Promise<{ messages: Message[]; meta: SessionMeta }> { // 系统级消息不可压缩 const compressible = messages.filter(m => m.role !== 'system'); const fixed = messages.filter(m => m.role === 'system'); const summary = await summarizeWithModel(compressible); const newMessages: Message[] = [ ...fixed, { role: 'system', content: `【会话摘要】\n${summary}`, isCompressible: false } ]; meta.compressedRounds += 1; meta.lastCompressedAt = Date.now(); return { messages: newMessages, meta }; }

注意压缩后的摘要消息也放在 system 角色里，而不是 user 或 assistant。这样模型会把摘要当作稳定的背景信息，而不是一段需要回应的对话内容，可以有效避免“回声问题”。所谓回声问题，就是压缩后模型总在复述摘要里的内容，而不是基于摘要继续执行任务。

4.4 工具输出是压缩的第一优先对象

工具返回的大块内容，应该按类型走不同策略。执行命令的原始输出，只保留最后几十行和退出码。测试跑出来的完整日志，只保留失败的测试名和堆栈的前几层。代码搜索的匹配结果，只保留文件名和匹配行号。错误信息则要原样保留，错误内容对后续调试至关重要。

这里有一个关键细节：工具输出压缩最好在它刚产生时就处理，而不是等窗口快满再统一压缩。因为原始输出留在内存里会持续占用预算，早压缩早释放。可以在工具执行结束后立即判断输出长度，超过预设上限就直接截断并写入 meta 信息，而不是把完整输出塞进消息队列。

4.5 会话恢复：快照与应用启动

长会话不可能永远驻留在内存里，用户可能会关闭终端、隔天继续。为了让上下文跨会话存活，压缩系统需要与快照机制配合。

我会在每次压缩后把消息队列、会话元信息、工作目录、最近执行的命令序列保存成一个 JSON 快照文件。恢复会话时读取快照，如果快照占用的 token 超过了新窗口的 70%，就先做一次额外收缩再载入。载入后不要直接继续对话，先注入一条系统提示：“以下是此前会话的摘要与最近状态，请基于它继续当前任务，不要复述摘要内容。”

这一步是很多实现容易漏掉的。快照里存了摘要，但如果模型不知道“接下来是基于快照继续而不是重新开始”，它的第一句话很可能变成“好的，这是一个新的对话”。

5. 常见问题与排查技巧实录

5.1 压缩后助手“失忆”，忘了用户约束

这是最高频的问题。压缩前用户说了“不要用枚举，用完就关闭”，压缩后摘要里写的是“用户提到了枚举和资源关闭”。问题就出在这个转述：模型接收到的是一句描述，而不是一条指令。

解决方法是要求摘要器对约束类内容使用祈使句，直接写成“用完后关闭资源”“禁止使用枚举”。我在摘要模板里加了一条规则：凡是检测到用户表达中带有“不要”“必须”“避免”“记住”等词，摘要中必须原样保留这些词，并转化为以动词开头的指令句式。

5.2 摘要丢掉了关键常量与路径

压缩模型为了追求简洁，很自然会把“/src/core/Engine.ts 中的 MAX_RETRY_COUNT”概括成“相关配置常量”。这对于后续执行任务来说毫无意义。

我给摘要模板加了一个“不可省略清单”字段，要求模型在处理命令、路径、文件名、常量名时不做任何改写，原样抄入清单。检查摘要时也以此清单为准，缺少一项就算压缩失败。这个规则看起来简单，但能极大减少因压缩导致的任务中断。

5.3 压缩频繁触发，又贵又慢

如果会话每几轮就触发一次压缩，说明阈值设置过低，或者压缩目标太大。每次全量摘要都要调用模型，耗时可能几秒到十几秒，非常影响体验。

更优的做法是分段处理：第一步先压缩工具输出，通常这一步就能释放大量预算；第二步再判断是否需要消息级摘要；最后才考虑多轮压缩。另外可以把摘要做成增量的，也就是每次只摘要自上次压缩以来的新增消息，再合并到旧摘要里，而不是每次把全部历史重新跑一遍。

5.4 如何验证一次压缩到底亏不亏

压缩质量是可以测的。我在测试时常用一个检查清单法：在压缩前，从原消息中人工挑出十条关键信息，包括目标、约束、路径、常量、下一步。压缩后，拿着这十条去新摘要里逐条查找，能找到才算通过。这个方法不依赖模型评估，简单直接。

更系统一点可以记录压缩前后的 token 数和任务完成率。压缩节省了 70% 的历史占用量，但导致任务完成率下降，这说明压缩取舍有问题，需要调整摘要模板而不是取消压缩。

5.5 排查速查表

5.6 一个让我印象很深的调试坑

压缩后的“回声问题”我实际调试过很久。第一次发现时，摘要确实完整，模型也记得关键信息，但每轮开头它都会把摘要里的目标、决策、约束重新念一遍，然后才开始干活。这导致每个回答都多出几百 token，而且显得啰嗦。

后来排查发现是因为摘要消息被塞进了 user 角色里。模型会认为这是一条需要回应的用户输入，于是本能地“针对摘要进行回答”。把摘要改成 system 角色后，问题立刻消失。这个经验看似小，但直接影响压缩后会话的体验，很多人没意识到。

6. 几句实际体会

反复调整压缩系统的过程中，我最大的感受是：压缩的本质不是“备份”，而是“重新叙事”。你要让模型记住的，不是过去发生了什么，而是接下来该怎么做。所以摘要的每一句话都应该面向执行，而不是面向回顾。

如果让我给初次实现的人一条建议，我会说：先把模板写好，再写代码。摘要模板决定了压缩质量的上限，而压缩流程只是执行这个模板的脚手架。模板里多花半小时，能省掉后面好几天的调试时间。

最后分享一个实用小技巧：压缩动作执行前，把旧的上下文快照保存在临时目录里，文件名带上时间戳。这样一旦压缩后发现质量崩了，还能回滚到压缩前的状态，重新调整策略再压一次。这个回滚能力在调试阶段能救你很多次。