[Bug Report] llm-deepseek SSE 装配用 !== void 0 判空：空字符串 delta 覆盖首块 tool_calls id/name，工具调用整体崩溃为 unknown tool ""

[DRAG0NM]

摘要

dsh-llm-deepseek 的 SSE 流装配器在合并 tool_calls[] delta 时，用 call.id !== void 0 / call.function?.name !== void 0 作为写入守卫（lib/index.js L321-322）。对"后续块用空字符串 "" 占位 id/name"的 OpenAI 兼容网关（OpenAI 规范本应只在首块携带 id/name、后续省略），空串通过守卫并覆盖首块已写入的值——最终工具调用块变成 id=""、name=""，agent 循环发出空名工具调用，本地注册表返回 unknown tool ""，整轮工具调用不可用。这是 #879 的现象，源码断点即上述两行。

复现步骤

1. 配置一个 SSE 流中 tool_calls delta 以空串占位 id/name 的 OpenAI 兼容网关（[bug]llm-deepseek: SSE tool_calls id/name overwritten by empty-string deltas #879 的示例网关）。
2. 让模型发起工具调用，网关分块返回：

   chunk 1: tool_calls[0] = {id:"call_xxx", function:{name:"ls",  arguments:""}}
   chunk 2: tool_calls[0] = {id:"",         function:{name:"",    arguments:"{"}}
   chunk 3: tool_calls[0] = {id:"",         function:{name:"",    arguments:"\"path\":\"/tmp\"}"}}
   

3. 结果：装配出的工具调用为 id=""、name=""；agent 以空名调用工具 → ToolNotFoundError: unknown tool ""。

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

@deepseek-ai/dsh-llm-deepseek/lib/index.js translate 的 delta 合并循环（L310-332）：

if (call.id !== void 0) block.callId = call.id;                 // L321："" 也覆盖
if (call.function?.name !== void 0) block.name = call.function.name;  // L322："" 也覆盖
const fragment = call.function?.arguments ?? "";
block.text += fragment;                                        // arguments 用 += 拼接（正确）

• L321/L322 的守卫只排除 undefined，不排除空字符串；OpenAI 规范约定 id/name
  仅在首块出现，因此符合规范的网关后续块省略这两个字段（undefined）——但存在
  以空串占位的兼容网关，空串通过守卫后覆盖首块已写入的 call_xxx/ls。
• 对照：arguments 的合并用 ?? "" + +=（L323-324），空串不影响累加——唯独
  id/name 的"最后写入者胜"语义对空串是错误行为。

建议修复

方案 A（推荐）· 空串视为缺失：L321/L322 增加空串排除：

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;

一行一处，向后兼容（规范网关不受影响），空串占位网关立即恢复。

方案 B · keep-first 语义：id/name 只在块尚未赋值时写入（block.callId === void 0 才写）。
更贴合"首块携带、后续省略"的规范意图；但对"后续块才第一次出现 id/name"的异常网关
（虽然不该存在）会丢值，需要与 A 权衡。

方案 C（诊断增强）· 装配后校验：块结束时若 callId/name 为空，抛出带网关
上下文（如块索引）的明确错误而非静默产出空名工具调用——至少让用户知道是网关
不符合规范，而不是"unknown tool"这种误导性错误。

影响

• 所有以空串占位 delta 的 OpenAI 兼容网关（此类网关在自建/转发场景真实存在，
  [bug]llm-deepseek: SSE tool_calls id/name overwritten by empty-string deltas #879 的示例即其一）工具调用整体不可用，且最终错误 unknown tool "" 完全
  误导定位方向
• 与 Bug: tool calls are dropped against servers that send null in continuation deltas (id/name overwritten, every call becomes UNKNOWN_TOOL) #161（null delta 覆写 id/name → UNKNOWN_TOOL）同族：同一装配点对"非规范
  缺失值"的防御不足（Bug: tool calls are dropped against servers that send null in continuation deltas (id/name overwritten, every call becomes UNKNOWN_TOOL) #161 已报 null，本报告补上空串分支）

环境

• 源码定位：0.1.0-rc.6（npx 缓存安装包 dsh-llm-deepseek/lib/index.js L310-332，
  Node v24.16.0，Windows 11）
• 原报告：[bug]llm-deepseek: SSE tool_calls id/name overwritten by empty-string deltas #879（rc.6；0 评论；发帖人已做协议层分析，未定位源码）

验证材料

• 根因节行号与代码片段：L321/L322 的 !== void 0 守卫 + L323-324 的 += 对照
• 复现即 [bug]llm-deepseek: SSE tool_calls id/name overwritten by empty-string deltas #879 的三块 SSE 示例，装配结果可直接推演（"" 通过守卫覆盖首块值）
• 修复方向对照：按方案 A 修改后同一示例产出 id="call_xxx"、name="ls"

---

First source-located analysis of discussion #879. Happy to open a PR with fix option A.

[Gelly52]

Confirmed with DeepSeek-V4-Pro; the same tool schema and prompt work with DeepSeek-V4-Flash. I implemented option A as a minimal two-file change and added a regression test for a valid opening identity followed by empty-string continuation placeholders:

Gelly52/deepseek-harness@master...develop/fix-empty-stream-tool-identity

The translator now updates id and name only for non-empty strings, preserving the opening delta values. Verification: 31 focused tests passed, with 100% exact-source coverage for translate.ts. The branch contains only the implementation and regression test.

[DRAG0NM]

感谢 @Gelly52 的跨模型复核（DeepSeek-V4-Pro 复现、V4-Flash 通过）并实现方案 A + 回归测试。这个对照尤其有价值——它把"判空写法差异"从单模型偶发锁定为跨模型的确定性缺陷，也印证了根因定位。感谢落地最小改动。