[BUG]工具调用名校验缺失：空名 tool_call 会被落盘并在回放时把整个会话锁死（附：strict 采样开关永不生效）

[qinu321]

工具调用名校验缺失：空名 tool_call 会被落盘并在回放时把整个会话锁死（附：strict 采样开关永不生效）

提交对象：deepseek-ai/deepseek-harness
复现版本：dsh 0.2.1-alpha.1（npx @deepseek-ai/dsh@0.2.1-alpha.1 web，Windows 11）
对照版本：dsh 0.2.0-rc.2
说明：本文只谈 DSH 侧的纵深防御缺口。触发这一切的根因在第三方 OpenAI 兼容端点侧（见「背景」），但 DSH 侧只要补一道名字校验，同类端点故障就不会再是「会话报废」级别。

---

背景（一句）

某第三方 OpenAI 兼容端点会把模型写在正文里的原生文本方言（尖括号 tool_call + function= 前缀）当成真调用执行，并返回一条 tool_calls[]，其中 name 取了正文里的占位符或空串、arguments 为 {}。DSH 侧对此没有任何校验。

---

问题 1（主项）：空名工具调用无任何校验 → 脏消息落盘 → 会话永久报废

现场（不是理论风险，真实发生过）

1. 模型先返回一次 unknown tool；
2. 随后它把这次调用写成原生文本方言，放在正文里；
3. 上游端点把这段正文当成调用执行，返回一条 name 为空串的 tool_calls[]；
4. DSH 侧照常落盘（append-only，不可删）；
5. 下一轮请求按原样序列化发出 → 端点返回
   400 Param Incorrect: messages[N].tool_calls[0] is missing a function name；
6. 脏消息删不掉 ⇒ 该会话此后每次请求必然失败，用户只能弃会话。

同一次事故中，25 次工具调用里有 7 次是这种伪造调用（6 次占位名 + 1 次空名）。

代码坐标（0.2.1-alpha.1 实读）

位置	现状
@earendil-works/pi-ai/dist/api/openai-completions.js:298	const name = toolCall.function?.name ?? toolCall.custom?.name ?? ""; —— 空名兜底成空串，既不丢弃也不报错
@deepseek-ai/dsh-llm-pi-ai/lib/index.js	回放时才做 ?? "unknown" 兜底；序列化不校验、不过滤
@deepseek-ai/dsh-tools/lib/index.js:2545	UNKNOWN_TOOL 只在「名字查不到」时抛出 —— 属事后路径；名字为空串的块在落盘/序列化前没有任何闸门
@earendil-works/pi-ai/dist/api/openai-completions.js:1057	相关背景：if (!hasContent && !assistantMsg.tool_calls) { —— 只有 reasoning、无 content 无 tool_calls 的 assistant 消息被整条丢弃（模型看不到自己上一轮想过什么）

期望

在工具调用进入管线时（落盘前 / 序列化前）补一条不变量：

function.name 为空、或不在本次请求声明的 tools 列表内 ⇒ 丢弃该块（或拒绝落盘并给出可自愈的错误）。

短拦截即可（序列化时过滤空名块）；若愿意做长拦截（dispatch 前拒绝未声明名），连 unknown tool 那一类也能提前变成明确错误。关键是别让一条脏消息把整会话锁死。

附：2026-09-26 社区讨论里已有同向方案（「序列化时过滤空名块」），当时未落地。

版本回归检查（0.2.0-rc.2 → 0.2.1-alpha.1）

项	结果
pi-ai	版本未动（仍 v0.87.1），dist/api/openai-completions.js 逐字节相同（SHA256 A2397CB3…，64,355 B）⇒ 空名兜底行仍在
dsh-tools/lib/index.js	16 处改动全部是 PTC run_code 的描述文案 / 参数顺序；无任何工具名校验
dsh-session/lib/index.js	仅 4 处改动，内容是一句注释改写（scoped-dispatch invariant 的措辞），无功能变化
⚠️ 负向变化	dsh-tools/lib/invariant.js 与 dsh-session/lib/invariant.js 在 0.2.1-alpha.1 中已不存在（全树 grep invariants.register 零命中）。其中 dsh-tools 那份原本含一条 exec.name.length === 0 ⇒ fail("tools/result execution must carry non-empty name and callId") 的空名断言 —— 也就是说旧版至少还有一条 dev-only 的空名断言，新版连它都没了。若是随 invariant 服务一并有意外移，请确认这是有意的；如果不是，建议恢复这条断言。

---

问题 2：strict 采样开关存在，但永不生效

• dsh-llm-pi-ai/lib/index.js 在两版之间逐字节相同（SHA256 D46DBC30…）；
• resolveJsonSchemaStrictSampling 首行即 if (!config || config.type !== "json_schema") return undefined; ⇒ 只对自行声明 constrainedSampling: {type:"json_schema"} 的工具生效；
• 而 DSH 的工具映射只发 {name, description, parameters}（dsh-llm-pi-ai/lib/index.js 约 :1232-1234），没有任何工具声明 constrainedSampling ⇒ 所有工具都以 strict: false 发出；
• 结果：即使 provider 目录里声明了 compat.supportsStrictMode: true（例如小米 mimo 的目录条目），这条能力永远走不到。

期望：provider 支持时，允许 / 默认对 DSH 工具启用严格 schema 约束（至少提供打开方式），让端点能对参数生成施加约束。（它治不了上面的名字错位——那种错位发生在端点的文本解析层——但属于同一类的"把可用的约束真正用起来"。）

---

影响面

• 问题 1 已实际造成 1 次不可恢复的会话报废，且触发不需要任何 DSH 侧的错误用法；
• 用户侧无从自救：脏消息 append-only，除弃会话或手改会话文件外没有出口；
• 问题 2 属于能力闲置（供应商支持、客户端不开），成本是整个 strict 通道的收益。

复现 / 验证建议

1. 问题 1：构造一条 tool_calls[0].function.name === "" 的 assistant 消息 → 断言序列化阶段被丢弃或拒绝（现行为是原样发出）。集成层面：用一次带空名块的回放请求观察端点 400 是否仍必然发生。
2. 问题 2：用声明 supportsStrictMode 的 provider 打桩 → 断言发出的 tools[] 中 strict 为 true（或至少不恒为 false）。

我们这边的责任

我们承认客户端可以更早拦截（也已在自建规则层面做了概率性止损）。提这条 issue 的定位是纵深防御：根因在上游端点，但只要 DSH 侧加一道名字校验，同类端点故障的后果就从「会话报废」降到「少一次工具调用」。

---

English summary (for triage)

• Missing tool-call name validation. @earendil-works/pi-ai/dist/api/openai-completions.js:298 coerces a missing tool name to "" (function?.name ?? custom?.name ?? ""). DSH then persists that block (append-only) and replays it verbatim; the upstream provider rejects every subsequent request with 400 ... messages[N].tool_calls[0] is missing a function name, making the session permanently unusable. Suggested fix: drop/reject blocks whose function.name is empty or not in the declared tool list, before persistence/serialization.
• strict sampling never engages. resolveJsonSchemaStrictSampling only applies to tools declaring constrainedSampling:{type:"json_schema"}, which no DSH tool does, so strict:false is always sent — even for providers declaring compat.supportsStrictMode: true.
• Regression note. dsh-tools/lib/invariant.js and dsh-session/lib/invariant.js are gone in 0.2.1-alpha.1; the former contained a dev-only exec.name.length === 0 ⇒ fail(...) assertion, so the only pre-existing empty-name guard disappeared with them. Please confirm that is intentional.