长会话管理与衰减应对
一句话定义
长会话会随轮次累积噪声与冲突约束，表现为「遗忘早前约定、重复解释、答非所问」；应对之道是把关键状态落盘、定期摘要重开，而不是无限续聊。
为什么重要
「一个会话从早聊到晚」是上下文准备中最隐蔽的损耗：每轮对话都是新增材料，旧约束被稀释，中途放弃的方案继续占预算，质量缓慢滑坡且难以归因。会话管理把窗口视为要主动维护的资源——何时压缩、何时重开、重开带什么——这些决定让长任务保持全程高质量。
前置知识
kp-008（上下文包准备清单）。
核心概念
- 衰减信号（出现两条就该行动）：模型重复问你已回答过的问题；无视早前给出的约束；开始在旧方案上打转；输出风格漂移；相同输入给出明显劣化输出。
- 状态落盘：把会话中「进化出的关键决策」（选定的方案、新约束、新教训）写入文件（规则文件/任务 TODO/设计笔记），使它们脱离会话生命周期而持久。
- 摘要重开：新会话以 5-10 行摘要 + 当前状态 + 下一步任务开始，而不是复述全部历史。
- 会话三段式：探索段（读代码问方案）→ 执行段（小步改代码）→ 收尾段（自查与总结），段边界即重开点。
原理与机制
会话历史是只增不减的上下文材料：每轮对话（包括失败尝试）都留在窗口里抢注意力预算（kp-004）。两条机制决定策略：其一，淘汰失败的探索路径的最有效方式不是口头宣布「忽略之前」，而是换窗口；其二，模型的「记忆」只在窗口内，落盘文件才是跨会话记忆——把决策写进仓库等于给 AI 装了持久记忆。
实例或案例
重开会话模板（新会话第一条消息）：
背景摘要：实现订单导出 CSV 功能，已选定流式写出方案（services/export.py）。
已完成：字段映射与金额分转元；测试 test_export_basic.py 通过。
当前阻塞：10 万行时内存超限。
约束：禁新依赖；UTC 时间；不改 DB 模型。
请先读 services/export.py 与 TODO.md，再给内存优化方案，先不动代码。操作步骤（三段式节奏）：
- 探索段自由提问，但不改代码；方案定了就写入 TODO.md。
- 重开执行段：贴摘要 + 指向 TODO.md，按小步执行。
- 每完成一个可测试的增量，总结一句写进 TODO.md（顺手即成收尾段材料）。
- 出现两条衰减信号 → 立即摘要重开，不要恋战。
排错清单：
- 模型「忘了」红线 → 红线没落盘，补进规则文件（kp-006）。
- 重开后质量骤降 → 摘要缺关键状态，对照六件套（kp-008）补齐。
- 总在旧方案打转 → 失败尝试仍在上下文里，重开而不是反驳。
公式或模型
本节不适用：衰减没有可靠的定量阈值，以信号清单做定性判断。
图示
探索段 ──落盘──▶ 执行段 ──落盘──▶ 收尾段
(自由问) TODO.md (小步改) TODO.md (自查总结)
↑ 重开点：摘要 + 当前状态 + 下一步直观类比
长会话像一块用了整天的黑板：不擦掉废算式，新题就没地方写。摘要重开是「拍照留档、擦净重来」，落盘是「把结论抄进笔记本」。
常见误区
- 会话越长越「有感情」舍不得重开：窗口是资源不是聊天记录的纪念册。
- 摘要写成流水账：只写「当前状态 + 约束 + 下一步」，历史细节靠文件。
- 把重开当失败：它是周期性维护动作，就像 git commit。
与其他知识点的关系
kp-020 用同样的「落盘 + 重述」策略处理 Agent 跑偏；kp-006 规则文件是跨会话状态的最重要落盘位置。
自测题
要点：重复提问、无视早前约束、原地打转、风格漂移——出现两条即行动。
要点：文件进入每次会话的常驻/显式上下文且随代码版本化，会话内强调会被新对话稀释。
- 哪些信号说明该重开会话？
- 为什么落盘比「在会话里反复强调」有效？
延伸阅读
本节不适用：会话管理是实践技能，无经典文献对应。