拆会话、做交接：降低重复上下文和任务漂移

为什么长会话会越来越贵

长会话中常见的问题不是消息数量本身，而是：

• 旧需求仍在上下文里
• 已经否决的方案反复出现
• 大段日志和工具结果被保留
• 新任务与旧任务边界混在一起
• 代理为确认状态重复读取文件

当交付目标已经变化时，继续沿用旧会话可能比开一个有良好交接的新会话更浪费。

什么时候应该新开会话

• 一个交付已经完成
• 从 Bug 修复切换到新功能
• 从后端根因分析切换到 UI 改版
• 对话中已有大量无关日志/截图
• 当前会话的计划已经多次推翻
• 需要换模型或工具配置

交接不是复制整个聊天

新会话只需要“当前状态”，而不是所有历史。建议生成 HANDOFF.md：

# Goal

# Current repository state

# Completed

# Key evidence and decisions

# Files changed

# Tests run and results

# Failed approaches (do not repeat)

# Remaining required work

# Out of scope / do not change

# Exact next action

交接提示词

请为新的 Codex 会话生成一份自包含 HANDOFF.md。
只保留继续工作所需的事实，不复述完整聊天。
必须区分：已完成、已验证、推测、未完成、禁止重复的失败方案。
列出当前 git diff、相关文件、测试结果和下一步。

一项交付一个会话

“登录失败修复”和“顺便重做权限系统”不是同一个交付。拆分后，每个会话有明确完成条件，代理更容易停止，也更容易选择合适模型。

不要丢失可验证状态

交接最好引用：

• commit SHA
• git diff --stat
• 失败测试名
• 关键日志文件路径
• 已确认的接口响应

而不是只写“差不多修好了”。

如何衡量效果

比较拆分前后：

• 每个交付的首次成功率
• 重复读取文件次数
• 返工次数
• 完成时间
• Codex 配额变化

如果交接文件本身越来越长，也要继续压缩，只保留后续需要的状态。