第五章：上下文有限，应该留下什么
简报任务已经读了十几份材料，用户又补充：“只讨论已经发布的变化。”如果这条约束淹没在旧网页和重复检索里，Agent 即使查到了最新资料，也可能写错范围。
问题从“能不能拿到信息”，变成了“下一次模型请求实际能读到什么”。这就是上下文管理要解决的问题。
5.1 硬盘上的资料不是模型的全部上下文
上下文（Context）指当前一次模型请求中实际提供的信息，可能包括系统说明、任务、历史、工具描述和工具结果。模型处理输入的容量有限，常用 token 计量；token 与汉字或单词并不一一对应。
文件保存成功，不意味着下次请求自动把文件读入；历史留在数据库，也不意味着模型每次都读到完整历史。程序要选择、组织和带入材料。第六章讨论跨会话保存，本章先处理当前请求。
5.2 用“对下一步是否有用”筛选材料
下面是一份教学示意的简报中间记录：
| 材料 | 下一轮的用途 | 处理方式 |
|---|---|---|
| 用户要求只看稳定发布 | 决定收录范围 | 清楚保留 |
| 已确认的版本、提交和链接 | 支持结论并定位原文 | 保留事实与定位信息 |
| 同一个错误重复二十次 | 对新判断帮助有限 | 合并错误原因与处理结果 |
| 尚未核实的机制变化 | 决定后续行动 | 保留为待办与不确定项 |
如果只保留“最终结论”，可能丢掉为何相信它；如果只留原始日志，信息又过多。有效上下文需要同时保留目标、证据、状态和缺口。
5.3 压缩会减少体积，也可能减少细节
上下文压缩（Compaction）可以精简或总结较早材料，为后续行动留出空间。Hermes 的上下文管理与压缩机制还会处理消息结构、工具调用与结果的配对等约束，不能随意把历史按字符截断。
压缩得到的“已经核对过源码”仍然不如一个具体提交、路径和结论可靠。摘要可能省略版本、否定条件或失败原因。因此，重要依据需要保留可找回的线索；遇到争议时能够重新读取原文。
5.4 缓存与压缩解决不同问题
提示词缓存（Prompt Cache）让提供方在符合条件时复用输入前缀的计算，具体规则依赖服务。它不负责替你挑选正确材料，也不会自动把窗口变大。
压缩改变带入的信息；缓存关注重复计算的复用。前者可能损失细节，后者受前缀稳定性和提供方行为影响。Hermes 在组织系统提示、上下文与压缩时需要兼顾这些条件，但不能因此宣称任意任务都有固定倍数的成本下降。
对简报来说，先确保版本约束和来源在场，再优化重复输入。错误材料即使被便宜地重复处理，也仍然是错误材料。
不写代码的小练习
找一段包含目标、重复材料、一个已确认事实和一个疑问的任务记录，将它压成五行摘要。再让自己只凭摘要复述范围和来源：找不回的信息，就是压缩时需要重新考虑的内容。
本章要点
- 上下文是本次实际输入，保存过的信息需要经过选择才能进入判断。
- 任务约束、已确认事实、来源定位和未解决问题都值得保留。
- 压缩有信息损失，工具调用与结果的结构也要保持有效。
- 缓存复用计算，压缩控制信息体积；两者都不能代替事实核查。
理解题
1. 摘要写着“版本已确认”，但没有版本号和链接，够吗？
对后续需要引用版本的任务不够。应该保留具体版本、提交或原始记录的定位方式，必要时重新检查。把过程压成一句确认，会丢掉可验证性。
2. 模型窗口更大，是否就不需要选择材料？
仍然需要。更大窗口提供容量，不保证模型能稳定识别所有关键约束；无关与矛盾材料也会增加成本和解释难度。选择材料是任务组织问题，不只是容量问题。
对照官方实现
当前请求的信息整理好了，下一次全新对话又怎样找回需要的东西？