[BUG] OpenAI Compatible 非流式模式（stream: false）下 reasoning_content 字段被静默丢弃

[JK-LIL]

Problem (one or two sentences)

使用 OpenAI Compatible 供应商且关闭流式传输时，API 返回的 reasoning_content（思维链）字段被 OpenAiHandler 的非流式分支完全忽略，仅提取了 message.content，导致 Reasoning 区域空白。

Context (who is affected and when)

使用 OpenAI Compatible 供应商（OpenAI 通用接口）且关闭了"启用流式传输"选项的用户，在用 DeepSeek-reasoner、xAI/Grok 等支持 reasoning 的模型时，无法看到思维链内容。

代理/中转服务如果强制将 stream 覆盖为 false，同样会触发此问题。

Reproduction steps

1. 环境/设置：

   • Roo Code 最新版本
   • API 供应商选择 "OpenAI Compatible"（OpenAI 通用接口）
   • 设置中取消勾选 "启用流式传输"（openAiStreamingEnabled = false）
   • 使用支持 reasoning_content 的模型（如 deepseek-reasoner）

2. 精确操作：

   • 发送一个需要模型思考的问题

3. 观察结果：

   • 模型正常返回响应文本
   • 但 Reasoning 折叠区域始终空白，没有展示思维链
   • 查看网络请求，API 响应中确实包含 reasoning_content 字段

Expected result

非流式模式下，OpenAiHandler 应该从 response.choices[0].message.reasoning_content 提取思维链内容，并以 type: "reasoning" 块的形式 yield 给上层消费。

Actual result

OpenAiHandler 的非流式分支（src/api/providers/openai.ts:263-266）仅提取了 message?.content： yield { type: "text", text: message?.content || "", // ← 完全忽略了 reasoning_content } 导致 reasoning_content 被静默丢弃。

Variations tried (optional)

• 使用 DeepSeek 供应商（DeepSeekHandler）：强制 stream: true，走流式分支，Reasoning 正常显示
• 使用 OpenAI Compatible 供应商 + 开启流式：走流式分支，Reasoning 正常显示
• 使用 OpenAI Compatible 供应商 + 关闭流式（stream: false）：Reasoning 空白 ← BUG

App Version

当前源码 main 分支

API Provider (optional)

OpenAI Compatible

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Problem: In src/api/providers/openai.ts, the non-streaming branch (lines 263-266) only extracts message?.content and yields it as a "text" block. It completely ignores the reasoning_content field that models like DeepSeek-reasoner return on the message object. The streaming branch (line 202) already handles reasoning_content correctly on the delta object.

Proposed fix:

1. In src/api/providers/openai.ts, in the non-streaming response handling (around line 262), add a check for reasoning_content (and reasoning for compatibility) on the message object before yielding the text content. If present, yield it as a { type: "reasoning", text: ... } block.

The change would look like:

// Before yielding text, check for reasoning_content
const reasoningContent = (message as any)?.reasoning_content || (message as any)?.reasoning || ""
if (reasoningContent) {
    yield { type: "reasoning", text: reasoningContent }
}

yield {
    type: "text",
    text: message?.content || "",
}

2. Add test coverage for the non-streaming reasoning_content extraction in the existing OpenAI handler test file.

This is a minimal, targeted fix that mirrors how the streaming branch already handles reasoning content, and is consistent with how other providers (like base-openai-compatible-provider.ts) handle the reasoning_content / reasoning fields.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[JK-LIL]

是的,你做修改吧