企业官网建设流程全解析

一、先给结论：自动压缩不是“删聊天记录”，而是 Agent 的记忆调度系统

很多人使用 AI 编码工具做长任务时，会遇到一个很典型的现象：前面刚说好的约束，后面突然忘了；刚修过的错误，过一会儿又重新犯；已经否定过的方案，又被重新提出来。表面看像是模型变笨了，实际上更常见的原因是上下文窗口快满了，系统开始把旧历史折叠成摘要。

这套机制的目标不是简单省 token，而是在有限窗口里做一次“记忆再分配”：哪些内容必须保留，哪些内容可以折叠，哪些内容需要从文件和附件里恢复，哪些失败场景必须立刻止损。

可以把它理解成一个高级项目经理：它不可能把每一句话都原封不动带到下一轮，但必须记住任务目标、关键文件、已踩过的坑、用户明确要求、当前进度和下一步方向。

1.1 为什么长会话一定需要压缩

大模型每次回答都要读取当前可见上下文。对话越长，文件越多，工具结果越密，窗口压力就越大。到了临界点之后，系统只有三条路：第一，直接失败；第二，粗暴丢掉旧内容；第三，把旧内容压缩成高密度摘要，再继续工作。真正可用的 Agent 系统一定会选择第三条路。

优秀的上下文压缩必须同时解决四个问题：触发时机要稳，摘要质量要高，失败后能恢复，用户要能干预。只要少一个环节，长任务就容易出现“越聊越乱”的情况。

1.2 一句话讲透本专题主线

自动压缩的本质，是在上下文窗口快满之前，把长历史浓缩成结构化摘要，并重新挂载关键文件、计划、工具和状态，让下一轮模型像接班人一样继续干活。

二、阈值判定：什么时候开始自动压缩

自动压缩最重要的第一个问题是：什么时候触发？太早触发，会丢掉还没必要丢的信息；太晚触发，会撞上输入过长错误，甚至连压缩请求本身都发不出去。

这套设计没有把上下文窗口全部拿来塞对话，而是预留出两块空间：一块给摘要输出，一块给当前轮可能新增的工具结果和系统消息。这样看起来“少用了一点窗口”，但换来的是稳定性。

2.1 三层预算：原始窗口、摘要预留、安全缓冲

以 200K 上下文窗口为例，系统会先扣掉最多 20K 的摘要输出预留，再扣掉 13K 的自动压缩安全缓冲。这样得到的默认触发点大约是 167K，也就是窗口的 83.5% 左右。

2.2 为什么不是 95% 才压缩

很多人会觉得：窗口不是 200K 吗？为什么不用到 195K 再压缩？原因很现实：长任务不是静止的。模型可能还会调用工具，工具结果可能非常大，系统还要追加附件、状态、指令、钩子结果。等到窗口已经快满再处理，就像等车快撞墙才踩刹车。

所以默认触发点看似保守，其实是为了留出“刹车距离”。自动压缩不是单纯追求窗口利用率，而是追求长任务连续性。

2.3 环境变量为什么只能让压缩更早，不让压缩更晚

一些高级使用者可以通过配置改变触发策略。比如限制可见窗口，或者按百分比让压缩更早发生。但这类覆盖通常采用“取更小值”的原则：可以更早压缩，不能把默认安全阈值推得更晚。

这个设计很像高速路限速：你可以更保守地开慢一点，但不能随便把安全限速提高。尤其是在 CI、网络慢、预算敏感、工具结果特别大的场景里，更早压缩反而更稳。

三、前置守卫：自动压缩不是一个简单 if 判断

真正的工程系统里，触发压缩不能只看 token 数。因为有些来源不应该压缩，有些实验模式已经接管上下文管理，有些用户明确关闭了自动压缩，还有些场景压缩会破坏正在构建的状态。

3.1 防递归：压缩请求不能再次触发压缩

