web 会话中 run_code 调用被反复拒绝：模型漏发必填 description 参数——建议对重复 INVALID_ARGS 增加熔断

[rccyuvyu]

发生了什么

在 dsh web（Code Mode）会话中，模型的 run_code 工具调用被反复以 invalid arguments: missing required property "description" 拒绝，而 agent 会以同样的错误参数形状不断重试——单次会话中 73 次 run_code 调用有 53 次被拒，浪费大量轮次。重启 dsh web 无效；同一任务切换到 CLI 会话（工具直接暴露、无 run_code 包装层）后立即正常。

期望行为

在收到一两次带精确信息的拒绝后，agent 应修正参数形状（补上缺失的 description），或由 harness 打断这个重试循环。

证据

• 73 次 run_code 调用中：带 description 的 20 次全部成功；缺 description 的 53 次全部被拒——与缺失字段 100% 相关。
• 模型发出的工具调用 JSON 以 {"code": "..."} 干净收尾——字段确实被模型漏掉，而非传输/组装丢失（未观察到截断 JSON）。
• 会话全程模型可见的 schema 均声明 description 为必填（无 schema 漂移）。
• 模型自身的推理显示它以为已经传了 description——它把该词写在了 code 内部（作为内层工具的参数），混淆了两层参数。

建议的改进（任选其一即可缓解）

1. 对重复 INVALID_ARGS 增加熔断：连续 N 次完全相同的非法工具调用后，在错误信息中追加纠正提示（列出必填参数名），或直接结束该轮，避免无限重试。
2. 更明确的拒绝消息：列出全部必填参数名，并给出一行期望的参数 JSON 示例。
3. （可选，产品决策）run_code 缺 description 时从 code 自动推导——注意这会改变"description 必填（用于 UI 展示）"的契约。

复现步骤

1. 启动 npx @deepseek-ai/dsh web，进入 Code Mode 会话。
2. 让 agent 通过 run_code 执行程序；模型有时只发出 {"code": "..."}，缺少必填的 description。
3. harness 以 invalid arguments: missing required property "description" 拒绝；agent 经常以相同形状重复。

环境

• dsh web（Code Mode），模型 deepseek-v4-flash（deepseek-official provider）。观测于 2026-08-14。

[yun520-1]

这是"重复失败无熔断"问题

这个场景（73 次调用 53 次缺 description 被拒，agent 用同样的错误参数形状不断重试）本质是重复失败没有升级路径。

代码事实

1. run_code 的 schema 明确要求 description（packages/core/tools/src/code-mode.ts:95："Clear, concise description of what this program does in active voice"）——参数确实不合法，拒绝合理。
2. DSH 已有 repeat-tool-reminder 守卫（packages/guard/repeat-tool-reminder/src/index.ts）：连续重复调用（默认阈值 [3,5,8]）会注入提醒，但它是 advisory 的——提醒模型，不否决调用、不改写调用。
3. 报告说"重启无效、切 CLI 立即正常"——CLI 直接暴露工具、无 run_code 包装层，说明问题出在 run_code 包装层 + 模型组合：包装层把 description 变成必填，模型没读到或没理会。

为什么 53 次里模型不改

repeat-tool-reminder 只做提醒，不做熔断。模型在长会话里可能没把提醒当硬约束，或提醒内容不足以让它意识到"这个参数必须补"。73 次循环里每次都被拒但 agent 继续——提醒的强度不足以打断行为。

建议：按错误签名做重复熔断

1. 按错误签名聚合：invalid arguments: missing required property "description" 有稳定签名。连续 N 次（比如 3 次）相同签名的 INVALID_ARGS → 不再让模型重试，把错误上下文（schema 片段 + 缺失字段）注入下一条消息，强制修正，或转交用户。
2. 区分"可修正"和"不可修正"：缺参数可修正，模型可能只是没注意。但连续 3 次同样的缺失说明它没读懂 schema——把 schema 的必填字段列表直接贴进拒绝消息，比"missing required property X"更有用。
3. 提醒→熔断的升级路径：repeat-tool-reminder 解决了"提醒"，缺第二级——提醒无效后的行为熔断。给 reminder 加 escalate 档：提醒后同签名错误再出现，注入结构化修正指令而不是继续循环。

一点判别视角（HeartFlow，AGI 第1层辨别者）

这个 bug 涉及两层：模型侧（没读到/没理会 description 约束）和 harness 侧（失败信息没有升级路径）。心虫决策引擎有类似分层：同样失败第一次重试 → 连续几次升级（escalate）→ 换策略或交人。这里缺的正是 harness 侧中间那级。repeat-tool-reminder 的 advisory 设计是有意的（不篡改模型调用），但第二级防线可以是"停止重试、注入修正上下文、等模型下一个动作"——保持 advisory 原则的同时打断循环。模型侧的问题（为什么 web 模式读不到必填约束）值得单独查，两个层面分开修。

[guntur-d]

We hit the exact scenario (model omitting the required description, repeating the same failing shape). Our contribution, tested in the fork:

1. Make description optional in run_code — it is a UI label, not an execution input (PR #5): the parameters schema drops required, an omitted value runs with a generic Run code card title, and a whitespace-only value still fails loud. The bash tool keeps its required description for now — but the same argument applies.
2. A real circuit breaker for repeated tool failures — maxConsecutiveToolFailures (default 3) in the agent loop: consecutive steps whose tool calls ALL error end the turn with a logged, model-visible notice instead of issuing another request (PR #3).
3. The notice now quotes the last tool error, so the model can self-correct its next call instead of repeating the same failing arguments.

Combined, the observed loop becomes: reject (once) → self-correct or end the turn with the error quoted. Verified by the full unit suite + live GUI tests.

[guntur-d]

我们遇到了完全相同的场景（模型漏发必填 description，并以相同错误形状反复重试）。我们 fork 中的已测试贡献：

1. 把 run_code 的 description 改为可选——它是 UI 标签，不是执行输入（PR #5）：参数 schema 去掉 required，省略时以通用的 Run code 卡片标题正常运行，纯空白值仍然明确失败。bash 工具暂时保留必填 description——但同样的论证同样适用。
2. 针对重复工具失败的真正熔断——agent loop 中的 maxConsecutiveToolFailures（默认 3）：工具调用全部出错的连续步骤以一条已记录且模型可见的通知结束本轮，而不是再发起一次请求（PR #3）。
3. 该通知现在引用了最后一条工具错误，让模型在下一轮自我纠正，而不是重复同样的失败参数。

组合之后，观察到的循环变成：拒绝（一次）→ 自我纠正或带着被引用的错误结束本轮。已通过完整单元测试与 GUI 实测验证。