![修复 OpenClaw context_length_exceeded：完整故障排除指南 [2026]](/posts/zh/openclaw-context-length-exceeded/img/cover.png)
OpenClaw 的 context_length_exceeded 错误发生在你的对话历史、工作区文件和工具输出超过 AI 模型最大 token 限制时。这是用户在长时间编码会话中最常遇到的错误之一，它会让你的 Agent 彻底停止工作。好消息是：你可以立即通过 /compact 压缩旧历史记录来修复它，使用 /new 开始全新会话，或者在 openclaw.json 中配置 agents.defaults.compaction.reserveTokens: 40000 来实现永久预防。本指南涵盖了所有原因、修复方案和预防策略，包含经过验证的命令和配置示例，所有信息均根据 2026 年 2 月的官方 OpenClaw 文档核实。
要点速览
如果你的 OpenClaw Agent 刚刚因上下文溢出错误而停止工作，以下是你现在需要做的事情：
- 立即修复：在 OpenClaw 会话中输入
/compact，将对话历史压缩为摘要，释放约 60% 的上下文窗口。这会保留你的关键决策和上下文，同时删除对话中较早部分的冗余细节。 - 终极方案：输入
/new开始一个全新的会话。你会失去对话历史，但可以立即获得一个正常工作的 Agent。当/compact单独使用不够时，这是你最好的选择。 - 检查状态：运行
/status查看你的上下文窗口到底有多满。如果显示使用率超过 80%，自动压缩应该会自动触发——但如果还没有触发，手动执行/compact就能解决问题。 - 永久预防：在 openclaw.json 中添加
"agents": {"defaults": {"compaction": {"reserveTokens": 40000}}}，以便在达到限制之前更早触发自动压缩。默认的 16,384 token 对于复杂的编码会话来说往往太低。
OpenClaw 中 context_length_exceeded 的成因
每次你向 OpenClaw 发送消息时，Agent 都会组装一个完整的请求负载发送给你配置的 AI 模型。这个负载不仅仅是你的消息——它包括系统提示词、所有工具 Schema、工作区文件以及你的整个对话历史。理解这个架构是修复和预防上下文溢出错误的关键，因为错误不是来自某一条大消息，而是来自 OpenClaw 需要在每次请求中包含的所有内容的累积负担。
仅系统提示词一项就在每次请求中消耗约 9,600 个 token。这是告诉 AI 模型如何作为 Agent 运行的核心指令集——如何使用工具、如何推理代码、如何与你的工作区交互。你无法在不破坏 Agent 功能的情况下大幅减少这部分消耗，因此它代表了从第一条消息开始就会吃掉可用上下文窗口的固定成本。
工具 Schema 在每次请求中又增加了约 8,000 个 token。OpenClaw 可以访问的每个工具——文件读取、代码执行、网络搜索以及其他数十个工具——都需要一个描述其参数和用法的 JSON Schema 定义。这些 Schema 对于模型了解有哪些可用工具是必要的，但它们消耗了你上下文预算中相当大的一部分。当你启用额外的技能或连接带有大量工具的 MCP 服务器时，这个数字会攀升得更高。
工作区文件注入往往是无声的杀手。 OpenClaw 会在你发送的每条消息中注入 AGENTS.md、SOUL.md、USER.md 和其他配置文件等工作区文件。根据 GitHub Issue #9157，在复杂的工作区中，这种注入每条消息可消耗约 35,600 个 token，在多消息对话中造成高达 93.5% 的浪费，因为相同的文件每次都被重新发送。如果你有大型工作区文件，它们正在以惊人的速度消耗你的上下文窗口。
对话历史是无限增长的组件。你发送的每条消息、每个工具结果、Agent 读取或编写的每个代码块——所有这些都会在对话历史中累积。在典型的编码会话中，当你在调试复杂问题、读取多个文件并迭代解决方案时，对话可以在 15 到 20 分钟内轻松达到数万个 token。如果不进行压缩，这种增长是不可避免的，context_length_exceeded 错误只是时间问题，而非会不会发生的问题。
第五个也是最后一个贡献因素是内存搜索结果。启用后，OpenClaw 会查询其内存系统以从过去的会话中查找相关上下文，并将这些结果注入当前请求。虽然此功能改善了会话之间的连续性，但它会向已经拥挤的上下文窗口中添加额外的 token。GitHub Issue #5771 记录了这样的案例：仅内存搜索注入就在全新会话上触发了上下文溢出，甚至在用户发送第一条真实消息之前就已发生。
快速诊断——60 秒内确定你的确切问题
当你的 OpenClaw 会话遇到 context_length_exceeded 错误时，你需要确定它是由于长对话导致的真正溢出、工作区文件注入的配置问题，还是产生误报的已知 Bug。诊断过程大约需要 60 秒，从一个揭示当前上下文状态所有关键信息的命令开始。
第 1 步：运行 /status 并查看上下文百分比。 此命令以百分比形式输出你当前的上下文窗口利用率。如果显示超过 80%，你遇到的是真正的上下文溢出——你的对话已经增长过长，需要压缩或重新开始。如果尽管出现错误但显示较低的百分比，你可能遇到的是误报 Bug，这需要完全不同的处理方法。
第 2 步：运行 /context list 查看什么在消耗你的上下文。 此命令详细分解了哪些文件和组件被注入到你的上下文窗口中。查找意外的大型工作区文件——如果你看到某些文件各消耗数千个 token，减少或从注入中移除它们将大大改善你的情况。输出会显示文件名及其 token 数量，让你轻松识别最大的"罪魁祸首"。
第 3 步：检查错误消息的变体。 并非所有上下文溢出错误都是相同的。标准错误内容为 "This model's maximum context length is X tokens. You requested Y tokens."。如果你看到这种模式，这是一个直接的溢出。但是，如果错误发生在全新会话中或最近一次压缩之后，你可能遇到了 Issue #7483，其中错误检测机制产生了误报。在这种情况下，运行 openclaw status --all 可以给你完整的诊断信息，包括内部 token 计数与报告计数的对比。
如果你在遇到上下文错误的同时还遇到了 OpenClaw 的速率限制错误，这两个问题可能是相关的。当系统反复重试失败的请求时，上下文溢出错误有时会级联为 429 错误，消耗你的速率限制配额。在调查速率限制问题之前，务必先修复上下文问题。
正确解读诊断输出很重要，因为每种根本原因都有不同的修复方法。 长对话导致的真正溢出需要 /compact 或 /new。臃肿的工作区文件导致的溢出需要调整工作区配置。误报 Bug 需要更新到最新的 OpenClaw 版本或应用特定的解决方法。上面的诊断命令为你提供了足够的信息，可以在一分钟内选择正确的解决路径。
修复 context_length_exceeded——分步解决方案
以下解决方案按从最快到最彻底的顺序排列。从修复方案 1 开始，只有在前一个方案未能解决你的问题时才继续往下。大多数用户使用 /compact 或 /new 即可在两分钟内恢复正常工作。
修复方案 1：使用 /compact 手动压缩
这是应对 context_length_exceeded 错误的推荐首选方案。当你运行 /compact 时，OpenClaw 会将整个对话历史总结为一个紧凑的摘要，保留关键决策、文件位置和重要上下文，同时丢弃早期交流中的冗长细节。压缩后的摘要通常使用原始对话 token 数的 40% 或更少，这通常提供了足够的空间继续工作。
bash/compact # 验证压缩是否生效： /status
压缩后，再次检查 /status。你的上下文利用率应该已经显著下降。如果仍然超过 80%，压缩可能不够激进——你可以再次运行 /compact 进行第二次压缩，或继续使用修复方案 2。一个重要的细节：压缩结果会持久化到 JSONL 会话文件中，因此摘要在重启后仍然保留。你不是在丢失数据——你是在压缩它。
修复方案 2：使用 /new 开始全新会话
当压缩单独不够用时——通常在超长会话或工作区文件消耗了不成比例的上下文量的情况下——开始全新会话是最可靠的修复方法。/new 命令创建一个完全干净的会话，对话历史为零。系统提示词、工具和工作区文件会自动重新加载，但你从一张空白的对话画布开始。
bash# 开始全新会话： /new # 替代方案：清除并重置 /reset
/new 和 /reset 之间的区别很微妙：两者都创建新会话，但 /reset 还会清除所有会话特定的内存。当你想用干净的对话继续同一个整体任务时使用 /new，当你想完全从零开始时使用 /reset。两个命令都不会删除你的项目文件或工作区配置——它们只影响对话状态。
修复方案 3：减少工作区文件注入
如果你的 /context list 输出显示大型工作区文件消耗了数千个 token，减小它们的大小或将它们从注入中排除可以提供实质性的缓解。OpenClaw 支持 bootstrapMaxChars 设置（默认值：20,000 字符，已根据官方文档验证），该设置限制了每条消息注入的工作区内容总量。
json{ "agents": { "defaults": { "bootstrapMaxChars": 10000 } } }
将 bootstrapMaxChars 从默认的 20,000 减少到 10,000 甚至 5,000 字符，可以为每条消息节省数千个 token。代价是你的 Agent 将拥有更少的即时可用工作区上下文，但它可以在需要时随时按需读取文件。对于大多数编码任务来说，当你频繁触及上下文限制时，这个代价是值得的。
修复方案 4：禁用内存搜索
如果你在全新会话上就遇到上下文溢出错误——特别是 GitHub Issue #5771 中记录的场景——禁用内存搜索可以立即解决问题。内存搜索会注入来自过去会话的相关片段，在某些情况下，仅这些注入就会在任何真实对话开始之前将上下文推过模型的限制。
json{ "agents": { "defaults": { "memorySearch": { "enabled": false } } } }
禁用内存搜索意味着你的 Agent 不会自动回忆以前会话的信息。对于依赖会话连续性的用户来说，这是一个重大代价，但它消除了意外上下文消耗的主要来源。你可以在底层 Bug 修复后或升级到具有更大上下文窗口的模型后重新启用它。
修复方案 5：切换到具有更大上下文窗口的模型
如果你经常处理大型代码库和长会话，最可持续的修复方法可能是切换到提供更大上下文窗口的模型。128,000 token 的模型与 200,000 token 的模型之间的差异，可能就是每 30 分钟就遇到瓶颈与整个下午不间断工作之间的差异。请参阅下面的模型对比部分了解具体建议。
要在 OpenClaw 中切换模型，请更新你的配置以指定不同的提供商和模型：
json{ "agents": { "defaults": { "model": "claude-sonnet-4-5-20250929", "provider": "anthropic" } } }
选择新模型时，不仅要考虑上下文窗口大小，还要考虑模型在你特定用例中的能力。拥有百万 token 上下文窗口的模型，如果无法完成你的工作流所需的推理任务，那也毫无帮助。对于大多数 OpenClaw 用户来说，Claude Sonnet 4（200K 上下文）在智能水平、上下文容量和成本之间提供了最佳平衡。
掌握 OpenClaw 上下文配置
OpenClaw 提供了多个控制上下文管理、压缩和裁剪方式的配置设置。这些设置位于你的 openclaw.json 文件中（通常在 ~/.openclaw/openclaw.json 或项目的 .openclaw/settings.json 中），让你可以对上下文管理行为进行细粒度控制。理解和调优这些设置，是不断与上下文错误作斗争和再也不会遇到这些错误之间的差别。
压缩设置是你能做的最有影响力的配置。 压缩系统控制 OpenClaw 何时以及如何总结对话历史。默认情况下，自动压缩是启用的，并在上下文接近模型限制时触发，但默认的阈值设置很保守——对于许多实际编码会话来说过于保守了。
json{ "agents": { "defaults": { "compaction": { "reserveTokens": 40000, "keepRecentTokens": 20000, "reserveTokensFloor": 20000 } } } }
reserveTokens 设置（默认值：16,384 token，已根据官方 OpenClaw 文档验证）决定了压缩后要维持多少可用空间。将其增加到 40,000 token 可确保压缩更早、更激进地触发，为你留下舒适的缓冲区，而不是不断在溢出边缘徘徊。keepRecentTokens 设置（默认值：20,000 token）控制在压缩期间保留多少最近的对话 token 原样不动——更早的内容都会被总结。reserveTokensFloor（默认值：20,000 token）作为压缩始终维持的绝对最低保留量。
上下文裁剪与压缩的工作方式不同。 压缩会将对话重写为摘要（这是一个持久化到 JSONL 文件的永久性变更），而裁剪则是在每次请求的内存中修剪工具结果和冗长输出，而不修改存储的会话记录。裁剪自动发生，不需要配置，但理解它有助于解释为什么你的 /status 输出可能显示与预期不同的数字——裁剪后的内存表示可能比存储的会话记录小得多。
引导文件管理控制工作区注入。 bootstrapMaxChars 设置限制每条消息注入的工作区内容总量。OpenClaw 对大文件使用 70/20/10 的拆分策略：70% 来自文件头部，20% 来自文件尾部，10% 保留给截断标记。如果你的工作区文件超过了这个预算，每条消息只会注入一部分，这意味着 Agent 可能会错过位于大文件中间的上下文。保持你的 AGENTS.md 和其他工作区文件简洁且组织良好，可以确保最重要的信息在截断后仍然存在。
内存刷新的 softThresholdTokens 设置（默认值：4,000 token）控制内存系统何时刷新搜索结果。当内存结果超过此阈值时，旧结果将被丢弃以腾出空间。如果你看到内存注入导致意外的上下文增长，降低此阈值可以减少内存占用，代价是可用的历史上下文会减少。
以下是针对频繁遇到上下文错误的用户的完整推荐配置。 此配置针对中大型代码库的长时间编码会话进行了优化，代表了 OpenClaw 社区通过大量实际测试后趋同的最佳设置：
json{ "agents": { "defaults": { "compaction": { "reserveTokens": 40000, "keepRecentTokens": 25000, "reserveTokensFloor": 25000 }, "bootstrapMaxChars": 12000, "memorySearch": { "softThresholdTokens": 3000 } } } }
此配置更早触发压缩（40K 保留量对比默认的 16K），保留更多最近的对话上下文（25K 对比 20K），将工作区注入限制在适中的 12,000 字符，并略微减少内存搜索注入。这些设置结合在一起，为经常进行超过 30 分钟会话的用户提供了显著更舒适的体验。关键洞察在于，默认设置是为简短、简单的交互设计的——如果你将 OpenClaw 作为多小时会话的严肃开发工具使用，你需要向上调整这些数值。
为你的上下文需求选择合适的模型
你选择的 AI 模型直接决定了你有多少可用上下文，而模型之间的差异是巨大的。一些模型提供的上下文窗口是其他模型的十倍，这可能就是持续出现上下文错误与无忧无虑地进行长时间会话之间的差别。以下是主要模型对 OpenClaw 用户的对比情况，数据已根据截至 2026 年 2 月的官方提供商文档进行验证。
Claude Sonnet 4 和 Claude Haiku 提供 200,000 token 的上下文窗口，是 Anthropic 系列中通过 OpenClaw 可用的最大上下文模型。对于大多数编码会话来说，200K token 足够在无需压缩的情况下连续工作数小时，即使有大型工作区文件也不例外。Claude 模型是 OpenClaw 的默认选择，为 Agent 工作流提供了最佳的能力和上下文大小平衡。
GPT-4o 和 GPT-4o Mini 都提供 128,000 token 的上下文。虽然 128K 已经相当可观，但比 Claude 的 200K 窗口小了 36%，这意味着在长会话中你会更早地触及上下文限制。如果你在使用 GPT-4o 时持续遇到 context_length_exceeded，切换到 Claude 模型可能无需任何配置更改就能彻底消除问题。
Gemini 2.0 Flash 以高达 1,000,000 token 的巨大上下文窗口领跑——是 Claude 的五倍，是 GPT-4o 的近八倍。如果你处理的是庞大的代码库或需要维持超长对话，Gemini Flash 是可用的最友好的上下文选项。但是，免费层将上下文限制在 32,000 token，这实际上是本次对比中最小的选项。请确保你使用的是付费层以获得完整的百万 token 窗口。
通过 Ollama 或类似框架运行的本地模型通常提供 8,000 到 32,000 token 的上下文，具体取决于模型和你的硬件。这些较小的上下文窗口意味着你会更快地触及上下文限制，需要更激进的压缩设置。如果你在运行本地模型时频繁遇到上下文错误，最有效的解决方案通常是切换到具有更大上下文窗口的 API 模型。
选择模型时，不仅要考虑原始上下文大小，还要考虑它与 OpenClaw 开销的交互方式。系统提示词、工具和工作区文件在你发送第一条消息之前就消耗了大约 20,000 到 40,000 个 token，因此 32K 上下文的模型几乎没有空间进行实际对话。要获得舒适的 OpenClaw 体验，128K 应该是你的最低目标，200K 或以上则是理想选择。如果你正在探索模型选项，请查看我们关于在 OpenClaw 中设置 LLM 提供商的指南获取分步配置说明，或阅读关于在 OpenClaw 中配置自定义模型的文章了解如何使用默认配置中未包含的提供商。
如果你需要在多个提供商之间访问具有更大上下文窗口的模型，可以考虑使用 laozhang.ai 这样的聚合 API 服务，它通过单一 API 密钥提供对 Claude、GPT-4o、Gemini 和其他模型的统一访问。这简化了提供商管理，让你无需为每个提供商单独重新配置凭证就能在模型之间切换。
永久预防 context_length_exceeded
预防永远比救火好，通过正确的配置和习惯，你可以将 context_length_exceeded 错误从每天的困扰变成罕见的事件。以下策略针对前文确定的根本原因——不断增长的对话历史、臃肿的工作区注入和保守的默认设置——共同构建起对抗上下文溢出的坚固防线。
使用 /status 和 /context 主动监控。 养成在长会话期间定期检查上下文利用率的习惯，特别是在开始会产生大量工具输出的复杂操作之前。运行 /status 显示整体百分比，/context list 则揭示哪些组件消耗了最多的空间。如果你看到利用率超过 60%，这是一个主动运行 /compact 的好时机，而不是等到错误触发。
设置激进的压缩阈值。 最有影响力的单一预防措施是将 reserveTokens 从默认的 16,384 增加到 40,000 甚至更高。这确保自动压缩在你达到模型限制之前就触发，给压缩过程足够的空间来有效工作。一个 PR（#9620）已被合并，将自动压缩保留缓冲区从 20K 增加到 40K token，反映了社区认识到原始默认值对于实际使用来说太紧的现实。
对长任务进行会话卫生管理。 不要为多小时的任务运行单个马拉松式会话，而是将工作分解为逻辑段落。当你完成一个工作阶段——比如在进入 UI 之前完成数据层——运行 /compact 或使用 /new 开始新会话，并清楚描述你到目前为止完成了什么。这种方法类似于经验丰富的开发者的工作方式：他们频繁提交并重置心理上下文，你的 AI Agent 也能从同样的纪律中受益。
保持工作区文件精简且聚焦。 定期检查你的 AGENTS.md、SOUL.md 和其他工作区文件。删除过时的指令，合并冗余部分，确保每一行都在你有限的上下文预算中占有一席之地。一个精心策划的 5,000 字符工作区文件，远比一个 Agent 必须在过时指令中筛选才能找到相关指导的 20,000 字符庞大文件更有价值。关于管理多个提供商的 token 成本的技巧，请参阅我们的优化 OpenClaw Token 用量指南。
根据你的工作流配置环境。 如果你主要处理小型、聚焦的任务，默认设置可能就够了。但如果你经常进行长时间的调试会话、大规模重构项目或多文件分析，花五分钟调优你的 openclaw.json 是值得的。将 reserveTokens 设置为 40,000，如果你的工作区文件臃肿则将 bootstrapMaxChars 减少到 10,000，如果你不依赖跨会话连续性则考虑禁用内存搜索。这三项更改共同消除了大多数用户 90% 的上下文溢出情况。
理解你工作流的 token 经济学。 不同类型的工作消耗上下文的速率截然不同。在单次工具调用中读取一个大文件可能一次性向你的历史记录添加 10,000 个 token。运行产生冗长输出的测试套件可能添加更多。迭代调试——你读取文件、做出更改、运行测试、读取错误输出、再做更改——是最消耗上下文的工作流，因为每个循环都会将你的指令和工具输出添加到不断增长的历史记录中。如果你知道即将进入上下文密集阶段，请提前主动运行 /compact 以最大化可用空间。
管理 token 成本与管理上下文限制密切相关。上下文窗口中消耗的 token 就是你使用 API 模型时需要付费的那些 token，因此激进的上下文管理也能降低你的 API 成本。关于管理多个提供商的 token 成本的策略，请参阅我们的优化 OpenClaw Token 用量指南，其中涵盖了预算编制、监控和成本降低技术，与此处描述的上下文管理策略相辅相成。
使用 /usage tokens 命令跟踪每次回复的消耗。 /status 显示的是你整体的上下文利用率，而 /usage tokens 分解了每个单独回复消耗了多少 token。这种细粒度视图帮助你识别哪些类型的操作最昂贵——你可能会发现一次文件读取消耗了 8,000 个 token，或者一次测试输出向你的历史记录添加了 5,000 个 token。有了这些知识，你可以调整工作流以避免最消耗上下文的操作，或者至少通过提前压缩来为它们做好准备。
高级故障排除——已知 Bug 和边界情况
即使配置完美，一些 context_length_exceeded 错误源于 OpenClaw 本身的 Bug，而非真正的溢出情况。OpenClaw 项目在 GitHub 上积极跟踪这些问题，了解哪些 Bug 与你相关可以帮助你避免追错方向。以下是截至 2026 年 2 月最重要的已知问题及其当前状态和解决方法。
Issue #7483：上下文溢出检测误报。 这可能是对用户来说最令人沮丧的 Bug，因为即使上下文实际上并未满，错误也会触发。根本原因在于 sanitizeUserFacingText 函数，该函数在某些边界情况下错误地计算了 token 数量，在仍有可用容量时报告溢出。如果你看到 context_length_exceeded 错误但 /status 显示还有充足空间，你很可能触发了这个 Bug。修复已经合并，因此更新到最新的 OpenClaw 版本应该可以解决它。在此期间，运行 /compact 然后重试你的消息通常可以绕过误检测。
Issue #5433：自动压缩未触发。 一些用户报告他们的会话会一直增长直到触及硬限制，而自动压缩从未启动。问题出在错误模式识别逻辑中——来自 API 提供商的某些错误响应格式未被正确识别为上下文溢出信号。PR #7279 改进了错误模式匹配，但如果你运行的是旧版本，解决方法很简单：当你注意到上下文超过 70% 时手动运行 /compact。
Issue #6012：contextTokens 显示错误值。 /status 命令有时显示模型的最大上下文大小而不是实际当前使用量。这使得无法判断你距离限制有多近——无论你的实际使用量如何，你都会看到 "128,000 / 128,000"。修复是一个界面级别的更正，已合并到最近的版本中。如果你在状态输出中看到可疑的整数，请更新 OpenClaw 以获得准确的读数。
Issue #7725：上下文注入导致网关挂起。 当工作区文件或工具输出在单次注入中超过 12,000 个 token 时，网关层可能会无限期挂起而不是返回清晰的错误。这表现为 OpenClaw 似乎冻结而不是显示明确的上下文错误。解决方案是优化上下文注入管道以优雅地处理大型负载。如果你的 OpenClaw 在文件读取或工具操作期间似乎冻结，这可能就是罪魁祸首，更新到最新版本即包含此修复。
Issue #5771：全新会话上的上下文溢出。 这可能是最反直觉的 Bug：一些用户在全新会话中、发送任何消息之前就遇到了 context_length_exceeded。原因是内存搜索在会话初始化期间注入了大量历史上下文。解决方法是禁用内存搜索（在你的配置中设置 memorySearch.enabled: false），永久修复涉及批量处理内存嵌入以遵守每次注入 8,192 token 的限制，如相关 Issue #5696 中的 buildEmbeddingBatches 修复所述。
Issue #9157：工作区注入浪费 93.5% 的 Token。 该问题记录了一个严重的低效问题，即工作区文件在每条消息上都被重新注入，在复杂工作区中每条消息消耗约 35,600 个 token。在多消息对话中，这意味着花在工作区注入上的 93.5% 的 token 是冗余的——相同的文件一遍又一遍地重新发送。修复引入了条件加载，仅在工作区文件自上次注入后发生更改时才注入。如果你运行的是旧版本且有复杂的工作区，仅这一个 Bug 就可能导致了你大部分的上下文溢出问题。更新到最新版本或减小工作区文件大小都是有效的解决方法。
未解决上下文错误的通用故障排除方法。 如果上述已知问题都不符合你的情况，请遵循以下系统化方法：首先，使用 openclaw --version 检查你的 OpenClaw 版本，如果不是最新版本就进行更新。其次，检查 ~/.openclaw/logs/ 中的日志，获取可能揭示特定故障点的详细错误信息。第三，尝试用最小配置重现问题——创建一个没有工作区文件的全新项目，看看错误是否仍然存在。如果存在，问题可能出在模型端而非配置端。如果在最小配置下消失了，逐步添加回你的工作区文件和设置，直到识别出触发溢出的具体元素。这种二分查找方法是隔离配置相关上下文问题的最快途径。
常见问题
OpenClaw 中的 context_length_exceeded 是由什么引起的？
该错误发生在你请求中的总 token 数——包括系统提示词（约 9,600 token）、工具 Schema（约 8,000 token）、工作区文件（可变，最高 35,600 token）、对话历史（随时间增长）和内存搜索结果——超过了你 AI 模型的最大上下文窗口。最常见的触发因素就是一段长对话，其中历史记录已超出模型的容量。较不常见的原因包括大型工作区文件注入或产生误报的已知 Bug。
如何增加 OpenClaw 上下文窗口？
你无法增加模型固有的上下文窗口大小，但你可以通过以下方式有效获得更多可用上下文：（1）切换到具有更大窗口的模型（Gemini 2.0 Flash 提供 1M token，Claude 模型提供 200K），（2）通过 bootstrapMaxChars 减少工作区文件注入，（3）禁用内存搜索以回收 token，（4）通过更高的 reserveTokens 值配置更激进的压缩。这些方法组合使用，可以使你的可用上下文与默认设置相比有效提升两到三倍。
什么是 OpenClaw 压缩，它会丢失数据吗？
压缩是 OpenClaw 内置的总结对话历史的机制。当触发时（自动或通过 /compact），系统会创建对话较旧部分的精简摘要，同时保留最近的消息原样不变。摘要捕获关键决策、文件位置和重要上下文，但丢弃冗长的中间步骤。压缩结果保存到 JSONL 会话文件中，因此它在重启后仍然持久存在。你确实会丢失早期交流的逐字细节，但摘要中保留了基本信息。
如何完全清除 OpenClaw 内存？
要清除所有内存并完全重新开始，使用 /reset 清除对话历史和会话特定内存。如果只想清除对话而保留内存，使用 /new。如果你想清除存储的内存数据库本身，可以删除 ~/.openclaw/memory/ 中的内存文件。请注意，清除内存是不可逆的——已删除的内存条目没有撤销操作。
为什么 context_length_exceeded 会在全新的 OpenClaw 会话上发生？
这通常由以下两种情况之一引起：（1）内存搜索注入在会话初始化期间加载了太多历史上下文（参见 Issue #5771），或者（2）极大的工作区文件在对话开始之前就消耗了大部分上下文窗口。内存相关溢出的修复方法是设置 memorySearch.enabled: false，工作区相关溢出的修复方法是将 bootstrapMaxChars 减小到较小的值如 10,000 字符。两项更改都可以在你的 openclaw.json 配置文件中完成。