[bug] an unloaded BTW loop model skips every LLM request

[YUZHEthefool]

Preflight

• I searched existing Issues and PRs.
• I tested the current master branch or the exact commit.
• This report contains no secrets, tokens, or private data.
• This is not a security vulnerability (those use a private advisory).
• I filled exactly one of Human note or Agent note, matching who wrote this Issue.

搜索了 conversation_loop.provider_id、work_loop.provider_id、provider_id_override、对话循环模型。 #152–#156 是工作循环的其他缺陷，没有 Issue 覆盖「循环模型解析不到会让整条请求停摆」。

Affected area

Providers / agent runners

What happened

期望：btw.conversation_loop.provider_id / btw.work_loop.provider_id 是持久配置，应按优先偏好生效——模型确实加载时压过会话选择；模型已不存在（或被改名、未加载）时，请求继续走会话/配置档默认模型，并留下告警。一个失效的配置项不该让整个配置档哑掉。

实际：该值是硬性要求。_select_provider() 解析不到就返回 None，build_main_agent() 随即记 未找到任何对话模型（提供商），跳过 LLM 请求处理。，消息不进入任何模型——配置档默认模型和被 /model set 选中的模型都到不了。

现场日志（提供商列表被编辑过；默认模型为 sukaka/agy-gemini-3.8-flash-medium，两个循环都钉在已不存在的 sukaka/agy-gemini-3.8-flash-high）：

没有找到 ID 为 sukaka/agy-gemini-3.8-flash-high 的提供商
未找到指定的提供商: sukaka/agy-gemini-3.8-flash-high。
未找到任何对话模型（提供商），跳过 LLM 请求处理。

现象上像「对话坏了」：/list、/set、/delete、新建会话都改不了结果，因为这是每次请求都重新读取的配置档值，不是会话历史。启动时 flash-high 也没被加载（只有另外两个模型进了 inst_map），所以 get_provider_by_id() 必然返回 None。

相关路径：

• astrbot/core/pipeline/process_stage/method/agent_sub_stages/internal.py:303-316 把 btw.<loop>_loop.provider_id 写进 MainAgentBuildConfig.provider_id_override；
• astrbot/core/astr_main_agent.py:357 _select_provider() 先解析 override，id 不在 inst_map、或类型不是对话模型，就返回 None；
• astrbot/core/astr_main_agent.py:2153-2163 把这个 None 变成「跳过 LLM 请求处理」。

复现（单元级，无需真实平台）：

1. 在 provider_id_override 传一个未加载的 id（等价于把循环模型钉到不存在的模型），另有一个可用的默认/会话模型。
2. _select_provider(event, ctx, "not-loaded") 返回 None 并写入 LLM_ERROR_MESSAGE_EXTRA_KEY；get_using_provider() 根本没被查询。
3. 于是 build_main_agent() 返回 None，不会有任何 LLM 调用。

master 上的 tests/unit/test_astr_main_agent.py::TestSelectProvider::test_invalid_loop_override_does_not_fall_back 正是把这个行为固定下来的测试，当前通过。

现场复现：让 btw.conversation_loop.provider_id 指向一个未加载的 id，给机器人发任意普通消息。

Commit or version

Xero-Team/AstrBot 00c57951d72942a983268278eb2fa564e8c40648（upstream/master，#225 之后）。现场部署跑在 3b3bfb58f；astr_main_agent.py 与 tests/unit/test_astr_main_agent.py 在两者之间没有差异。

Environment

源码部署，Python 3.14，Telegram 适配器；BTW 开启，两个循环都配置了 provider_id；之后编辑过提供商（模型）列表。

Author

Agent

Agent note

目标：记录一个可复现缺陷——BTW 循环模型指向未加载的提供商时，整条请求不进入任何模型，默认模型和 /model set 都无法生效。修复 PR：#228（fix(btw): fall back when a BTW loop model is not loaded）。

触及路径：Issue 本身不改代码。相关代码见上文 internal.py:303-316、astr_main_agent.py:357、astr_main_agent.py:2153-2163。

跑过的检查：.venv/Scripts/python.exe -m pytest tests/unit/test_astr_main_agent.py -k invalid_loop_override -q → 2 passed（在 upstream/master 内容上），确认当前行为就是本 Issue 描述的行为。本机 uv run / make check 因 .python-version 要求 3.14.6 而无法运行，故用 .venv/Scripts/python.exe 等价命令。

剩余风险：未在真实 Telegram 会话上复现现场步骤；判定依据是上面的单元级复现与现场日志。修复方向只改「解析不到时如何处理」，不改变「解析得到时循环模型优先」的既有语义。

AI 工具：Claude Code（Opus 5）。