[Bug] DeepSeek + Structured Output: parser extracts JSON from the reasoning block ( ), so placeholder values (“string” / “…” / the whole S

快速结论：这个报错通常出现在 Dify 工作流里给 DeepSeek（`deepseek-flash`，Thinking Mode 开启）的 LLM 节点开启 Structured Output 之后：解析器从模型的 reasoning 块里抽出了占位 JSON，而不是最终答案，节点却仍然报告 succeeded。优先排查 Structured Output 的解析来源，以及是否能先关闭 Thinking Mode 规避。

适用环境：Dify Cloud，backend X-Version 1.17.1（2026-10-14）；模型 `deepseek-flash`，provider plugin `langgenius/deepseek@0.0.24`，Thinking Mode 默认开启；节点为 LLM 节点 + Structured Output。Issue 未确认自托管版本、Python、CUDA 或显卡环境。

最快修复方案：暂无确认的一步修复方案。Issue 评论中给出的即时缓解手段是：在 `创建内容` 节点的模型参数中关闭 Thinking Mode，而不是去改 reasoning 标签分离设置。

注意事项：关闭 Thinking Mode 只是绕过 reasoning 污染这条路径，并不保证 schema 或内容一定正确。上游已有 open、未合并的修复提案 PR #44005，且明确不包含 schema 校验；因此 `”string”`、`”…”` 这类占位字符串在教程 schema 下本身就是合法字符串，单靠 schema 校验也无法全部拦住，仍可能需要应用层检查。

问题场景

用户在 Dify Cloud 按官方「30-min quickstart — multi-platform content generator」教程搭建工作流：用户输入 → 参数提取器 → 条件分支 → 迭代，迭代内部为「识别风格 → 创建内容」（LLM 节点，开启 Structured Output）→ 模板转换 → 输出。

在「创建内容」节点启用 Structured Output，填入教程 schema，模型设为 `deepseek-flash`（Thinking Mode 开启，默认），运行若干次后出现间歇性失败：`structured_output` 被从 reasoning 块中解析出来，占位值（`”string”` / `”…”` / 整个 Schema）流向下游，但整次运行仍报告 succeeded，14 个节点全绿，`exceptions_count = 0`。

报错原文

[Bug] DeepSeek + Structured Output: parser extracts JSON from the reasoning block (<think>), so placeholder values ("string" / "..." / the whole Schema) reach downstream while the run reports succeeded

<think>
<!--dify-deepseek-reasoning-->…use string/number. Schema: {"platform_name": string, "post_content": string}.
Need platform_name "LinkedIn". Content in Chinese…
</think>{"platform_name":"LinkedIn","post_content":"…the correct post…"}

every run still reports succeeded
exceptions_count = 0

原因分析

Issue 正文给出的根因分析（当前解析器行为支持该诊断）：

DeepSeek 插件把 reasoning 拼接进 `content`。在 `models/deepseek/models/llm/llm.py` 的 `_handle_generate_response`（非流式）中，只要存在 `reasoning_content`，就会无条件地把 `\n…\n` 前缀加到 `result.message.content` 前面，没有 `reasoning_format` 检查。于是 `content` 变成 reasoning 块加真正的 JSON 答案。
Structured Output 在脏文本上做宽松 JSON 提取。当前解析器直接解析原始 message content（或累积的流式内容），不会先剥离 reasoning；其修复回退逻辑选取的是第一个 dictionary，校验只检查是否为 JSON mapping，而不是是否符合节点配置的 schema。因此解析到的常常是模型思考时复述的 schema 本身或占位值。
「分离 reasoning」开关保护不了这条路径。相关报告显示 structured parsing 发生在节点分离 reasoning 之前，所以早期建议的 `separated` 模式在这里不适用。
关于 `{“type”:”json_object”}` 的返回，Issue 认为这与「选错对象」一致，并不能单独证明存在请求侧缺陷。

可能原因还包括请求侧参数对最终答案格式的影响，但 Issue 中未给出该方向的确认证据。

环境排查

确认 Dify 版本：Issue 为 Dify Cloud，backend X-Version 1.17.1（2026-10-14）。
确认模型与插件：`deepseek-flash`，provider plugin `langgenius/deepseek@0.0.24`。
确认 LLM 节点是否开启了 Structured Output，以及填入的 schema 内容。
确认该节点的 Thinking Mode 是否开启（`deepseek-flash` 暴露该布尔设置，插件将 `false` 映射为关闭思考）。
查看运行日志中该节点的 outputs，对比 `text` 与 `structured_output`。
确认 `structured_output` 是否来自 “ 块（是否存在 `<!–dify-deepseek-reasoning–>` 标记）。
注意失败是间歇性的，需要多跑几次同一配置才能观察到。

解决步骤

打开「创建内容」LLM 节点的 outputs，对比 `text` 与 `structured_output`，确认 `structured_output` 是否取自 “ 块中的内容（例如 `platform_name` 为 `”string”`、`post_content` 为 `”…”`，或直接是整个 schema）。
可优先尝试：在该节点的模型参数中关闭 Thinking Mode，不要改 reasoning 标签分离设置（相关报告已说明分离设置不保护此解析路径）。保存后重跑工作流。
若仍需使用 Thinking Mode：当前没有已验证的一步修复。可跟踪上游进度——Issue 提到已有 open、未合并的修复提案 PR #44005，目标是在阻塞与流式两条 Structured Output 路径中修正 reasoning JSON 的选择，但不包含 schema 校验。
在 schema 之外增加应用层检查：由于 `”string”`、`”…”` 在教程 schema 下是合法字符串，schema 校验无法拦住这类占位值，可考虑对 `platform_name` 等字段限制允许取值，或在后续节点中校验内容并显式失败。
如需帮助定位 Cloud/插件特有情况，按 Issue 建议提供脱敏后的工作流 DSL，以及失败节点的完整 `text` / `structured_output` 载荷，作为 #43983 的回归证据。

验证方法

关闭 Thinking Mode 后，多跑几次同一工作流，检查「创建内容」节点的 outputs：`structured_output` 应来自最终答案而不是 “ 块，`text` 中也不应再出现 reasoning 前缀污染导致选错对象的情况。同时确认模板转换节点拿到的 `platform_name` / `post_content` 不再是 `”string”` / `”…”` 这类占位值。注意：这只是规避 reasoning 污染路径，不代表 schema 与内容一定正确，仍需人工抽查输出。