[Bug Report] 子代理继承父代理的"创建时默认模型"而非"会话当前模型"，第三方 provider 会话中 subagent 必报 no API key for provider route "deepseek-official"

[DRAG0NM]

摘要

子代理（subagent）的模型路由继承自父代理的 AgentOptions（dsh-subagent 的 resolveChildAgentOptions），而 Web 会话里父代理的 options.provider 在创建时被固化为默认模型选择（agentDefaultModel）。父代理实际运行所用的模型则是会话级选择（会话内切换的模型，记录在 session 的 request header / in-process 选择表里，selectionFor 的优先级：in-process 选择 → 会话日志 → 默认）。两条链不一致：当会话运行在第三方 provider（自建网关/兼容 API）而默认选择仍是官方路由时，父代理一切正常，但模型一调用子代理，子代理就按默认路由 deepseek-official 解析凭据（找 DEEPSEEK_API_KEY），用户根本没有该 key → llm-deepseek: no API key for provider route "deepseek-official"。这正是 #117 的现象：第三方 API 下，模型调用子代理必失败。

根因（源码定位，rc.6）

1. dsh-host-apiproxy/lib/index.js L1708-1714：Web 会话创建/恢复时的 seed options——

   const agentOptions = () => {
     const { provider, model } = defaults.defaultModelSelection();  // 默认选择，非会话选择
     return { provider, model };
   };

   父代理 options.provider 从此固化。
2. 同文件 selectionFor()（L1750-1773）：父代理实际每轮请求用的模型解析优先级是
   in-process 选择 → agent.session.requestHeader()?.config（会话里选过的模型）→
   默认选择。会话级切换只落在这一层，不回写 parent.options。
3. dsh-subagent/lib/types/child-agent.js resolveChildAgentOptions()（L51-62）：

   const parentProvider = parent.options.provider;   // ← 创建时固化的默认路由
   const parentModel = parent.options.model;

   子代理只继承这两个字段，完全看不到第 2 条的会话级选择。
4. dsh-llm-deepseek/lib/index.js resolveApiKey()（L740-750）：子代理按
   deepseek-official 路由解析 apiKeyEnv（默认 DEEPSEEK_API_KEY），
   credentials 服务与启动环境都没有该 ref → 抛 MISSING_CREDENTIAL。
   第三方用户的 key 存在他们自己的网关 ref 下，永远匹配不上。

链路总结：会话级模型选择（父代理实际路线）≠ parent.options（创建时的默认路线）→ 子代理继承后者 → 路由到默认 provider → 凭据解析必然落空。

复现步骤

1. 默认模型选择保持官方 deepseek-official（不配 DEEPSEEK_API_KEY，或配一个不存在的值）。
2. 在某个会话内把模型切换为自建网关/第三方兼容 provider（配置了可用 key），此时主代理对话一切正常。
3. 在该会话中让模型调用子代理工具（subagent / 后台子代理）。
4. 结果：子代理首轮即报
   llm-deepseek: no API key for provider route "deepseek-official"; store DEEPSEEK_API_KEY ...
   （子代理BUG #117 原报错）。
5. 对照：把默认模型选择也改成该第三方 provider → 子代理正常（证明断点就在"继承对象选错"）。

建议修复

方案 A（推荐）· 继承父代理的"有效模型"而非创建时 options：在 resolveChildAgentOptions（或驱动器调用点）处，按与父代理一致的优先级解析父代理当前有效的 provider/model（in-process 选择 → session request header → 默认选择）再传给子代理。改动集中在 dsh-subagent 一处，语义正确：子代理永远跟随父代理此刻实际在用的路线。

方案 B · 会话级选择同步回写 options：每次 session.selectModel/in-process 选择变更时同步更新 parent.options.provider/model，使 options 始终等于有效路线。改动面更广（要处理回写与持久化一致性），不如 A 干净。

方案 C（缓解）· 子代理报错信息补充实际路由与继承来源：即使短期不修，MISSING_CREDENTIAL 时提示"该路由来自父代理创建时的默认模型选择，当前会话运行的是 X"，可大幅减少定位时间。

影响

• 所有"默认官方 + 会话内切第三方网关"的用户，子代理工作流 100% 不可用（subagent、后台子代理、workflow 分叉均受影响）
• 与 子代理BUG #117 完全吻合；[Bug] 多个子任务结束后主任务返回 HTTP 400 / HTTP 400 after multi-agent reports #422（多子任务后主任务 HTTP 400）可能同源或相关

环境

• 源码定位：0.1.0-rc.6（npx 缓存安装包，Node v24.16.0，Windows 11）
• 原报告：子代理BUG #117（第三方 api 时模型调用子代理失败，0 评论，此前无人分析）

验证材料

• 四个源码定位点（文件+行号）见"根因"节，链路可静态复读
• 复现步骤 5 步可任意环境执行；第 5 步的对照实验（改默认选择即恢复）是最强验证

---

First analysis of discussion #117. Happy to open a PR with fix option A.