GPT-OSS-120b 返回空响应？工具调用与推理内容获取的排查指南

问题现象：模型返回空内容与工具调用失败

有开发者在 Azure 上托管了 gpt-oss-120b 模型，通过 AzureChatOpenAI 进行调用。该模型绑定了两个工具（参数简单，最多两个键），但调用时模型有时返回的响应中既没有内容（content），也没有工具调用（tool_calls），即完全空响应。相同的提示词在其他模型（如 gpt-54 等更强大的模型）上工作正常。此外，开发者还想从 AIMessage 对象中获取 reasoning_content，但发现找不到该属性。

reddit source: GPT-OSS-120b, Empty responses and tool calls

这个问题在开源模型部署中并不罕见，尤其是当模型规模较大、推理能力较强时，其行为可能与商业闭源模型存在差异。下面我们从几个可能的角度分析原因，并给出排查方向。

为什么会出现空响应？

1. 模型本身的输出格式与绑定工具不兼容

gpt-oss-120b 作为一个开源大模型，其工具调用（function calling）的实现可能依赖特定的提示词模板或输出格式。如果 AzureChatOpenAI 的封装没有完全适配该模型的工具调用协议，模型可能生成了不符合解析预期的输出，导致客户端将其解析为空。例如，模型可能返回了工具调用的意图，但格式不是 OpenAI 标准的 JSON，从而被解析器丢弃。

OpenAI 标准的 function calling（工具调用）协议要求模型返回一个结构化的 JSON 对象，通常包含在 tool_calls 字段中，每个调用有 id、type、function.name 和 function.arguments。商业闭源模型经过大量对齐训练，能稳定输出该格式；而开源模型往往在训练中接触的模板多样，部署时若未严格套用其指定的 chat template（例如带特殊 token 的 <|python_tag|> 或 <|tool_call|> 标记），生成的文本就可能偏离标准结构。LangChain 的解析器只识别标准字段，一旦格式不符便静默丢弃，表现为 content 与 tool_calls 双空。因此，查看模型卡片中推荐的 prompt 模板和工具调用示例，是判断兼容性的第一步。

2. 工具定义过于简单导致模型困惑

开发者提到工具参数最多两个键，看似简单，但可能正是这种简单性让模型难以判断何时该调用工具。部分开源模型对工具描述的敏感度较高，如果工具描述不够明确，模型可能选择不调用工具也不生成内容，而是直接返回空。建议检查工具定义的描述是否清晰，是否明确说明了工具的用途和调用时机。

3. 推理内容（reasoning_content）的干扰

gpt-oss-120b 可能是一个支持推理内容输出的模型（类似 o1 系列），其内部会先生成推理过程，再生成最终回复。如果推理过程占用了大量 token，而 max_tokens 设置过小，可能导致最终回复被截断为空。另外，推理内容可能被封装在响应的特定字段中，而 AzureChatOpenAI 的 AIMessage 对象默认不暴露该字段。

reasoning_content 并非 OpenAI 官方 Chat Completions 规范中的标准字段，而是部分推理模型（如 DeepSeek^广告-R1 及一些开源推理模型）在响应中额外返回的思维链文本。不同厂商的字段命名并不统一，常见的有 reasoning_content、reasoning、thinking 等。OpenAI 的 o 系列模型则通过 reasoning_tokens 计入 usage 并隐藏具体推理文本。LangChain 的 AIMessage 只映射了标准字段，未知字段通常被放入 additional_kwargs 或直接丢弃，所以直接访问 message.reasoning_content 会抛出属性错误。要拿到该内容，需从原始响应 JSON 或 additional_kwargs 中提取，而不能依赖属性访问。

4. 模型部署配置问题

在 Azure 上托管开源模型时，推理参数（如 temperature、top_p、max_tokens）的默认值可能与模型预期不符。例如，过高的 temperature 可能导致输出不稳定，而过低的 max_tokens 可能直接截断响应。建议检查部署时的参数配置，并与模型文档中的推荐值对比。

在 Azure AI Foundry 或 Azure OpenAI 兼容端点托管开源模型时，实际生效的是部署配置中的推理参数，而非模型自带的默认值。max_tokens 在推理模型场景下尤其关键：它限制的是推理 token 与最终回复 token 之和，若推理过程消耗较多，最终 content 可能被截断为空。此外，部分托管服务对开源模型使用 vLLM 或 TGI 作为推理后端，其 temperature、top_p、repetition_penalty 等默认值与模型文档推荐值可能不同，stop 序列配置不当也会提前终止生成。排查时应显式设置这些参数，并在端点日志或响应 usage 中对比 prompt_tokens 与 completion_tokens 的实际消耗。

如何获取 reasoning_content？

开发者提到无法从 AIMessage 对象中找到 reasoning_content 属性。这通常是因为 LangChain 的 AzureChatOpenAI 封装尚未适配该模型的推理内容字段。可以尝试以下方法：

检查响应对象的原始 JSON：在调用链中打印 response 的 dict 或 JSON 表示，查看是否有 reasoning_content 或类似字段（如 reasoning、thinking 等）。
使用模型的原始 API：绕过 LangChain 封装，直接调用 Azure 的推理端点，查看返回的完整结构。
自定义回调或解析器：如果原始响应中包含推理内容，可以编写自定义解析逻辑，将其提取并附加到 AIMessage 的 additional_kwargs 中。

排查步骤与建议

简化复现：用一个最简单的提示词和单个工具进行测试，确认空响应是否稳定出现。
检查原始响应：在代码中打印模型返回的原始 JSON，确认是否真的没有内容，还是解析环节丢失了信息。
调整 max_tokens：适当增加 max_tokens，排除截断导致空响应的可能。
验证工具描述：确保工具的描述清晰、无歧义，并明确说明参数含义。
查阅模型文档：确认 gpt-oss-120b 是否支持工具调用，以及其推荐的调用方式。
对比其他模型：如开发者所说，其他模型正常，说明问题可能出在模型适配层，可向 Azure 或 LangChain 社区反馈。

总结

gpt-oss-120b 返回空响应且工具调用失败，很可能源于模型输出格式与客户端解析的不匹配，或是推理内容字段未被正确暴露。通过检查原始响应、调整参数、优化工具定义，并尝试直接调用 API，开发者可以逐步定位问题。对于 reasoning_content，目前可能需要自定义解析或等待框架更新支持。开源模型的部署往往需要更多的调试工作，但一旦适配完成，其灵活性和成本优势仍然值得投入。