# Bug：subagent 在无显式覆盖时静默使用与父 Agent 不同的模型

[xuanyuyufish]

Bug：subagent 在无显式覆盖时静默使用与父 Agent 不同的模型

摘要

一个运行在 basecq/gpt-5.6-sol（部分后续回合为 basecq/gpt-5.6-terra）上的 DSH 父 Agent，调用普通 subagent 后，创建的子代理实际运行在 base/glm-5.3。

父 Agent 的 subagent 调用参数不含 provider、model 或 agentOptions。但子会话持久化 descriptor 明确记录：

{
  "origin": "subagent",
  "delegationDepth": 1,
  "agentProvider": "base",
  "agentModel": "glm-5.3"
}

这不符合 DSH 当前子代理实现的默认继承逻辑：未提供 request.agentOptions 时，子会话应继承父会话的 provider/model。并且，用户无法在委派时发现模型改变，历史会话也没有保存覆盖来源。

预期行为

普通 subagent 调用不携带模型路由参数时：

父 Agent provider/model  ->  子 Agent provider/model

若某个配置组件有意覆盖子代理路由，DSH 应明确显示并持久化该覆盖的来源、规则和最终路由。

实际行为

父 Agent：basecq / gpt-5.6-sol
          （后续部分回合：basecq / gpt-5.6-terra）

调用：subagent({ description, prompt, run_in_background: true })
      无 provider/model/agentOptions 参数

子 Agent：base / glm-5.3
          origin: subagent
          delegationDepth: 1

该差异在约 50 分钟内产生 50 条 glm-5.3 上游 API 调用。用户没有手动在 GUI 中选择 GLM，也没有手动创建这些子会话。

影响

1. 意外计费/额度消耗：父会话显示使用 A 模型，子任务却可静默消耗 B 模型额度。
2. 数据与策略边界不透明：跨 provider 可能对应不同的数据处理、区域路由、保留策略、能力或安全边界。
3. 不可审计：会话只记录最终子模型，未记录谁、以哪条规则、为何进行了覆盖。
4. 用户信任问题：用户看到的父会话使用 basecq，实际任务被委派到 base/glm-5.3。

证据

以下数据均来自本地 DSH session 持久化与已安装 DSH 源码。已删除凭据、完整提示词和服务器敏感信息。

1. 父会话使用 basecq，不是 GLM

父 session（脱敏）：session-cecd679c-…。

持久化 request/header：

{
  "config": {
    "provider": "basecq",
    "model": "gpt-5.6-sol",
    "reasoningEffort": "max"
  }
}

后续回合：

{
  "config": {
    "provider": "basecq",
    "model": "gpt-5.6-terra",
    "reasoningEffort": "medium"
  }
}

2. 父 Agent 调用了不带模型覆盖的普通 subagent

约 09:08:39，父会话发出两条调用（任务正文已脱敏）：

{
  "name": "subagent",
  "arguments": {
    "description": "设计现状适配方案",
    "prompt": "...",
    "run_in_background": true
  }
}

{
  "name": "subagent",
  "arguments": {
    "description": "审查风险迁移路径",
    "prompt": "...",
    "run_in_background": true
  }
}

参数中均无 agentOptions、provider 或 model。后续独立设计/复核子代理也出现同样不一致。

3. 子会话明确记录为 base/glm-5.3

代表性子会话：

{
  "id": "30784a97-…",
  "parentSession": "session-cecd679c-…",
  "origin": "subagent",
  "delegationDepth": 1
}

{
  "type": "subagent/descriptor",
  "data": {
    "mode": "continuable",
    "provider": "spawn",
    "label": "审查风险迁移路径",
    "agentProvider": "base",
    "agentModel": "glm-5.3"
  }
}

子会话的 request/header：

{
  "config": {
    "provider": "base",
    "model": "glm-5.3"
  }
}

同一时间启动的 8181a615-… 及同父任务后续多个子会话，也记录为 base/glm-5.3。

4. 上游用量记录佐证

网关日志在本地时间 09:08:50–09:58:54 记录到 50 条 glm-5.3 调用，均为 OpenAI-compatible Chat Completions 路径，时间与子会话活动一致。

该记录仅作佐证；父/子 session 元数据和工具调用已经直接证明了自动委派及最终路由。

5. DSH 当前源码的默认继承逻辑

已安装版本的 @deepseek-ai/dsh-subagent/lib/index.js：

const agentProvider = request.agentOptions?.provider ?? parent.options.provider;
const agentModel = request.agentOptions?.model ?? parent.options.model;

因此，在父调用未传 agentOptions 的前提下，跨模型路由意味着：有效执行路径中某处提供了不同的 request.agentOptions，或在该解析前/解析过程中存在缺陷。

标准 @deepseek-ai/dsh-tool-subagent 工具 schema 仅暴露：

