subagent 继承 stale 的 agent.options.provider，忽略 Web 模型选择，导致子代理用错 provider 计费

[evander-wang]

subagent 继承的是父代理创建时固定的 agent.options.provider，而非 Web 模型选择器改后的当前 provider，导致子代理用错 provider 计费。

复现、预期与验收

• 复现步骤：

  1. 新建会话，初始 provider 为内置 deepseek-official。
  2. 在 Web 的 Models 选择器里把会话模型/提供商切换到自定义 provider（例如 provider-A）。
  3. 让父代理派发子代理（spawn / continuable）。
  4. 观察子代理的 subagent/descriptor 与真实发起的 LLM 请求。

• 实际结果：
  子代理的 subagent/descriptor.agentProvider 仍是 deepseek-official，其真实 request/header 也路由到 deepseek-official（计费错误账号）。父会话 request/header 明明已经切到 provider-A。

• 预期结果：
  子代理继承父会话当前生效的模型选择（最后一次 request/header 路由或 ModelSelectionRef.current），而不是创建时冻结的 agent.options。

• 环境：
  @deepseek-ai/dsh-root 0.1.0-rc.8；in-process spawn continuable provider；内置 deepseek-official + 自定义 OpenAI-compatible provider。

• 验收条件：
  父会话用 Models 页切走 provider 后，新派发的子代理 provider 与父会话当前路由一致，不再落到 stale provider。

根因

两套并行的模型状态未对齐：

1. 继承值来自冻结的 agent.options —— packages/subagent/subagent/src/child-agent.ts:68-83 的 resolveChildAgentOptions 读 parent.options.provider；而 parent.options 是 readonly，构造函数固定（packages/core/agent-loop/src/agent.ts:83）。
2. 发请求的基础路由也读 agent.options —— agent.ts:440 const route = { provider: this.options.provider ?? '', ... }。
3. Web 模型选择器改的是另一套状态 —— packages/core/agent/src/model-selection.ts 的 ModelSelectionRef（current/assembled），在 agent/request 瀑布里临时覆盖 provider/model（57–68 行），从不回写 agent.options。

因此父代理一旦在会话中途切换 provider，agent.options.provider 永远停留在创建时的值，子代理读它就会继承到 stale provider。

证据

父会话 request/header 时间线（用户反复切换，已脱敏）：

2026-08-15 14:43:38  provider-A        model-1
2026-08-15 14:48:05  provider-A        model-2
2026-08-15 14:54:28  deepseek-official deepseek-v4-flash
2026-08-15 17:11:15  deepseek-official deepseek-v4-pro
2026-08-15 17:27:10  provider-A        model-3
...
2026-08-16 16:34:36  provider-B        model-4

会话结束时 agent-default-model 已是 provider-A，但派生的所有子代理 descriptor 都是：

{"type":"subagent/descriptor", ...,
 "data":{"version":2,"mode":"continuable","provider":"spawn",
         "label":"...","agentProvider":"deepseek-official","agentModel":"deepseek-v4-pro"}}

某个深度为 1 的子代理实际发起的请求全部是 {"provider":"deepseek-official","model":"deepseek-v4-pro"}，跑了 122 步 / 约 3500 条 reasoning chunk，扣到 deepseek-official 而非用户选择的 provider-A。

注：除内置 deepseek-official 外的 provider/model 名及 session id 已脱敏为 provider-A/provider-B/model-N。

建议修复方向

• 让 resolveChildAgentOptions 从父代理当前生效的模型选择（最后一次 request/header 路由，或 ModelSelectionRef.current）解析子路由，而非 parent.options。
• 或将 Web 模型选择回写一份子代理缝可读的 per-agent 路由，消除两套状态的不一致。

[argszero]

你的根因分析很完整，补充三块让机制闭环 + 修复设计评估：

1. 家族交叉验证 —— 这是同一根因的第 2 个独立报告

