UMO 专属配置的 max_context_length 不生效，or 短路导致永远走全局配置

[vcvcvcvcvcvcvcvcvc]

Bug 描述

在 WebUI 中为某个会话单独设置 max_context_length（压缩前最多保留对话轮数），该设置不生效。实际上下文无限增长。

版本

AstrBot v4.27.2 (Docker)

根因

astrbot/core/astr_main_agent.py 的 _decorate_llm_request() 函数中：

cfg = config.provider_settings or plugin_context.get_config(
    umo=event.unified_msg_origin
).get("provider_settings", {})

使用了 or 短路逻辑。全局 provider_settings 永远是非空 dict，因此 plugin_context.get_config(umo=...) 永远不会执行，UMO 专属配置被跳过。

实际影响

• UMO 级 max_context_length 设置无效
• 上下文无限堆积（实测 94K tokens，202 轮历史消息）
• LLM API 响应延迟严重（单次 50-60 秒）
• 即使全局设为 -1，用户也无法通过 UMO 配置覆盖

修复建议

改为 merge 而非短路：

global_cfg = config.provider_settings or {}
umo_cfg = plugin_context.get_config(umo=event.unified_msg_origin).get("provider_settings", {})
cfg = {**global_cfg, **umo_cfg}  # UMO 覆盖全局

备注

疑似近期更新引入（仓库迁移前旧版本 UMO 配置正常生效）。

---

🤖 Generated with Claude Code
Co-Authored-By: Claude noreply@anthropic.com

[dosubot]

Hi @vcvcvcvcvcvcvcvcvc! I'm Dosu and I'm helping the AstrBotTeam team.

Bug 已确认。_decorate_llm_request() 第 998-1000 行确实存在 or 短路问题 [1]：

cfg = config.provider_settings or plugin_context.get_config(
    umo=event.unified_msg_origin
).get("provider_settings", {})

全局 config.provider_settings 始终是非空 dict，因此 UMO 专属配置永远不会被读取。你提出的 merge 修复方向是正确的。

相关进展：

• PR feat: add UMO config overrides #9147（开放中）引入了 UMO 作用域的配置覆盖机制（get_base_conf(umo)、get_conf(umo) 等），这应该是修复此类优先级问题的方案 [2]。
• 另外还有一个类似的优先级 bug：Issue [Bug] contextLimit元数据覆盖用户配置 #9254 报告了 max_context_tokens 被外部模型元数据覆盖的问题 [3]，说明配置覆盖优先级在多处存在类似问题。

补充一点：max_context_length 在 build_main_agent() 中是作为 enforce_max_turns 传给 AgentRunner.reset() 的 [4]，它从 MainAgentBuildConfig dataclass 字段读取 [5]，而不是在运行时动态从 UMO provider_settings 解析——这意味着即使 _decorate_llm_request() 的短路问题修复了，可能还需要确认 build_main_agent() 是否也正确使用了 UMO 级别的 max_context_length。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.