description, prompt, run_in_background

环境

• DeepSeek Harness Web GUI
• User-Agent：deepseek-harness/0.1.0-rc.8
• Windows，web profile
• 父路由：basecq/gpt-5.6-sol，后续 basecq/gpt-5.6-terra
• 子路由：base/glm-5.3
• 本地 JSONL 压缩 session 持久化
• 标准 subagent 工具启用；安装中同时存在自定义/注入插件和 Agent preset
• 事后检查的静态 profile YAML 中未发现 tool-subagent 的 agentOptions 覆盖

已知与未知

已知

• 父 Agent 直接调用了 subagent。
• 父调用未指定 provider/model。
• 子会话均为 origin: "subagent"、delegationDepth: 1。
• 子会话被解析到不同 provider/model。
• 差异产生了真实的跨 provider GLM 流量。
• 当前源码表示无 request.agentOptions 时应继承父路由。

未知

历史 session 仅保存解析完成后的子模型，未保存路由覆盖来源。该覆盖可能来自运行时 preset、注入插件、router 或其他 wrapper；静态 profile YAML 未能确认来源。

“路由覆盖来源缺失”本身是本 Issue 请求修复的可观测性问题。

最小复现建议

1. 配置两个有效路由：A/model-A 和 B/model-B。
2. 明确用 A/model-A 启动父 Agent。
3. 启用标准 continuable subagent（provider: spawn，不设置 agentOptions）。
4. 调用 subagent({ description, prompt, run_in_background: true })，不传路由覆盖。
5. 检查子会话 subagent/descriptor、request/header 和父/子 agent.options。

预期： 子会话为 A/model-A。
本安装观察到： 子会话为 B/model-B。

请求的修复

1. 默认继承断言

subagent 未收到显式 agentOptions 时，断言子会话 provider/model 等于父会话。若不同，不应静默继续，应输出结构化错误或警告。

2. 持久化路由来源

建议将如下信息写入子会话 descriptor 或 request header：

{
  "modelRoute": {
    "parent": { "provider": "basecq", "model": "gpt-5.6-sol" },
    "resolved": { "provider": "base", "model": "glm-5.3" },
    "source": "plugin-or-config-id",
    "ruleId": "optional-rule-id",
    "explicitOverride": false
  }
}

至少需区分覆盖来自调用方、工具配置、preset 或拦截层。

3. UI 显示跨 provider 委派

子代理创建前/创建时显示最终 provider/model；跨 provider/model 路由应明确区别于普通继承。

4. 回归测试

建议覆盖：

• 无 agentOptions：继承父 provider 与 model；
• 仅覆写 model：provider 继承；
• 仅覆写 provider：若目标 provider 不支持父 model，清晰拒绝；
• 拦截/配置覆盖：持久化覆盖来源；
• 父子路由不一致：写入审计事件。

临时规避

在根因和来源追踪修复前，需要禁止隐式跨 provider 委派的用户，可禁用 tool-subagent / 相关 Agent preset，或使用能够显式固定子代理路由的配置。

可提供的脱敏附件

• 父会话的 subagent tool/call 事件；
• 子会话 subagent/descriptor 与 request/header；
• 仅含时间戳的网关用量关联记录；
• 已删除凭据的 profile/preset 配置。
  由5.6sol整理

[ylwl1997]

父会话是 basecq/gpt-5.6-*、子会话落到 base/glm-5.3，这不是「子 agent 不跟随 UI 切换」(#3377 / #3878)，而是某个插件或自定义 preset 在 tool-subagent 上叠了 agentOptions。调用没带 provider/model 时就会吃到这条 overlay，轨迹里也看不到来源。

没有 settings.yaml 键能单独钉死子模型。到插件列表里找会改 subagent / 默认模型的行（套装或自定义 preset 常见），临时 dsh plugin --profile web disable 那条，或去掉 overlay 后再开新会话验证。已经在跑的子会话不会热跟随。

[weijiafu14]

补一条可立即落地、并且可以从 session 日志审计最终路由的替代方案。边界先说清：它不改变 DSH 原生 subagent，而是把 Pi 社区的 @tintinweb/pi-subagents 接成原生 DSH child sessions：

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

未指定覆盖时，子代理默认 route 来自父会话最后一次真实请求，而不是创建时的全局默认；provider/model 作为一对继承。每个子会话仍有自己的 subagent/descriptor 和 request/header，所以实际使用了哪个模型可以事后核验。

stock TUI 真机测试已经做过“父会话官方模型 → /model 切换独立网关 → spawn 无模型子代理”，子日志只记录切换后的网关并完成真实工具调用。复现：
https://github.com/weijiafu14/pi2dsh/tree/main/examples/subagents
https://github.com/weijiafu14/pi2dsh/blob/main/community/subagents-acceptance-report.md