如果压缩任务本身又触发压缩，就会出现递归：为了压缩而压缩，越处理越复杂。因此来自 session_memory、compact 等内部来源的请求，会直接跳过自动压缩。

这个细节很关键。很多 Agent 系统出问题，不是因为不会做功能，而是因为没有区分“用户请求”和“系统维护请求”。系统维护请求必须有特权通道，不能被普通业务逻辑再次处理。

3.2 防抢跑：不同上下文策略不能互相打架

有些机制会在 90% 左右开始准备保存细粒度上下文，有些机制会在更靠后的节点做阻塞处理。如果自动压缩提前抢跑，就可能破坏另一套机制刚刚准备好的上下文。

因此，当更高级的上下文管理策略接管时，传统自动压缩会让位。这体现了一个非常重要的工程原则：同一个资源只能有一个主调度者，否则状态会被两个系统来回改写。

3.3 开关体系：允许用户关闭，但必须知道代价

自动压缩可以被关闭，但关闭并不代表窗口限制消失。关闭后，使用者需要自己管理上下文，否则长任务很容易直接遇到输入过长问题。换句话说，关闭压缩不是获得更多空间，而是拿走安全气囊。

四、熔断器：连续失败时，宁可停下来也不要空转

自动压缩最危险的失败模式，是压缩之后仍然过大。下一轮又触发压缩，压缩后还是过大，于是进入“压缩 - 失败 - 再压缩 - 再失败”的死循环。

资料里提到过一个非常典型的规模问题：存在大量会话连续失败很多次，甚至有单个会话连续失败数千次，造成海量 API 调用浪费。这说明熔断器不是锦上添花，而是生产级 Agent 的必需品。

4.1 为什么连续失败 3 次就要停

如果一次失败，可能是偶发网络、响应异常或临时窗口压力；如果连续两次失败，已经说明问题比较严重；如果连续三次失败还无法恢复，大概率不是重试能解决的，而是上下文里存在大量不可压缩内容、超大附件、编码数据或结构性膨胀。

这时继续自动重试，只会烧钱、占资源、拖慢用户体验。更好的选择是停下来，把控制权交还给用户：要么手动压缩，要么切换新会话，要么先清理上下文。

4.2 熔断器体现的工程智慧

很多人设计 Agent 时喜欢加“重试”，但成熟系统一定会给重试加边界。没有边界的重试，就是自动化事故。熔断器让系统在不可恢复场景里及时承认失败，从而保护整体稳定性。

五、摘要模板：为什么高质量压缩需要 9 段结构

压缩不是把历史随便概括成几句话。对 AI 编码任务来说，最值钱的信息往往藏在细节里：用户为什么否决某个方案、哪个文件刚刚修改过、哪个错误已经修复、当前做到哪一步、下一步是否真的符合最新指令。

因此，高质量压缩需要结构化模板。模板越清楚，模型越知道哪些内容必须保留，哪些内容可以省略。

5.1 第一段：显式请求与真实意图

长任务里，用户会不断补充要求。如果摘要只保留“做一个功能”，却忘了“不要改接口”“保持兼容”“优先修测试”，后续执行就会偏离方向。第一段的任务，是把用户明确说过的目标和约束压住。

5.2 第二段：关键技术概念

技术概念是对话的骨架。比如使用哪套框架、遵循哪种架构、涉及哪些模块、采用哪种状态管理方式。如果骨架丢了，后面的回答就会变成泛泛建议。

5.3 第三段：文件与关键片段

AI 编码最怕“知道大概，但不记得具体”。文件名、函数签名、关键片段、修改位置，这些都是继续工作的锚点。摘要模板会要求尽量保留关键片段，而不是只写“改了某个文件”。

5.4 第四段：错误与修复

调试历史是非常宝贵的记忆。一个错误为什么发生，如何修复，用户对哪个方案不满意，这些信息一旦丢失，模型就很可能重复犯错。

5.5 第五段：问题解决过程

