问题描述
发生了什么 / What happened
在一个多轮工具调用（agent / tool loop）的长会话里，虽然界面显示的上下文占用很低，但 AstrBot 仍然触发了一次上下文压缩/截断，把之前对话里携带的关键信息（项目内容、翻过的讨论等）概括掉，表现为对话突然失忆——再搜不到、再答不出之前聊过的硬信息。
实测：比如会话 conversation.token_usage（= llm_response.usage.total，单次）入库仅 68,435，约占 1M 窗口的 6.8%；界面/记录里的 current_context_tokens（= usage.input）也显示"健康"（54K、79K 等）。远低于 820K 压缩触发线，却发生了压缩。
观察上下文的实时统计数据，我从未见过超过130K/1M 的时候，有些时候AI在回答的过程中就出现压缩了。
下图示意是97K被压缩成19K，使用的是下图上下文管理策略配置
下图是AstrBot上下文管理策略
上下文窗口兜底值不管是不设置，还是设置成1000000，都是会提前压缩。
补充：最开始我一直使用的默认配置——历史超限或上下文接近上限时的处理方式：按对话轮数截断，
😭这个真的恐怖，我发现多次长对话过程中某一轮AI完全失记忆，连上一轮AI回答过的记忆都没有，实在是被坑怕了，有几次甚至插卡抽到开始乱编乱改配置了。真的不推荐默认设置选这个！
如何复现？
复现步骤 / Reproduce
- 配置上下文管理策略为「多轮保留 + 接近上限时用 LLM 压缩」，主模型用 DeepSeek responses 系列（如
deepseek-v4-flash-vision-exp，max_context_tokens = 1,000,000）。
- 在一个会话里持续做多轮含工具调用的对话（agent/tool loop），累积若干轮。
- 通过数据库查
conversations.token_usage（界面环形读取的是另一路径 current_context_tokens = usage.input）。
- 观察到上下文占用还在很低（6.8% 左右）时，对话就被提前压缩/截断。
AstrBot 版本
v4.27.4
操作系统
Linux
部署方式
Docker
使用的消息平台适配器
webchat
错误日志
# AstrBot 对话「对话历史搜索不到项目内容」 轮次统计明细
- 会话：webchat `ae2ca4b5…`（conversation `357b7294…`）
- 统计源：`platform_message_history`（逐条消息）+ `provider_stats`（每次 LLM 调用 token）
- 用户轮次：共 38 个，其中真实回复轮 36 个，空轮 2 个（无回复）
- 思考次数合计：256 工具调用次数合计：428 LLM 调用次数：36
说明：每一行 = 一次用户提问触发的一轮对话。`思考` = 该轮中模型的 think 块数量；`工具` = 该轮中调用的工具次数；token 为该轮 LLM 调用统计（输入=其他+缓存，输出，合计）。
| 轮 | 时间 | 思考 | 工具 | 输入other | 输入cached | 输出 | 合计token |
|---|------|-----|----|-----------|-----------|-----|----------|
| 0 | 2026-08-28 08:53 | 2 | 1 | 3858 | 32768 | 1467 | 38093 |
| 1 | 2026-08-28 08:54 | 16 | 25 | 50168 | 820992 | 12109 | 883269 |
| 2 | 2026-08-28 09:03 | 7 | 21 | 33495 | 774400 | 10983 | 818878 |
| 3 | 2026-08-28 09:08 | 13 | 18 | 19481 | 490112 | 9422 | 519015 |
| 4 | 2026-08-28 09:19 | 7 | 46 | 96932 | 3763072 | 19959 | 3879963 |
| 5 | 2026-08-28 12:08 | 1 | 0 | 1467 | 15872 | 1534 | 18873 |
| 6 | 2026-08-28 12:11 | 1 | 0 | 2630 | 15872 | 936 | 19438 |
| 7 | 2026-08-28 12:16 | 1 | 0 | 3483 | 16000 | 865 | 20348 |
| 8 | 2026-08-28 12:18 | 1 | 0 | 2351 | 18048 | 800 | 21199 |
| 9 | 2026-08-28 12:20 | 1 | 0 | 2374 | 19072 | 1263 | 22709 |
| 10 | 2026-08-28 12:20 | 1 | 0 | 2650 | 19968 | 865 | 23483 |
| 11 | 2026-08-28 12:22 | 1 | 0 | 4928 | 15872 | 1843 | 22643 |
| 12 | 2026-08-28 12:23 | 1 | 0 | 7319 | 15872 | 904 | 24095 |
| 13 | 2026-08-28 12:25 | 3 | 4 | 7753 | 102016 | 2907 | 112676 |
| 14 | 2026-08-28 12:28 | 4 | 6 | 13832 | 154112 | 4832 | 172776 |
| 15 | 2026-08-28 12:33 | 11 | 11 | 183067 | 260864 | 8211 | 452142 |
| 16 | 2026-08-28 12:37 | 15 | 17 | 87905 | 543232 | 15193 | 646330 |
| 17 | 2026-08-28 12:43 | 4 | 4 | 36001 | 168192 | 4784 | 208977 |
| 18 | 2026-08-28 12:47 | 14 | 16 | 51926 | 1059456 | 17060 | 1128442 |
| 19 | 2026-08-28 12:51 | 35 | 40 | 65888 | 2010368 | 30655 | 2106911 |
| 20 | 2026-08-28 13:00 | 17 | 55 | 75162 | 2749440 | 37138 | 2861740 |
| 21 | 2026-08-28 13:07 | 1 | 0 | 3022 | 15872 | 1168 | 20062 |
| 22 | 2026-08-28 13:18 | 13 | 50 | 182940 | 2998912 | 23779 | 3205631 |
| 23 | 2026-08-28 13:23 | 1 | 0 | 3750 | 15872 | 1310 | 20932 |
| 24 | 2026-08-28 13:24 | 1 | 0 | 5116 | 15872 | 2357 | 23345 |
| 25 | 2026-08-28 13:31 | 16 | 15 | 21780 | 593280 | 15577 | 630637 |
| 26 | 2026-08-28 13:34 | 1 | 0 | 33584 | 20608 | 1176 | 55368 |
| 27 | 2026-08-28 13:35 | 1 | 0 | 22647 | 32768 | 656 | 56071 |
| 28 | 2026-08-28 13:38 | 10 | 9 | 20506 | 651776 | 12909 | 685191 |
| 29 | 2026-08-28 13:43 | 19 | 28 | 26770 | 1106944 | 20181 | 1153895 |
| 30 | 2026-08-28 13:49 | 3 | 4 | 51342 | 264960 | 3397 | 319699 |
| 31 | 2026-08-28 14:00 | 6 | 24 | 45256 | 2020992 | 16723 | 2082971 |
| 32 | 2026-08-28 14:14 | 8 | 11 | 16746 | 214656 | 11970 | 243372 |
| 33 | 2026-08-28 14:19 | 3 | 3 | 27923 | 99072 | 4956 | 131951 |
| 34 | 2026-08-28 14:20 | 1 | 3 | 16844 | 135040 | 2013 | 153897 |
| 35 | 2026-08-28 14:42 | 16 | 17 | 33115 | 1114368 | 19057 | 1166540 |
| **合计** | | **256** | **428** | **1264011** | **22366592** | **320959** | **23951562** |
**总计**：LLM 调用 36 次 · 思考块 256 个 · 工具调用 428 次
**Token**：输入（other）1,264,011 · 输入（cached）22,366,592 · 输出 320,959 · 总计 23,951,562
## 空轮（无回复，不计 token）
- msg 5526：再读取当前对话的完整历史 ”AstrBot对话历史搜索不到项目内容“。
详细的分析总结到笔记中，点出
- msg 5564：帮我检查这个对话”AstrBot对话历史搜索不到项目内容“，每轮的思考次数调用工具次数，token统
辅助信息
对话-AstrBot对话历史搜索不到项目内容-脱敏log.txt
检查清单
问题描述
发生了什么 / What happened
在一个多轮工具调用（agent / tool loop）的长会话里，虽然界面显示的上下文占用很低，但 AstrBot 仍然触发了一次上下文压缩/截断，把之前对话里携带的关键信息（项目内容、翻过的讨论等）概括掉，表现为对话突然失忆——再搜不到、再答不出之前聊过的硬信息。
实测：比如会话
conversation.token_usage（=llm_response.usage.total，单次）入库仅 68,435，约占 1M 窗口的 6.8%；界面/记录里的current_context_tokens（=usage.input）也显示"健康"（54K、79K 等）。远低于 820K 压缩触发线，却发生了压缩。观察上下文的实时统计数据，我从未见过超过130K/1M 的时候，有些时候AI在回答的过程中就出现压缩了。
下图示意是97K被压缩成19K，使用的是下图上下文管理策略配置
下图是AstrBot上下文管理策略
上下文窗口兜底值不管是不设置，还是设置成1000000，都是会提前压缩。补充：最开始我一直使用的默认配置——历史超限或上下文接近上限时的处理方式：按对话轮数截断，
😭这个真的恐怖，我发现多次长对话过程中某一轮AI完全失记忆，连上一轮AI回答过的记忆都没有，实在是被坑怕了，有几次甚至插卡抽到开始乱编乱改配置了。真的不推荐默认设置选这个！
如何复现？
复现步骤 / Reproduce
deepseek-v4-flash-vision-exp，max_context_tokens = 1,000,000）。conversations.token_usage（界面环形读取的是另一路径current_context_tokens = usage.input）。AstrBot 版本
v4.27.4
操作系统
Linux
部署方式
Docker
使用的消息平台适配器
webchat
错误日志
辅助信息
对话-AstrBot对话历史搜索不到项目内容-脱敏log.txt
检查清单