DeepSeek 推理模型（如 deepseek-reasoner）在回答复杂问题时，会在内部生成一条完整的思维链，用来逐步推导出最终答案。默认情况下，API 响应中可能同时包含推理过程与最终答案，但很多业务场景只需要展示答案，不希望用户看到中间推理步骤。反过来，开发者在调试提示词或验证模型逻辑时，又希望把思维链完整拉取出来。要实现这种灵活控制，就需要正确设置思维链显式输出参数。
不同版本的 DeepSeek API 在参数命名上略有差异，但核心思路一致：通过请求体中的布尔型开关，指定是否在响应中返回 reasoning_content 字段。对于兼容 OpenAI SDK 的调用方式，这个开关通常放在 extra_body 参数中。下面先看一个最简单的非流式调用示例。
一、非流式调用中控制思维链输出
在非流式请求中，DeepSeek API 返回的是一个完整的 JSON 对象。如果开启了思维链输出，响应体会多出一个 reasoning_content 字段，里面就是模型在给出最终答案之前的推理文本。关闭该字段后，响应只保留 content 部分，数据体积会明显减小。
以 Python 的 openai 库为例，调用 deepseek-reasoner 模型时，可以在 extra_body 中传入 include_reasoning 参数。该参数为 true 时显式输出思维链，为 false 时隐藏推理过程。需要注意的是，不同版本的 DeepSeek API 服务端可能使用 reasoning_content 或 show_reasoning 作为开关名，建议先查阅当前 API 文档确认。下面的示例演示了开启与关闭两种调用方式。
from openai import OpenAI
client = OpenAI(
api_key="你的DeepSeek密钥",
base_url="https://api.deepseek.com"
)
# 开启思维链输出
response_with_reasoning = client.chat.completions.create(
model="deepseek-reasoner",
messages=[
{"role": "user", "content": "请推导勾股定理的证明过程"}
],
extra_body={
"include_reasoning": True
}
)
print("推理过程:", response_with_reasoning.choices[0].message.reasoning_content)
print("最终答案:", response_with_reasoning.choices[0].message.content)
# 关闭思维链输出
response_without_reasoning = client.chat.completions.create(
model="deepseek-reasoner",
messages=[
{"role": "user", "content": "请推导勾股定理的证明过程"}
],
extra_body={
"include_reasoning": False
}
)
print("最终答案:", response_without_reasoning.choices[0].message.content)
使用 curl 命令时，参数直接放在 JSON 请求体中。下面的命令同样开启了思维链输出，可以看到响应中的 reasoning_content 字段。
curl https://api.deepseek.com/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer 你的DeepSeek密钥" \
-d '{
"model": "deepseek-reasoner",
"messages": [
{"role": "user", "content": "什么是快速排序？请解释其时间复杂度"}
],
"include_reasoning": true
}'
非流式响应的 JSON 结构大致如下，可以看到 reasoning_content 与 content 是平级字段。如果关闭思维链输出，整个 reasoning_content 字段会被省略。
{
"id": "chatcmpl-xxxx",
"object": "chat.completion",
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "快速排序是一种分治算法...",
"reasoning_content": "用户询问快速排序的解释与时间复杂度。先回忆快速排序的基本步骤..."
},
"finish_reason": "stop"
}
],
"usage": {
"prompt_tokens": 32,
"completion_tokens": 180,
"total_tokens": 212
}
}
需要特别说明的是，即使关闭了思维链输出，模型内部仍然会执行完整的推理过程，消耗的计算资源不会减少。因此关闭输出主要节省的是响应传输流量和客户端解析成本，对服务端计费的影响要看 DeepSeek 的计费规则是否将 reasoning_content 的 token 单独计费。
二、流式输出下的思维链控制与提取
流式调用（stream=True）场景比非流式更复杂，因为响应被拆分成多个 chunk。每个 chunk 可能只包含 content 的一部分，也可能同时携带 reasoning_content 片段。如果请求时开启了思维链输出，开发者需要在回调中分别累积这两部分内容，否则会导致最终拼接结果错位。
以下 Python 示例展示了如何在流式模式下开启思维链输出，并将推理过程和最终答案分开保存。关键在于判断每个 chunk 中是否存在 reasoning_content 字段，并注意 DeepSeek API 在流式开始时可能先返回一个只包含角色信息的 chunk。
from openai import OpenAI
client = OpenAI(
api_key="你的DeepSeek密钥",
base_url="https://api.deepseek.com"
)
stream = client.chat.completions.create(
model="deepseek-reasoner",
messages=[
{"role": "user", "content": "请分析快速排序与归并排序的优缺点"}
],
stream=True,
extra_body={
"include_reasoning": True
}
)
reasoning_parts = []
content_parts = []
for chunk in stream:
if not chunk.choices:
continue
delta = chunk.choices[0].delta
# 获取思维链片段
reasoning = getattr(delta, "reasoning_content", None)
if reasoning:
reasoning_parts.append(reasoning)
# 获取最终答案片段
content = getattr(delta, "content", None)
if content:
content_parts.append(content)
full_reasoning = "".join(reasoning_parts)
full_content = "".join(content_parts)
print("完整推理过程:", full_reasoning)
print("完整最终答案:", full_content)
如果开发者使用的是原生 HTTP 流式响应，每个 chunk 是一个 JSON 对象，字段结构与 OpenAI 格式类似，只是 delta 中可能包含 reasoning_content。关闭思维链输出后，这些 chunk 将不再携带 reasoning_content 字段，客户端只需处理 content 即可。这种场景下，参数同样通过请求体中的 include_reasoning 控制，但要注意部分第三方代理或网关可能会忽略该参数，需要在实际环境中验证。
还有一种常见的做法是：无论服务端是否返回思维链，客户端在展示前都会做一次过滤，只把 content 字段渲染给最终用户。这样即使服务端配置错误导致思维链泄露，也能在展示层兜底。不过这不能代替请求参数的显式控制，因为传输的思维链数据仍然会占用带宽。
三、思维链输出对成本、性能与调试的影响
思维链 token 的数量往往远大于最终答案的 token 数量。对于一道数学证明题，模型可能消耗 800 个 token 进行推理，而最终答案只有 150 个 token。如果 API 计费规则将 reasoning_content 与 content 分别计费，那么开启思维链输出意味着响应体积和网络传输成本同时上升。因此生产环境通常建议显式关闭思维链输出，除非业务本身需要展示推理过程。
但在调试阶段，思维链是非常有价值的诊断工具。当模型给出的答案不符合预期时，检查 reasoning_content 可以判断问题出在理解提示词、推理路径还是最终表达。例如，如果推理过程正确但最终答案错误，说明模型在总结阶段出现了偏差；如果推理过程本身就跑偏了，则需要调整提示词或换用更强模型。这种情况下，开发者可以通过环境变量或配置中心动态切换 include_reasoning 的值，而不需要修改业务代码。
一个实用的工程实践是：在开发环境默认开启思维链输出，并将推理内容写入日志；在测试和生产环境默认关闭，仅记录最终答案和 token 消耗。这样可以在不增加线上成本的前提下，保留完整的问题排查能力。同时，建议对 reasoning_content 的长度做监控，如果发现某类请求的推理 token 占比异常高，可以针对性地优化提示词或采用缓存策略。
四、常见问题与参数兼容性排查
实际开发中，最常遇到的问题就是设置了 include_reasoning 参数后，响应中仍然没有 reasoning_content 字段。这通常有几种原因：模型本身不是推理模型（例如使用了 deepseek-chat 而非 deepseek-reasoner）；API 网关或代理层过滤了未知字段；客户端 SDK 版本过老，不认识新参数。排查时可以先使用 curl 直接调用官方 API 验证参数是否生效，再逐步检查中间层。
另一个容易混淆的点是：非流式响应中的 reasoning_content 是一个完整字符串，而流式响应中是多个片段，需要客户端拼接。有些开发者误以为流式模式下关闭思维链输出后，前面累积的 reasoning_content 会自动清空，实际上不会，需要手动重置变量。
如果使用的是兼容 OpenAI 格式的第三方库，建议优先使用官方 SDK 并在 extra_body 中传参，避免直接在 messages 或 temperature 同级放置未被识别的字段。对于需要同时兼容多个推理模型的项目，可以封装一个统一的思维链开关配置，根据模型名称自动选择正确的参数名（include_reasoning、reasoning_content 或 show_reasoning），从而降低维护成本。
最后提醒一点：思维链内容属于模型内部推理，可能包含不完整、不严谨甚至错误的中间结论，不应直接作为业务数据返回给终端用户。除非产品明确需要展示推理过程，否则始终建议保持思维链输出关闭，确保输出内容干净、合规。
DeepSeek API思维链推理过程参数修改时间：2026-09-27 14:45:24