机制分析
档案完整，不保证这次输入完整
场景是修复 largest(values)。当前 v1 已修复全负数，但空列表仍返回 undefined，任务要求返回 null，而且固定验收用例不能修改。即使读者没有看过修复过程，这几项事实也足以确定本轮还需要完成什么。
档案架上的六类原始材料共43个教学单位，输入预算只有12。全部放入会超限；只保留一张“负数已经修好”的摘要又会漏掉空列表约定和修改范围。前者容量不够，后者必要信息不够，两种失败不能用同一个“压缩率”解释。
| 材料组织 | 保留了什么，缺少什么 |
|---|---|
| 全部原始材料 | 历史丰富，但本例输入超过容量预算 |
| 任务与简短摘要 | 体积变小，空列表约定和约束可能遗漏 |
| 摘要与来源指针 | 知道去哪里查，仍没有取得具体证据 |
| 约束、状态与关键摘录 | 本轮持有可核对的失败证据，再分别检查容量与信息 |
指针解决定位，摘录解决本轮可见
来源指针指向 T-EMPTY · v1，说明相关记录在哪里；回查读头打开原文，才得到输入为空列表、预期 null、实际 undefined 的差异。把这段摘录放进输入后，本轮才拥有这份证据。原件仍留在档案架，整理改变的是选取的副本。
本页的核对器按固定规则检查必要信息，不是让模型自动证明摘要无损。两项检查都通过，只能说明这个输入满足本例前置条件，不能保证后续回答一定正确。
工程取舍
预算有限时，先保留什么？
保留过程，还是保留状态？
重复尝试和旧补丁有审计价值，却未必都适合放进每一轮输入。当前代码版本、未解决问题、有效约束通常更接近下一步决策。可以把详细过程留在外部，用摘要交代状态，并保留能回到关键证据的路径。状态摘要也要随工作更新，避免新代码仍配着旧失败说明。
先写摘要，还是需要时再回查？
预先放入更多摘录会增加输入成本，按需回查则增加延迟和一次定位失败的机会。稳定而关键的约束适合直接保留；体积大、只在某一步需要的记录可以先保留指针，再在使用前取回。来源不可访问或权限失效时，指针本身不能填补证据缺口。
容量预算与信息预算怎样一起管理？
只按长度裁掉最早记录，很容易删掉任务原约定；只按“相关”累加材料，又可能超过窗口。实现时可以先保留不可丢的任务条件与当前状态，再分配检索和历史片段的空间，并为工具返回和模型输出预留容量。本页单位是教学权重，真实请求还需按实际接口计算 token 及适用限制。
落到实现
整理过程应当留下可回溯的关系
一份可检查的上下文记录，需要知道摘要对应哪个任务状态、摘录来自哪里、属于哪个代码版本，以及发送时实际选择了哪些材料。发现模型遗漏要求时，就能区分摘要漏写、回查失败和装配遗漏，分别修复。
本例讨论同一任务中的输入整理，不处理跨会话存储，也不展示推理引擎的 KV Cache。摘要和模型建议是预设，容量与缺口检查依据实际选择执行。材料进入输入以后，仍需由后续执行和验证来判断任务结果。
“装得下”只解决容量问题。能够继续工作的上下文，还需要保留决定下一步所必需的事实，以及回到原始证据的路径。