OpenClaw context_length_exceeded 怎么修复？压缩失败后保留工作继续运行

OpenClaw 报 context_length_exceeded 时，先保存已经完成的动作与仍待处理的请求，再检查失败请求实际使用的模型、上下文窗口和输入来源。 如果主要是旧历史占满窗口，在支持手动压缩的运行时使用 /compact；如果连压缩请求也失败，先核对文件和工具结果，再携带简短交接记录用 /new 开新会话。恢复的目标是让未完成任务继续，并避免重复执行已经发生的动作。

上下文超限不只由聊天字数引起。系统指令、工具定义、工作区文件、检索结果、附件和工具输出都可能进入一次请求。/status 的百分比是诊断线索，不能单独证明请求足够小；更大摘要模型也不会扩大前台模型的窗口。官方上下文说明和压缩说明分别解释了这些边界。

以下流程依据 2026 年 10 月 4 日核对的第一方说明，以及 10 月 5 日核对的压缩配置说明。命令与示例用于在你自己的 Gateway 环境中操作；这里没有执行真实 OpenClaw 恢复或付费模型调用。

先保住工作，别把报错当作“什么都没发生”

出现错误后，暂停反复重发整条任务。模型请求失败时，前面的文件修改、命令执行或外部工具动作可能已经完成。停止运行只能阻止后续恢复和重试，不能撤销已经发生的动作；已经提交的压缩也不会因取消而回滚。当前内置运行时说明明确区分了取消与回滚。

先从聊天记录、实际文件和工具返回中保存以下内容。会话已无法回答时，直接在编辑器或笔记中整理，不依赖再发一条长请求来生成交接。

例如：工具已经写好一个文件，而模型在读取长测试日志后超限，应保留文件和测试结果，下一会话从核对文件、读取最早错误开始。不要把整个生成命令重新跑一遍，更不要在无法确认外部状态时重复提交、发送或购买。

内置运行时可以在工具结果已经落定后压缩，并利用已记录结果继续，保留原请求而不重放已完成动作。仍有待完成工具、审批或取消时，保持相应流程，不能据此声称每种中断都会自动恢复。官方恢复条件也适用于判断是否应等待当前运行结束。

查失败请求，而不是只看窗口百分比

在发生错误的聊天会话中，分别发送这些命令：

/status
/context list
/context detail

它们是聊天命令，不是在终端里直接运行的 shell 命令。在 Gateway 实际运行的主机和服务用户下，查看相应时间的日志：

openclaw --version
openclaw logs --follow

logs --follow 会持续输出；找到对应错误后用 Ctrl+C 结束查看。保留版本、失败时间、请求 ID、错误原文、实际 provider/model，以及是否发生回退。共享记录时去掉凭据和私人内容。

/context list 用来找注入文件与粗略大小，/context detail 用来区分系统指令、工具 Schema 和可压缩的历史。如果还没有本会话的运行报告，/context map 可能无法绘图；此时 list、detail 或 /context json 仍可给按需估算，不必为了得到一张图重复大任务。上下文诊断文档说明了各命令用途。

Control UI 的 Prompt budget (last run) 只有在最近运行与当前模型、有效上下文上限匹配时才使用那次预算。改过模型或上限后，它会暂时显示 Context window；旧 token 数仍是近似值。低百分比不能排除“大附件刚加入”“工具结果突然变大”或“实际请求走另一个较小模型”的情况。

按下面的证据选择下一动作：

429 与超限可以先后出现，但 429 本身不是上下文错误。当前回退取决于模型选择来源：配置默认或自动选择可以使用相应备用链，用户明确固定的会话模型通常严格使用该选择；成功的回退也只作用于当前回合。于是，界面中选定的模型可能不同于真正失败或回答的模型。当前 model failover 说明是核对这类情况的依据。

/compact 也失败时，按错误类型恢复

在支持手动压缩的内置 OpenClaw 运行时中，可以带一个简短重点：

/compact 保留原目标、未完成请求、已修改文件、已执行动作和检查结果；准确保留路径与标识符。

摘要重点用于提醒保留什么，不能代替前面已经保存的真实记录。内置压缩把旧对话整理为摘要、保留近期消息，并保持工具调用与对应结果成对；完整历史仍保留在本地。摘要不会逐字保留一切，内置摘要也不读取图片像素，关键视觉信息应另存原图和文字说明。手动压缩与摘要输入说明给出了运行时差异。

