长时间使用编程 Agent 后，短请求也可能触发大量无关分析：旧需求仍留在历史里，完整构建日志反复出现，失败尝试与当前结论互相冲突。此时继续补充提示通常只会增加噪声。更可靠的做法是把任务状态从对话记忆中外置，明确哪些是已验证事实、哪些只是失败假设，以及下一步需要读取哪些最小证据。本文给出一套与具体工具命令无关的上下文整理流程，目标是让当前会话或新会话都能从同一事实状态继续工作。

识别上下文污染的信号

出现下面情况时，应暂停修改并整理状态：

这些信号不能证明上下文长度是唯一原因，但足以说明当前信息组织已经妨碍验证。

第一步：把日志收窄成证据包

不要把整份构建输出反复复制到会话中。先整理一个最小证据包：

失败命令：实际执行的完整命令
退出码：进程返回值
首个相关错误：文件、行号和错误消息
复现条件：操作系统、运行时和必要输入
相关日志：错误前后有限范围
基线：最近一次已知正常的提交或版本

如果原始日志仍有价值，将它保存为文件并记录路径和生成命令。后续只有在新假设需要时才读取指定片段，而不是默认重新传入全部内容。

第二步：区分事实、假设和动作

状态记录使用三类条目：

FACT：已由文件、命令或测试直接确认
HYPOTHESIS：用于指导下一步，但尚未证实
ACTION：准备执行且带有验证方法的动作

例如：

FACT：目标测试在基线提交上失败，退出码为 1。
FACT：堆栈首个项目文件位于 parser 模块。
HYPOTHESIS：空输入没有在进入解析器前被拒绝。
ACTION：读取入口校验和目标测试；若缺少空输入用例，先补回归测试。

压缩对话时只保留仍有效的事实和假设。已被证伪的猜测可以记录一句结论，不必保留完整讨论过程。

第三步：在阶段边界形成检查点

复杂任务可以分为复现、定位、修复、验证和交付。每完成一个阶段，写一个短检查点：

阶段 必须保留的内容
复现 命令、输入、失败消息和环境
定位 根因证据、涉及文件和被排除的方向
修复 行为变化、修改范围和兼容边界
验证 实际命令、退出码和失败数
交付 变更文件、剩余限制和回滚方式

检查点不是工作日志。它只保留下一阶段必须知道且能够验证的信息。

第四步：让项目规则充当索引

常驻项目说明应包含高频命令、关键目录边界、安全限制和按需文档索引，不应复制完整架构史或所有模块文档。

一个精简入口可以写成：

目标测试：运行位置和命令
全量验证：运行位置和命令
禁止修改：生成目录、供应商代码、密钥文件
详细规范：按任务读取的文档路径
交付要求：必须报告实际执行结果

详细内容留在对应文档中，任务需要时再读取。这样既能保留约束，又避免每轮携带与当前模块无关的材料。

第五步：生成可接力状态

准备切换会话或暂停工作时，使用固定结构整理交接：

目标：本次唯一要实现或修复的行为
范围：允许修改和禁止修改的路径
已确认事实：附文件位置或命令证据
已修改：文件及行为变化
已验证：命令、退出码和结果
未完成：尚未满足的验收条件
下一步：一个具体动作及其预期信号
风险：可能影响的接口、数据或环境

检查交接中是否存在“应该通过”“看起来完成”等推测表达。未执行的验证只能放在下一步，不能放入已验证。

第六步：用交接反向恢复

在新会话中先读取交接，再执行一条廉价的状态检查，例如查看目标文件差异或运行最小复现。若实际状态与交接不一致，以文件和命令结果为准，并立即修正交接。

不要一恢复就运行全部耗时命令。先确认当前分支、改动范围和最小失败仍与记录一致，避免在错误工作树上继续。

临时问题不要改写主任务

处理主任务时出现无关问题，把它记录到待办列表，并说明为什么不属于当前范围。只有会改变当前技术路线或验收标准的问题才进入主状态。

如果必须研究新问题，单独保存输入、结论和来源。研究结束后只把与主任务直接相关的已确认事实带回，而不是合并整段讨论。

结论与限制

编程 Agent 的上下文卫生本质上是状态管理：收窄证据，区分事实与假设，在阶段边界记录可验证检查点，并用固定交接结构恢复。这样可以减少重复读取和错误路径，但不应把“上下文更干净”写成确定的成本或性能收益。

本文方法不依赖某个工具的会话、压缩或清理命令。具体产品如何保存历史、加载项目规则或计算用量会随版本变化，使用相关命令前仍需核对当前官方文档。