OpenCode 上下文压缩与长对话管理：/compact 命令完全指南

OpenCode 上下文压缩与长对话管理：/compact 命令完全指南

引言

在日常使用 OpenCode 进行开发时，你可能会遇到这样一个场景：聊着聊着，AI 突然"忘记"了之前说过的话，或者给出的建议开始偏离最初的需求。这不是 AI 出了 bug，而是上下文窗口已经满了。

OpenCode 提供了 /compact 命令来解决这个问题。本文将深入讲解 OpenCode 的上下文管理机制，以及如何利用 /compact 保持长时间对话的连贯性。

什么是上下文窗口

每次你和 OpenCode 对话时，模型会把你输入的所有消息、OpenCode 执行过的工具调用、读取过的文件内容、以及它自己的回复，一起打包发送给 LLM。这个"打包"的容量上限就是上下文窗口（Context Window）。

不同模型的上下文窗口各不相同：

| 模型 | 上下文窗口 |
|------|-----------|
| Claude 4.5 Sonnet | 200K tokens |
| GPT-5 | 128K~256K tokens |
| Gemini 2.5 Pro | 1M tokens |
| DeepSeek V3 | 128K tokens |

Token 不等于字数。简单估算：1 个中文字约等于 1.5~2 个 token，一段 100 行的代码文件可能消耗数千 token。这意味着，在一个复杂任务的对话中，上下文窗口很容易被快速消耗。

上下文满了会发生什么

当上下文接近上限时，LLM 提供商通常会采取以下策略之一：

截断早期消息：直接丢弃对话开头的内容，导致 AI "失忆"

返回错误：API 直接拒绝请求

OpenCode 的主动管理：在达到阈值前提示用户执行 /compact

无论哪种情况，都会影响 AI 的回答质量。最典型的表现是：AI 开始重复提问、忽略你之前的指令、或者给出与前半段对话矛盾的方案。

/compact 命令的工作原理

/compact 是 OpenCode 内置的上下文管理命令。它的核心思路是：用一次摘要替换掉整个对话历史。

执行 /compact 时，OpenCode 会做以下几件事：

生成对话摘要：将当前会话中的所有关键信息——你的需求、已完成的修改、待处理的问题、重要的文件引用——浓缩成一段结构化的摘要

重置对话历史：清空旧的完整消息记录

注入摘要：将摘要作为新的对话起点，让后续对话继续基于之前的上下文

关键点在于：/compact 不会丢失信息。它只是将冗长的原始对话换成了精炼的摘要，模型依然知道你做过什么、接下来要做什么。

何时使用 /compact

以下场景强烈建议使用 /compact：

1. 对话轮次超过 30 轮

当你和 OpenCode 来回对话超过 30 轮时，上下文通常已经积累了大量内容。此时执行一次 compact，可以让后续对话更加流畅。

2. 执行了大量文件操作

如果你在对话中让 OpenCode 读取了几十个文件、执行了一系列复杂的 bash 命令，这些操作的完整记录会占据大量空间。compact 后可以腾出空间进行新一轮密集操作。

3. 切换任务方向

你完成了功能 A，准备开始功能 B。虽然主题不同，但项目背景是相通的。compact 会保留关键项目信息，同时释放空间用于新任务的细节。

4. 收到上下文警告

OpenCode 在上下文接近上限时会主动提示。不要忽视这个警告，立即执行 /compact 可以避免信息丢失。

手动触发与自动触发

在 OpenCode 终端界面中，直接输入 /compact 即可手动执行：

/compact

OpenCode 也支持自动 compact，你可以在 opencode.json 中配置阈值：

{
  "context": {
    "auto_compact_threshold": 0.8,
    "auto_compact_trigger": "比例",
  }
}

• auto_compact_threshold：上下文占用比例达到多少时触发，0.8 表示 80%
• auto_compact_trigger：默认在上下文利用率达到阈值时自动执行 compact

启用自动 compact 后，你不需要手动关注上下文占用，OpenCode 会在合适的时机自动压缩。

多会话分流：另一种上下文管理策略

除了 /compact，多会话（Multi-session）也是管理上下文的利器。

如果你同时有多个独立任务，与其在一个会话中来回切换话题，不如创建多个并行会话：

# 新建第二个会话，右上角按 Ctrl+N
# 或者使用 opencode run 启动独立任务
opencode run "检查并修复 src/api/auth.ts 中的所有类型错误"
opencode run "为 src/utils/validator.ts 编写单元测试"

每个会话拥有独立的上下文，互不干扰。这样既避免了上下文混乱，又提升了并行处理能力。

与大项目的上下文博弈

对于大型项目，以下策略可以帮你更好地管理上下文：

1. 用 @ 精确引用文件

不要在 prompt 中泛泛而谈，使用 @ 精确指定需要关注的文件：

@src/services/order.ts @src/types/order.d.ts
请分析 OrderService 的支付流程，找出可能的并发问题。

精确引用能避免 OpenCode 为了理解你的需求而去盲目读取大量无关文件。

2. 善用 AGENTS.md 持久化项目知识

将项目的关键背景信息写入 AGENTS.md（执行 /init 可自动生成），OpenCode 在每次对话启动时会自动加载这些信息，无需在对话中反复交代。

3. 分阶段执行大型任务

不要试图在一个对话中完成整个功能。将任务拆分为多个阶段，每个阶段结束执行一次 compact，保留关键进展后进入下一阶段。

# 阶段 1：分析现有代码，输出重构方案
分析 @src/legacy/ 目录下的代码，给出重构建议

# compact 后进入阶段 2
/compact

# 阶段 2：根据方案执行重构
按照之前的重构方案，开始重构 @src/legacy/user_manager.ts

4. 用 Plan 模式减少无效对话

在 Plan 模式下，OpenCode 不会修改文件，只做分析和规划。这能减少大量工具调用的记录，节省上下文空间。确认方案可行后，再切回 Build 模式执行。

按 Tab 键即可在 Plan 和 Build 模式之间切换。

/compact 后如何快速恢复状态

compact 之后，OpenCode 的首条回复会基于摘要给出当前状态确认。你可以用以下 prompt 快速验证：

请总结一下你当前已知的项目信息和待办事项。

如果发现摘要遗漏了关键信息，直接在对话中补充即可：

补充一下：之前我们还确定了 API 接口使用 RESTful 风格，响应格式统一为 { "code": 0, "data": ..., "msg": "" }。

常见误区

误区一：compact 后 AI 就"忘了"

AI 并没有忘记——它拥有浓缩后的摘要。只是丢失了原始对话中的细节描述。如果那些细节在后续工作中不再需要，compact 就达到了目的。

误区二：越早 compact 越好

如果对话刚开始就 compact，摘要信息量太少，反而浪费一次上下文重建的机会。建议在上下文占用达到 60%~80% 时进行。

误区三：compact 是银弹

compact 无法解决"单次请求内容过多"的问题。如果你一次性贴了 10 万字的代码让 AI 分析，compact 也无能为力。控制每次输入的信息量才是根本。

总结

/compact 是 OpenCode 中一个不起眼但至关重要的命令。掌握它的使用时机和策略，可以让你在长时间开发会话中始终保持高效的协作体验。

核心要点回顾：

• /compact 用摘要替换完整对话历史，释放上下文空间
• 建议在 30+ 轮对话、大量文件操作、切换任务时使用
• 配合多会话、精确文件引用、AGENTS.md 实现全面的上下文管理
• 启用 auto_compact_threshold 可以实现自动化管理

下一次当你发现 AI 开始"健忘"时，不妨键入 /compact——你会发现，对话质量和效率都会明显回升。