如果当前运行时不支持手动压缩，就直接使用保存后的新会话路径。某些原生后端有自己的压缩策略，不能把带重点的命令当成全部后端都支持的功能。

摘要请求本身超限

先找日志中失败的是前台请求还是摘要请求，确认摘要实际使用哪个模型及窗口。压缩也要发送旧消息、已有摘要、摘要指令和输出预留；切到一个小窗口摘要模型，可能让压缩请求先失败。

恢复顺序是：缩小刚刚追加的资料和工具输出；检查已配置摘要模型能否承载其输入；需要更换时选已经有权限、已接入且窗口匹配的模型。agents.defaults.compaction.model 只选择摘要模型，显式覆盖有独立回退规则，不能假设它会自动使用前台备用链。即便摘要成功，前台仍必须容纳固定指令、保留历史、待处理请求及回复空间。摘要模型与预算说明支持这一判断。

如果完整固定输入或当前附件本身已超过前台容量，反复压缩旧历史不会解决。把资料拆成可独立处理的部分，先完成一部分并保存结果，或使用真正具备所需窗口的路线。

摘要超时、质量检查失败或其他错误

内置 safeguard 模式的质量检查失败时，会保留原历史并报告压缩失败；不要为消除报错默认关闭质量检查。确认日志是否有真实进展、服务是否响应，以及错误是否来自摘要账号或模型，再决定修正该处问题。

当前 timeoutSeconds 默认 180 秒表示没有有效流式进展的等待窗口，不是整个压缩固定最多 3 分钟。真实流式 token 会重启这个计时，完整内置压缩最多 10 个窗口，默认合计 30 分钟。它不意味着应该等足半小时，取消和前台运行终止仍会停止恢复。10 月 5 日核对的配置说明给出了具体语义。

自动压缩还有一个需要单独核对的例外：运行仍有效时，摘要截止时间到达，或收到 HTTP 408/504，内置运行时可以提交没有新摘要的压缩，保留近期消息、未处理请求和先前摘要后继续。日志会出现 summary=deterministic 的超时降级记录。较早且从未进入摘要的事实可能已离开模型上下文，之后的压缩不会自动把它们带回来；原始记录仍可查阅。手动 /compact、其他摘要错误以及已取消运行不享有同样保证。自动压缩超时说明解释了这个取舍。

看到这种降级后，从保存的记录补入原任务必需的遗漏事实，先让模型确认目标、状态与下一动作；不要因已经继续回复就假定所有历史都保住了。

没有可用摘要：用交接记录开新会话

先核对已改文件与已完成动作，然后发送 /new。/reset 也是手动开始新会话的入口，不能把它解释成删除持久记忆的清理命令。会话生命周期说明没有给这两者附加“删除 memory 目录”的操作。

把自己的实际信息填入这份交接记录，再发给新会话：

目标：我要完成……
已完成：文件……已经修改；检查……的结果为……。
已执行动作：……已成功，结果/ID 为……；……的状态尚未知。
必须保留：……版本、……路径、……决定、……限制。
未完成请求：……
下一步：先读取……核对状态，只继续……。
停止条件：若发现……，先报告差异，不重复执行未知状态的动作。
请先复述目标、已完成状态和下一步；确认前不要修改文件或执行外部动作。

新会话仍会加载系统指令、工具定义和工作区内容。只交接与当前任务有关的路径、状态和关键证据，不把全部旧历史重新粘进去；需要原始资料时，明确按需读取的位置。不要删除历史或记忆目录来“释放窗口”，它们可能正是恢复工作所需的依据。

算清楚预算：固定输入、历史和待处理请求都要占空间

可以先用下式理解一次前台请求的压力：

固定指令与工具定义 + 保留摘要/历史 + 当前输入/工具结果 + 回复预留 ≤ 实际可用窗口

这里是排查用的预算关系，不是某家服务商的精确 tokenizer。附件计量、隐藏包装、输出限制和运行时规则会改变实际结果，最终要结合对应请求的错误与使用量。

