Agent falls into infinite bash loop while intending to call a dynamic tool (reasoning/action decoupling)

[Vexo44]

Environment

• DSH version: 0.1.0-rc.7 (@deepseek-ai/dsh, apps/cli)
• Model: deepseek-v4-flash (provider: deepseek-official)
• Session ran under a cordis dynamic plugin that registered 8 host tools (team_create, team_spawn, team_assign, team_msg, team_task, team_status, team_interrupt, team_collect)

Summary

The agent's reasoning layer says it will call tool X, but the action layer repeatedly emits tool Y (bash). Because bash always succeeds (isError: false), the loop never receives a failure signal and spins until the user manually interrupts it.

Reproduction

1. Register dynamic host tools via cordis_define (tools confirmed present in the model request: request/header tools list contained all 8 team_* tools, schemas valid).
2. Ask the agent to smoke-test team_create.
3. Observed: 1139 bash calls in one session, 966 of them no-op echo markers (echo "calling team_create", echo "direct", echo "invoke", ...).

Evidence (from session log)

• The model's reasoning text explicitly says: "我需要直接调用 team_create 工具...让我直接调用。" ("I need to call team_create directly... let me call it directly.")
• But the emitted tool-call in the same turn is: name: "bash", arguments: {command: echo "=== 冒烟测试：调用 team_create ==="} — i.e. the model generated bash, not team_create.
• Every bash result returns isError: false with the echoed text, so the model reads "success" and in the next turn repeats: "now call team_create for real" -> emits bash again. Reasoning and action each loop independently and never converge.
• Context at loop time: cacheReadTokens=237568, fresh inputTokens=78 per turn — 42 tools in the list, model repeatedly picked the early bash tool over team_create (position ~34).
• The existing duplicate-call guard only fires on byte-identical calls ("You are repeating the exact same tool call" fired twice); the loop alternated echo strings (direct/invoke/calling/skip/true) and later repeated echo "direct" 6 times without interception.

Root causes (hypotheses)

1. No intent-action consistency check: reasoning declares tool X, action emits tool Y, no harness-level guard interrupts the mismatch.
2. Tool-selection degradation under long context + many tools: 237K-token cached context, 42 tools, flash-class model repeatedly selects the early-listed bash instead of the intended dynamic tool.
3. Duplicate-call guard granularity too coarse: content-level repetition (same tool, same command text) is not caught, only byte-identical calls.

Suggested fixes

1. Add an intent-action consistency check: if reasoning declares tool X but N consecutive emitted calls are tool Y, inject a correction.
2. Upgrade the duplicate-call guard to content-level (same tool + same command text => warn/stop), not just identical parameters.
3. Add a per-turn tool-call budget / circuit breaker to bound runaway loops.
4. Consider mitigations for long-context tool-selection degradation (tool list reordering/trimming, or model switch for long sessions).

Happy to provide the full session log path or more extracted evidence on request.

[Vexo44]

Raw evidence (from the session log, sensitive IDs redacted)

1. Reasoning vs emitted tool-call — same turn, model output as captured

Streamed blocks at turn 3 / step 20 (the agent intends to call team_create; the emitted tool-call is bash):

{ "type": "reasoning",
  "text": "我需要直接调用 team_create 工具。这些工具是模型可见的，我在当前会话中可以调用它们。让我直接调用。" }
// translation: "I need to call the team_create tool. These tools are model-visible; I can call them in this session. Let me call it directly."

{ "type": "tool-call",
  "id": "call_00_hoea...7878",          // redacted
  "name": "bash",
  "arguments": "{ "command": "echo \"=== 冒烟测试：调用 team_create ===\"", "description": "Smoke test marker" }" }

{ "type": "usage",
  "usage": { "inputTokens": 78, "outputTokens": 100, "cacheReadTokens": 237568, "reasoningTokens": 26 } }

The reasoning block says "call team_create"; the emitted call in the same response is bash with an echo marker. No team_create call was ever emitted.

2. Consecutive bash calls during the loop (every one succeeded)

seq176024: echo "calling team_create now"
seq176087: echo "direct"
seq176151: echo "invoke"
seq176217: echo "calling team_create"
seq176281: echo "tool call"
seq176344: echo "direct"
seq176408: echo "invoking"
seq176474: echo "calling team_create"
seq176541: echo "tool call: team_create"
seq176605: echo "direct invocation"
seq176671: echo "invoke team_create"
seq176735: echo "calling"
seq176798: echo "direct"

All returned isError: false with the echoed text as stdout. The guard that fires on byte-identical calls did NOT trigger here because the echo text keeps varying.

3. Duplicate-call guard fired only twice, and was ignored

The guard message (injected as a user message) appeared at seq 177261 and seq 180266:

"You are repeating the exact same tool call with identical arguments. Carefully analyze the previous result before calling again: if the task is not complete, try a different approach or different arguments instead of repeating the call."

The agent continued looping afterwards regardless. Later in the loop, echo "direct" repeated 6 times consecutively (seq 179951-180760) without any guard firing, because each call had a fresh callId.

Session totals: 1139 bash calls, 966 of them no-op echo markers. Total tool calls in the session: 1226; team_create was never actually called.

[weijiafu14]

这份取证很难得——推理层说要调 X、动作层却持续发 Y，而且因为 bash 永远 isError: false，循环拿不到任何失败信号。1139 次 bash、966 次空转 echo，这个数字本身就说明问题不在"模型笨"，在于它没有任何机制会告诉它走错了。

补一条你可能用得上的机制事实。

模型看到的工具表是可以被改写的

DSH 的 system-prompt/assemble 是一条 async waterfall，其中的 assembly.tools 不是只读、也不是只能追加——已注册的条目可以被改写。我在真实 DSH 组合上（SessionStore + SystemPrompt + ToolRuntime）验过：改一个已注册工具的 description、从 parameters.properties 里删掉一个字段，两处改动都出现在 assemble 的返回结果里。

对你这个场景，直接的用法是：在跑这类冒烟测试时，把 bash 从模型可见的工具表里摘掉（或者临时只保留 team_*）。动作层没有 bash 可发，它就只能发 team_create——或者干脆发不出来，那也是个明确信号，比 966 次"成功"的 echo 有用得多。

边界写清楚：

• 需要有人写一个插件，现在没有现成的包。 我给的是"这条路通"的机制证明。
• 只能改 schema（模型看到什么），不能改 arguments（模型已发出的调用）——tools/pre-execute 对原生工具的参数改写是硬拒的（核心在策略之前就把 arguments 记进日志，有意为之）。所以"拦下 bash 调用把它改成 team_create"这条走不通。

另一半：空转 echo 应该被识别为"没进展"

即使不摘 bash，一个确定性的断路器（比对最近 N 次同名同参调用，命中就直接返回否决结果、并把"已被断路"如实写回工具结果让模型改道）能把 966 次砍到 3 次。这同样需要写，而且我没见到现成的包。

我不建议用"第二个模型来审批每次工具调用"那类方案顶这个——那是用一个概率性判断去治另一个概率性失败，而这里你需要的是确定性的计数。

边界

我们不修 DSH 的 agent loop，也改不了模型的推理/动作解耦。上面两条都是"在模型看见之前动手"的思路，而且都还没有人做成包。

你这份报告最有价值的部分我觉得是那句"bash 永远成功所以循环收不到失败信号"——这可能值得单独提给官方：一个总是成功的工具，在 agent loop 里是没有刹车的。

利益相关：我维护 pi2dsh。上面那个 assembly.tools 结论是我做别的事时实测出来的，对任何插件作者都成立，不需要装我的东西；我也没有现成的包能给你。