在 OpenClaw 里，contextWindow 不是“能填多大就填多大”。
特别是 OpenClaw 4.x 以后，虽然统计逻辑更好了，但在 stream=true 场景下，很多国内模型服务商仍不返回 usage，这会直接影响你对上下文水位的判断。

这篇文章给你一个可落地的设置方法，核心目标是：稳定，不爆窗，可预期。

———

1. 先讲结论

1. 不要把 OpenClaw 的 contextWindow 直接设置成模型官方标称最大值。
2. 建议设置为官方值的 70%~90%（保守场景建议 70%~80%）。
3. 长文档、表格、工具调用多的场景，建议再留更大冗余。
4. 如果你的模型服务在流式不返回 usage，一定要在网关层补 usage 粗算（国产大模型 1token≈3-4英文字符 1token≈1.3汉字）。
5. 没有自建网关时，可以用开源项目：
   https://github.com/answerlink/llm-gateway-lite

———

2. 为什么不能“顶格配置”上下文

OpenClaw 的上下文控制是“usage累加 + 增量估算”的组合逻辑。
问题在于：

1. 上游 usage 不完整

• 很多服务商在 stream=true 时返回 usage=null。
• 这会导致会话内已用 token 统计偏弱或滞后。

2. 增量是估算，不是模型官方 tokenizer 精算

• 新增内容（比如刚读进来的文档段落）通常是估算值。
• 不同模型 token 规则不同，估算可能偏高或偏低。

3. 真实请求结构会膨胀

• 工具调用参数、系统提示词、会话包装、消息结构化字段都会占 token。
• 这些在“肉眼看文本长度”时很容易被低估。

所以配置到官方上限，实战里很容易撞到上游 400（超上下文）。

———

3. OpenClaw 4.x 的变化（你需要知道的重点）

OpenClaw 4.x 之后，会尽量优先使用模型返回的 usage 做累计，这是正确方向。
但在 stream=true 且上游不给 usage 时，仍然要依赖估算兜底。

换句话说：
4.x 更准确了，但“上游 usage 缺失”这个现实问题并没有自动消失。

———

4. 实用配置策略（建议直接照做）

4.1 建议的安全系数

1. 官方 200k 模型

• 建议先配 140k~170k。
• 生产稳定优先建议 150k 左右。

2. 官方 128k 模型

• 建议先配 90k~110k。
• 稳定优先可先用 100k。

3. 你有大量文档注入、表格解析、工具返回长文本

• 再额外下调 10%~20%。

———

4.2 配置示例（openclaw.json）

{
“models”: {
“providers”: {
“default”: {
“models”: [
{
“id”: “claw-primary”,
“name”: “claw-primary”,
“contextWindow”: 150000,
“maxTokens”: 8192
}
]
}
}
},
“agents”: {
“defaults”: {
“compaction”: {
“mode”: “safeguard”,
“reserveTokensFloor”: 20000
}
}
}
}

reserveTokensFloor 建议不要太小，给 compaction 留出缓冲空间。

———

4.3 观察指标

重点看这三项：

1. /status 里的 Context: x/y 占比是否长期高于 80%。
2. 是否出现频繁 compaction。
3. 是否出现上游 context overflow 或输入长度超限 400。

如果频繁告警，先降 contextWindow，不是先加。

———

5. 流式不返回 usage，怎么办

最推荐：在 AI 网关层补 usage 粗算，并保留冗余。

目标不是“绝对精确”，而是“稳定可控”：

1. 统一统计 prompt/output 的近似 token。
2. 与 OpenClaw 侧会话统计口径尽量一致。
3. 保守策略：宁可略高估，也不要低估。
4. 对长文档和工具回包做截断/摘要前置。

可参考项目：
https://github.com/answerlink/llm-gateway-lite

6. 一句话总结

OpenClaw 的上下文配置要遵循：官方上限 - 安全冗余 - 真实链路误差。
特别是在 stream=true 且上游不返回 usage 的现实里，contextWindow 必须保守设置，并尽量在网关层补 usage 统计。这样系统才会稳定。