上下文组织与信息保留策略

代理每一轮都会把此前的对话消息与工具调用结果纳入本轮提示，线程越长，携带的历史越多、成本与延迟越高、早期噪声也越容易稀释重点。上下文管理的目标不是"记住一切"，而是分层保留：稳定事实沉淀到仓库文档与配置，短期过程留在会话，临时探索及时隔离。本节讲机制、代价与可执行的组织策略。

一、上下文由哪些部分构成

来源	性质	保留建议
当前任务提示	本轮直接指令，最重要	写清目标、范围与验收标准
本轮工具结果	命令输出、文件读取、检索结果	只保留与决策相关的部分，避免整段堆砌
历史轮次消息与调用	随线程累积，是长线程成本主因之一	无关旧轮次应通过新会话隔离
项目级约定与规则	稳定、可复用的行为偏好	沉淀到规则文件/配置，跨会话生效（具体语法以官方为准）
用户/项目配置默认值	运行基线（如 $CODEX_HOME/config.toml）	保持精简、稳定，不塞临时任务细节

二、长线程的代价

1. 成本累积：历史上下文越长，每轮处理的输入越多，消耗随之上升。
2. 响应变慢：需要携带并理解的内容增加，单轮等待时间变长。
3. 重点被稀释：早期无关讨论、废弃尝试混在历史中，容易干扰当前判断。
4. 方向漂移：在同一条长线程上反复改方向，新旧目标混杂，结果偏离主线。
5. 问题难定位：错误假设被后续轮次默认继承，排查时不易区分有效结论与过期尝试。

三、上下文组织策略

• 按目标分段：一个明确目标对应一段精炼对话；完成或切换主题后新开会话，而不是无限续聊。
• 结论文档化：把稳定结论、约定、关键决策写进仓库文档或项目说明，使新会话可直接读取，不必依赖旧线程回忆。
• 探索用 fork 隔离：备选方案在分叉线程中试验，主线保持干净；试验结论再择优沉淀回文档。
• 稳定偏好入配置/规则：反复使用的偏好、允许与禁止规则放入配置或规则文件（官方机制含用户与项目级 .rules 规则文件、用户配置 config.toml；具体键与语法以当前官方文档为准），避免每轮重复说明。
• 恢复时给交接提示：续作时明确"当前目标、已完成结论、下一步、不要沿用的旧假设"，而不是只把旧线程丢给代理。
• 产出物优先落盘：关键结果以 diff、提交、报告、文档形式保存，会话历史仅作过程参考。

四、信息保留分层

信息类型	最佳载体	说明
长期稳定事实与规范	仓库文档、项目规则、配置基线	跨会话、跨成员复用，版本化管理
本次任务过程与推理	会话历史	用于追溯，不承担长期知识存储
临时备选探索	fork 分叉线 / ephemeral 运行	验证后保留结论、丢弃过程噪声
可交付改动	Git diff、提交、报告文件	可审查、可回退、可归档

五、FAQ

问题	处理建议
线程太长、反应慢怎么办	提炼当前结论写成简短交接，新开会话继续；把长期约定迁入文档/规则。
为什么它"忘记"了前面说过的偏好	会话历史不会自动变成长期规则；稳定偏好应写入配置/规则文件或项目文档。
如何让习惯跨多个会话生效	区分个人偏好（用户配置）与团队约定（项目规则/文档），分别落到对应载体。
是否应始终延续一个会话	否。主题切换、长线程失焦、目标完成后，新建或分叉比强行续聊更高效可靠。

六、动手练习

• 练习：把一次冗长会话的内容按"长期事实 / 任务过程 / 临时探索 / 交付物"四类归档；为其中的长期事实写一段可放入项目文档或规则的精简描述，体会"文档交接替代长线程"的做法。