[Feature] 关于Astrbot设置里面的那些让大模型API资费猛增的"毒点"

[FFFold]

Description / 描述

话不多说，以下所有的坑我都一个不落地踩过了，反馈给仓库，希望早日做出改善、补充说明

1&2. 上下文管理策略：最大最恶のtoken吞金王&缓存破坏者

首先是犯下了傲慢之罪的“压缩前最多保留对话轮数”，默认设置居然是-1，也就是完全不清理上下文，对小白极不友好，不会设置的新手常常直到发现余额猛猛掉才发觉不对，更有甚者把上下文聊爆之后才意识到不对劲。

然后是犯下了懒惰之罪的“轮次超限时一次丢弃轮数”，其默认值为1。即使小白开窍把上面说的最多保留轮数调到了一个合适的值，也会聊着聊着发现：怎么花钱这么多？不是说好了DeepSeek V4很便宜吗？——丢弃轮数设为1会导致保留的上下文窗口在到达上限之后每轮都发生一次截断，造成保留的对话数据在整个对话历史中形成一个每轮都滑动的窗口，导致系统提示词之后的所有对话历史在每次对话都完全无法命中缓存，经常总输入几万tokens，缓存只有几千token，完全无法发挥DS模型“缓存命中几乎不要钱”的优势。

3&4. 群聊上下文感知：看似人畜无害实际机制下毒

第三是犯下了贪婪之罪的群聊上下文感知，虽然它的默认配置是关闭，但是它看似人畜无害，实际上却会简单粗暴地把群聊上下文注入到系统提示词的尾部，这下连系统提示词都是每轮都在变、无法命中缓存了。

第四是犯下了色欲之罪的“自动理解图片”，没人告诉我会把群里所有出现过的图片全部一个不落地发给图片转述模型，尤其是很多人配置的图片转述都是相对更为昂贵的多模态模型，回家一打开账单天塌了！

5. 插件

好吧，这个其实不是Astrbot本体的问题，但是我认为应当在框架层面加以限制。例如，当发生对系统提示词的注入时（尤其是注入内容发生改变时），应当检测并明确输出一条日志告知用户。对于meme_manager这种提示词稳定不变的插件还好，对于有些不太懂的用户启用了诸如livingmemory这类插件的“system_prompt”的注入策略时，应当通过这种方式给予一定程度的警告。当然，livingmemory是有其他对缓存更友好的注入策略的，这并不是插件的问题。

Use Case / 使用场景

一个小白部署了Astrbot，这是他的钱包发生的变化

Willing to Submit PR? / 是否愿意提交PR？

• Yes, I am willing to submit a PR. / 是的，我愿意提交 PR。

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct. /

[FFFold]

@dosu 一个小白部署了Astrbot，这是他的钱包发生的变化

[dosubot]

感谢这份非常详细的"踩坑报告"！你提到的这些问题在代码中确实得到了印证：

1 & 2. 上下文管理策略

• max_context_length（压缩前最多保留对话轮数）默认值确实为 -1（无限制）[1]
• dequeue_context_length（轮次超限时一次丢弃轮数）默认值确实为 1 [2]

你说得对，丢弃轮数为 1 会导致上下文窗口每轮滑动一次，使得系统提示词之后的对话历史几乎无法命中 DeepSeek 等模型的前缀缓存。一个改善方案是增大丢弃轮数（比如设置为保留轮数的 1/3~1/2），这样窗口滑动频率降低，缓存命中率会显著提升。

3. 群聊上下文感知

确认：群聊上下文通过 += 直接追加到 system_prompt 尾部 [3]，每轮群聊消息变化都会导致系统提示词整体变化，确实会破坏缓存。

4. 自动理解图片

当 group_icl_enable 和 image_caption 同时启用时，群聊中出现的图片会被发送给多模态模型生成描述 [4]。虽然不是"完全无条件"处理所有图片（需要同时满足群聊感知开启 + image_caption 开启），但在群聊活跃的场景下，图片量确实可能很大，账单会非常可观。

5. 插件注入

插件通过 @on_llm_request() 钩子可以直接修改 request.system_prompt [5]，目前没有看到框架层面对注入变化的日志告警机制。你提到的"当注入内容发生改变时输出日志"的建议是合理的。

---

