Auto-sync: 2026-04-27 20:02

wiki/sources/养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑.md

@@ -1,57 +1,58 @@
----
-title: "养虾日记4：一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑"
-type: source
-tags: [OpenClaw, 错误排查, Context-Window, Telegram, 日志调试]
-date: 2026-04-10
----
-
-## Source File
-- [[微信公众号/养虾日记4： 一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑.md]]
-
-## 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 "记忆失效"症状的不同根因；养龙虾系列归因于记忆插件和压缩机制，本文归因于模型配置本身
-  - 对方观点：养龙虾系列认为写入纪律和压缩协同是主要挑战
-  - 说明：互补而非冲突，两类问题可同时存在
+---
+title: "养虾日记4：一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑"
+type: source
+tags: ["调试经验", "OpenClaw", "模型配置", "Context-Window", "养虾日记"]
+date: 2026-04-10
+---
+
+## Source File
+- [[微信公众号/养虾日记4： 一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑.md]]
+
+## 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
+1. 不要默认认为错误信息就是表面意思——「Context limit exceeded」不一定是因为对话太长，可能是模型配置本身就有问题
+2. 两层配置要分清：全局 compaction 配置和 agent 模型配置是两码事，改全局不行就得往 agent 级别去找
+3. 日志真的有用：Gateway 日志把问题写得明明白白，只是之前没仔细看
+4. 工具/系统越复杂，问题的隐藏路径越深：OpenClaw 这种分布式 agent 系统，问题可能藏在 session、memory、model config、routing rules、compaction 策略等多个地方