子代理首请求缺 reasoning effort，始终思考模型直接 400（subagent run failed）

[realCliffwang]

一句话说明（不多于50字）：subagent 工具派生的子代理首次 LLM 请求不带 reasoning effort，「始终思考」模型被严格网关直接 400，表现为 Error: subagent run failed。

复现、预期与结果

• 复现步骤：

  1. agent-default-model 配置为始终思考模型（如 worldcode-ds / glm-5.3-flash，仅接受 low/high/max），settings.yaml 带 reasoningEffort: high；
  2. 会话内调用 subagent 工具（前台/后台、spawn/fork 均复现），prompt 任意；
  3. 工具返回 Error: subagent run failed；子会话日志 turn/end 显示 400。

• 实际结果：子会话 request/header 的 config 仅 {provider, model}，无 reasoningEffort；网关 400：

  OpenAI API error (400): 400 event: response.failed
  "code":"400001" / "1210"
  "message":"The request is invalid: 该模型始终思考，不支持关闭思考；请使用 low、high 或 max。"
  

• 预期结果：子代理请求携带与父会话一致或可配置的 reasoning effort，正常完成。

• 环境：DSH Desktop（web profile）；@deepseek-ai/dsh-subagent / dsh-agent-loop / dsh-tool-subagent 随发行版 node_modules 分发；provider 为 OpenAI-compatible responses API 严格网关。

• 其他信息：无报错堆栈可贴，工具结果只吐出笼统的 "subagent run failed"，真实原因在子会话 session.jsonl.zstd 的 turn/end 事件里（建议工具层透传子会话诊断）。

根因分析（源码定位）

1. AgentOptions（dsh-agent 的 types/runtime-types.d.ts）只有 provider / model / maxTokens，没有 reasoningEffort 字段——子代理路由继承在设计上就缺这个参数。
2. resolveChildAgentOptions（dsh-subagent/lib/index.js:501）仅继承父的 provider / model / maxTokens 三项。
3. buildRequest（dsh-agent-loop/lib/index.js:719-733）只从会话持久化 request/header 读 effort——全新子会话首请求没有 header → reasoningEffort = undefined → 请求体不带 reasoning.effort。
4. 父会话不受影响的原因：UI 模型选择经 installModelSelection 的 agent/request 瀑布在请求时注入 effort，该监听器只装在会话自身 scope；普通 subagent 路径没有这个桥。
5. 旁证：@nanmicoder/dsh-agent-teams 的成员子代理不受影响——该插件对成员自行 installModelSelection(childCtx, …) 注入 provider/model/reasoningEffort，绕过了上述断链。

建议修复

• AgentOptions 增加 reasoningEffort；
• resolveChildAgentOptions 继承/透传（显式值 > 父 options）；
• buildRequest 首请求在持久化 effort 缺席时回落 options.reasoningEffort（后续请求仍由持久化 header 延续）。

或最小改动方案：tool-subagent 的 Config.agentOptions schema 接受 reasoningEffort 并透传，让预设（agent preset）即可显式配置（如 reasoningEffort: low）。

[liyangbing]

I compared the two pinned source boundaries because the symptom matches the earlier rc.2 gap, but the tagged alpha.1 code changes the expected diagnosis.

• rc.2 AgentOptions and resolveChildAgentOptions() omit reasoningEffort.
• dsh-v0.1.2-alpha.1 (cd5ef814) adds the field and parentAgentOptionsForDelegation() reads the parent’s latest request header before child option merging.

So the most useful next evidence is: (1) dsh --version from the exact launch environment, (2) resolved versions/entry paths for dsh-agent, dsh-agent-loop, dsh-subagent, and dsh-tool-subagent, and (3) the parent and child first request/header events. If all active packages are alpha.1 and the parent header has effort while the child header omits it, that is a much stronger alpha.1 regression case. If the child header contains effort, the next boundary is adapter/wire translation instead.

I added the full evidence ladder and privacy-safe capture commands here: https://sandbaseai.github.io/deepseek-harness-handbook/spawn-subagent-reasoning-effort.html

Disclosure: I maintain this independent handbook with SandBase; it is not an official DeepSeek AI project.

[realCliffwang]

Evidence collected from the affected deployment — it confirms the rc.2 diagnosis and rules out the alpha.1 regression case:

• dsh --version: 0.1.0-rc.6 (DSH Desktop resources install)
• Resolved packages (all from resources/dsh-desktop/node_modules/@deepseek-ai/): dsh-agent 0.1.1-rc.2, dsh-agent-loop 0.1.1-rc.2, dsh-subagent 0.1.1-rc.2, dsh-tool-subagent 0.1.1-rc.2
• Parent first request/header: "config":{"provider":"worldcode-ds","model":"glm-5.3-flash","reasoningEffort":"high"} (effort present)
• Child first request/header: "config":{"provider":"worldcode-ds","model":"glm-5.3-flash"} (effort omitted) → gateway 400 "该模型始终思考，不支持关闭思考；请使用 low、high 或 max"

All active packages are rc.2, so this matches the pinned rc.2 gap rather than an alpha.1 regression. Resolution for this deployment is upgrading DSH Desktop past v0.1.2-alpha.1 (cd5ef814); I will re-test subagent dispatch after upgrading and report back if the child header still omits effort.