4.3 Auto Compact 与上下文管理

对话越长，AI 越笨——不是因为模型不行，而是上下文窗口装不下了。Auto Compact 就是 OpenCode 的"记忆压缩器"，让 AI 在长对话中保持清醒。

这一节在讲什么？

你一定遇到过这种情况：跟 OpenCode 对话了 30 分钟，AI 开始"遗忘"之前讨论的内容，回答变得前后矛盾，甚至重复之前已经解决的问题。这不是 AI 变笨了——而是上下文窗口满了。每个 LLM 都有上下文窗口限制（Claude Sonnet 约 200K token），当对话历史 + 文件内容 + 工具输出超过这个限制时，AI 就无法正常工作了。OpenCode 的 Auto Compact 机制就是为了解决这个问题——它会在上下文接近上限时自动压缩对话历史，保留关键信息，丢弃冗余细节。这一节我们深入 Auto Compact 的工作原理、手动压缩策略、会话管理技巧，帮你掌握长对话场景下的上下文管理。

上下文窗口：AI 的"短期记忆"

理解 Auto Compact 之前，先理解上下文窗口。上下文窗口是 LLM 一次能处理的最大 token 数量——你可以把它理解为 AI 的"短期记忆容量"。

上下文窗口的组成：

  ┌──────────────────────────────────────────────┐
  │  上下文窗口（200K token for Claude Sonnet）    │
  │                                               │
  │  ┌─────────────────────────────────────────┐  │
  │  │  系统提示词（~1K token）                  │  │
  │  │  AGENTS.md（~2K token）                  │  │
  │  └─────────────────────────────────────────┘  │
  │                                               │
  │  ┌─────────────────────────────────────────┐  │
  │  │  对话历史（逐渐增长）                      │  │
  │  │  - 用户消息                               │  │
  │  │  - AI 回答                                │  │
  │  │  - 工具调用和结果                          │  │
  │  └─────────────────────────────────────────┘  │
  │                                               │
  │  ┌─────────────────────────────────────────┐  │
  │  │  @ 引用的文件内容                          │  │
  │  │  $ 命令的输出                              │  │
  │  └─────────────────────────────────────────┘  │
  │                                               │
  │  ┌─────────────────────────────────────────┐  │
  │  │  剩余空间（AI 生成回答需要空间）            │  │
  │  └─────────────────────────────────────────┘  │
  └──────────────────────────────────────────────┘

随着对话的进行，"对话历史"部分会越来越大，留给"剩余空间"的部分越来越小。当剩余空间不足时，AI 无法生成完整的回答——这就是为什么长对话中 AI 的回答会变短、变差、甚至报错。

Auto Compact 机制

Auto Compact 是 OpenCode 的自动上下文压缩机制。当对话接近上下文窗口的 95% 时，OpenCode 会自动触发压缩：

Auto Compact 的工作流程：

  1. 监控 token 使用量
     → 每次对话后计算当前上下文占用了多少 token

  2. 触发压缩（当使用量达到 95%）
     → OpenCode 调用 LLM 对对话历史进行摘要
     → 保留关键信息：用户的需求、AI 的修改、当前的进度
     → 丢弃冗余信息：中间的调试过程、重复的讨论、过时的方案

  3. 创建新会话
     → 压缩后的摘要作为新会话的起始上下文
     → 用户可以继续对话，就像什么都没发生一样

Auto Compact 默认开启，你可以在配置文件中控制：

json

{
  "autoCompact": true
}

如果你想关闭自动压缩（不推荐），设为 false：

json

{
  "autoCompact": false
}

手动 /compact

除了自动压缩，你也可以手动触发压缩：

/compact

手动压缩在以下场景很有用：

你感觉 AI 的回答质量开始下降，但还没到自动压缩的阈值
你刚完成一个大任务，想"清理"上下文再开始新任务
你引用了很多文件，上下文已经很满了

手动压缩的效果跟自动压缩一样——OpenCode 会把对话历史总结成摘要，保留关键信息，丢弃冗余细节。

会话管理

除了压缩，会话管理是另一个重要的上下文控制手段。OpenCode 支持多会话并行——你可以同时开多个会话，每个会话有独立的上下文。

创建新会话：

/sessions

在会话管理界面，你可以创建新会话、切换到已有会话、删除旧会话。

启动时指定会话：

bash

# 继续上次的会话
opencode -c

# 指定会话 ID
opencode -s <session-id>

会话管理的最佳实践：

