[BUG] dsh subagent 在 GUI 冷恢复后默认切回 dsv4p 模型导致扣费路由错误

[NattoCB]

问题

Subagent 继承的是 agent.options 而非父 agent 的实际模型路由 —— GUI 切换模型或冷恢复后子代理静默跨 provider 计费

---

概述

dsh-subagent 解析子代理的 provider/model 时读取的是 parent.options（父 agent 创建时的 AgentOptions），而父 agent 的实际服务路由可以被模型选择瀑布（installModelSelection，@deepseek-ai/dsh-agent）按请求覆盖。两者一旦分叉，subagent 就会静默地把账单记到 agent.options 里写的 provider 上——而不是父 agent 真正在用的那个 provider。

本次事故中，分叉由 GUI 冷恢复路径引入：它用部署默认模型播种 agentOptions，同时把服务路由钉在会话持久化的 request/header 上。父 agent 自己一直在钉定路由上跑，但它派生的全部 61 个子/孙会话都按部署默认模型创建，账单全部记到了官方平台账号。

严重度

Critical —— 静默跨 provider 计费 / 成本泄漏，附带错误模型执行。财务影响只有去 provider 账单页才看得到。

环境

• @deepseek-ai/dsh 0.1.0-rc.6；涉及包均为 0.1.0-rc.6：
  dsh-subagent、dsh-host-apiproxy、dsh-api-remotes、dsh-agent-loop、dsh-agent-default-model、dsh-agent、dsh-session。
• Node.js v22.22.2，macOS 26.6.1 (arm64)。
• 服务：launchd com.deepseek.dsh.web 运行 dsh web，监听 127.0.0.1:3080。

真实事故

时间线（UTC+8）：

时间	事件
20:48	session 启动。第 1 轮。request/header（reason=initial）：custom1/custom1。
21:18	DSH 宿主停止（重启）。run 记录被 recoverInterruptedRuns() 标为 failed / host_interrupted。
21:24	会话经 Web GUI API proxy 冷恢复。request/header（reason=resume）：仍是 custom1/custom1。
21:37 / 21:50 / 22:01	恢复后的父 agent 分三批派发 44 个直接子代理 + 17 个孙代理。
22:10	最后一个子代理活动结束。期间 DeepSeek 平台账号持续扣费。

观测到的父/子分叉：

• 父会话日志（每一条 request/header）：config.provider=custom1，config.model=custom1。
• 每个子会话日志（subagent/descriptor）："agentProvider":"deepseek-official"，"agentModel":"deepseek-v4-pro"；子会话自己的 request/header 证实它确实由 deepseek-official/deepseek-v4-pro 服务。
• deepseek-official/deepseek-v4-pro 正是 settings.yaml → agent-default-model——即部署默认模型。

成本：树内 61 个子会话，token 字段合计 ≈ input 471 万 / output 190 万 / reasoning 109 万（≈ 770 万），全部记到错误的provider，而父 agent 的流量一直走原路由。

根因

1. subagent 继承读的是 options，不是实际路由

@deepseek-ai/dsh-subagent/lib/index.js（0.1.0-rc.6），resolveChildAgentOptions（501–512 行）：

function resolveChildAgentOptions(parent, requested, childDepth) {
	const parentProvider = parent.options.provider;
	const parentModel = parent.options.model;
	const parentMaxTokens = parent.options.maxTokens;
	return {
		...parentProvider !== void 0 ? { provider: parentProvider } : {},
		...parentModel !== void 0 ? { model: parentModel } : {},
		...parentMaxTokens !== void 0 ? { maxTokens: parentMaxTokens } : {},
		...requested,
		subagentDepth: childDepth
	};
}

parent.options 是父 agent 创建/恢复时传入的 AgentOptions。任何改变父 agent 实际服务路由的机制都不会更新它。

2a. 冷恢复用部署默认模型播种 options，同时把路由钉在会话日志上

@deepseek-ai/dsh-host-apiproxy/lib/index.js（0.1.0-rc.6），createApiProxy：

/** The seed model each create/resume declares; re-read so it never goes stale. */
const agentOptions = () => {
	const { provider, model } = defaults.defaultModelSelection();
	return { provider, model };
};

这个闭包同时用于全新创建和冷恢复（经 createApiRemoteAgentResolver → ctx.agents.resume({ resumeSessionId, agentOptions: options.agentOptions() })，@deepseek-ai/dsh-api-remotes/lib/index.js 124–126 行）。

而 selectionFor()（host-apiproxy 1750–1774 行）按此优先级安装请求级选择：进程内 picker 选择 → 会话持久化的 request/header 配置 → 部署默认。于是恢复后的 agent 处于：

• agent.options = 部署默认（deepseek-official/deepseek-v4-pro）
• 每次请求的实际路由 = 持久化 header（custom1/custom1）

父 agent 自己的 LLM 调用因此继续走持久化路由（正确），但 resolveChildAgentOptions 把 agent.options——部署默认——复制进每个子代理（错误，产生扣费）。

2b. GUI 模型选择器在活跃会话上有同样的分叉

