1. 问题背景与现象描述
最近在使用OpenClaw平台构建的多智能体协作系统时,遇到了一个令人困扰的问题。我的团队由三个AI助手组成:负责编码的"小猿潘"、负责产品的"小产潘"和负责测试的"小测潘"。初期交互一切正常,但随着使用时间增长,"小猿潘"和"小产潘"开始出现不回复消息的情况,尤其是"小猿潘"的问题最为严重。
从飞书通信记录来看,这种不回复现象呈现以下特征:
- 初期交互流畅,问题通常出现在连续对话10-15轮之后
- 不回复时系统没有明确的错误提示,消息状态显示为"已发送"但无响应
- 问题在代码量较大的任务中更容易复现
- 重启会话后问题暂时缓解,但会再次出现
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术背景与核心概念
2.1 OpenClaw的Token机制
在排查问题前,需要先理解OpenClaw平台的Token处理机制。根据官方文档和与DeepSeek的沟通,OpenClaw将Token分为四种类型:
- Input Token:用户输入的原始内容
- Output Token:模型生成的响应内容
- Cache Read:从缓存中读取的上下文
- Cache Write:写入缓存的上下文
这四种Token都会产生费用,但计价方式不同。Cache Write是用户主动写入缓存的,而Cache Read是模型从内存缓存中读取上下文的行为,发生在服务提供商侧。
2.2 缓存机制的关键问题
针对当前使用的GLM Code Plan模型,有几个关键问题需要明确:
- 模型兼容性:并非所有模型都支持缓存机制,需要确认GLM Code Plan的具体支持情况
- 缓存周期控制:缓存的有效期如何设置和管理
- 心跳机制:会话保持的心跳间隔如何影响缓存有效性
从实际观察来看,心跳间隔设置对缓存成本影响显著。频繁重启会话会导致缓存重建,增加成本;而不合理的心跳间隔则可能导致缓存过早失效,需要重复发送上下文。
3. 问题排查过程
3.1 Token增长分析
通过Dashboard观察三个智能体的Token增长情况:
3.1.1 小猿潘的Token增长
- 初期缓存效果明显
- 随着代码量增加,Token/上下文长度达到峰值后不再使用缓存