什么时候开新会话？

  ✅ 应该开新会话的情况：
  - 开始一个全新的任务（从修 bug 切到加功能）
  - 当前会话已经很长（20+ 轮对话）
  - 切换到不同的项目区域
  - AI 的回答质量明显下降

  ❌ 不需要开新会话的情况：
  - 同一个任务的后续步骤
  - 只是想补充一些信息
  - 对 AI 的回答做小幅调整

上下文窗口的利用策略

不同的模型有不同的上下文窗口大小，理解这些差异能帮你更好地选择模型：

模型	上下文窗口	适合场景
Claude Sonnet 4	200K token	日常编码，足够大多数场景
Claude Opus 4	200K token	复杂任务，需要更多推理空间
Claude Haiku 4	200K token	简单任务，上下文通常够用
GPT-4o	128K token	日常编码
Gemini 2.5 Pro	1M token	需要理解整个项目
Ollama 7B	4K~8K token	简单任务，上下文很有限

策略一：大文件用 Gemini

当你需要 AI 理解一个非常大的文件（比如 5000+ 行的配置文件），或者同时分析多个文件时，Gemini 的 100 万 token 上下文窗口是唯一的选择：

bash

opencode run -m google/gemini-2.5-pro "Analyze the entire @src/ directory and find inconsistencies"

策略二：长对话用 Claude

Claude 的 200K token 上下文窗口对于大多数长对话场景够用。配合 Auto Compact，你可以持续对话 30 分钟以上而不会遇到上下文问题。

策略三：Ollama 注意上下文限制

Ollama 的 7B 模型只有 4K~8K token 的上下文窗口，这意味着你只能给 AI 提供很少的上下文。使用 Ollama 时，尽量只引用小文件，避免长对话。

上下文管理的高级技巧

技巧一：用 /context 检查上下文

/context

这个命令显示当前上下文中包含了哪些文件和命令输出。当你觉得 AI 的回答"不对劲"时，用这个命令检查——可能是 AI 看到了错误的文件，或者缺少关键信息。

技巧二：用 /clear 重置上下文

/clear

/clear 会清空当前会话的所有对话历史，重新开始。这比 /compact 更彻底——/compact 是"压缩"，/clear 是"清空"。当你想完全换一个话题时，用 /clear。

技巧三：拆分复杂任务

如果一个任务需要 AI 处理很多文件，不要在一个会话里全部完成——拆分成多个小会话：

会话 1：分析项目结构，制定修改方案
会话 2：修改数据库层代码
会话 3：修改 API 层代码
会话 4：修改前端代码
会话 5：运行测试，修复问题

每个会话的上下文更干净，AI 的回答质量更高。

常见误区

误区一：Auto Compact 会丢失重要信息

不会。Auto Compact 不是"删除历史"，而是"压缩历史"——它会把之前的对话总结成一段摘要，保留关键信息（你问了什么、AI 做了什么修改、当前的进度），丢弃冗余的细节（中间的调试过程、重复的讨论）。压缩后，AI 仍然知道之前讨论了什么，只是占用的上下文空间更少了。

误区二：上下文窗口越大越好

不一定。更大的上下文窗口意味着更多的 token 消耗（按 token 计费），也意味着 AI 需要在更多信息中找到重点——有时候过多的上下文反而会让 AI "迷路"。好的做法是提供精准的上下文，而不是更多的上下文。

误区三：/compact 和 /clear 一样

不一样。/compact 是"压缩"——保留关键信息的摘要，你可以继续对话。/clear 是"清空"——所有对话历史都被删除，AI 从零开始。/compact 适合"对话太长了，压缩一下继续"；/clear 适合"换个话题，重新开始"。

误区四：Auto Compact 关掉也没关系

如果你只进行短对话（10 轮以内），关掉 Auto Compact 确实没关系。但如果你习惯长对话（30 分钟以上），关掉 Auto Compact 会导致上下文溢出——AI 无法生成回答，甚至报错。建议保持 Auto Compact 开启。

小结

这一节我们深入了 OpenCode 的上下文管理：上下文窗口是 AI 的"短期记忆"，Auto Compact 在上下文接近上限时自动压缩对话历史，手动 /compact 可以主动触发压缩，/clear 可以完全重置上下文。上下文管理的核心原则是"精准而不贪多"——只提供跟任务直接相关的上下文，长对话定期压缩，复杂任务拆分成多个小会话。下一章我们进入 OpenCode 最强大的扩展能力——MCP 协议与工具扩展。

4.3 Auto Compact 与上下文管理 ​

这一节在讲什么？ ​

上下文窗口：AI 的"短期记忆" ​

Auto Compact 机制 ​

手动 /compact ​

会话管理 ​

上下文窗口的利用策略 ​

上下文管理的高级技巧 ​

常见误区 ​

小结 ​