[Bug]: 网络短暂中断并恢复后，QwenPaw 无法自动恢复

QwenPaw Version

2.0.1（qwenpaw --version 确认）

Description

Bug 描述： 网络短暂中断并恢复后，QwenPaw 无法自动恢复，所有 LLM 请求持续报 httpx.ConnectTimeout / openai.APITimeoutError，必须手动重启 QwenPaw 服务进程才能恢复正常。同一天内已复现两次（早上、下午各一次），现象完全一致。

期望行为： 网络中断是常见、正常的瞬态事件。网络恢复后，QwenPaw 应能自动重连 LLM API 并继续正常工作，不需要人工重启服务。

问题核心： 网络恢复后 QwenPaw 不会自动恢复。QwenPaw 每次 LLM 调用都新建 openai.AsyncClient（无连接池复用，已读源码确认），理论上网络恢复后新请求应成功；但实际观察是：网络已恢复（同一 WSL 内 curl 到同一 API 秒连成功），QwenPaw 的 LLM 请求仍持续失败约 7-10 分钟，直到进程重启才恢复。默认重试策略（3 次重试 + 指数退避，总窗口约 7 秒）不足以覆盖分钟级网络故障，且网络恢复后没有自愈或重连机制。

Related PR(s)： 无

Security considerations： 无敏感信息暴露。故障仅表现为 API 请求超时，未涉及认证信息泄露。

Component(s) Affected

[x] Core / Backend (app, agents, config, providers, utils, local_models) [ ] Console (frontend web UI) [ ] Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.) [ ] Skills [ ] CLI [ ] Documentation (website) [ ] Tests [ ] CI/CD [ ] Scripts / Deploy

Environment

QwenPaw version: 2.0.1 OS: Windows 11 + WSL2（networkingMode=Mirrored，内核 6.6.87.2-microsoft-standard-WSL2） Install method: pip Python version (if applicable): 3.12.3

Steps to Reproduce

在 WSL2（Mirrored 网络模式）中运行 QwenPaw，正常运行一段时间（本次故障发生在持续运行数小时后）。
等待或制造一次外网网络闪断（WSL 到外网的 TCP 出口短暂中断，几秒到几分钟）。
网络恢复后，向 QwenPaw 发送任意需要 LLM 的请求（聊天、定时任务等）。
观察：请求持续报 httpx.ConnectTimeout，重试 3 次（退避 1s/2s/4s）后失败；此后所有请求持续失败，即使网络已完全恢复。
手动重启 QwenPaw 服务进程，恢复正常。
Actual vs Expected

Actual: 网络恢复后 QwenPaw 仍持续 ConnectTimeout 约 7-10 分钟不恢复，必须手动重启进程。两次故障窗口：09:22:51 至 09:47:30（重启后 09:50 恢复）；14:50:09 至 15:01:20（重启后 15:02 恢复）。故障期间同环境内 curl https://api.deepseek.com/ 秒连成功（HTTP 401 表示连通），证明网络已恢复但 QwenPaw 未恢复。

Expected: 网络恢复后 QwenPaw 自动恢复，无需人工干预。至少应在网络恢复后的下一次请求中成功，而不是持续失败数分钟。

Logs / Screenshots

2026-08-12 14:56:08 | WARNING | .../qwenpaw/providers/retry_chat_model.py:543 | LLM call failed (attempt 1/4): Request timed out.. Retrying in 1.0s ... 2026-08-12 14:56:28 | WARNING | .../qwenpaw/providers/retry_chat_model.py:543 | LLM call failed (attempt 2/4): Request timed out.. Retrying in 2.0s ... 2026-08-12 14:56:46 | WARNING | .../qwenpaw/providers/retry_chat_model.py:543 | LLM call failed (attempt 3/4): Request timed out.. Retrying in 4.0s ... 2026-08-12 14:57:08 | ERROR | .../qwenpaw/runtime/runtime.py:171 | runtime: unhandled error session=...: Request timed out. 2026-08-12 14:57:08 | ERROR | .../qwenpaw/app/crons/manager.py:369 | cron background task cron-run-... failed: APITimeoutError('Request timed out.') 2026-08-12 15:00:12 | ERROR | .../reme/components/job/base_job.py:68 | Failed to execute job: Request timed out. Traceback (most recent call last): ... httpcore.ConnectTimeout httpx.ConnectTimeout ... raise APITimeoutError(request=request) from err openai.APITimeoutError: Request timed out.

（日志中的 ConnectTimeout 为 TCP 连接层超时；同一时段内两个不同 API 域名同时超时，排除单一服务商问题。）

Additional Notes

故障环境为 WSL2 Mirrored 网络模式，该模式已知存在网络闪断问题（见 microsoft/WSL#11369 等），但这是环境诱因，不是免责理由：网络抖动在真实环境很常见，QwenPaw 应具备自愈能力。
已读源码确认：QwenPaw 每次 LLM 调用都新建 openai.AsyncClient（agentscope _call_api 内），openai SDK 无全局 client 缓存，QwenPaw 未传入自定义 http_client，因此不存在连接池复用坏连接的问题，每次都是新 TCP 连接。网络恢复后新请求理论上应成功，但实际持续失败，说明网络恢复存在滞后或 QwenPaw 进程内存在其他导致恢复失败的状态，需要维护者进一步定位。
可参考的改进方向（供维护者参考）：a) 增大重试窗口（如指数退避上限到 30-60s 并延长总重试时间），使分钟级网络故障可自动跳过；b) 增加网络恢复自愈或重连机制；c) 对 ConnectTimeout 类瞬态错误考虑更长的容忍策略。
影响：故障期间早上 09:20 的「每日选股交易」定时任务因 APITimeoutError 失败（job_id=eadce36c），下午的定时任务同样失败（job_id=ea736333），需人工补跑。