[Bug Report] 子代理会话流式工具调用丢失 name/callId（unknown tool ""）：无子代理特化传输路径，丢失点即共享 SSE 装配器的空串覆盖守卫

[DRAG0NM]

摘要

#887 报告子代理（subagent spawn）会话中工具调用确定性失败：tool/call 事件里 name 与 callId 为空串，执行报 unknown tool ""，而同一环境下主循环工具调用完全正常。源码核查结论：子代理没有任何独立的流式传输或工具调用装配路径——spawn 提供器（dsh-subagent-spawn-in-process）与主循环共用 startInProcessRun → 同一 agent factory → 同一 dsh-llm-deepseek SSE 装配器；tool/call 事件的 name/callId 直接取自装配器的 block（dsh-agent-loop L120-128、L293-304，无子代理分支）。因此丢失只能发生在共享装配点——即 dsh-llm-deepseek/lib/index.js L321-322 的 !== void 0 守卫允许空字符串 delta 覆盖首块 id/name 的缺陷（#885 已定位）。子代理独有的触发面：子代理请求携带的工具集更大（常规工具 + structured_output 捕获工具），兼容网关在多工具 delta 流中更容易以空串占位续块，覆盖行为在子代理流中确定性触发；主循环单工具流恰好不触发。

复现步骤

1. 配置 子代理会话的流式工具调用丢失 name 与 callId，执行报 unknown tool "" #887 报告者所述环境（rc.6，subagent spawn，写文件类工具）。
2. 让子代理执行一次工具调用（如写文件）。
3. 观察子代理会话的 tool/call 事件：name=""、callId=""；执行结果 unknown tool ""（子代理会话的流式工具调用丢失 name 与 callId，执行报 unknown tool "" #887：三次复现确定性失败）。
4. 对照：主循环同类工具调用正常（子代理会话的流式工具调用丢失 name 与 callId，执行报 unknown tool "" #887 同环境自证）。

根因（源码定位，rc.6）

1. 无子代理特化路径：dsh-subagent-spawn-in-process/lib/index.js L33-35 start() → startInProcessRun(request, {})（与 fork 提供器同一驱动）；驱动内部 parent.ctx.agents.create(...) 创建子 agent，LLM 适配器与主循环相同——不存在子代理专属的流式/装配代码。
2. 事件直通：dsh-agent-loop/lib/index.js L120-128 exec = { callId: block.id, name: block.name }、L293-304 session.append("tool/call", { ..., callId: block.id, name: block.name })——事件里的空值必然来自装配器产出的 block，而非事件层丢失。
3. 唯一可疑点 = 共享装配守卫：dsh-llm-deepseek/lib/index.js L321-322：

   if (call.id !== void 0) block.callId = call.id;
   if (call.function?.name !== void 0) block.name = call.function.name;

   !== void 0 不排除空串：续块若带 id:""/name:""（[Bug Report] llm-deepseek SSE 装配用 `!== void 0` 判空：空字符串 delta 覆盖首块 tool_calls id/name，工具调用整体崩溃为 `unknown tool ""` #885 已证实的兼容网关行为），会覆盖首块值。
4. 子代理为何确定性触发：子代理请求的工具列表更大（含 structured_output，见
   dsh-subagent-in-process-driver L49-53 的注册），多工具 delta 流的网关分块模式不同
   （续块对工具 0 发空串占位），覆盖必然发生；主循环单工具流首块即带 id/name 且无
   续块覆盖，恰好不触发。这也解释了 子代理会话的流式工具调用丢失 name 与 callId，执行报 unknown tool "" #887"主循环正常、子代理必失败"的对照。

建议修复

方案 A（推荐）· 修共享装配守卫（同 #885 方案 A）：空串视为缺失：

if (call.id !== void 0 && call.id !== "") block.callId = call.id;
if (call.function?.name !== void 0 && call.function.name !== "") block.name = call.function.name;

一处修复同时覆盖主循环与子代理两条触发面（#885/#887 同源）。

方案 B · 装配后校验 + 明确报错：块结束时若 callId/name 为空，抛出带网关与
块索引的明确错误（而不是静默产出空名工具调用），便于定位网关问题。

方案 C（子代理侧兜底）· 事件层防御：tool/call 发射前若 name/callId 为空，
记录 warn 并跳过该调用（避免把空名请求打进工具注册表）——防御性，不替代 A。

影响

• 子代理 spawn 工作流在受影响网关上全部工具调用不可用（子代理会话的流式工具调用丢失 name 与 callId，执行报 unknown tool "" #887 确定性失败），
  表现为误导性的 unknown tool ""
• 与 [Bug Report] llm-deepseek SSE 装配用 `!== void 0` 判空：空字符串 delta 覆盖首块 tool_calls id/name，工具调用整体崩溃为 `unknown tool ""` #885 同源：同一守卫的第二个触发面（主循环流 vs 子代理多工具流）
• Bug: tool calls are dropped against servers that send null in continuation deltas (id/name overwritten, every call becomes UNKNOWN_TOOL) #161（null delta 覆写）同族第三分支：null / 空串在共享装配点均未被防御

环境

• 源码定位：0.1.0-rc.6（dsh-subagent-spawn-in-process、dsh-subagent-in-process-driver、
  dsh-agent-loop L293-304、dsh-llm-deepseek L321-322；Node v24.16.0，Windows 11）
• 原报告：子代理会话的流式工具调用丢失 name 与 callId，执行报 unknown tool "" #887（0 评论，此前无人分析）

验证材料

• 根因节 4 个源码定位点：子代理无特化路径（spawn→startInProcessRun）、事件直通
  （agent-loop L120-128/L293-304）、装配守卫（llm-deepseek L321-322）、子代理
  多工具流差异（driver L49-53）
• 与已发布 [Bug Report] llm-deepseek SSE 装配用 `!== void 0` 判空：空字符串 delta 覆盖首块 tool_calls id/name，工具调用整体崩溃为 `unknown tool ""` #885（[Bug Report] llm-deepseek SSE 装配用 `!== void 0` 判空：空字符串 delta 覆盖首块 tool_calls id/name，工具调用整体崩溃为 `unknown tool ""` #885 ）
  同源呼应；修复方案 A 一处覆盖两报告
• 子代理会话的流式工具调用丢失 name 与 callId，执行报 unknown tool "" #887 的确定性对照（主循环正常/子代理必失败）与多工具流分块解释自洽

---

First source-located analysis of discussion #887 (sibling of #885). Happy to open a PR with fix option A covering both.