模型侧内层引号漏转义使 tool_use 参数合法但缺 description:单会话 34 次整轮重试——建议窄范围 schema 引导的参数修复

[KannaKuron]

环境

• dsh 0.1.6-alpha.2(PTC 模式,run_code + 内层 SDK 调用),桌面与 web 两个 profile
• 模型:智谱 GLM-5.3,经 zai-coding-cn provider(anthropic-messages API)接入 —— 是第三方模型,不是 DeepSeek 官方模型;先说明这一点,后文的根因也确实在模型侧,不在 dsh 的装配。

现象

模型发出的 run_code 调用,其 code 载荷内部又包含一个 SDK 调用(tools.bash({...})),内层自带 description: "…" 字符串。当这行靠近载荷末尾时,模型经常把内层的闭引号写成裸引号(漏转义)。在参数 JSON 里,这个裸 " 会把 code 字符串提前终止,随后对象闭合,外层 description 成员根本没被生成。dsh 收到的是合法 JSON:code 在程序中途截断、description 缺失:

{"code":"const r1 = await tools.bash({\n  command: `ssh … | head -30`,\n  description: \"查wk日志54秒期间详情"}

校验结果:Error: invalid arguments: missing required property "description",模型整轮重发。程序本体的剩余部分(});\nconsole.log(…) 等)从未到达 dsh。

取证与根因(来自单个会话的持久日志)

• 同一会话内该失败发生 34 次;每次之后模型重试都能成功。
• assistant/message 的 stream 记录保存了 provider 的原始参数增量分片(本次 110 片):逐片拼接与装配后的参数逐字节一致 —— dsh 的装配无损,参数到达时就是此形状。
• finish reason 为 tool-calls(正常结束,远未到任何 token 上限),不走 assembler 的 max-tokens 丢弃路径。
• 形态分布:29/34 精确命中"内层 description 闭引号漏转义"签名(code 最后一个非空行是未闭合的 description: "xxx);5/34 是程序完整、仅外层 description 成员缺失。
• 除往返浪费外还有更隐蔽的代价:模型从失败-重试中形成了迷信——本例中它开始给每个调用尾部追加 console.log(r1.stdout),以为这才是成功的原因(真正的变量是引号位置),这种错误归因会贯穿整个会话并污染其工具使用策略。

为什么仍然值得 dsh 处理

• 根因在模型侧不假,但第三方 provider 是 dsh 官方支持的能力(llm-pi-ai 的 providers 配置就是为此存在的);任何模型——包括官方模型——都可能产生嵌套引号转义错误,这类防御层只有放在 harness 才能一次覆盖所有 provider。
• 这个失败形态是可确定性复原的:断点文本恰好就是模型想写的 description,可执行载荷(命令本身)完整到达。
• 与仓库已有的提案笔记 .agents/notes/proposed/feature/2026-06-30-pre-tool-input-rewrite.md 方向一致:这是它的一个收窄实例 —— schema 引导、规则确定、无任意重写钩子,且发生在执行身份创建之前,可原子地反映到 assistant 历史、tool/call 审计与 UI 展示三个读者。

提案

在持久读者落盘之前,仅对以下两种签名做修复(提供配置开关,默认行为可保持现状):

1. JSON 损坏,且唯一未闭合的字符串是顶层 description 值 → 闭合引号与缺失的括号;断在 code/command 等被执行字段、key、字面量的一律不修,维持严格失败。
2. JSON 合法但缺 description,且载荷字符串结束于内层未闭合的 description: "… 行(恰好包含一个 await tools.<name>({ 调用)→ 闭内层字符串与调用、把断点文本复用为 description、补上模型自己的结果打印惯用行,使执行仍产出输出。

修复对模型静默(历史记录修复后的值;原始流增量保留在日志中可供审计)。其余一切形状保持今天的严格报错。

本地实现

我已基于 0.1.6-alpha.2 本地实现并验证(两包 852 项测试全过,含新增签名用例;实测上述 34 连发场景全部直接跑通、零重试)。如果维护者认可方向,我可以整理成 PR。

开放问题

• 配置字段 vs 环境变量开关;修复是否需要 log-only 标记事件,还是完全静默;
• "程序完整、仅缺成员"的 5/34 形态是否保持自然报错(本地实现选择了保持)。

---

附:模型侧的转义缺陷会另行反馈给智谱(GLM),但正如上文所论,harness 层的防御不依赖、也不等待模型侧修复。