[RFC] AstrBot Context 管理升级路线（基于 #6625 与 #6259）

[Jacobinwwey]

讨论目标

1. 如何避免 tool loop 导致 context 无效膨胀（Fix/tool result dedup config #6259）
2. 如何把Context压缩从“被动超限触发”升级为“可治理”（feat: periodic llm-based conversation history compaction #6625）

---

1) #6259：Tool Loop 上下文膨胀治理

问题 A：相同 tool + args 连续失败，模型还在重复调用

示例

• AI 调用 xx_api(args=a) 报错。
• 后续仍反复调用 xx_api(args=a)，错误持续堆叠进 context。

措施

• 对相同 tool_name + normalized_args 计数错误次数。
• 达到阈值后：当前 run 禁用工具调用，返回禁用原因，要求模型直接基于现有信息回答。

配置

• provider_settings.tool_error_repeat_guard_threshold（默认 8，<=0 关闭）

---

问题 B：相同 tool + args + result 被重复写入 context

示例

• 轮询类调用多次返回相同结果，完整文本被重复注入。

措施

• 首次结果完整保留。
• 连续重复结果改为摘要标记（重复次数 + 预览），不再整段重复写入。

配置

• provider_settings.deduplicate_repeated_tool_results=true
• provider_settings.tool_result_dedup_max_entries=1024（<=0 不裁剪）

---

问题 C：参数缺失/不匹配导致 handler 层噪声报错

措施

• 执行前做参数契约预校验（required / anyOf / oneOf + 参数归一化 + 类型归一化）。
• 失败时返回显式工具错误，避免噪声 TypeError。

---

2) #6625：会话本体压缩治理

问题：仅在超限时压缩，长会话治理滞后

措施

• 新增定时压缩调度器：周期扫描会话，满足条件则压缩并回写历史本体。
• 支持手动运维命令：/ctxcompact status、/ctxcompact run [limit]。
• 支持工具调用后压缩策略（软/硬阈值、最小增量、防抖）。

关键默认值（保守）

• periodic_context_compaction.enabled=false
• compact_context_after_tool_call=false
• context_token_counter_mode=estimate

---

本讨论希望确认的 3 个点

1. tool_error_repeat_guard_threshold=8 是否合适？
2. 自动触发比例（当前默认 0.3）是否合理？
3. 后续长期记忆是否先维持“手动 pinned memory”为主，检索增强是单独做一个模块还是去融入memory里？

想听听大家关于context manage的构想和期望

[jinbangyi]

建议把变更内容详细说下，突出重点，看完整的代码变更很费劲废时间，最好先交流想法

比如 L0: 短期工作记忆: Recent N turns + tool结果去重（https://github.com/AstrBotDevs/AstrBot/pull/6259） 可以详细展开为:

解决 AI 调用工具报错，但是还是反复使用相同 args 调用相同 tool 占用 context 的问题
示例：比如 AI 调用 xx 接口，返回一个报错，结果 AI 后续还是用相同 arg 调用相同 tool 导致 context 增长
解决措施：如果识别到相同工具、相同参数反复失败，直接 disable 对应的 tool 并返回 disable 原因
解决相同工具相同结果占用 context 的问题
示例：比如调用一个 xx 接口，相同参数，相同结果，结果好几个一样的堆在上下文里
解决措施：如果识别到相同工具、相同参数、相同结果，将结果直接截断+截断原因返回

[Jacobinwwey]

谢谢提醒，已改