模型选择 RPC（host-apiproxy 2701 行）：

selectionFor(found.agent).current = selected;

它只写请求级 selection，从不写 agent.options。因此任何用户在 GUI 里选了不同于 agent-default-model 的模型的会话，立即出现 options ≠ 实际路由，它派生的每个 subagent 都会静默记到默认 provider 的账上。无需重启——这就是下面的最小复现。

最小复现

复现 A —— GUI 模型选择器（无需重启）：

1. settings.yaml 的 agent-default-model = provider A / model a。
2. 新建会话。用模型选择器切到 provider B / model b（B ≠ A）。
3. 发送：「Delegate one subagent (run_in_background: false) to reply with a single word.」
4. 观察：父会话 request/header = B/b；子会话的 subagent/descriptor 与 request/header = A/a。扣费的是 provider A。

复现 B —— 冷恢复：

1. 会话被钉到 B/b（picker）。至少发一次请求，让 request/header 存在。
2. 重启 dsh web。
3. 在 GUI 恢复该会话并派发一个 subagent。观察结果同上。

[Cfomodz]

Duplicate RCA as #1581/#1472/#2006/#2053

Also document correction: JSDoc at runtime-types.ts:67-68

[weijiafu14]

这份 RCA 是这一族里最完整的一份（定位到 resolveChildAgentOptions 501–512、把 2a 冷恢复和 2b 选择器两条分叉分开、还带 61 个子会话 770 万 token 的实测账）。我只补一件事，因为它会直接影响这个 bug 被怎么修。

你的标题在削弱你自己的发现

标题写的是「GUI 冷恢复后默认切回 dsv4p」，但你自己的复现 A 是这样的：

复现 A —— GUI 模型选择器（无需重启）

以及正文里那句：

因此任何用户在 GUI 里选了不同于 agent-default-model 的模型的会话，立即出现 options ≠ 实际路由 ……无需重启

这两件事的影响面差着一个数量级。 冷恢复要求宿主先重启过；而 2b 只要求"在 GUI 里换过一次模型"——那是每个用第三方 provider 的人每天都在做的动作。也就是说：不是"重启过的会话有风险"，是**"任何换过模型的会话，从那一刻起派生的每个子代理都记在默认 provider 账上"**。

为什么这值得单独说：维护者按标题分诊时，很容易把修复范围圈在 resume 路径上（createApiRemoteAgentResolver → ctx.agents.resume 那条），修完之后 2b 依然完好无损——而 2b 触发得更频繁。你在正文里已经把话说全了，但标题和正文打架时，通常是标题赢。

建议把标题改成后果 + 触发条件的宽口径，比如「subagent 继承 agent.options 而非实际路由 → 换过模型的会话静默跨 provider 计费（冷恢复与 GUI 选择器两条路径）」。

关于 @Cfomodz 说的重复

他指的 #1581 / #1472 / #2006 / #2053 确实同源。但重复不等于冗余——这一族现在有五份独立报告，各自贡献的证据类型不同，而你这份是唯一同时具备"根因定位到函数 + 两条分叉路径分别可复现 + 实际计费金额"的。

对维护者来说更有用的做法可能是：在你这帖里把五份并成一张表（谁贡献了什么证据），然后建议其余四帖指向这里，而不是让五个线程各自半死不活。这一族的说服力在于五个人在五种配置下撞到同一行代码——但只有并起来才看得出来。

一个结构性的观察

parent.options 和"父 agent 实际在用的路由"是同一个事实的两份副本，而只有其中一份会被模型选择瀑布更新。子代理读了没人更新的那一份。

这个形状最近在这个社区出现得很密：#2915 是 replay metadata 与持久内容从同一份数据的两个不同版本各自派生、于是长度对不上；#3226 / #3566 是模型声明在归一化时被剥掉一半。共同点是"同一个事实存了两份，只有一份跟着变"，而不一致的代价一律由用户承担。

按这个视角，最小修法（resolveChildAgentOptions 改读实际 selection）之外还有个更彻底的问题值得提：agent.options.provider/model 在存在请求级 selection 的世界里，还应不应该被任何人当作"当前模型"来读？ 如果答案是不该，那要找的就不止 subagent 这一处。

边界与利益相关

我们不修 DSH 自家组件——dsh-subagent、host-apiproxy、模型选择瀑布都在 DSH 里，上面全是分析和建议。

利益相关必须披露：我维护 pi2dsh，它能跑一套 Pi 生态的子代理，而那套子代理是按会话当前的实时路由解析模型的，不吃创建期快照（我们有端到端的 example，断言是"父会话 /model 切换后，未固定模型的子代理跟着换到新路由"）。所以理论上它不会有你这个分叉。

但我不建议你为这个换掉 DSH 原生子代理，理由有三条：① 你要的是这个 bug 被修，换运行时不会让 #1581/#1472/#2006/#2053 那四份报告消失；② 你已经把根因精确到函数和行号了，一行改动的事，不值得换一整套运行时；③ 换过去你会失去 DSH 原生子代理的那些集成。我写这段只是为了把利益相关摊开，不是推销。