假设实际窗口为 32,768 tokens，固定指令与工具占 9,000，保留摘要与近期历史占 12,000，新输入占 5,000，再预留 8,192，则合计 34,192，超出窗口 1,424。历史压缩过一次不等于已经能运行；把待处理输入缩到 2,000 后，同样假设下合计 31,192，才有 1,576 的余量。这些数字用于演算，并非本站运行结果或你的实际预留。

当前内置运行时的默认压缩预留为 20,000 tokens，且不超过活动模型窗口的四分之一。对 32,768 的窗口，这个默认预留是 8,192；对至少 80,000 的窗口，默认仍是 20,000。手动压缩的 keepRecentTokens 默认 20,000 是近期历史的切分预算，不能与预留直接相加后当成通用配置配方。压缩设置文档说明了这两种数值的用途。

当自动压缩已经得到完整前台请求信息时，它会同时考虑系统指令、工具 Schema、待处理输入和输出预留，必要时少保留近期消息。早期预检查还没有这些完整信息时，只按历史估算，不能保证已经留下足够空间。因此，验证必须看后面的真实请求，不能只看“压缩完成”。

新会话仍然超限：先检查加载窗口和固定开销

对于 LM Studio，已加载实例的有效上下文优先于模型宣传的最大值。例如目录写着支持 128K，但实际实例只加载了 16K，不能只在 OpenClaw 元数据里填 128K 就认定容量扩大。需要在实际后端准备足够上下文的实例，再核对 OpenClaw 使用的实例和真实响应。LM Studio 的实例与上下文说明对此有明确区分；首次接入步骤可看OpenClaw 模型配置指南。

固定开销过大时，用 /context detail 找具体来源。把一次性分析与长日志移到可按需读取的文件，保留项目长期规则与安全约束，避免靠删掉必要指令“修好”请求。bootstrapMaxChars 默认 20,000、bootstrapTotalMaxChars 默认 60,000 的单位是字符，并非 token，也不表示这些文件一定全部注入；应看 raw/injected 与是否截断。工作区注入规则提供了准确口径。

工具裁剪、历史压缩和记忆保存分别解决什么？

三种机制可配合使用，但不要互相替代：

先控制新的工具输出，通常比不断补救历史更直接：搜索时限定文件或目录，读日志时先看第一条错误与相邻栈，长网页先定位所需章节。完整原件留在文件里，交给模型的是当前判断需要的部分。工具裁剪也保护近期内容，不会自动把刚刚产生的大结果全部清掉。

当前 pruning 不能统一描述为“所有提供商默认开启、只存在 RAM 中”。Anthropic 插件会给未显式配置的相关认证设置 cache-ttl；其他提供商默认关闭。直接 Anthropic API key、原生端点使用服务端工具结果清理；其他符合条件的路线使用客户端 TTL 裁剪。客户端裁剪视图会记录在隐藏的会话记录标记中，重启后仍可恢复，原工具结果保留。关闭 mode 只停止新裁剪，已有视图会继续使用，直到相应结果离开压缩后的活动历史或开始新会话。当前 session pruning 文档比笼统的“清空缓存”说法更适合作为操作依据。

配置要按版本核对，别复制固定的 40K 配方

修改前用 openclaw config file 找活动配置，保存原值与可恢复副本；查看当前安装版支持的配置说明，再精确修改相关项。修改后用 openclaw config validate 检查，按 CLI 给出的加载提示确认正确 Gateway 已生效。当前 config CLI 文档说明：校验不启动 Gateway，通过本地 schema 也不证明上游接受请求。

尤其要纠正旧例子里的字段归属：softThresholdTokens 属于 agents.defaults.compaction.memoryFlush，是记忆保存相对于压缩阈值提前多少 token 的间隔，不是 memorySearch 的检索输出上限。

下面只展示这一字段的当前配置位置，合并时保留你的其他配置；4,000 是文档默认值，并非要求把每台机器调成这个数：

{
  "agents": {
    "defaults": {
      "compaction": {
        "memoryFlush": {
          "enabled": true,
          "softThresholdTokens": 4000
        }
      }
    }
  }
}

按记忆保存文档的默认示例，窗口 32,768，预留 8,192，提前间隔 4,000，则记忆保存触发点为 20,576，阻塞式压缩触发点为 24,576；适用的服务端阈值可能使后者更晚。关掉 memory flush 不等于关掉历史压缩，也不能修复一个已经过大的请求。

