<!-- Canonical URL: https://ask.atlascloud.ai/zh/prevent-long-coding-sessions-from-losing-context -->

# 如何防止长时间编码会话丢失上下文？

> 防止上下文丢失的关键，是把长期有效的信息移出聊天，写入精简任务台账、决策日志、测试记录和仓库检查点。压缩上下文或更换模型前，应从这些材料恢复状态，而不是重放无限增长的会话记录。

长时间会话通常不是突然“失忆”，而是逐渐偏移。智能体可能仍记得总体目标，却漏掉一个小约束、相信已经过时的测试结果、重复调查，或按照不再符合仓库现状的计划编辑代码。解决办法是建立比聊天记录更短、更可靠的持久状态。

把对话当作工作记忆，把仓库当作事实来源。每到一个有意义的检查点，都要记录发生了什么、哪些结果已经验证、哪些仍不确定，以及下一步应做什么。

## 跟踪四类上下文

按用途拆分信息，避免摘要变成一段无法核验的叙事。

| 上下文类型 | 示例 | 持久保存位置 |
|---|---|---|
| 目标 | 用户期望的结果与验收标准 | 任务台账 |
| 约束 | 兼容性、安全、风格、范围 | 任务台账 |
| 仓库状态 | 已修改文件和当前分支 | 版本控制 |
| 证据 | 测试、日志、截图、基准结果 | 验证记录 |

只有在明确标注时，才把假设作为第五类信息。每个假设都应附带一个成本最低的验证或否定动作。

## 维护一屏以内的任务台账

有效的台账应能在一个屏幕内读完。只在里程碑后更新，不必记录每条消息。

```md
Objective:
Ship model-switch support without changing existing tool behavior.

Constraints:
* Preserve the public API.
* No destructive migration.

Current state:
* Parser adapter added in src/stream.ts.
* Unit tests pass; cancellation test still fails.

Decisions:
* Buffer tool arguments until the final event.

Evidence:
* npm test: 142 passed, 1 failed.

Next action:
Fix duplicate execution after stream cancellation.
```

保留准确的路径、命令和失败名称，不要把台账写成讨论过程的日记。

## 围绕已验证状态建立检查点

检查点应位于下一次会话能够复现的结果之后，例如一组测试通过、一次小范围提交、确认过的 API 响应，或由夹具支持的设计决定。

更换模型或压缩上下文前，应记录未提交文件。不能因为代码已经写完就声称功能可用；每个结论都应关联测试、构建或可观察成果。

| 结论 | 所需证据 |
|---|---|
| 解析器支持两次调用 | 含两个已关联调用 ID 的夹具 |
| 重试安全 | 断线场景下的幂等性测试 |
| 重构保持原行为 | 旧测试与新测试均通过 |
| UI 正确 | 在目标尺寸下完成渲染检查 |

## 重新读取源文件，不要重放聊天

某个细节重要时，应重新打开当前文件、Schema 或官方文档。旧会话可能描述的是后来已经改变的代码。给智能体准确路径和搜索词，让它检查最新状态。

检索范围应尽量窄。先加载接口、实现、失败测试和相关日志，而不是整个仓库，这样能保留推理空间并减少干扰。

## 压缩时保留决策与证据

好的压缩会删除对话中的重复内容，同时保留约束、难以撤销的决定、被否决的方案和验证结果，并区分 `verified`、`observed`、`assumed` 和 `pending`。

不要把失败实验总结成最终设计。如果某个诱人的错误方案以后可能再次出现，应保留它被否决的原因。

## 在工具输出进入上下文前限制长度

超长日志和生成文件会迅速消耗注意力。让工具返回相关范围、计数或匹配行，把完整输出保存为成果物，再返回带路径的简短摘要。

测试失败也应遵循同一原则：保留第一个有用的堆栈、失败断言和环境信息，不要把数百个重复帧送回模型。

## 使用确定性的恢复流程

暂停、上下文压缩或模型切换后：

* 读取目标和约束。
* 检查版本控制状态与最近修改。
* 打开当前状态中提到的文件。
* 重新运行最近一次相关检查。
* 确认记录的下一步仍然有效。

这套流程能在过时摘要引发新编辑前发现问题。

## 不依赖聊天记忆来选择模型

网关能简化模型切换，但状态管理仍是客户端的责任。Atlas Cloud 通过一个 Base URL 提供多种 LLM 协议；迁移正在运行的智能体前，应检查[协议矩阵](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context)和最新[模型目录](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context)。

向替换模型提供任务台账、相关源文件和一份新的验证结果。除非已经确认相同协议与行为，否则不要依赖供应商特有的状态句柄。

## 结论

要让长时间编码会话保持上下文，持久状态必须精简、有证据支持且容易重新载入。维护一屏台账，围绕已验证修改建立检查点，重新读取当前源文件而不是重放聊天，限制工具输出，并使用确定性恢复流程。更大的上下文窗口有帮助，但真正让工作可恢复的是规范的外部状态。

## FAQ

### 更大的上下文窗口足以支撑长时间编码会话吗？

不足以。更大容量只能推迟压力，不能保证旧约束始终醒目，也不能自动纠正过时观察。

### 编码会话台账应该记录什么？

记录目标、约束、当前计划、已修改文件、关键决策、验证结果、未解决风险以及准确的下一步操作。

### 智能体应该多久创建一次检查点？

在出现有意义的状态变化后创建，例如测试通过、完成一个迁移阶段、作出设计决定，或发现会改变计划的新信息。

### 应该把完整会话记录交给新模型吗？

通常不应该。应提供经过整理的检查点、相关源文件和日志，再让新模型检查仓库当前状态。

### 怎样防止摘要保留旧错误？

把已验证事实与假设分开，为事实附上命令或文件位置等证据；新测试与旧结论冲突时，应明确废弃旧结论。

### 中断后最安全的恢复方式是什么？

重新读取任务台账，检查版本控制状态，重跑最近一次相关验证，然后从台账记录的下一步开始。