第六章：上下文怎样组织、压缩与复用
简报已经能按反馈推进。现在扩大教学情境：助手还读了很多背景材料，用户后来补充“只收本周原公告”。下一轮输入越来越长，最新要求、旧资料和重复内容混在一起，模型可能采用了不该使用的材料。
问题不只是“模型能装多少文字”，还包括程序把哪些信息放在什么位置、怎样保留任务进度，以及省略以后还能否找回。本章会把选择、压缩、检索与缓存分别解释。
本章的产物是一份压缩前后对照：你需要指出哪些事实、条件和待办必须保留，哪些内容可以缩短，哪些应留下定位线索。
6.1 输入有容量，保存可以更长
第三章已经区分磁盘材料与本轮输入。模型接口对一次请求所能处理的信息有范围，常用 token 计量。你可以把 token 理解为模型计量输入和输出的单位，它不与汉字或单词固定一一对应。
很多工具返回、长网页、历史消息和工具说明一起进入请求，会增加占用。还要考虑后续输出需要的空间；不能把窗口理解成所有位置都能留给旧正文。
把所有资料永久塞进每次请求，简单却有三种代价：容量可能不够，重复处理会增加开销，旧内容还可能混淆当前范围。即使模型窗口更大，也仍然需要组织信息。
6.2 先选择，再考虑怎样缩短
先确定下一步需要什么。在简报任务里，持续目标、本周范围、已确认事件、冲突、尚未取得的材料，分别承担不同作用。
| 内容 | 应保留的东西 | 可以缩短或移出的部分 |
|---|---|---|
| 用户新要求 | 本周、原公告、只形成草稿 | 重复表达的修饰语 |
| A 的正文 | 纯文本导出、图片限制、材料标识 | 与本任务无关的背景介绍 |
| A 与 B 的冲突 | 同一事件、相反说法、采用哪项依据 | 多次重复粘贴的相同段落 |
| 已经失败的读取 | 失败原因、已尝试办法、当前缺口 | 没有新信息的重复日志 |
| 旧周草稿 | 必要时的定位线索 | 不能当成本周事实的旧正文 |
选择首先是任务判断，不能用“最近的都留、早的都删”代替。最早的用户约束可能仍然关键，最新工具结果也可能只是一长段无关内容。
6.3 压缩不是删掉中间一大块
压缩是把部分材料改成更紧凑的表示，同时尽量保留继续任务所需的信息。它可能使用摘要，也可能先精简过大的工具结果；不同策略的代价不一样。
一个坏摘要可能写：“资料已查完，接下来写三条。”它把数量不足、图片限制和冲突都丢了。一个更有用的摘要应写清：A、B 是同一事件，A 只支持纯文本；C 是第二件事；没有第三件；交付时说明不足。
摘要还要区分“取得”“判断”和“尚未完成”。若把“准备核对 B”写成“B 已核实”，后续会继承一份错误进度。压缩改变的不只是文字体积，也可能改变任务认识。
消息结构为什么不能随便切断
模型提出的工具调用与相应结果有对应关系。只留下结果，丢掉它回答的是哪项请求，可能把正文归给错误来源；只留下调用，没有实际返回，又可能让程序或模型误判执行状态。
因此，压缩需要照顾消息结构和关键锚点，而不仅按字符长度截一段。最近行动、真实用户要求和可恢复的来源线索，也需要有明确保留策略。
6.4 Hermes 在什么时候整理上下文
本版 Hermes 将上下文管理组织为可替换的上下文引擎，默认实现负责判断压力、执行压缩和跟踪用量。配置可以选择不同实现，但可替换不表示任意插件会自动启用。
触发也不只发生在一个固定位置：入口处积累的会话历史，与当前循环里新增加的大工具结果，是不同来源的压力。系统既要处理正常的容量管理，也要应对模型服务实际拒绝过大请求的情况。
判断压力时，服务回报的用量与本地估计各有作用；模型容量、预留输出、配置阈值、刚完成压缩的状态及失败后的保护，也会影响是否继续整理。不能用“超过某个长度就一定压缩一次”概括全部路径。
在普通主流程中，较早的材料可以被总结，关键起始信息与必要的近期材料得到保护。压缩后的表示还会保留恢复线索，以便需要时查询原历史。具体保留策略随配置与调用路径不同，不应把一张教学前后图当成唯一固定算法。
6.5 压缩失败，不能假装已经腾出空间
生成摘要也可能依赖模型服务，可能超时、失败或得到不合格结果。系统需要区分“尝试过整理”和“已经提交新上下文”。
本版有针对失败、无进展和真实溢出的处理路径；部分情况保留原材料并延后重试，某些条件下可以采用确定性的降级摘要。降级意味着取舍发生了变化，不能一概宣称信息完整无损。
这里最重要的状态是：当前实际使用哪份材料，原始记录是否还在，整理有没有成功，以及哪些细节可能需要重新取得。若压缩没有完成，却按“已释放容量”继续追加内容，后续请求仍可能失败。
6.6 四种办法，各自解决什么
| 办法 | 主要作用 | 需要承担的代价 |
|---|---|---|
| 保留原文 | 直接呈现细节与条件 | 输入体积和重复处理成本 |
| 形成摘要 | 用较短材料承接任务 | 可能遗漏、误写或混淆状态 |
| 按需检索 | 需要时找回相关部分 | 依赖检索命中、定位与核对 |
| 提示词缓存 | 复用符合条件的重复计算 | 依赖提供方、前缀内容与顺序 |
缓存不会替我们挑选材料，也不会自动扩大逻辑窗口。它可能让相同前缀的处理更省，但错误信息被重复使用仍然是错误信息。
压缩则改变本轮带入的信息，即使模型服务完全不支持缓存，也仍可能需要它。检索与压缩可以配合：摘要保留任务脉络，遇到争议再根据定位线索找回原文。这样减少常驻输入，同时增加了恢复查证的责任。
这也解释了为什么第七章要讨论会话保存。若原始过程已经不可找回，摘要丢掉的细节就很难重新核对。
6.7 为简报保留一个最小工作状态
请把当前任务压成四项：目标与范围；已确认事件及条件；材料定位；未解决问题。再故意给自己一个反例：“用户现在要求解释为什么没有采信 B。”
如果摘要只写“两条草稿已完成”，无法回答这个反例。若保留 A、B 的关系、图片冲突以及原材料编号，就能决定是否直接解释或重新读取。
好的压缩不是保证以后永远不用回看，而是既能支持接下来的工作，也知道什么时候需要回看、回到哪里。
本章要点
- 当前输入容量、持久保存范围和重复计算成本是不同问题。
- 选择材料应围绕目标、证据、进度与缺口，不能只按时间远近处理。
- 压缩会改变任务表示，必须保护关键条件、调用对应关系和恢复线索。
- Hermes 在不同运行位置处理上下文压力，并区分整理尝试、成功提交与失败降级。
- 原文、摘要、检索和缓存可以配合，但没有一种办法单独解决所有问题。
理解题
1. 摘要保留了“两条草稿已完成”，却没保留 A、B 的冲突，主要损失是什么？
损失了结论的范围和判断依据。后续追问为何排除 B 时，模型只知道结果，不知道原因；还可能把 B 当成未读的新事件。应保留冲突、选择理由与材料定位，必要时重新读取原文。
2. 提供方支持提示词缓存，是否就不再需要上下文压缩？
仍可能需要。缓存主要复用重复计算，逻辑输入仍然占用窗口；压缩改变带入的信息。是否需要压缩，要看容量、任务材料和运行状态，不能由缓存开关直接推断。
3. 压缩尝试失败，但原历史仍存在，下一步首先检查什么？
检查当前实际使用的上下文、失败原因和容量状态，确认新表示有没有提交。然后再按支持的恢复条件决定延后、重试、取回材料或说明限制。不能把“已尝试压缩”当作“已经成功释放空间”。
下一章：对话结束后，状态保存在哪里。