尧图网站建设 
1. OpenClaw 上下文控制从报错到配置落地OpenClaw 的上下文控制机制说白了就是解决一个很现实的问题对话一长、工具一多、文件一大模型就开始报context_length_exceeded或者干脆model crashed。Context、contextWindow、contextTokens、compaction 这几个词看着像一家人实际各管一段。Context 是每次请求真正发给模型的全部内容contextWindow 是模型能吃下的上限contextTokens 是 Agent 侧提前设的预算compaction 则是在快撑爆之前把旧对话压成摘要。适合谁看正在用 OpenClaw 接本地模型或云端模型、被上下文溢出反复折磨、想搞明白openclaw.json里那几个参数到底怎么填的人。我试过把contextWindow直接填成模型标称的 128000结果本地推理服务只开了 8k 的 KV Cache请求一上去就崩。后来才明白OpenClaw 本质是每次请求重新构建一个完整 promptContext 不等于 memory磁盘上的记忆可以重新加载但当前请求里塞进去的 system prompt、对话历史、工具调用与返回、附件转录、压缩摘要全都实打实吃 token。最容易被忽略的是工具 schema 和文件注入它们不是聊天记录却占了大头。这篇就围绕 Context、contextWindow、contextTokens、compaction 这几个核心概念给出一份可复制的openclaw.json配置骨架再配上验证动作和排错思路。你照着改完至少能搞清楚为什么之前会崩以及怎么让对话可持续地跑下去。2. 前置准备TaoToken 与 OpenClaw 的接入关系在动openclaw.json之前得先把模型接入这条链路理顺。OpenClaw 本身不生产模型它是个 Agent 运行时负责拼 prompt、调工具、管上下文。模型从哪来可以是本地推理服务也可以是通过 TaoToken 这类统一接入层去调云端模型。TaoToken 在这里的角色是提供兼容 OpenAI 协议的 API 入口让你在models.providers里填一个baseUrl和apiKey就能用不用为每个模型单独改代码。如果你还没拿到 Key先去控制台创建一个。地址是 https://taotoken.net/console 登录后进 API Keys 页面生成。生成完记得复制保存页面上通常只显示一次。接入文档在 https://taotoken.net/doc 里面写了baseUrl该填什么、api字段选openai-completions还是别的。模型对话想先试试水可以用 https://taotoken.net/model 直接在里面发消息验证模型通不通。长期跑编码或 Agent 任务Coding Plan 在 https://taotoken.net/coding-plan 适合需要稳定额度的场景。这里要强调一点TaoToken 是正规的 API 接入服务不是那种灰色中转。你在openclaw.json里填的apiKey就是控制台生成的那串baseUrl按文档填https://taotoken.net/api对应的路径。别把首页地址直接塞进baseUrl那样请求会 404。前置准备做完下面进入配置正题。3. 可复制配置openclaw.json 上下文控制骨架先看修改前的典型配置长什么样。很多人一开始只填了模型和 workspace没有主动管理机制{ models: { mode: merge, providers: { local-provider: { baseUrl: http://127.0.0.1:1234/v1, apiKey: local, api: openai-completions, models: [ { id: local-model, name: Local Model, contextWindow: 128000, maxTokens: 4096 } ] } } }, agents: { defaults: { model: { primary: local-provider/local-model }, workspace: ~/.openclaw/workspace } }, session: { maintenance: { mode: enforce, pruneAfter: 7d, maxEntries: 200 } } }这份配置的问题在于contextWindow填了 128000但本地服务实际只开了 8k 或 32kOpenClaw 以为模型能吃 128k于是拼命往里塞直到后端崩掉。session.maintenance的enforce模式还会过早删会话文件上下文管理完全交给磁盘清理治标不治本。修改后的配置引入三层防护。第一层是硬限制对齐让 OpenClaw 知道模型真实能力第二层是软预算控制预留安全缓冲区第三层是主动压缩在到上限前自动瘦身。下面这份骨架可以直接复制把PLACEHOLDER换成你的实际值{ models: { mode: merge, providers: { local-provider: { baseUrl: http://127.0.0.1:1234/v1, apiKey: local, api: openai-completions, models: [ { id: local-model, name: Local Model, contextWindow: 32768, maxTokens: 4096 } ] } } }, agents: { defaults: { model: { primary: local-provider/local-model }, workspace: ~/.openclaw/workspace, contextTokens: 24000, compaction: { reserveTokensFloor: 4000, memoryFlush: { enabled: true, softThresholdTokens: 14000, systemPrompt: Session context is filling up. Please archive important information to memory files., prompt: Write key information to memory/YYYY-MM-DD.md; reply with NO_REPLY if nothing to store. } }, subagents: { maxConcurrent: 2, model: local-provider/local-model } } }, session: { maintenance: { mode: warn, pruneAfter: 30d, maxEntries: 500 } } }几个关键点解释一下。contextWindow必须小于等于后端实际 KV Cache 大小本地服务开 32k 就填 32768别虚标。contextTokens建议设为contextWindow的 75% 到 85%这里 32768 的 75% 约 24576取 24000 留出系统提示词和工具定义的隐形开销。reserveTokensFloor是触发压缩的剩余空间阈值当剩余空间小于 4000 token 时开始压缩旧对话。softThresholdTokens要比reserveTokensFloor大这里设 14000意思是剩余空间降到 14000 时先触发 memoryFlush让模型把重要信息写进memory/YYYY-MM-DD.md比正式压缩早一步。工作机制是这样的上下文增长剩余空间降到 14000触发 memoryFlush模型保存关键记忆继续增长剩余空间降到 4000触发 compaction旧对话被压成摘要空间释放。session.maintenance从enforce改成warn避免过早删会话文件上下文管理交给 compaction 处理。如果你用的是 TaoToken 接入云端模型把providers换成对应配置即可{ models: { mode: merge, providers: { taotoken: { baseUrl: https://taotoken.net/api, apiKey: YOUR_TAOTOKEN_API_KEY, api: openai-completions, models: [ { id: MODEL_ID, name: MODEL_NAME, contextWindow: 128000, maxTokens: 4096 } ] } } } }MODEL_ID和MODEL_NAME按接入文档里列出的模型填contextWindow填该模型真实支持的上限。云端模型一般不会像本地那样虚标但contextTokens还是建议留 15% 到 25% 的缓冲。4. 验证请求与成功结果配置改完别急着跑长任务先用诊断命令看上下文占用。OpenClaw 提供几个常用命令/status /context list /context detail /usage tokens/status看当前占用概况/context list列出谁在占空间/context detail做精细分析/usage tokens在正常回复后附加每次回复的 token 使用量页脚。推荐流程是/context list找到最大项再对应优化。我实测下来工具 schema 经常是隐形大头。/context detail会分解最大的工具 schema让你看到什么占主导。如果某个工具的 JSON schema 特别大而你又很少用考虑关掉它。Skills 也有两种成本系统提示词里有一个紧凑的 Skills 列表名称加描述加位置这个列表有实际开销Skill 指令默认不包含模型只在需要时 readSKILL.md。所以别把所有 Skill 都塞进注入列表。验证压缩是否生效可以跑一段长对话观察日志里有没有 compaction 触发记录。当剩余空间降到reserveTokensFloor应该能看到旧对话被总结成摘要条目。同时检查memory/目录下有没有生成当天的 md 文件那是 memoryFlush 的产物。如果这两个动作都没发生说明阈值设得不对或者contextTokens设得太高根本没触发。再验证一下bootstrapMaxChars。默认 20000 字符大文件按文件截断。OpenClaw 默认注入一组固定工作区文件如果存在的话AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md、HEARTBEAT.mdBOOTSTRAP.md仅首次运行。用/context能看到原始大小 vs 注入大小以及是否发生截断。如果某个文件被截断得厉害要么精简文件要么调大bootstrapMaxChars但别调太大否则又吃 token。还有一个contextPruning配置形如{ contextPruning: { mode: cache-ttl, ttl: 30m } }它的作用是删除 tool results 或大输出缓存不影响核心对话历史。适合工具返回大量数据、但那些数据过一会儿就没用的场景。ttl 设 30m 表示 30 分钟后清理缓存。5. 本篇常见错排查第一个坑contextWindow填得比后端实际大。本地推理服务如果只开了 8k 上下文openclaw.json里填 128000请求一上去就崩报model crashed或model reload。解决办法是查后端启动参数LM Studio 看 n_ctxOllama 看 num_ctx填一致的值。第二个坑contextTokens设得比contextWindow还大。这样永远不会触发 compaction因为预算根本没超。contextTokens必须小于contextWindow建议 75% 到 85%。第三个坑softThresholdTokens小于reserveTokensFloor。memoryFlush 应该比 compaction 早触发所以 soft 阈值对应的剩余空间要更大。如果写反了memoryFlush 永远等不到直接进 compaction重要记忆可能丢。第四个坑session.maintenance.mode还是enforcepruneAfter设得很短。这会导致会话文件被过早删除而上下文管理又没配好两头落空。改成warn把pruneAfter拉长到 30d让 compaction 主导。第五个坑工具 schema 太大没察觉。用/context detail看如果某个工具占了几万 token考虑禁用或简化。Skills 列表同理别把所有 Skill 都注入。第六个坑baseUrl填错。TaoToken 的 API 地址是https://taotoken.net/api别填首页。填错会 404 或连接失败误以为是上下文问题。接入文档在 https://taotoken.net/doc 有完整说明。第七个坑压缩本身失败导致崩溃循环。reserveTokensFloor设得太小压缩操作本身需要空间执行空间不够就压不动然后继续涨继续崩。建议至少留 2000 到 4000 token。6. 继续深入诊断、优化与接入入口诊断推荐流程再走一遍/context list找最大项/context detail看工具 schema 分解/usage tokens看每次回复的实际消耗。优化优先级是减少 Tool schemas控制 workspace 文件注入大小开启 compaction设置合适的contextWindow和contextTokens最后才是 pruning。如果你在接入阶段还没拿到 Key去 https://taotoken.net/api-keys 生成然后对照 https://taotoken.net/doc 把baseUrl和api字段填对。想先验证模型通不通用 https://taotoken.net/model 发一条消息试试。长期跑编码或 Agent 任务Coding Plan 在 https://taotoken.net/coding-plan 额度更稳。Claude Code 相关的接入参考 https://taotoken.net/claude-code 。上下文控制不是一次配完就一劳永逸的事。模型换了、工具加了、workspace 文件大了都得重新看/context list。养成改完配置先跑诊断的习惯比崩了再查日志省事得多。 OpenClaw 上下文控制机制：Context、contextWindow 与 compaction 配置实战
1. OpenClaw 上下文控制从报错到配置落地OpenClaw 的上下文控制机制说白了就是解决一个很现实的问题对话一长、工具一多、文件一大模型就开始报context_length_exceeded或者干脆model crashed。Context、contextWindow、contextTokens、compaction 这几个词看着像一家人实际各管一段。Context 是每次请求真正发给模型的全部内容contextWindow 是模型能吃下的上限contextTokens 是 Agent 侧提前设的预算compaction 则是在快撑爆之前把旧对话压成摘要。适合谁看正在用 OpenClaw 接本地模型或云端模型、被上下文溢出反复折磨、想搞明白openclaw.json里那几个参数到底怎么填的人。我试过把contextWindow直接填成模型标称的 128000结果本地推理服务只开了 8k 的 KV Cache请求一上去就崩。后来才明白OpenClaw 本质是每次请求重新构建一个完整 promptContext 不等于 memory磁盘上的记忆可以重新加载但当前请求里塞进去的 system prompt、对话历史、工具调用与返回、附件转录、压缩摘要全都实打实吃 token。最容易被忽略的是工具 schema 和文件注入它们不是聊天记录却占了大头。这篇就围绕 Context、contextWindow、contextTokens、compaction 这几个核心概念给出一份可复制的openclaw.json配置骨架再配上验证动作和排错思路。你照着改完至少能搞清楚为什么之前会崩以及怎么让对话可持续地跑下去。2. 前置准备TaoToken 与 OpenClaw 的接入关系在动openclaw.json之前得先把模型接入这条链路理顺。OpenClaw 本身不生产模型它是个 Agent 运行时负责拼 prompt、调工具、管上下文。模型从哪来可以是本地推理服务也可以是通过 TaoToken 这类统一接入层去调云端模型。TaoToken 在这里的角色是提供兼容 OpenAI 协议的 API 入口让你在models.providers里填一个baseUrl和apiKey就能用不用为每个模型单独改代码。如果你还没拿到 Key先去控制台创建一个。地址是 https://taotoken.net/console 登录后进 API Keys 页面生成。生成完记得复制保存页面上通常只显示一次。接入文档在 https://taotoken.net/doc 里面写了baseUrl该填什么、api字段选openai-completions还是别的。模型对话想先试试水可以用 https://taotoken.net/model 直接在里面发消息验证模型通不通。长期跑编码或 Agent 任务Coding Plan 在 https://taotoken.net/coding-plan 适合需要稳定额度的场景。这里要强调一点TaoToken 是正规的 API 接入服务不是那种灰色中转。你在openclaw.json里填的apiKey就是控制台生成的那串baseUrl按文档填https://taotoken.net/api对应的路径。别把首页地址直接塞进baseUrl那样请求会 404。前置准备做完下面进入配置正题。3. 可复制配置openclaw.json 上下文控制骨架先看修改前的典型配置长什么样。很多人一开始只填了模型和 workspace没有主动管理机制{ models: { mode: merge, providers: { local-provider: { baseUrl: http://127.0.0.1:1234/v1, apiKey: local, api: openai-completions, models: [ { id: local-model, name: Local Model, contextWindow: 128000, maxTokens: 4096 } ] } } }, agents: { defaults: { model: { primary: local-provider/local-model }, workspace: ~/.openclaw/workspace } }, session: { maintenance: { mode: enforce, pruneAfter: 7d, maxEntries: 200 } } }这份配置的问题在于contextWindow填了 128000但本地服务实际只开了 8k 或 32kOpenClaw 以为模型能吃 128k于是拼命往里塞直到后端崩掉。session.maintenance的enforce模式还会过早删会话文件上下文管理完全交给磁盘清理治标不治本。修改后的配置引入三层防护。第一层是硬限制对齐让 OpenClaw 知道模型真实能力第二层是软预算控制预留安全缓冲区第三层是主动压缩在到上限前自动瘦身。下面这份骨架可以直接复制把PLACEHOLDER换成你的实际值{ models: { mode: merge, providers: { local-provider: { baseUrl: http://127.0.0.1:1234/v1, apiKey: local, api: openai-completions, models: [ { id: local-model, name: Local Model, contextWindow: 32768, maxTokens: 4096 } ] } } }, agents: { defaults: { model: { primary: local-provider/local-model }, workspace: ~/.openclaw/workspace, contextTokens: 24000, compaction: { reserveTokensFloor: 4000, memoryFlush: { enabled: true, softThresholdTokens: 14000, systemPrompt: Session context is filling up. Please archive important information to memory files., prompt: Write key information to memory/YYYY-MM-DD.md; reply with NO_REPLY if nothing to store. } }, subagents: { maxConcurrent: 2, model: local-provider/local-model } } }, session: { maintenance: { mode: warn, pruneAfter: 30d, maxEntries: 500 } } }几个关键点解释一下。contextWindow必须小于等于后端实际 KV Cache 大小本地服务开 32k 就填 32768别虚标。contextTokens建议设为contextWindow的 75% 到 85%这里 32768 的 75% 约 24576取 24000 留出系统提示词和工具定义的隐形开销。reserveTokensFloor是触发压缩的剩余空间阈值当剩余空间小于 4000 token 时开始压缩旧对话。softThresholdTokens要比reserveTokensFloor大这里设 14000意思是剩余空间降到 14000 时先触发 memoryFlush让模型把重要信息写进memory/YYYY-MM-DD.md比正式压缩早一步。工作机制是这样的上下文增长剩余空间降到 14000触发 memoryFlush模型保存关键记忆继续增长剩余空间降到 4000触发 compaction旧对话被压成摘要空间释放。session.maintenance从enforce改成warn避免过早删会话文件上下文管理交给 compaction 处理。如果你用的是 TaoToken 接入云端模型把providers换成对应配置即可{ models: { mode: merge, providers: { taotoken: { baseUrl: https://taotoken.net/api, apiKey: YOUR_TAOTOKEN_API_KEY, api: openai-completions, models: [ { id: MODEL_ID, name: MODEL_NAME, contextWindow: 128000, maxTokens: 4096 } ] } } } }MODEL_ID和MODEL_NAME按接入文档里列出的模型填contextWindow填该模型真实支持的上限。云端模型一般不会像本地那样虚标但contextTokens还是建议留 15% 到 25% 的缓冲。4. 验证请求与成功结果配置改完别急着跑长任务先用诊断命令看上下文占用。OpenClaw 提供几个常用命令/status /context list /context detail /usage tokens/status看当前占用概况/context list列出谁在占空间/context detail做精细分析/usage tokens在正常回复后附加每次回复的 token 使用量页脚。推荐流程是/context list找到最大项再对应优化。我实测下来工具 schema 经常是隐形大头。/context detail会分解最大的工具 schema让你看到什么占主导。如果某个工具的 JSON schema 特别大而你又很少用考虑关掉它。Skills 也有两种成本系统提示词里有一个紧凑的 Skills 列表名称加描述加位置这个列表有实际开销Skill 指令默认不包含模型只在需要时 readSKILL.md。所以别把所有 Skill 都塞进注入列表。验证压缩是否生效可以跑一段长对话观察日志里有没有 compaction 触发记录。当剩余空间降到reserveTokensFloor应该能看到旧对话被总结成摘要条目。同时检查memory/目录下有没有生成当天的 md 文件那是 memoryFlush 的产物。如果这两个动作都没发生说明阈值设得不对或者contextTokens设得太高根本没触发。再验证一下bootstrapMaxChars。默认 20000 字符大文件按文件截断。OpenClaw 默认注入一组固定工作区文件如果存在的话AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md、HEARTBEAT.mdBOOTSTRAP.md仅首次运行。用/context能看到原始大小 vs 注入大小以及是否发生截断。如果某个文件被截断得厉害要么精简文件要么调大bootstrapMaxChars但别调太大否则又吃 token。还有一个contextPruning配置形如{ contextPruning: { mode: cache-ttl, ttl: 30m } }它的作用是删除 tool results 或大输出缓存不影响核心对话历史。适合工具返回大量数据、但那些数据过一会儿就没用的场景。ttl 设 30m 表示 30 分钟后清理缓存。5. 本篇常见错排查第一个坑contextWindow填得比后端实际大。本地推理服务如果只开了 8k 上下文openclaw.json里填 128000请求一上去就崩报model crashed或model reload。解决办法是查后端启动参数LM Studio 看 n_ctxOllama 看 num_ctx填一致的值。第二个坑contextTokens设得比contextWindow还大。这样永远不会触发 compaction因为预算根本没超。contextTokens必须小于contextWindow建议 75% 到 85%。第三个坑softThresholdTokens小于reserveTokensFloor。memoryFlush 应该比 compaction 早触发所以 soft 阈值对应的剩余空间要更大。如果写反了memoryFlush 永远等不到直接进 compaction重要记忆可能丢。第四个坑session.maintenance.mode还是enforcepruneAfter设得很短。这会导致会话文件被过早删除而上下文管理又没配好两头落空。改成warn把pruneAfter拉长到 30d让 compaction 主导。第五个坑工具 schema 太大没察觉。用/context detail看如果某个工具占了几万 token考虑禁用或简化。Skills 列表同理别把所有 Skill 都注入。第六个坑baseUrl填错。TaoToken 的 API 地址是https://taotoken.net/api别填首页。填错会 404 或连接失败误以为是上下文问题。接入文档在 https://taotoken.net/doc 有完整说明。第七个坑压缩本身失败导致崩溃循环。reserveTokensFloor设得太小压缩操作本身需要空间执行空间不够就压不动然后继续涨继续崩。建议至少留 2000 到 4000 token。6. 继续深入诊断、优化与接入入口诊断推荐流程再走一遍/context list找最大项/context detail看工具 schema 分解/usage tokens看每次回复的实际消耗。优化优先级是减少 Tool schemas控制 workspace 文件注入大小开启 compaction设置合适的contextWindow和contextTokens最后才是 pruning。如果你在接入阶段还没拿到 Key去 https://taotoken.net/api-keys 生成然后对照 https://taotoken.net/doc 把baseUrl和api字段填对。想先验证模型通不通用 https://taotoken.net/model 发一条消息试试。长期跑编码或 Agent 任务Coding Plan 在 https://taotoken.net/coding-plan 额度更稳。Claude Code 相关的接入参考 https://taotoken.net/claude-code 。上下文控制不是一次配完就一劳永逸的事。模型换了、工具加了、workspace 文件大了都得重新看/context list。养成改完配置先跑诊断的习惯比崩了再查日志省事得多。