deepseek-v4-pro emits Anthropic-style <invoke> tool-call text into content, not normalized to tool_calls — leaks to the user

[fpyr7jkydh-bot]

Summary

When the agent runs on the deepseek-official route with a reasoning model (deepseek-v4-pro, thinking enabled), the model sometimes expresses a tool call as plain text in the message content using Anthropic Claude's tool-use syntax, instead of the native tool_calls field:

<invoke name="mcp__stock__wait"><parameter name="seconds">5</parameter></invoke>

dsh-agent-loop only dispatches native tool_calls blocks (see executeToolCalls), and nothing in the loop / tool-presentation / LLM adapter strips or normalizes this text, so it ends up visible to the user as raw markup in the assistant's reply.

Environment

• dsh 0.1.0-rc.6 (all @deepseek-ai/dsh-* packages at 0.1.0-rc.6)
• @deepseek-ai/dsh-llm-deepseek — provider route deepseek-official
• Model: deepseek-v4-pro (reasoning; thinking default enabled)
• @deepseek-ai/dsh-mcp-client — tools exposed as mcp__<serverName>__<rawName>

Steps to reproduce

1. Boot dsh with dsh-llm-deepseek (deepseek-official, deepseek-v4-pro, thinking enabled) and one or more MCP clients.
2. Run a task that requires several sequential tool calls.
3. Trigger a case where a tool call fails or times out (e.g. an MCP tool exceeding the 60s toolCallTimeoutMs), then ask the agent to retry/continue.

Observed: the model falls back to emitting the retry tool call as literal <invoke>…</invoke> text in its content, which is rendered to the user verbatim.

Expected vs actual

• Expected: either (a) normalize the <invoke> text into tool_calls and execute it, or (b) strip it from the user-facing output so it never leaks.
• Actual: the raw <invoke name="mcp__stock__wait">…</invoke> block appears in the assistant reply, and the tool is not executed.

Root cause (from reading the source)

• @deepseek-ai/dsh-agent-loop dispatches only native tool_calls blocks (executeToolCalls in lib/index.js); there is no text-level tool-call parser.
• A grep across dsh-agent-loop, dsh-agent-tool-presentation, dsh-llm and dsh-llm-deepseek finds no handling of the string <invoke.
• @deepseek-ai/dsh-mcp-client confirms the model-facing name mcp__<serverName>__<rawName> (publicToolName), which is exactly what appears inside name="…".

So this is a gap: reasoning-model text-form tool calls (Claude-style <invoke>) are neither normalized nor sanitized by the harness.

Context / prior art

This is a known behavior of DeepSeek reasoning models — under ReAct-style prompting they can emit Anthropic tool-use syntax in text. In our own in-house ReAct loop we already handle it by stripping <invoke>…</invoke> in a post-processing stage, which is why we recognized it. It would be great if the harness handled this natively.

Suggestion

Either:

1. Add a text tool-call normalizer in dsh-agent-loop that parses <invoke name="…">…</invoke> (and <tool_calls>/function-call variants) into tool_calls blocks before dispatch; or
2. At minimum, strip these blocks from any content surfaced to the user, so internal tool syntax never leaks.

Happy to provide logs or a minimal repro repo if a template exists.

[weijiafu14]

Measured the "what happens today" half of this, so the feature discussion can start from ground truth:

Fault injection into the real pi-ai accumulator (unmodified client/parser; only wire bytes synthetic): a completion whose content carries Anthropic-style <invoke name="…"><parameter …></invoke> text lands as a plain text block — no toolCall is detected at any layer, and the turn ends as a normal completion (transport-classify-results.json, case invokeTagInContent). So there is currently no rescue net anywhere in the chain: if the model misses the native tool_calls field, the syntax goes to the user as prose — exactly what you observed.

This is one member of a family we've been mapping (model output lands in the wrong channel): markdown-fenced arguments is another, which silently empties tool-call args — filed upstream with harness and fix proposal as earendil-works/pi#8858. Text-format tool-call detection (your case, and #3609's <tool_call> variant) is a bigger policy decision than a fence unwrap — it means parsing prose — so it deserves an explicit upstream design rather than an adapter hack; consider cross-linking with #3609 so the two syntaxes get one detector design.

The prompt-side mitigation (system-prompt nudge to always use native tool_calls) reduces frequency but is not a guarantee — the measurement above is what happens on every miss.

[PerryLink]

注：本条评论原文因编码问题曾显示为乱码，已重建为可读版（2026-09-07）。

这个「输出风格泄漏」问题（来自 dsh-translate 与 dsh-defend 的实践）：

1. 翻译层：<invoke> 泄漏说明 content 与 tool_calls 混在一条消息里，需要归一化；dsh-translate 在 JSON 修复层会把供应商的字段归一化，content 与工具调用分开重打包，避免二次泄漏；
2. 防御层：dsh-defend 的注入/越狱护栏能拦截「冒充工具调用」的内容；
3. 路由层：如果模型自带 agent-loop，content 输出（含 <invoke> 的模型输出）需要拆分/重写工具调用。

如果是大模型问题，欢迎贴出模型与具体输出样例，帮你判断「到底要不要重打包 tool_calls」。