OpenClaw 出现 `context too large` 错误的五种解决方法

你好，我是茂林，一个AI爱好者，最近一直在折腾OpenClaw/Hermes，踩过老多坑了。我把踩过的坑整理出来，帮你少走弯路。

我遇到的问题：

解决什么问题

当你用 OpenClaw 处理长任务，比如长篇小说创作、大型代码库重构，跑着跑着突然弹出 context too large 错误，任务直接中断。这是 OpenClaw 长任务最常见的问题，我给你提供五种不同层级的解决方法，从轻量到彻底解决。

这个错误本质是：当前对话的总长度超过了你所用大模型的上下文窗口限制。模型一次性能处理的 token 数量有限，对话越长，累积的 token 越多，超出限制就会报错。

最简单也最快速的解决方法：结束当前会话，用一句话总结已经做到哪一步，然后重启任务继续。

断点重启提示词（直接复制）：

我们之前在做：<一句话描述任务，比如：给我的博客写一篇关于AI记忆的文章，已经写完了开头和痛点分析>
接下来请继续完成<具体要做的下一步>

适用场景： 任务已经接近尾声，只是偶然触发，不想做复杂配置。

OpenClaw 内置了上下文压缩命令，你只需要输入：

/compact

智能体会自动总结当前对话中的关键信息，把几千字压缩到几百字，释放上下文空间。

使用步骤：

✅ 优点：内置命令，不用额外配置，一键压缩
⚠️ 注意：压缩会丢失部分细节，关键信息要提醒智能体保留

把不常变的关键信息（项目结构、开发规范、用户偏好）提前存入 memory.md 或者用 memory 技能保存，不要让它们每次都占对话上下文空间。

操作示例：

# 存入记忆（只需做一次）
记住以下项目信息，永久保存：
我的项目放在 ~/work/api，使用 Go 1.22，sqlc 生成代码，chi 路由。

之后每次对话，这些信息自动加载，但不计入当前对话的上下文增长。

如果你的任务真的很长（比如写一本小说、重构一个项目），不要一次性塞给智能体，主动拆分：

❌ 不好：一次性把 10 章小说需求全发过来
✅ 好：一章一章来，写完一章确认没问题再写下一章

每章完成后，新建会话写下一章，上下文永远不会溢出。

如果你经常处理长任务，最彻底的方法就是换一个上下文窗口更大的模型：

✅ 优点：一劳永逸，基本不用再担心溢出
❌ 缺点：API 成本会相应增加