只保留结果不够，还要保留解决过程。因为复杂任务往往需要接着做判断：为什么选方案 A，不选方案 B；哪些路径已经试过；哪些限制仍然存在。

5.6 第六段：全部用户消息

用户消息比工具结果更高优先级。工具结果可以重新读取或重新计算，但用户明确说过的偏好、禁止事项、验收标准，一旦被省略，就会导致后续执行不贴合需求。

5.7 第七段：待办任务

待办任务必须只来自用户明确要求。不能因为模型自己猜测“可能还要做什么”，就在摘要里塞入额外任务，否则后续可能越做越偏。

5.8 第八段：当前工作状态

当前工作状态决定下一步从哪里接上。比如“已经完成 A，正在处理 B，C 还没验证”。如果这部分不精确，下一轮就会像换了一个完全不了解进度的人。

5.9 第九段：下一步建议

下一步必须直接对齐最近的显式请求，不能凭空扩展。这个限制很关键，因为压缩后模型容易把历史里的旧目标和最新目标混在一起。

六、草稿块与禁止工具：压缩时只允许认真总结，不允许乱动

压缩请求通常会要求模型先在内部草稿区按时间顺序梳理，再输出最终摘要。这样做的目的，是让模型逐段检查对话，减少遗漏。但草稿内容不会作为后续上下文保留，真正留下的是整理后的摘要。

同时，压缩请求会反复强调不要调用工具。原因很简单：压缩只有一轮机会，如果模型这时去读文件、跑命令、调工具，工具调用被拒绝后可能没有有效文本输出，整个压缩就失败。

6.1 为什么要先按时间顺序梳理

长对话里的信息不是平铺的，而是逐步演化的。用户可能先提出目标，再否定方案，再补充限制，再修正方向。按时间顺序梳理，能保留这种演化过程，避免把早期想法误当成最终决策。

6.2 为什么压缩阶段不应该调用工具

压缩阶段的职责只有一个：把已有上下文整理好。它不是继续开发、不是继续搜索、不是继续修改文件。如果允许它调用工具，就会把“记忆维护”和“业务执行”混在一起，失败概率会明显上升。

七、执行流程：压缩不是生成摘要就结束

真正的一次压缩包含多个步骤：执行压缩前钩子、构建提示、发送请求、处理输入过长、校验摘要、清理旧文件状态、重新生成附件、执行启动钩子，最后才把结果送回主循环。

7.1 先清空，再恢复：为什么要“先忘后想起”

压缩完成后，系统会清理旧的文件读取缓存，再把最关键的文件重新挂载回来。这样看起来绕了一圈，其实非常稳。因为让模型在摘要里记住所有文件内容是不可靠的，而重新读取关键文件是确定性的。

这也是上下文工程的核心思想：不要把所有东西都塞进摘要；对可重新获取的信息，尽量用确定性恢复；对用户意图、已踩坑、当前状态这类难以重读的信息，才重点写入摘要。

7.2 附件恢复解决什么问题

压缩会折叠旧历史，也会影响之前注入的工具声明、技能列表、计划信息、MCP 指令等上下文附件。如果压缩后不重新注入这些内容，模型第一轮就可能不知道自己有哪些工具、当前计划是什么、项目有哪些固定规则。

所以压缩后的恢复不是可选动作，而是让新上下文重新具备工作能力的关键。

八、消息结构：旧历史如何变成新的上下文

压缩后的消息队列通常由几类内容组成：边界标记、摘要消息、近期保留消息、恢复附件、钩子结果。它不是把旧内容全部删光，也不是把所有历史塞成一个摘要，而是分层重组。

8.1 边界标记：告诉系统这里发生过折叠

边界标记的价值，是让后续逻辑知道：前面那段长历史已经被压缩过。它像一本书里的折页，告诉读者旧内容不是不存在，而是被浓缩到了摘要里。

