bug: Improved Message Rendering drops message-level thinking on OpenAI-shaped ChatML messages

问题场景

用户在使用 Langfuse 自托管 v4.41.0 的 Trace 视图查看一条 observation 时，数据是由 OpenInference（llama-index）span 经自定义 OTel processor 写成 ChatML 格式的 input.value / output.value。assistant 消息同时带有 message-level thinking 数组和 OpenAI 风格的 tool_calls：

[
  {
    "role": "assistant",
    "thinking": [{ "type": "thinking", "content": "User wants the entity details, so call get_entity_details." }],
    "content": "",
    "tool_calls": [
      {
        "id": "call_1",
        "type": "function",
        "function": { "name": "get_entity_details", "arguments": "{\"entity_id\":\"abc\"}" }
      }
    ]
  }
]

在 Formatted 视图中，稳定路径会把这部分推理渲染成可折叠的 “Thinking” 块；开启 Settings → Feature Previews → Improved Message Rendering（normalizedIoPreview）后重新加载同一 observation，tool call 仍然渲染，但 “Thinking” 块消失，且 UI 不会提示任何内容被丢弃。

报错原文

bug: Improved Message Rendering drops message-level thinking on OpenAI-shaped ChatML messages

Issue 标题中的核心报错即以上内容；报告中还明确描述：

Expected: the preview renders the reasoning, as the legacy view does.
Actual: the reasoning is silently dropped.

原因分析

最可能的原因是归一化预览的 provider conventions 路由与字段读取范围不一致：

• ChatMlMessageSchema（packages/shared/src/utils/IORepresentation/chatML/types.ts）定义了 thinking: ThinkingContentPart[]（{type: "thinking", content, signature?, summary?}），与 OpenAI 字段 tool_calls、tool_call_id 并列，该字段由 PR #11615 引入。
• conventions 采用“一个会话只被一个 convention 认领”的机制，而 openAiProvider 在 registeredProviders 中排在前面。这些消息因为带有 OpenAI 风格的 tool_calls 被 OpenAI convention 认领。
• 但 OpenAI convention 的 collectSiblingParts 只读取 refusal、audio 以及 Responses 风格的 type: "reasoning" 项，没有读取 message-level 的 thinking 数组。
• Anthropic convention 虽然已经会读取 message.thinking[]（providers/anthropic/index.ts），但由于消息被 OpenAI convention 抢先认领，它不会处理这些消息。

报告者还提出可能原因：OpenAI convention 同样忽略 reasoning_content——这是 DeepSeek、vLLM 等 OpenAI 兼容后端以及 LiteLLM 等网关使用的 reasoning 字段，因此同类问题可能也影响这些 trace。该扩展影响属于报告者推测，Issue 中未给出对应复现数据。

环境排查

• 确认 Langfuse 是 Cloud 还是自托管；本 Issue 为 self-hosted。
• 确认自托管版本号（本 Issue 为 v4.41.0），并检查是否已包含 PR #17610 的修复。
• 确认 Settings → Feature Previews → Improved Message Rendering（normalizedIoPreview）是否开启。
• 确认触发问题的数据形态：assistant 消息是否同时带有 message-level thinking 数组与 OpenAI 风格 tool_calls。
• 确认数据写入路径：如 OpenInference（llama-index）span 经自定义 OTel processor 写入 ChatML input.value / output.value；报告者认为 bug 位于渲染器，source integration 不应影响结果。
• Issue 未提供 Python、CUDA、PyTorch、显卡或节点版本信息，无需据此排查。

解决步骤

1. 先用报告中给出的 ChatML payload 在 Formatted 视图中复现：关闭 Improved Message Rendering 时应看到 “Thinking” 块。
2. 开启 Settings → Feature Previews → Improved Message Rendering，重新加载同一 observation，确认 “Thinking” 块消失而 tool call 仍在（即确认命中本 Issue）。
3. 若暂时不能升级：关闭 Improved Message Rendering 预览，回退到稳定渲染路径，作为临时绕过方案。
4. 关注并采用 Issue 评论中提到的修复 PR #17610，将其合入或升级到包含该修复的 Langfuse 版本。
5. 若你自行贡献修复，Issue 中建议的方向是：在 OpenAI convention 的 collectSiblingParts 中读取 message-level thinking 数组（匹配 ThinkingContentPartSchema）以及 reasoning_content（字符串），并把两者作为 reasoning parts 输出到 legacy renderer 使用的同一 slot；同时增加一个 fixture，断言该 payload 在 legacy parser 与 normalized parser 之间的渲染一致性。该修复方向属于报告者建议，需以实际合入的 PR 为准。

验证方法

使用 Issue 中的 ChatML payload，分别在 Improved Message Rendering 关闭与开启状态下打开同一 observation 的 Formatted 视图：关闭时 assistant 消息显示可折叠的 “Thinking” 块；开启后，修复生效时应与关闭时一样显示该 “Thinking” 块，同时 tool call 正常渲染。也可按报告者建议的 fixture 方式，断言 legacy 与 normalized 两套 parser 对该 payload 的输出一致。

参考来源

langfuse/langfuse #17805

langfuse/langfuse PR #17610

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。