OpenClaw 上下文变短的原因与扩容做法

如果 OpenClaw 支持切模型，先把窗口拉大最省事。比如：

• Claude Opus：200K tokens
• GPT-4 Turbo：128K tokens

配置上大致是这样：

# 修改配置文件（示例路径）
vim ~/.openclaw/config.json

# 设置模型参数
{
  "model": "claude-opus-4",
  "max_context_tokens": 200000
}

这招简单，但不是所有项目都值得一直开大窗口。大窗口更像缓冲垫，不是无限仓库。

把长对话切成段

一个子任务做完就收尾，别让它在同一会话里无限延伸。比如修完认证模块，就开新会话处理支付模块。新会话里只带一句足够清楚的摘要，别把整个历史拖过去。

让工具只看你关心的文件

请求要具体一点，别一上来就让它'优化整个项目'。

❌ 不推荐：帮我优化这个项目的性能
✅ 推荐：只看 src/api/handler.py，优化其中的数据库查询

这个差别很大。前者大概率会扩散上下文，后者更容易把 token 花在刀刃上。

把项目知识放到外部存储里

设计文档、API 规范、历史决策，没必要每次都塞进对话。单独放到向量数据库或者对象存储里，需要时检索相关片段再喂给 OpenClaw，会稳得多。它不算优雅，但对大项目很实用。

先做摘要，再做细活

长对话开始前，先让 OpenClaw 给核心模块出一版简短摘要，后面只引用摘要，不要反复读全量代码。

请先阅读 src/core/ 下所有文件，为每个文件生成 3 句话摘要，后续对话中只引用摘要而非完整代码

只输出增量改动

如果每次都回整份文件，重复内容会迅速吃掉窗口。改成只输出 diff，性价比高得多。

后续所有代码修改，只输出 unified diff 格式的改动部分，不要重复输出未修改的代码

不同场景下怎么选

单文件 Bug 修复

这种场景最轻。直接点文件、点问题、点修改，别扩大到整个仓库。

多模块功能开发

适合拆成几轮，每轮一个模块。做完就归档，不要把所有子任务塞在同一个会话里。

架构重构

先让工具出重构计划，再分阶段执行。计划阶段吃一点上下文没关系，执行阶段最好切会话，不然很容易边改边丢背景。

代码审查和学习

这类场景最容易被'讲解'拖垮上下文。更好的办法是把笔记放在外部工具里，OpenClaw 只负责具体问题分析。

和其他工具比，差别主要在哪

如果是短平快的修改，GitHub Copilot 就够了。要做多轮深度协作，OpenClaw 和 Cursor 更合适。超大项目则别指望单靠聊天工具，还是得配检索和外部知识库。

FAQ

OpenClaw 支持无限上下文吗？

不支持。只要底层还是大模型，就绕不开窗口大小。那些号称'无限上下文'的方案，通常是外部索引加检索，不是真正把所有内容塞进模型。

清空历史会让它失忆吗？

会。它不会在后台替你长期记住项目知识。重要决策最好放到 DECISIONS.md 这类文件里，别只靠聊天记录。

付费版上下文会更长吗？

通常会，前提是它解锁了更大的模型窗口。

为什么它会忘掉刚刚改过的东西？

常见原因就三个：窗口满了、会话断了、工具调用没把状态更新进去。重大修改后让它复述一遍，能少踩很多坑。

能手动控制它记住什么吗？

大多数工具做不到很细。比较靠谱的办法是每轮都把关键背景讲清楚，尤其是涉及认证、支付、架构决策这类内容时。

结尾

OpenClaw 的上下文短，不是单一问题，而是模型窗口、会话策略和多文件场景一起叠出来的结果。真要缓解，靠的不是'让它更聪明'，而是把会话拆开、文件收紧、知识外置。大项目里这么做不算漂亮，但很管用。