4.6 KiB
4.6 KiB
title, type, tags, date
| title | type | tags | date | |||||
|---|---|---|---|---|---|---|---|---|
| 养虾日记4：一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑 | source |
|
2026-04-10 |
Source File
Summary（用中文描述）
- 核心主题：OpenClaw AI Agent 系统中"Context Limit Exceeded"错误的深度排查与解决
- 问题域：OpenClaw 的模型路由、Compaction 机制与 Telegram Channel 配置的交叉地带
- 方法/机制：通过 Gateway 日志（
openclaw logs）定位问题根因——模型回退（Fallback）机制导致 Telegram Channel 绑定了只有 16K context 的 deepseek-reasoner，而 OpenClaw 的 safeguard 模式又预留 16K 给 compaction，实际可用空间为 0 - 结论/价值：不要轻信表面错误信息；OpenClaw 全局配置与 Agent 级别模型配置是两层独立的配置体系；Gateway 日志是排查分布式 Agent 问题的关键工具
Key Claims（用中文描述）
- 星枢的 Telegram Channel 被回退到了只有 16K context window 的 deepseek-reasoner 模型，而非用户默认的 MiniMax-M2.7（200K）
- OpenClaw 的 safeguard 模式会为 compaction 预留 token 数（reserveTokens=16384），两者叠加导致 context window 完全被耗尽
- 问题配置不在
openclaw.json全局 compaction 配置里，而在 OpenClaw 的 agent 路由规则中，所以修改全局 compaction 配置无效 - Fallback 触发原因包括：API 服务不可用（503/502/429/Timeout）、Token 长度隐式溢出预判、配置文件优先级覆盖、负载均衡随机切换
Key Quotes
"deepseek-reasoner 的 context window 只有 16K？" — 发现模型被切换后的震惊 "好家伙，这谁扛得住" — 得知 16K context + 16K reserve = 0 可用空间后的反应 "别小看任何报错，也别急着改配置。先问一句：到底哪儿出问题了？" — 核心教训总结
Key Concepts
- Context-Window：模型的上下文窗口大小，MiniMax-M2.7 为 200K，deepseek-reasoner 仅 16K
- Compaction：OpenClaw 的上下文压缩/压缩保护机制，safeguard 模式会预留一半 context 给 compaction
- Fallback-机制：当主模型不可用或触发特定条件时，自动切换到备选模型
- Agent-Routing-Rules：OpenClaw 的 agent 级别模型配置，独立于全局 compaction 配置
Key Entities
- OpenClaw：自托管 AI Agent 系统，星枢（xingshu/main agent）运行在其上
- 星枢：xingshu/main agent，星枢通过 Telegram Channel 与用户交互
- MiniMax-M2.7：用户默认使用的模型，context window 为 200K
- deepseek-reasoner：回退备选模型，context window 仅 16K，导致问题的元凶
- openclaw logs：Gateway 日志工具，用于排查 OpenClaw 系统问题
Connections
- 养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战 ← series_prequel ← 养虾日记4
- 养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享 ← series_prequel ← 养虾日记4
- 养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统 ← series_prequel ← 养虾日记4
- 养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流 ← series_sequel ← 养虾日记4
- 养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录 ← related ← 养虾日记4（均为 OpenClaw 调试实战记录）
- OpenClaw ← uses ← Compaction（OpenClaw 通过 Compaction 机制管理长对话）
- 星枢 ← runs_on ← OpenClaw（星枢 agent 运行在 OpenClaw 系统上）
- 星枢 ← connected_to ← Telegram（Telegram Channel 是星枢的对话入口）
Contradictions
- 无冲突——本文为调试经验分享，与其他养虾日记系列构成互补关系（养虾1-3为使用场景本文为运维调试）
Lessons Learned
- 不要默认认为错误信息就是表面意思——「Context limit exceeded」不一定是因为对话太长，可能是模型配置本身就有问题
- 两层配置要分清：全局 compaction 配置和 agent 模型配置是两码事，改全局不行就得往 agent 级别去找
- 日志真的有用：Gateway 日志把问题写得明明白白，只是之前没仔细看
- 工具/系统越复杂，问题的隐藏路径越深：OpenClaw 这种分布式 agent 系统，问题可能藏在 session、memory、model config、routing rules、compaction 策略等多个地方