问题描述：今天在写环世界mod时发现Astra的缓存出现异常，经常出现缓存丢失的现象，我让其他Ai分析了下原因，Ai发现长会话下，同一会话内交替出现两种请求形态，其中一种的 cache_read 恒为 0（连系统提示等固定前缀都不命中），导致出现大量请求无缓存命中。以下文案在编写时有AI辅助
关键特征：两种请求形态的规模稳定相差约 8,400–8,700 token，且差值位于请求前部（未命中请求的 cache_read 恒为 0，说明不是末尾追加导致，而是前缀本身不匹配）。
复现步骤：
1.在 Windows 上开启一个会话（模型 gpt-6-astra），执行一个长任务：连续大量工具调用（读文件、跑构建、等待后台进程），让上下文增长到 15 万 token 以上。在实际操作中，我让Astra扮演设计及审查，由GLM5.3Flash扮演程序员，Astra会启动大量子程序来进行开发及测试。
2.在任务过程中穿插使用 wait 等待后台任务、接收 注入消息，并继续对话（即正常 agent 工作流）。（在实际操作中，我还发现由于GLMToken生成速度较慢，有时候会超出等待时间，导致生成了大量等待超时的请求，同时我观察后台，发现每次出现这种请求就会丢失所有缓存）
3.从渠道账单导出逐请求用量，按时间排序，观察缓存读取信息：会话开头数条请求即为 0（此时上下文仅 1.3–3 万 token，前后请求仅差几百 token，本应大部分命中）；上下文超过约 18 万 token 后，全未命中请求逐渐占主导。
预期行为：追加式对话中，第 N+1 次请求应命中第 N 次请求已建立的前缀缓存（cache_read 接近前次请求总量，未命中输入仅数百 token）。本地数据库中 usage_ledger.lastCall 记录的常规形态也印证这一点。
实际行为：同一会话内两种请求流交替：
21:00:42 input=227,620 cache_read=0
21:01:05 input=218,930 cache_read=218,624 ← 前缀稳定命中
21:01:23 input=227,946 cache_read=0
21:01:57 input=219,374 cache_read=218,624
21:02:29 input=228,302 cache_read=0
另外，fork 出的会话（相同模型）有 5 次 token 量完全相同（272,000）的请求，全部 0% 命中。
已排除的原因（均有数据支撑）：渠道故障（同期 GLM 子会话命中率 97–99.8%）、run 边界切换（全程同一 run 内两种形态并存）、上下文压缩（无 compaction 记录）、模型切换、请求中断、通知/steer 注入触发（MISS/HIT 距注入事件的中位间隔 117s vs 110s，无差异）、272,000 硬上限（同会话出现过 734,291）。
环境信息：
- 操作系统：Windows 11 家庭版中文版（10.0.26200）
- DimCode 版本：0.3.32
- 相关模型或服务：gpt-6-astra
补充材料：
这个问题是第一次出现，之前同样写环世界mod和其他功能时没有出现过这种现象。不知道是偶发问题还是我这渠道问题。
问题描述：今天在写环世界mod时发现Astra的缓存出现异常，经常出现缓存丢失的现象，我让其他Ai分析了下原因，Ai发现长会话下，同一会话内交替出现两种请求形态，其中一种的 cache_read 恒为 0（连系统提示等固定前缀都不命中），导致出现大量请求无缓存命中。以下文案在编写时有AI辅助
关键特征：两种请求形态的规模稳定相差约 8,400–8,700 token，且差值位于请求前部（未命中请求的 cache_read 恒为 0，说明不是末尾追加导致，而是前缀本身不匹配）。
复现步骤：
1.在 Windows 上开启一个会话（模型 gpt-6-astra），执行一个长任务：连续大量工具调用（读文件、跑构建、等待后台进程），让上下文增长到 15 万 token 以上。在实际操作中，我让Astra扮演设计及审查，由GLM5.3Flash扮演程序员，Astra会启动大量子程序来进行开发及测试。
2.在任务过程中穿插使用 wait 等待后台任务、接收 注入消息，并继续对话（即正常 agent 工作流）。（在实际操作中，我还发现由于GLMToken生成速度较慢，有时候会超出等待时间，导致生成了大量等待超时的请求，同时我观察后台，发现每次出现这种请求就会丢失所有缓存）
3.从渠道账单导出逐请求用量，按时间排序，观察缓存读取信息：会话开头数条请求即为 0（此时上下文仅 1.3–3 万 token，前后请求仅差几百 token，本应大部分命中）；上下文超过约 18 万 token 后，全未命中请求逐渐占主导。
预期行为：追加式对话中，第 N+1 次请求应命中第 N 次请求已建立的前缀缓存（cache_read 接近前次请求总量，未命中输入仅数百 token）。本地数据库中 usage_ledger.lastCall 记录的常规形态也印证这一点。
实际行为：同一会话内两种请求流交替：
21:00:42 input=227,620 cache_read=0
21:01:05 input=218,930 cache_read=218,624 ← 前缀稳定命中
21:01:23 input=227,946 cache_read=0
21:01:57 input=219,374 cache_read=218,624
21:02:29 input=228,302 cache_read=0
另外，fork 出的会话（相同模型）有 5 次 token 量完全相同（272,000）的请求，全部 0% 命中。
已排除的原因（均有数据支撑）：渠道故障（同期 GLM 子会话命中率 97–99.8%）、run 边界切换（全程同一 run 内两种形态并存）、上下文压缩（无 compaction 记录）、模型切换、请求中断、通知/steer 注入触发（MISS/HIT 距注入事件的中位间隔 117s vs 110s，无差异）、272,000 硬上限（同会话出现过 734,291）。
环境信息：
补充材料：
附件：用ai分析的缓存失效报告：
findings-gpt6astra.md
这个问题是第一次出现，之前同样写环世界mod和其他功能时没有出现过这种现象。不知道是偶发问题还是我这渠道问题。