8.2 摘要消息：新的长期记忆入口

摘要消息承担“接班说明书”的作用。后续模型看不到完整旧历史，但能看到这份说明书。说明书越结构化，接班越顺滑；说明书越模糊，后续越容易跑偏。

8.3 近期保留消息：让最新上下文不被摘要稀释

最近几轮消息通常信息密度最高，尤其是用户刚刚提出的新要求、刚刚出现的错误、刚刚修改的方向。因此部分压缩会把近期消息原样保留下来，再把更早内容折叠成摘要。

九、PTL 重试：当“压缩请求本身”也太长

极端长会话会遇到一个很尴尬的问题：对话太长需要压缩，但把完整对话拿去压缩时，请求本身也超出输入上限。这个情况通常称为 prompt_too_long。

解决方式不是硬发，而是按 API 轮次从头部丢掉最旧内容，再重新尝试压缩。

9.1 为什么按 API 轮次分组，而不是按消息条数乱切

工具调用一般是成对出现的：模型发出工具请求，随后得到工具结果。如果从中间切断，只保留请求不保留结果，或只保留结果不保留请求，后续上下文会变得不完整。

按 API 轮次分组的好处，是尽量保持交互原子性。丢弃的时候丢整组，保留的时候保留整组，避免破坏工具链路。

9.2 token 差额优先，20% 回退兜底

如果错误信息能解析出还差多少 token，系统会从最旧组开始累加，直到丢掉足够多的内容。如果解析不到差额，就采用丢弃 20% 旧轮次的回退策略。

这是一种典型的工程折中：能精确就精确，不能精确就用保守启发式，目标是让系统继续前进。

9.3 最多 3 次，仍失败就明确告诉用户

PTL 重试也有上限。最多重试 3 次，如果仍然失败，就说明上下文已经太长，需要用户回退、手动整理或开启新会话。成熟系统不会假装什么都能自动恢复。

十、主循环编排：每一轮都在做上下文体检

自动压缩并不是偶尔运行的小工具，而是被主循环在每轮迭代中检查。它会先看是否禁用，再看是否熔断，再判断是否超过阈值，然后优先尝试更细粒度的 Session Memory 压缩，最后才回到传统摘要压缩。

10.1 为什么先尝试 Session Memory

传统摘要压缩像是把旧历史折叠成一份接班文档，而 Session Memory 更像是对记忆做局部整理。能用更细粒度的方式释放空间，就不必立刻做大规模折叠。

这体现了一个非常重要的设计方向：未来的上下文管理会越来越像“内存管理器”，不只是简单摘要，而是按价值、时效、可恢复性来调度信息。

10.2 遥测事件为什么重要

压缩成功、失败、PTL 重试，都需要被记录。否则系统只会在用户抱怨“怎么变笨了”时才发现问题。可观测性让团队能看到压缩是否频繁失败、是否浪费预算、是否在某些模型或场景中特别不稳。

十一、使用策略：怎样让长任务更稳

理解自动压缩机制后，普通使用者也能做很多优化。最核心的一点是：不要等系统被迫压缩，而是在任务自然断点主动整理。

11.1 在子任务结束时主动压缩

比如完成一个模块重构、修完一批测试、确认一个方案之后，可以主动压缩，并补充保留重点。这样摘要会围绕你关心的内容生成，而不是在窗口快满时被系统紧急处理。

11.2 把长期约束写进稳定记忆

一些不应该丢的信息，比如项目规范、技术栈偏好、禁止使用的库、固定命令、测试环境要求，适合写入 CLAUDE.md 或自动记忆文件。它们不应该只靠对话历史保留。

官方资料提到，自动记忆会使用 MEMORY.md 作为索引，启动时加载前 200 行或前 25KB，并把更详细的内容放进独立主题文件。这个设计说明了一个重要原则：稳定记忆也要保持精简，不能把它变成新的上下文垃圾场。

11.3 不要把所有内容都塞进摘要

