分清项目文件、会话记录与发给模型的窗口；讲清单次输出截断、压缩触发、本地/远端路径与压缩后如何核对原要求。
任务做得越久，读过的文件、跑过的命令、用户补充的要求就越多。这些信息怎么保存？上下文满了怎么办？第三章讲 Codex 的上下文压缩。
先分清三样东西
- 电脑上的项目文件；
- 程序保存的会话记录；
- 这一次真正发给模型的请求内容。
三者常有关联，但不能画等号。文件在项目里 ≠ 模型读过；日志显示在界面上 ≠ 已进入模型请求。任务跑偏时，先查那条条件有没有进入当前请求，再讨论「模型没理解」。
一次请求里大致三类内容
- 基础指令：模型怎么工作；
- 当前上下文与历史：用户目标、刚读到的代码、上次工具结果、项目规则等；
- 工具定义：有哪些能力、参数怎么传。
只说「帮我改测试 bug」却没带上测试内容，就缺依据；能跑测试却没把上次报错带回，下一步就接不上。实际检查法：把当前请求拿出来看——要求、结果、可用工具是否对上，而不只看界面上的会话摘要。
两层体积控制：单次输出 vs 累积历史
真正容易撑大窗口的往往是工具输出（一次测试几千行日志）。整理整段历史之前，先控制单次输出体积：常见做法是留头尾、中间截断；具体工具还有自己的规则。一份结果变短，不代表整段会话不会变长——读文件、改代码、跑测试每步都加点记录，做久了会累加。
- 输出阶段：处理「这一次返回太多」；
- 上下文压缩：处理「已经积累起来的历史」。
被截断的细节若后面还要用，得有办法再查：缩小读取范围，或针对那条报错再跑一次查询。
何时开始压缩
不是每读完一个文件就压一次，也不必等到彻底放不下。请求开始前会检查已有历史是否达阈值，也会处理部分模型切换；这是对当时已有信息的检查，不能理解成发送前已精确算完所有新增内容、绝对不超限。任务跑起来后，在本轮仍需继续的前提下，达阈值或收到明确压缩请求，就进入压缩流程；整理成功后再准备后面的模型请求。压缩也可能失败或被取消——不能把失败结果当正常可用历史继续跑。
两条常见路径：本地压缩与远端
本地压缩：客户端组织流程，把已有历史与摘要要求交给配置的模型，拿回整理后的内容，再组装后续要用的记录——描述的是「谁组织这段流程」，不是规定模型部署在哪里。
远端路径：客户端发起压缩请求，拿回压缩条目，再结合保留规则与预算组装后续历史——不能简单理解成服务端丢来一整份聊天记录客户端直接用；压缩条目也不一定是人类可读的摘要。「压缩＝让模型写一段总结」只是其中一种做法。
要看懂的是：谁发起压缩、返回什么、谁准备下一次请求要用的内容。
压缩后历史长什么样
以本地路径为例：常保留预算内较新的用户消息，加上整理出的摘要，组成替换后的历史；当前指令也可能有重新注入。一份能接上的工作记录，至少应说清：要改什么、哪些行为不能变、动过哪些文件、做过哪些验证。压缩让后面请求更短，也可能遗漏——尤其「旧接口不能变」这种只提过一次的约束；反复提到的信息更易保留。
旧记录不是一压缩就全删：模型眼前窗口与程序持久记录是两件事。Codex 会记压缩检查点（含重建用的替换历史）；恢复时可从有效检查点接着处理后续事件。持久记录也不是包罗万象的原始录像——工具输出可能早被截断，事件保存受策略影响，不能承诺随时找回每一行原文。
压缩后如何接着修 bug
同时要保留旧接口行为、前面已改过判断、测试还没确认——这时发生压缩，后面应：核对原要求；看工作区实际改了什么（摘要写「已修改」就去看差异；写「已验证」却找不到证据就不能当通过）；旧接口有没有对应用例覆盖。信息够就接着验证；缺关键内容就重读文件或记录；测试结果找不到就确认运行状态再决定是否重跑。这是 Agent 工程上的核对规范，不是所有工具都会自动完成的核验。
四个排查落点
- 发送请求时：哪些要求与结果进了模型；
- 工具返回时：哪里限制了输出，截掉的内容还能怎么查；
- 需要压缩时：什么条件触发、换成了哪份记录；
- 接着做时：拿原要求与实际文件核对。
跑偏了就能区分：要求没写进去、工具结果太长被截断，还是整理时漏掉关键条件——处理方式各不相同。
下一期讲多 Agent 协作：任务怎么拆、给子 Agent 哪些信息、结果怎么收回并核验。