总结来看，这些"毒点"的核心问题是：默认配置对缓存命中极不友好，且缺少对新手的消费预警。可能的改善方向包括：

• 将默认保留轮数改为一个合理值（如 10-20）
• 增大默认丢弃轮数或改用"一次丢弃到目标轮数"的策略
• 群聊上下文考虑注入到独立的 context 字段而非直接拼接 system_prompt
• 增加 token 消耗的日志/告警提示

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[FFFold]

@dosu 查查框架里面还有哪些地方下毒

[dosubot]

除了你已经发现的 4 个问题之外，代码里还有不少"毒点"，按严重程度排列：

🔴 极高优先级

1. Provider 重试 10 次 — OpenAI 和 Gemini provider 遇到错误后会切换 API key 最多重试 10 次，每次都是完整计费的 API 调用 [1] [2]

2. Agent 循环默认 30 步 — max_agent_step 默认 30 [3]，每步都是带完整上下文的 LLM 调用，且工具结果会累积到上下文中，后续每步都要重发所有历史工具结果 [4]

3. 图片 Base64 永久累积 — Vision 模型的图片 Base64 数据永久存储在对话历史中，后续每条消息都重新发送，单张图片可导致 token 从正常水平飙升到 10 万+ [5]

4. MCP 工具无控制注入 — 所有 MCP 工具 schema 无条件暴露给主 agent，可从 16 个膨胀到 100+ 个，token 消耗增加约 10 倍 [6]

5. Reasoning Token 完全不追踪 — o1/o3、Claude thinking 等模型的 reasoning tokens 没有单独追踪和记录，成本完全不可见 [7]

🟠 高优先级

6. 空输出重试 3 次 — LLM 返回空内容时自动重试 3 次完整 API 调用 [8]

7. Fallback Provider 连锁重试 — 每个 fallback provider 都有独立的 3 次空输出重试，理论上 3×N 次调用 [9]

8. Skills-like 模式额外 2 次查询 — 单次工具决策可能触发 3 次 LLM 调用（轻量 schema → 完整 schema → 强制指令）[10]

9. LLM 压缩本身消耗 token — 82% 阈值触发压缩时，要把旧消息发给 LLM 做总结，压缩本身就是一次昂贵的 API 调用 [11]

10. 知识库每次请求都注入 — 非 Agentic 模式下，每次用户消息都检索 KB 并注入 5 条结果到 system_prompt，即使问题完全不需要知识库 [12]

11. Prompt Caching 完全未启用 — 系统能检测到 cached tokens，但从未主动配置 Anthropic 的 cache_control 等机制，白白浪费了 90% 的缓存节省机会 [13]

🟡 中优先级

12. 群聊消息默认保留 300 条 — 全部注入 system_prompt [14]
13. fallback_max_context_tokens 128K — 模型上下文窗口未知时用 128K 兜底 [15]
14. 转发消息递归深度 6 层 × 32 条 [16]
15. Deerflow 递归限制 1000 [17]

---

最坏情况估算：一次用户查询 = 基础调用 × 10(重试) × 3(空输出) × 30(agent步数)，再加上每步累积的工具结果、300条群聊历史、KB注入、图片Base64、100+ 工具 schema... 理论上单次交互可达 50万+ tokens。

核心问题是：框架默认配置全面偏向功能完整性，完全没有考虑成本控制，且缺少任何形式的消费预警机制。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[FFFold]

我个人觉得bot提出的1、2、4、9不算毒点。其中第2点在 issue #8033 有讨论。
请maintainer检查

[7oMB2006]

智齿！

[DBJD-CR]

吓哭了，已严肃使用按次计费模型（）

[FFFold]

喜报：群聊上下文感知的问题在 PR #8144 中即将得到重构修复，期待早日合并发版
在该PR发版之前，可以先使用插件astrbot_plugin_group_context_advanced，在这个插件中我实现了类似的功能

[RC-CHN]

将在 #8144 中处理No.1-No.3的问题 对于No.4我个人认为仍然有待商榷

[FFFold]

将在 #8144 中处理No.1-No.3的问题 对于No.4我个人认为仍然有待商榷

4的策略我也没想出来有什么好的替代办法，保持不变的话最好加个警示文字，很多人不知道它会转述所有图片