【建议】子代理没有继承当前对话模型配置，错误调用其它模型产生意外扣费

[Hyl209]

问题现象

我配置了两组 API Key：

1. DeepSeek 官方 Key
2. OpenCode‑Go 的 Key
   两个后端对应的模型都选择 deepseek‑v4‑flash。

在对话会话里，我手动选定使用 OpenCode‑Go 渠道的 deepseek‑v4‑flash，调用子代理进行代码审查。
实际运行子代理的时候，没有沿用当前会话选择的 OpenCode‑Go 配置，错误使用了 DeepSeek 官方的 Key，造成非预期扣费。

使用场景

同一个模型，对接多个不同服务商/中转渠道，希望子代理完全继承当前对话所使用的后端、密钥、模型参数，而不是回退到默认的官方配置。

期望行为

子代理启动时，完整继承父对话的：

• API Key / 后端渠道
• 当前选用模型
• 温度、上下文等参数

而不是回退使用全局默认或者第一个配置的密钥。

[denial123789]

这个现象可以确认是当前子代理继承路径的问题，不是同名模型导致的正常路由选择。\n\n当前实现中，in-process driver 创建子代理时会调用 resolveChildAgentOptions(parent, request.agentOptions)；该函数默认复制的是 parent.options.provider、parent.options.model 和 parent.options.maxTokens：\n\n- resolveChildAgentOptions\n- in-process driver 的调用位置\n\n问题在于 parent.options 是父代理创建时的配置快照。Web UI 后续切换当前会话的 provider/model 时，实际请求可以已经走 OpenCode-Go，但创建时的快照仍可能是 deepseek-official / deepseek-v4-flash。子代理继续读取这个旧快照，就会选中 DeepSeek 官方 route，并使用该 route 对应的 Key。即使两个渠道的模型名相同，provider 不同也足以产生你看到的扣费。\n\n这与 #1581 报告的是同一根因；该讨论也已有 current master 上的复现和测试补丁。正确修复方向应是：创建子代理时优先继承父会话最近一次有效 request/header 中的 provider/model，创建快照只作为父会话尚未发出请求时的 fallback；显式的 child override 再保持最高优先级。\n\n在官方修复进入发行版之前，建议先这样规避：\n\n1. 先选择目标 provider/model，再新建父会话；不要在已创建的会话里切换 route 后立即启动子代理。\n2. 首次调用子代理前，用普通请求确认父会话确实走目标 provider，并检查请求事件里的 provider，而不只看模型名。\n3. 对可能产生费用的备用 Key 设置独立预算/额度；如果当前任务不需要官方 route，临时禁用该凭据最稳妥。\n4. 升级后用两个同名模型、不同 provider 的最小用例重新验证，重点检查子代理 request/header.config.provider。\n\n关于“温度、上下文等参数”：当前这个继承函数明确处理的主要是 provider/model/maxTokens，并不能据此认为所有适配器参数都会完整继承。因此建议把“当前有效路由继承”和“其余生成参数继承”分别验证。\n\n便于转发和升级后回归，我们把根因、路由图和验证清单整理成了英文事故说明：When the child agent takes the wrong route。\n