DeepSeek V4 推理力度 API 支持三种格式：为什么你的代理可能悄悄传错了参数

8 月 13 日 DeepSeek V4-Pro 正式版的发布，外界讨论最多的是峰谷定价。但从运维角度看，更值得关注的变化藏在 API 文档里：推理力度控制从实验性选项升级为正式参数，分成 low、high、max 三档，默认值是 high。而且，不同 API 格式的写法完全不同——这对任何接了代理层或网关的团队都意味着潜在的静默失效。

V4-Pro 正式版改变了什么

现在 V4-Pro 和 V4-Flash 都支持三档推理力度。不同格式的写法如下：

OpenAI Chat Completions 格式：

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[...],
    reasoning_effort="high",
    extra_body={"thinking": {"type": "enabled"}}
)

这里需要两个字段：顶层的 reasoning_effort 设置档位，extra_body 里的 thinking 开启思考模式。如果只写 reasoning_effort 而漏掉 extra_body，思考模式不会启动，档位设置也没有意义。

Anthropic Messages 格式：

{
  "model": "deepseek-v4-pro",
  "thinking": {"type": "enabled"},
  "output_config": {"effort": "high"}
}

Responses API 格式：

{
  "model": "deepseek-v4-pro",
  "reasoning": {"effort": "high"}
}

三种格式，三条不同的字段路径，指向同一个底层能力。

代理层为什么会悄悄传错

大多数 OpenAI 兼容代理转发的是标准的 Chat Completions 字段——model、messages、temperature、max_tokens——对于 extra_body 这类扩展，往往直接丢弃。问题在于，extra_body 是 Python SDK 的客户端概念：SDK 在发起请求时会把它合并进请求体，真正到达网络层的是一个普通 JSON，thinking 和 messages 并列在顶层。

如果你的代理重新构造请求体而不是原样转发，thinking 字段就可能被丢掉。结果是思考模式未启动，reasoning_effort 的值形同虚设。服务端不会报错，响应正常，但你拿到的是不带思维链的输出，计费按非思考模式走，成本和延迟都可能不是你预期的。

Reddit 上已经有用户在 OpenCode 场景下复现了这个问题：框架没把 thinking 字段透传给 DeepSeek，服务端在某些版本里静默应用了自己的默认值。

工具调用序列里的 reasoning_content 规则

多轮 agent 流水线还有一个容易忽视的行为差异：reasoning_content 在工具调用序列里的处理方式。

模型执行工具调用时，中间那轮 assistant 响应的 reasoning_content 必须在拼接下一轮上下文时一并传回。如果没有工具调用，上一轮的 reasoning_content 则应该丢弃，不必传回（传了也无妨，只是多余的 token）。

很多 agent 框架在拼接上下文时只保留 content 字段，reasoning_content 会被直接丢掉。工具调用序列里丢失这个字段，模型在后续轮次的行为可能出现不一致。这个规则和力度档位无关，low、high、max 三档都适用。

Codex 集成配置里的线索

DeepSeek 发布了针对 Codex 的集成配置文档，里面的 JSON 规格暴露了内部路由行为。deepseek-v4-flash 的配置显示：

{
  "default_reasoning_level": "high",
  "supported_reasoning_levels": [
    {"effort": "low", "description": "Fast responses with lighter reasoning"},
    {"effort": "high", "description": "Extra high reasoning depth for complex problems"},
    {"effort": "max", "description": "Maximum reasoning depth for the hardest problems"}
  ]
}

这意味着：通过支持 Codex 的客户端路由 V4-Flash，如果你不显式指定力度，默认是 high。如果你的网关试图在路由层统一设置 reasoning_effort=low 来控制成本，而 Codex 客户端在下游用自己的 default_reasoning_level 覆盖，两者之间存在冲突，且不会产生任何报错。

和其他提供商的横向对比

三档力度（low、high、max）的设计和 Anthropic Claude 扩展思考的预算控制相似。OpenAI 的 Fast mode 和服务层级（standard、priority、fast）是另一个维度，控制的是吞吐和延迟，和推理深度正交，不能直接类比。

DeepSeek 的关键差异是默认值：不设置任何参数时是 high，而不是 low。这意味着通过 V4-Pro 跑大量 agent 任务，基准成本就在中高推理预算上。对那些做分类、抽取、简单生成的高并发任务来说，显式设置 reasoning_effort=low 可以明显降低成本和延迟——前提是你的代理层确实把这个参数传到了 DeepSeek。

运维侧需要确认的三个问题

上线前，建议先回答这三个问题：

1. 你的代理是否原样转发 thinking 字段？直接抓包看实际请求体，不要只看 SDK 调用侧的参数。

2. 力度是按请求设置还是按路由设置？混合工作负载（agent 需要 high 或 max，批处理可以用 low）要求路由层能在请求粒度上传递力度参数，而不是用一个全局默认值覆盖所有请求。

3. 你的 agent 框架在工具调用序列里是否保留了 reasoning_content？查一下框架拼接 assistant 消息的逻辑，看它是否会丢弃不认识的字段。

TheRouter 用户的关注点

通过 TheRouter 路由到 DeepSeek 的团队：代理层会原样把请求体转发给上游提供商，thinking 和 reasoning_effort 字段只要客户端发出来就会到达 DeepSeek。风险在客户端侧——如果你用的是 OpenAI 格式路径，确认你的 SDK 版本正确合并了 extra_body。

混合工作负载下，把简单任务路由到 deepseek-v4-flash 并显式设置 reasoning_effort=low 是合理的成本策略。V4-Flash 在常规任务上的表现足够强，low 档位的输出质量在大多数生产场景下不会比 high 差出多少。