Feedback(0.1.5-rc.2): INVALID_ARGS 报错缺上下文——模型分不清缺的是哪一层参数,PTC 场景陷入连环错误重试(附补丁)

[KannaKuron]

现象

dsh 0.1.5-rc.2、PTC 模式(run_code)、GLM-5.3(第三方 Anthropic Messages 兼容端点)。长会话中模型发生参数漂移:run_code 调用的顶层 JSON 只带 code,description 被写进了程序文本内部(成了内层 tools.bash({ ... }) 的参数)。

dsh 的校验正确拒绝了这些调用——schema 本身没有问题(模型可见 schema 与校验 schema 一致,code/description 均 required,pi-ai 严格解析也全过,排除了流截断)。问题在于错误消息本身:每次返回

Error: invalid arguments: missing required property "description"

之后,模型检查自己写的调用,发现内层工具明明有 description,于是得出"我有写"的结论,转而去修改毫不相干的措辞重试。该会话 11 步烧掉 8 步,最终报废,模型归纳出的"规律"(内外 description 措辞相同时触发)完全是错觉。

失败调用的线上原始样本(从会话记录解出,合法 JSON、非截断,顶层只有 code):

{"code":"const r = await tools.bash({\n  command: \"mkdir -p fly-brain-playground && ...\",\n  description: \"准备果蝇项目工作目录\"\n});\nconsole.log(r.stdout, r.stderr);"}

根因

ToolArgsError 的消息只列出缺失属性,不说明:

1. 是哪个工具拒绝了参数;
2. 实际收到了哪些顶层键。

单层工具场景下这不痛不痒;但 PTC 场景存在两层同名参数(run_code 顶层的 description 与程序内层工具的 description),模型无法定位缺失发生在哪一层,只能在错误反馈回路里盲试。

建议修复(已在本地验证)

给 ToolArgsError 消息追加可选诊断上下文——拒绝调用的工具名 + 实际收到的顶层键:

invalid arguments: missing required property "description"; tool "run_code"; received top-level argument keys: [code]

改动面 packages/core/tools/src/schema.ts:

• ToolArgsError 构造器加可选 context(tool / receivedKeys),不传则消息与现状完全一致(subagent 等其他调用点零影响);
• defineTool 的 execute 抛出时带上 { tool: options.name, receivedKeys }(顶层键排序后拼接);
• tests/tools.spec.ts 两处断言同步更新。

收到这种消息后,模型能立即看出"run_code 顶层只到了 code",一步修正,而不是循环。

环境

• dsh 0.1.5-rc.2(本地构建)
• provider:zai-coding-cn / glm-5.3(Anthropic Messages 协议,第三方端点)
• 该会话 8 次失败调用的原始 arguments 均为合法 JSON、仅缺顶层 description

[PerryLink]

核对成立(master c291e79, 相关文件自 rc.2 零改动): 报错文本逐字吻合 - schema.ts:466 生成 invalid arguments: missing required property ..., index.ts:1860-1868 加 Error: 信封(测试 tools.spec.ts:2587-2591 钉死 exact 文本); 消息不含工具名(构造器 461-470 仅收 violations)也不含实际收到的键. 你的根因分析成立: PTC 两层同名 description + 错误无定位信息. 两点补充: 1) 嵌套缺失时消息带 JSON 路径(config.host 风格, json-schema.ts:564), 仅顶层缺参才退化为裸字段名; 2) 空字符串 description 走独立错误 invalid description: expected a non-empty string(ptc.ts:328-330), 与 INVALID_ARGS 分支不同. 补丁方向(可选 context、默认不传保持兼容)与现有调用点兼容(structured.ts:87-89), code=INVALID_ARGS 的机器路由不受 message 追加影响(llm/llm/src/error.ts:13-22). master 未修复, 问题仍存在. 会话层现象(11 步烧 8 步、GLM-5.3 端点)按你的环境描述接受, 未独立复现【未核实】.