子进程全部都走到了主模型上了

[springsky1]

我给子模型单独配了一个key 发现所有请求都走到主模型上子模型一个token都没有消耗

[springsky1]

[springsky1]

[springsky1]

[springsky1]

qqq

[PerryLink]

这个现象可以从源码上定下来：它不可能是「选了子模型但被静默降级」，而只能是「从来没有选过路由」。下面按判断顺序给依据，最后给两个自查手段。

1. 路由规则：显式选择 → 已配置默认值 → 继承父会话

委派调用里不传 provider/model 时，requestedAgentOptions 直接返回该工具实例的默认值：

packages/subagent/tool-subagent/src/model-selection.ts:105

if (!hasDelegationModelRequest(request)) return configured

若该实例也没有默认值，子会话就继承父会话的有效请求头里的 provider/model（不只是创建时的 options）：

packages/subagent/subagent/src/child-agent.ts:69-86 读的是 parent.session.requestHeader()?.config；:104-119 把它铺开、再让 ...requested 覆盖。

schema 的描述写的就是这件事（packages/subagent/tool-subagent/src/index.ts:405-406,411-412）：

omit both to use configured child defaults or inherit the parent route

2. 白名单只「授权」，从不「强制」——所以不会是静默降级

这条是关键，源码注释写得很直白：

packages/subagent/tool-subagent/src/model-selection.ts:130-133

/**
 * Enforce a settings-owned route list at the operation that creates the child.
 * Pure inheritance remains outside this policy because no model-facing choice
 * occurred; any explicit route or effort field must resolve to an allowed route.
 */

而且越界时是 抛错，不是回落（:151-152）：

if (policy.routes.some(route => route.provider === provider && route.model === model)) return
throw new Error(`child LLM route "${provider}/${model}" is not allowed for this Session`)

⇒ 纯继承刻意不受白名单约束；而一旦真的显式选了、又不在白名单里，你会看到一条明确的报错。所以「全部走到主模型、子模型 0 token」这个现象，只能解释为路由字段根本没被带上。

3. 最可能的原因：策略是按会话快照的

那些路由字段只在该会话的策略已解析时才存在，而策略是逐会话快照的 —— 改动设置只影响此后新建的顶层会话。你截图里那句「仅影响新会话」说的就是这件事。在开关打开之前就已经建立的会话，工具 schema 里根本没有路由字段，于是每次都走静默继承。

4. 两条会直接导致「怎么配都不生效」的边界

• subagent_fork 在设计上永远不能改路由。packages/bundle/base/cordis.patch.yml:363（四个预设里同一行注释都在）：

  Fork omits model selection so provider/model stay equal to the parent
  只有 spawn 的 subagent 那一行带 modelSelectionSettings。如果你用的是 subagent_fork，换型号这件事本身不成立。

• 凭据是按 provider 解析的，不是按 model。apiKeyEnv 是 provider 行上的单个 credential ref（packages/llm/llm-deepseek/src/config.ts:29,82）。同一个 provider 下的两个模型共用这把 key —— 想用另一把子 key，需要另建一个 provider 条目。所以在 pluson 内部换模型，token 仍记在同一把 key 上。

5. 两个自查手段

1. 看 list_subagent_models 在不在工具表里。 它只在策略已解析的会话中注册（packages/subagent/tool-subagent/src/list-models.ts:86 接收 policy: ModelSelectionPolicy）。如果这个工具不存在，就证明那个会话压根没有路由能力 —— 换新会话再试即可。
2. 看子会话第一次请求头里的实际 provider/model。 子路由由父请求头推导（上面 child-agent.ts:69-86），所以子会话发出的第一个请求头就写着真正生效的那一对值。

---

我没能确定的部分（照实说）：我看不出你这次观测具体是上面哪一条造成的 —— 手上没有你的配置转储、没有会话日志、也没有那次委派调用的实际参数，截图里也看不到该会话的工具 schema 和子会话的 transcript。另外 DSH Desktop 0.6.4 的 composition 是另一个产品，我没有核对它挂载了哪些行。如果方便，把「list_subagent_models 是否出现」和「子会话首个请求头的 provider/model」贴出来，就能直接定位到具体哪一条。