StepFun Step 3.7 Flash 登陆 DashScope：你的路由代理必须处理的非标准字段

当一个新模型上线 DashScope 时，路由问题很少只是"我该用它吗？"更关键的是："我的代理能正确处理它的 API 接口吗？"StepFun Step 3.7 Flash 于 5 月 29 日上线，引入了一个位于标准 OpenAI chat completions schema 之外的思考模式开关——而这个差距正是路由代理静默失效的地方。

发生了什么

阿里云百炼于 2026 年 5 月 29 日将 stepfun/step-3.7-flash 加入 DashScope 模型目录。该模型由阶跃星辰直供，定位为"Flash 档位新一代旗舰"，在搜索、agent 任务、编码和多模态理解方面全面升级。

模型通过标准 DashScope OpenAI 兼容 endpoint 访问：

base_url: https://dashscope.aliyuncs.com/compatible-mode/v1
model: stepfun/step-3.7-flash

关键 API 行为：思考模式默认关闭。要开启，调用方必须在 extra_body 中传入 enable_thinking: true。开启后，模型在 delta 的 reasoning_content 字段中返回推理过程，与标准 content 字段分离。调用方还可通过 reasoning_effort 参数（可选值：low、medium、high）控制推理深度。

为什么这对 AI 工程团队很重要

extra_body 模式是 DashScope（以及其他几家中国 provider）暴露模型特定参数的方式，这些参数在 OpenAI 规范中没有对应项。直接用 OpenAI SDK 调用 API 时没有问题——SDK 会将 extra_body 字段直接传入请求体而不做校验。但在路由层中，这会产生一个特定的失效模式。

大多数 OpenAI 兼容路由代理会丢弃或忽略未知的顶层请求字段。 如果你的代理转发请求体时丢弃了 extra_body 内容，模型会在没有 enable_thinking: true 的情况下收到调用，静默回退到非思考模式，返回一个看起来正确但缺少应用所期望的推理过程的响应。没有报错——只是不同的模型行为。

响应侧的 reasoning_content 字段也存在对称问题。如果你的代理在转发给客户端之前将响应规范化为标准 OpenAI schema，它可能会完全丢弃 reasoning_content。解析 delta 中推理过程的应用将收到空字符串。

这不是 StepFun 特有的问题。同样的模式适用于 Qwen3 系列（enable_thinking、thinking_budget）、DeepSeek V4（thinking.type、reasoning_effort）以及其他通过非标准字段暴露思考控制的 DashScope 托管模型。Step 3.7 Flash 是这一类别的最新成员。

Router/Operator 视角

对于跨 DashScope 托管模型进行路由的团队，Step 3.7 Flash 引入了一个超越模型选择的决策点：

1. 审计你的代理对 extra_body 的处理。 如果你在应用和 DashScope 之间使用路由层，测试 extra_body 字段是否能在整个链路中存活。发送一个带有 enable_thinking: true 的请求，检查响应是否在流式 delta 中包含 reasoning_content。如果没有，你的代理正在静默丢弃思考开关。

2. 决定是向调用方暴露思考模式，还是在路由层统一管理。 有两种有效架构：让调用方直接传递 enable_thinking（要求代理透传 extra_body），或者让路由层根据任务分类为特定模型路由注入 enable_thinking: true。第二种方式提供集中控制，但要求路由配置知道哪些模型支持该字段。

3. 在响应规范化中处理 reasoning_content。 如果你的代理规范化流式响应，为 delta 对象中的 reasoning_content 添加显式处理。决定是将其转发给客户端、剥离，还是单独记录用于可观测性。静默丢弃是最糟糕的结果——它让调试思考模式行为变得不可能。

4. 将思考模式视为路由信号，而非仅仅是模型特性。 开启 reasoning_effort: high 的 Step 3.7 Flash 与关闭思考的 Step 3.7 Flash 行为不同——延迟、token 成本、输出质量都不同。如果你基于任务复杂度进行路由，思考开关实际上是同一模型内的第二个路由维度。需要深度推理的任务可以使用 reasoning_effort: high；延迟敏感的任务可以在同一模型上关闭思考。

5. 地域限制：仅限北京。 DashScope 文档指出 stepfun/step-3.7-flash 目前仅在华北 2（北京）地域可用，需要使用北京地域的 API Key。如果你的路由策略跨越 DashScope 地域，该模型不能作为全局 fallback——它需要特定地域的路由规则。

TheRouter 用户应该关注或尝试什么

extra_body 透传问题是测试任何路由层是否正确处理 DashScope 扩展参数接口的好用例。如果你在评估当前代理是否能正确处理 DashScope 的扩展参数：

• 向 stepfun/step-3.7-flash 发送带有 extra_body: { enable_thinking: true } 的测试请求，验证流式响应中是否出现 reasoning_content。
• 如果没有，检查你的代理是否有显式的 extra_body 透传设置，或者是否需要将思考参数展平到该 provider 的顶层请求体中。
• 对于生产路由策略，将思考模式模型视为独立分层：开启思考时每 token 成本更高、延迟更高、响应 schema 不同。为能从扩展推理中受益的任务显式路由到它们，而不是作为标准 Flash 级调用的直接替代。

更广泛的规律是：中国 provider 生态系统正在向共享的思考模式 API 接口收敛——enable_thinking、reasoning_content、reasoning_effort——但字段名称和位置在不同 provider 之间差异足够大，每个都需要在路由配置中显式处理。Step 3.7 Flash 是加入这份名单的最新模型。