🐛 Bug: 会话内切换模型后，子 Agent 仍使用创建时的全局默认模型

[delaydai]

现象

在 GUI 会话中通过模型选择器把当前会话模型切换到「千问3.8」（provider qwen-local）后：

• 编排器（父 Agent）自身的请求确实使用千问 ✓
• 但该会话通过 subagent / subagent_fork 派生的子 Agent 仍然使用会话创建时的全局默认模型（deepseek-official / deepseek-v4-flash）✗

期望：子 Agent 继承父 Agent 当前生效的模型，除非显式指定（如 preset 的 agentOptions）。

复现

1. 配置两个 provider，全局默认模型为 A。
2. 新建会话（父 Agent 以 A 创建）。
3. 会话内切换到模型 B。
4. 父 Agent 发消息确认使用 B，然后调用 subagent 派生子 Agent → 子 Agent 实际使用 A。

根因

两套机制脱节：

• 子 Agent 继承链存在：packages/subagent/subagent/src/child-agent.ts 的 resolveChildAgentOptions() 与 continuation.ts（约 413 行）都以 parent.options.provider/model 为继承源。
• 但会话内切换模型走 installModelSelection（packages/core/agent/src/model-selection.ts），只挂钩 system-prompt/assemble 与 agent/request，从不回写 agent.options；而创建 Agent 时（packages/host/apiproxy/src/api-proxy.ts 约 1112 行）一律用全局默认 agentOptions()。
• 结论：继承源是「创建时选项」而非「当前生效选项」，会话切换对子 Agent 不生效。

已修复（附补丁）

修改：子代理模型解析优先读父会话最近一次实际请求的模型（parent.session.requestHeader()?.config，即 harness 自身认可的"当前生效模型"来源，apiproxy 1163 行同源），回退到创建时选项；显式 agentOptions 仍优先。

• 文件：child-agent.ts（新增 parentModelRoute）、continuation.ts（续跑路径）、测试 continuation.spec.ts
• 测试：continuation.spec 98/98 通过（含新增回归测试）
• 补丁：见附件 / 可联系获取（commit f892329，分支 fix/subagent-model-inheritance，已推送至 fork delaydai/deepseek-harness）

若团队认为方向正确，可直接应用该补丁；也欢迎指正更合适的实现位置（例如让 installModelSelection 同步回写 agent.options，或把 ModelSelectionRef 暴露给 subagent 解析路径）。

影响

任何"会话内切换模型后派生子 Agent"的用法都会静默使用旧模型（子 Agent 会话不显示模型，不易察觉）。对多模型部署（本地 Qwen + 云端 DeepSeek 混用）影响明显。

临时规避（部署侧）

在 preset 的 tool-subagent / tool-subagent-fork 配置 agentOptions: { provider, model } 固定子 Agent 模型。

[weijiafu14]

这个问题现在有一条已经在 stock DSH + 真模型上跑通的替代路线。先说明边界：这不是修改 DSH 原生 subagent/subagent_fork，而是让 Pi 社区的 @tintinweb/pi-subagents 通过 pi2dsh 创建原生 DSH 子会话：

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

这条路线的继承顺序是：子代理显式模型 → 父会话持久日志最后一条真实 request/header 路由 → 创建时快照兜底。刚做的真机 E2E 和本帖复现同形状：父会话先走 deepseek-official，随后在 TUI 用 /model 切到独立 work-gw/deepseek-chat，再 spawn 一个不指定模型的子代理；持久日志断言父请求为 official → work-gw，子请求只出现 work-gw，且子代理真实执行工具写入 marker。

所以需要立即使用时，不必重启，也不需要给每个子代理写死 route；它会跟随父会话已经实际使用的当前 provider/model。完整可复现装置与证据：
https://github.com/weijiafu14/pi2dsh/tree/main/examples/subagents
https://github.com/weijiafu14/pi2dsh/blob/main/community/subagents-acceptance-report.md