摘要适合保留不可轻易恢复的信息，比如用户意图、技术决策、错误历史、当前状态。文件内容、工具列表、计划附件这类可重建内容，更适合在压缩后重新注入。

11.4 对关键偏好要显式表达

如果你非常在意某个约束，比如“不要改公共接口”“保留兼容性”“错误修复记录必须保留”，就应该在主动压缩时写清楚。越明确，越容易被保留下来。

十二、哪些信息最容易在压缩后丢失

压缩不是无损复制。它一定会选择性保留信息，因此有些内容天然容易丢。了解这些风险，才能提前防护。

十三、版本演进：从热压缩到冷治理

从演进方向看，上下文压缩正在从“窗口快满时紧急救火”，逐渐走向“有节奏、有开关、有用户确认、有状态提醒的控制平面”。

13.1 文件状态陈旧提示：别让模型相信过期读取

当工具执行过程中修改了之前读取过的文件，系统可以提示模型：你记住的文件状态可能已经过期。这个能力和压缩后的文件恢复形成互补：压缩解决长期记忆，陈旧提示解决单轮即时性。

13.2 冷压缩：不一定要等到火烧眉毛

热压缩是在上下文快满时紧急触发，冷压缩更像是延迟到更合适的断点执行。前者强调及时救火，后者强调用户体验和任务节奏。

13.3 快速回填熔断：防止刚压完又被塞满

如果刚刚压缩完，用户或工具结果又在很短时间内把窗口塞满，系统可能进入“压缩 - 回填 - 再压缩”的抖动。快速回填熔断器就是为这种场景准备的：牺牲一次自动压缩机会，换取系统稳定。

十四、企业级 Agent 系统可以借鉴什么

这套机制不只适用于 AI 编码工具，对企业级大模型应用同样有参考价值。比如智能客服、研发知识库、金融问答、工单助手、数据分析 Agent，都需要长会话记忆治理。

14.1 把上下文分成四类

14.2 给摘要设计固定字段

企业级系统不要依赖一句“请总结对话”。应该设计固定字段，比如用户目标、业务实体、已确认信息、失败原因、待办任务、当前状态、下一步动作、风险提醒。固定字段能显著提升恢复质量。

14.3 给自动压缩加可观测性

至少要记录压缩前 token 数、压缩后 token 数、触发原因、失败原因、重试次数、摘要长度、用户是否中断。没有这些数据，就无法判断压缩策略到底是帮忙还是添乱。

14.4 给失败加熔断和人工入口

失败重试必须有上限。连续失败后，系统应该明确提示用户：当前上下文已经不适合自动恢复，可以选择手动摘要、导出任务状态、开启新会话，或者删除不必要的附件。

十五、总结：会压缩的 Agent，才跑得了长任务

长上下文不是无限记忆。真正可靠的 Agent，不是把所有历史都塞给模型，而是持续判断哪些信息值得留下、哪些信息可以折叠、哪些信息应该重新读取、哪些失败必须及时止损。

自动压缩的核心价值，可以总结为五句话：

第一，阈值不是随便定的，而是由摘要预留、安全缓冲和有效窗口共同决定。

第二，摘要不是简单概括，而是带有明确字段的结构化接班文档。

第三，压缩不是结束，还要重新挂载关键文件、计划、工具、技能和状态。

第四，PTL 重试和熔断器保证系统在极端场景下不会无限空转。

第五，用户越会主动管理上下文，长任务越不容易跑偏。

未来的 AI Agent 竞争，不只是模型参数和工具数量的竞争，更是上下文工程能力的竞争。谁能把记忆、预算、缓存、文件状态、错误恢复做成一套稳定系统，谁就能让 Agent 从“短问短答”走向真正可持续的复杂任务执行。

资料参考：https://pan.baidu.com/s/1Fm6rZSZkY3q2NcrmTfTMeQ?pwd=6fkr