这个"子代理继承冻结的 parent.options 而非当前生效路由"的问题，我之前在 #2904 分析过同一机制（resolveChildAgentOptions 读 parent.options.provider 是创建时冻结值）。你的报告独立复现并给出了更硬的证据（descriptor + request/header 双时间线对照），两帖互为交叉验证——特别是"计费错误账号"这个实际后果，把问题从"路由不一致"升级为"真金白银的账算错"。

2. 第三层缺口：子代理的 ctx 根本没有 ModelSelectionRef 槽（比"没对齐"更彻底）

rc.8 里 installSelection（api-proxy.ts:1129）只挂在 composeAgent（:1180/:1189）——即 Web 会话装配路径；而子代理 in-process 创建走 continuation.ts:458 this.materialize(...) → ctx.agents.create()，从不安装 selection 槽。所以：

• 父代理切模型 = 写 selectionFor(parent).current（api-proxy.ts:2230），这个槽是 api-proxy 的 WeakMap（:1062），子代理包根本够不到
• 子代理 ctx 上没有任何 agent/request 瀑布监听 → buildRequest（agent.ts:440）const route = { provider: this.options.provider ?? '', ... } 永远从冻结的 options 构造
• 连 selectionFor getter 的 requestHeader 回退路径（:1108）在子代理上都不存在

所以修复不能只在"继承值"上打补丁——子代理从路由构造到请求发出，整条链都没有 live 来源。

3. 修复设计评估：requestHeader() vs ModelSelectionRef.current

• parent.session.requestHeader()（我在 [BUG] Spawned subagents inherit the parent's creation-time model options — stale provider keeps 401ing until server restart #2904 提过的前例，childSessionMeta 已读 parent.session.header）是近似值：header 只记录"已发出的请求"，如果用户在 Models 页切换后、父代理下一轮请求之前就派发子代理，requestHeader 还是旧值——你验收条件里"切走 provider 后立即派发"恰恰是 pending 态。
• selectionFor(parent).current 才是精确值（含 pending 切换）。但它活在 api-proxy 的 WeakMap 里，子代理包无法访问——需要把 live 选择作为注入的 live-default 穿过 ctx.agents.create()（或在新 seam 上共享同一个 WebModelSelectionRef）。这正是"路由构造（agent.ts:440）"与"descriptor 继承（child-agent.ts:73）"两处都要吃到的同一来源。
• 附带一个点：resolveChildAgentOptions 与 buildRequest 都读 options，若只改前者（descriptor 好看）而后者仍从 options 构造，第一轮请求照样落到 stale provider——两处必须同源。

修复形态建议（按优先级）：① 子代理创建时注入父代理的 live WebModelSelectionRef（精确、含 pending）；② 做不到共享 ref 时，退化用 parent.session.requestHeader() + 在子代理 ctx 安装 installModelSelection（让 child 也有一条可覆盖的瀑布）；③ 最小改动：resolveChildAgentOptions 的 provider/model 优先取 live 选择。验收时除了看 subagent/descriptor.agentProvider，记得验证子代理首轮 request/header（两处同源的硬证据）。

[weijiafu14]

这个问题不仅是显示错误，确实会把子代理费用打到错误账户。补一个已经用持久请求日志验证过的替代路径（Pi 子代理插件路线，不是 DSH 原生 subagent 修复）：

dsh plugin --profile <你的-profile> add pi2dsh
dsh plugin --profile <你的-profile> add @tintinweb/pi-subagents

pi2dsh 创建子代理时不再把 agent.options.provider/model 当作当前路由，而是优先读取调用者最后一次真实 request/header，provider 和 model 成对继承；显式 per-child 模型仍然优先。

真机 E2E 中父会话先走官方 provider，再通过 /model 切到独立网关；子代理会话的持久 header 只出现新网关，且工具执行成功。也就是说在这条替代路线里，可以从日志审计“父当前路由 = 子默认路由”，不会静默回到创建时账户。

复现与证据：
https://github.com/weijiafu14/pi2dsh/tree/main/examples/subagents
https://github.com/weijiafu14/pi2dsh/blob/main/community/subagents-acceptance-report.md