[Bug] callAgent: the called agent runs on the caller’s model, its own model/provider are ignored (v2.2.17)

快速结论：在 LobeChat v2.2.17 中，当 Agent A 通过 lobe-agent-management 的 callAgent 调用 Agent B 时，B 的子运行会继承调用方 A 所在话题锁定的 model / provider，而不是 B 自己配置的模型，导致报错 [Bug] callAgent: the called agent runs on the caller’s model, its own model/provider are ignored。优先排查被调用 Agent 是否运行在调用方的话题上（isolation thread）。

适用环境：自建 Docker 部署，LobeHub / LobeChat v2.2.17，已启用 Agent Mode，CLI lh 0.0.54。Issue 未提及操作系统、Python、CUDA 或显卡信息。

最快修复方案：升级到包含 #20385 修复的版本。该修复让话题的模型锁定仅对话题自身的 Agent 生效，通过 callAgent 启动的被调用 Agent 会按顶层运行的方式解析并使用自己的 model / provider。

注意事项：#20385 的补丁同时保留了两条既有行为：话题自身 Agent 仍会回退到话题锁定的模型，显式的单次运行 override 仍然优先生效。如果你暂时无法升级，callAgent 本身并不暴露 model / provider 参数，无法通过调用参数绕过该问题；可考虑改用会显式传递 override 的 callSubAgent 虚拟子 Agent 路径。

问题场景

在 LobeChat 自建环境中使用 Agent Mode。用户创建两个配置了不同模型的 Agent：Agent A（model: DeepSeek-Flash、provider: deepseek_relay）与 Agent B（model: gpt-6-astra、provider: openai_relay）。在 A 上启用 lobe-agent-management 后，让 A 通过 callAgent 把任务委派给 B。

此时 B 的子运行实际跑在 A 的模型上，B 自己配置的 model / provider 被忽略。而直接用 lh agent run -a <B> 以顶层运行方式启动 B 时，B 的模型配置是正确的。

报错原文

[Bug] callAgent: the called agent runs on the caller's model, its own model/provider are ignored (v2.2.17)

agent_operations: model = DeepSeek-Flash, provider = deepseek_relay (parent_operation_id points to A's operation)
messages: every assistant message written by B inside that topic has model = DeepSeek-Flash, provider = deepseek_relay

原因分析

根因已由维护者确认：callAgent 会在调用方的话题中以隔离线程（isolation thread）运行被调用的 Agent，并且不传递任何 model / provider。

当 execAgent 复用已有话题时，会应用该话题锁定的 model / provider（相关代码位于 apps/server/src/services/aiAgent/pipeline/turnSetup.ts），而原有的守卫逻辑只排除了群组话题，因此在普通话题上调用方的锁定模型会覆盖被调用方的自身配置。

callAgent 只解构 { agentId, instruction, taskTitle, timeout }，随后调用 subAgent.run({ agentId, description, instruction, timeout })，未传 model / provider。
执行器 execSubAgent 调用 execAgentThreadRun(deps, e, { isSubAgent: false, logScope: 'execSubAgent' })，同样不带 model / provider。
相比之下，虚拟子 Agent 路径 execVirtualSubAgent 会传入 { ..., model: e.model, provider: e.provider }，取自调用方的 agencyConfig.subagent，这也是 callSubAgent 能跟随配置模型、而 callAgent 不能的原因。

顶层运行 lh agent run -a <B> 使用的是 B 自己的话题，所以行为正常；callSubAgent 之所以不受影响，是因为它显式传递了 override。同类历史问题参见 #17511（在 #17766 中通过让显式传入的 model / provider 优先于复用话题的锁定值来修复），以及 #17403、#17902。

环境排查

确认 LobeChat / LobeHub 版本是否为 v2.2.17（该问题在修复版本之前的版本中存在）。
确认是否为自建 Docker 部署。
确认是否已启用 Agent Mode。
确认 lh CLI 版本（Issue 中为 0.0.54）。
确认调用方 Agent 已启用 lobe-agent-management。
核对两个 Agent 的 model / provider 配置确实不同且各自有效。
Issue 未提供 Python、CUDA、PyTorch、显卡信息，无需在这些方向排查。

解决步骤

升级到包含 #20385 修复的 LobeChat 版本。
升级后，话题的模型锁定只会应用到该话题自身的 Agent。
通过 callAgent 启动的被调用 Agent 会按顶层运行的方式解析并使用自己的 model / provider。
话题自身的 Agent 仍然回退到话题锁定的模型；显式传入的单次运行 override 依旧优先生效。
若暂时无法升级：由于 callAgent 不暴露 model / provider 参数，没有已知的一步绕过方案；可优先尝试改用会显式传递 override 的 callSubAgent 虚拟子 Agent 路径。

验证方法

复现原流程后检查数据表：

查询 agent_operations 中 agent_id = <B> 且 parent_operation_id 指向 A 操作的子操作，确认记录的 model / provider 为 B 自己的配置（如 gpt-6-astra / openai_relay），而非 A 的。
查询该话题下由 B 写入的 assistant messages，确认其 model / provider 也与 B 的配置一致。
作为对照，再执行 lh agent run -a <B> 顶层运行，两者的模型记录应当一致。