openclaw中免费模型上下文需手动约束：contextwindow设为3072（qwen3-4b等量化模型最稳阈值），maxtokens设为1024，并启用mode: "merge"；同时llm层配置max_input_tokens=2560或ollama加--num_ctx 2560，避免超限导致响应慢、截断或任务中断。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你在OpenClaw中启用Qwen3-4B量化版、cherry-aihubmix/coding-glm-4.7-free等免费模型时，若未主动限制其上下文长度，系统可能默认加载全部历史对话或完整文档片段，导致单次请求token飙升至8000+——这相当于让一个轻量模型硬扛本该由Claude Opus处理的负载，不仅响应变慢，还会触发隐性重试和缓存膨胀。
确认当前模型的实际上下文能力
打开终端，执行openclaw llm list，查看目标免费模型的contextWindow字段值。很多本地免费模型（如ollama/qwen2.5-coder:7b）实际支持的最大上下文仅4096 token，但OpenClaw默认可能按8192或更高值加载——这会导致显存溢出或tokenizer静默截断，最终输出不完整甚至中断任务流。
注意：不要依赖models.json中的数值，它只是扫描缓存；必须以openclaw.json中手动配置为准。
修改openclaw.json强制约束上下文窗口
第一步：用文本编辑器打开~/.openclaw/openclaw.json文件。
第二步：在"models" → "providers" → 对应免费模型节点下，添加或覆盖以下两项：
【"contextWindow": 3072】——对Qwen3-4B-Thinking-2507-GPT-5-Codex-Distill-GGUF这类量化模型，3072是实测最稳阈值；设为4096虽理论可行，但会显著增加推理延迟，且无质量提升。
【"maxTokens": 1024】——限制模型单次输出长度，防止其生成冗长解释或重复代码块，这对自动化任务尤其关键。
第三步：确保外层"mode": "merge"已启用，否则重启后配置会被自动重置。
对当前分支的待审变更进行安全评审，检测密钥泄露、SQL注入、XSS、SSRF、权限绕过、危险依赖六类漏洞，生成风险分级报告并在用户批准后修复。适用于PR合并、对外开源、事故复盘。触发词：安全评审、security review、漏洞检查、密钥扫描、我的代码...
同步调整LLM层输入截断参数
方法一：进入config/llm/目录，找到对应模型配置文件（如qwen2.5-coder-7b.json），在"model_config"区块内添加：
"max_input_tokens": 2560——比contextWindow小512，为系统提示词和工具返回留出安全余量。
方法二：若该模型通过Ollama调用，在Ollama模型定义中追加参数：--num_ctx 2560，避免OpenClaw与Ollama两层上下文策略冲突。
⚠️ 避坑提醒：不要把input_length_limit（字符级）和max_input_tokens（token级）混用。前者在网关层截断，后者在模型推理前校验，二者叠加会导致二次截断，引发不可预测的prompt错位。
验证配置是否生效
① 执行openclaw gateway restart重启服务。
② 向OpenClaw发送一条含2800字中文的测试请求（约4200 tokens）。
③ 查看DEBUG日志中[LLM] input token count:行——若显示数值稳定在2560±50，说明LLM层截断已起效；若仍接近4200，则检查Ollama服务是否也同步设置了--num_ctx。
④ 触发一次/compact指令，观察后续对话中历史摘要是否明显变短——这是上下文压缩与新窗口协同工作的信号。