旧的 reserveTokens、reserveTokensFloor 或“40K 缓冲 + 固定近期历史”示例不要直接粘进配置。当前文档给出了内置预留和 keepRecentTokens 的语义；旧字段是否仍被你安装的版本接受，要看那个版本的 schema，不能只凭新文档未列出就断言全部版本不支持。网上“5 分钟彻底修复”“连续 800 轮”的个别旧文章也不能作为你这条路线的容量或稳定性保证。

需要对工具循环提前检查时，可核对当前可选的 agents.defaults.compaction.midTurnPrecheck.enabled：默认关闭，开启后会在工具结果追加、下一模型调用之前检查压力，并使用已有的裁剪或压缩恢复路径。它不能保证全部大结果都可恢复。maxActiveTranscriptBytes 则是另一个主动开启的字节阈值，不等于 token 窗口，也不同于 memory flush 的字节触发项；不应把配置页示例中的 20mb 当通用默认值。完整配置说明可用于按具体原因选择这些选项。

怎么确认原任务真的恢复了？

完成压缩、缩小输入或新会话交接后，按这个顺序验证：

1. 确认关键状态。 对照自己保存的文件、结果 ID 和检查记录，请模型复述当前目标、已完成工作、未完成请求及下一步。有差异先补证据，不进入执行。
2. 完成一次小请求。 使用同一实际 agent、模型路线和合理输入，让回复正常结束；排除“首个 token 出现，但随后仍报错”与“备用模型回答”的情况。
3. 验证需要的工具。 原任务需要文件读取，就用一个已存在、非敏感的小文件验证真实读取；不要仅凭模型打印出工具 JSON 判断成功。
4. 只继续未完成部分。 从缩小后的读文件或检查动作开始，确认所需结果真实存在，再逐步恢复任务范围。
5. 检查后续预算。 看这次新运行的匹配预算、实际使用量和日志。确认下一轮资料或工具结果加入后仍可运行，而不是立即重复同样超限。

压缩次数增加说明发生了压缩，Gateway 正常说明服务可用，使用率下降说明估算减少；这三者都不能单独证明原任务完成。上下文 token 也是窗口估算或使用报告，账单可能累计多次调用、缓存读写和不同输出；不能把单次上下文 token 数直接当最终收费。运行计数与预算说明明确区分了相应口径。

出现下面的情况时停止原样重试：新会话短输入仍超限；同一摘要错误未改变却反复出现；无法确认已执行动作的状态；错误已变为认证、额度或功能资格问题。提交排障信息时保留版本、时间、准确错误、实际模型/实例、请求预算、最近新增内容与已采取动作。先解决新的阻塞，随后再恢复未完成任务。

常见问题

OpenClaw 上下文太长，直接 /new 就能解决吗？

历史过长时可以减轻输入，但应先保存工作与未完成请求。新会话仍有系统指令、工具定义和工作区注入；固定开销、附件或实际模型窗口有问题时，开新会话也可能超限。上下文组成说明支持这个区别。

/reset 会删除持久记忆吗？

不能把它当作删除持久记忆的命令。官方把 /new 和 /reset 列为手动开始新会话的入口；当前上下文与磁盘上的记忆是不同对象。恢复前保存关键记录，不删除 memory 目录或历史来代替诊断。会话说明给出了相应生命周期。

换一个更大摘要模型，就能增加上下文吗？

它可以帮助合适的摘要请求运行，但不会扩大前台模型窗口。前台仍要容纳系统指令、工具定义、摘要、近期历史、当前输入和回复预留。压缩预算说明对此有直接说明。

为什么压缩显示完成，模型却忘了早期信息？

摘要本身有损，自动压缩超时降级还可能保留旧摘要而舍去更早、尚未摘要的事实。应从真实记录补回原任务必需内容，核对当前状态后继续；完整历史保留不等于它仍全部在模型窗口里。自动压缩说明解释了这个例外。

把 contextWindow 填成 128K，就能修复本地模型吗？

只有后端实际支持并加载了足够上下文，且 OpenClaw 使用相应实例时，声明才与运行能力一致。LM Studio 的已加载窗口优先于宣传最大值；单改客户端数字不能证明后端扩大容量。LM Studio 文档是核对入口。