5.1 KiB
5.1 KiB
title, type, tags, date
| title | type | tags | date | |||||
|---|---|---|---|---|---|---|---|---|
| 养虾日记4：一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑 | source |
|
2026-04-10 |
Source File
Summary（用中文描述）
- 核心主题：OpenClaw Agent 系统的 Context Limit 错误深度排查——从表象修复（调整 compaction 配置）到找到根本原因（Telegram channel 绑定了只有 16K context 的 DeepSeek 模型）
- 问题域：OpenClaw Telegram Channel 配置、模型 Fallback 机制、Context Window 管理
- 方法/机制：通过 Gateway 日志定位到模型被切换为 deepseek-reasoner（16K context），safeguard 模式预留 16K tokens 导致实际可用空间为 0；问题根源在 Agent 路由规则而非全局配置
- 结论/价值：错误信息 ≠ 问题根因；分层配置需要分层排查；日志是系统状态的最直接反映
Key Claims（用中文描述）
- 星枢 Telegram Channel 触发「Context limit exceeded」，直接原因并非对话历史过长，而是当前使用的模型（deepseek-reasoner）context window 仅 16K
- OpenClaw safeguard 模式在 compaction 时预留 16K tokens，与 16K context 模型叠加，导致实际可用 context 为 0
- 全局 compaction 配置（openclaw.json）与 Agent 级别模型配置是两套独立层级，修改全局配置无法解决 Agent 级别的模型问题
- 解决根本方案是将星枢 Telegram channel 的路由改回 MiniMax-M2.7（200K context），而非继续调低 compaction 阈值
- 日志分析是定位此类"隐藏配置路径"问题的唯一可靠手段
Key Quotes
provider=custom-api-deepseek-reasoner/deepseek-reasoner ctx=16000 / estimatedPromptTokens=393 overflowTokens=392 reserveTokens=16384— Gateway 日志直接揭示了模型切换和 token 耗尽问题「Context limit exceeded」不一定是因为对话太长，可能是模型配置本身就有问题— 核心教训：错误表象 ≠ 根本原因不要默认认为错误信息就是表面意思。先问一句：到底哪儿出问题了？— 最终方法论总结
Key Concepts
- Context-Window: 模型单次请求能处理的最大 token 数量；deepseek-reasoner 仅 16K，MiniMax-M2.7 为 200K
- Model-Fallback: 当默认模型不可用时，OpenClaw 按优先级切换到 fallback 列表中的下一个模型；触发原因包括 API 503/429/Timeout、路由权重错误、或配置覆盖
- Compaction: OpenClaw 的上下文压缩机制，在 safeguard 模式下会预留 16K tokens 用于执行压缩操作
- Agent-Routing-Rules: 绑定 Telegram channel 到特定模型的路由规则，优先级高于全局配置
- Error-Surface-vs-Root-Cause: 不要被错误信息的字面意思误导；表象修复 ≠ 根本解决
- Layered-Configuration: OpenClaw 配置分全局配置（openclaw.json）和 Agent/Channel 级别配置；问题可能藏在不同层级
- Log-Driven-Debugging: Gateway 日志直接揭示了模型切换事件和 token 分配详情，是定位问题的唯一可靠手段
- Hidden-Failure-Paths: 复杂分布式系统中，故障可能藏在 session、memory、model config、routing rules、compaction 策略等多个地方
Key Entities
- OpenClaw: 运行星枢的 AI Agent 框架；本文核心调试对象
- 星枢: 用户的 AI 助手（xingshu/main agent）；通过 Telegram 与用户交互
- DeepSeek: deepseek-reasoner 模型提供方；context window 仅 16K，是本次问题的直接触发者
- MiniMax: MiniMax-M2.7 模型提供方；context window 为 200K，是正确的配置目标
Connections
- 养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录 ← related_to ← 养虾日记4（同属 OpenClaw 调试系列，互补关系）
- 养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战 ← related_to ← 养虾日记4（同属"养虾日记"系列）
- 养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享 ← related_to ← 养虾日记4（同属"养虾日记"系列）
- 养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统 ← related_to ← 养虾日记4（同属"养虾日记"系列）
- n8n调用hermes-agents的工作流架构 ← related_to ← 养虾日记4（OpenClaw 配置层级问题在此亦有体现）
Contradictions
- 与 养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录 的互补关系：
- 冲突点：养龙虾系列重点在记忆写入/检索失效（semantic memory、context compression），本文重点在模型配置错误导致 context 立即耗尽
- 当前观点：两者均为 OpenClaw "记忆失效"症状的不同根因；养龙虾系列归因于记忆插件和压缩机制，本文归因于模型配置本身
- 对方观点：养龙虾系列认为写入纪律和压缩协同是主要挑战
- 说明：互补而非冲突，两类问题可同时存在