简要结论
在长任务中保留决定性事实，减少噪声，并用新会话或 Fork 隔离不同工作方向。
上下文不是越多越好。重复日志、旧方案和超长工具结果会挤占模型真正需要的任务契约、代码证据和未完成事项。目标不是保存每个字符，而是让关键事实可恢复、可追溯。
三种信息不要混在一起
| 信息 | 放在哪里 | 示例 |
|---|---|---|
| 会话事实 | Session Event | 用户消息、工具调用、工具结果 |
| 当前任务状态 | 结构化检查点 | 已完成、决定、下一步、阻塞 |
| 长期项目知识 | 项目文档或 Skill | 架构约定、发布流程、常见故障 |
把长期知识反复粘贴进每次会话会浪费上下文；只把任务状态放在聊天末尾又容易在长日志中丢失。
DeepSeek Harness 的压缩语义
压缩是可选能力，不是 Agent Loop 的必经主干。它可以在压力或上下文溢出时运行，也可以由空闲会话手动触发。一次成功压缩会选择安全范围，用一条摘要替换可见表层中的旧内容，同时在 Session Log 中保留开始、摘要和结束等记账事件。
需要注意：
- 压缩摘要是新的可见检查点，不等于删除原始事件；
- 范围边界必须保持工具调用与结果配对；
- 工具结果可先被确定性剪枝，再决定是否生成摘要；
- 中途失败会留下可诊断的尝试记录，而不是假装成功。
写一个抗压缩检查点
每完成一个里程碑，生成：
任务目标：
不可变约束：
已确认事实（含证据位置）：
已完成及验证：
当前修改：
待办顺序：
未解决风险：摘要中不要保留已经否定的方案细节；但要保留“为什么否定”的关键证据，避免后续重复走弯路。
何时开新会话
以下情况适合新会话，而不是继续追加：
- 目标已经改变；
- 旧任务完成，新任务只共享项目背景；
- 历史包含大量与新问题无关的日志；
- 需要不受实现者推断影响的独立审阅。
新会话的首条消息应带最小交接包：目标、范围、当前状态、关键文件、验证结果和未决问题。
何时使用 Fork
Fork 适合从同一已知状态探索不同方案，例如：
- 一个分支尝试最小修复；
- 另一个分支评估接口重构；
- 两边使用相同基线与验收；
- 汇总时比较 diff、证据、风险和迁移成本。
不要让两个分支同时改同一工作区文件却没有隔离策略。会话分叉不自动等于 Git 分支或独立文件系统。
上下文预算练习
选择一个有长日志的任务：
- 标出任务契约、已验证事实和未决项。
- 删除重复解释与完整成功日志，只保留证据摘要。
- 写一个不超过 300 字的交接检查点。
- 在新会话中仅使用该检查点继续，让 Agent 先复述范围。
- 比较是否遗漏关键约束，并修订模板。
下一篇把可复用知识放进Skills 与项目记忆。