DashScope OpenAI Responses API — compatible-mode/v1 现已支持 Qwen 有状态上下文和内置工具

这次变化影响的不是选哪个模型,而是选哪个 API 接口来构建系统。阿里云百炼(DashScope)正式发布了 OpenAI Responses API 的兼容支持,这意味着已经采用 client.responses.create() 的团队,只需修改 base_url 和 API Key,就能将同一套 SDK 指向 Qwen 模型。

发生了什么

阿里云百炼文档现已提供完整的 OpenAI Responses API 调用指南,支持通过该接口调用 Qwen 模型。Responses API 是 OpenAI 在 2025 年初推出的有状态、面向 agent 的新一代接口,是 Chat Completions 的演进版本。当前支持的模型涵盖推荐主力层:qwen3.7-max、qwen3.6-plus、qwen3.6-flash、qwen3.5-plus、qwen3.5-flash、qwen3-coder-plus、qwen3-coder-flash 及多个开源版本。

该接口已在全球四个区域上线:

• 华北2(北京):https://dashscope.aliyuncs.com/compatible-mode/v1
• 新加坡:https://dashscope-intl.aliyuncs.com/compatible-mode/v1
• 美国(弗吉尼亚):https://dashscope-us.aliyuncs.com/compatible-mode/v1
• 德国(法兰克福):https://{WorkspaceId}.eu-central-1.maas.aliyuncs.com/compatible-mode/v1

同时,DashScope 发出了弃用通知:旧版 URL 路径 /api/v2/apps/protocols/compatible-mode/v1/responses 即将停止维护,使用该路径的团队需迁移至 /compatible-mode/v1/responses。

对 AI 工程团队意味着什么

Responses API 与 Chat Completions 在运营层面有三处关键差异:

通过 previous_response_id 实现有状态上下文。 无需在每轮请求中重建完整消息历史,只需传入上一轮响应的 ID,DashScope 在服务端保存上下文,有效期为 7 天。这改变了 token 计费的计算方式:第 N 轮的输入 token 数包含了前几轮的累积上下文,但无需重复传输。对于长时间运行的 agent 会话,这能显著减少单次请求的 payload 体积。

内置工具,无需自定义函数定义。 DashScope 的 Responses API 将联网搜索、网页抓取、代码解释器、文搜图、图搜图作为一等公民工具直接暴露,无需编写 function schema。对于构建研究型或编程 agent 的团队,这省去了一层 prompt 工程和工具调用的样板代码。

reasoning.effort 控制思考深度。 Chat Completions 使用非标准的 enable_thinking 参数(通过 extra_body 传入),而 Responses API 使用 reasoning.effort,支持 none、minimal 等取值。这是一个更清晰的按请求控制思考深度的接口,与 OpenAI 自家推理模型的参数设计保持一致。

实际影响:如果团队已在 OpenAI 工作负载上标准化使用 Responses API,现在可以将 Qwen 加入路由目标,无需为 Chat Completions 维护独立的代码路径。

Router/Operator 视角分析

provider 依赖与 fallback 规划。 DashScope 的 Responses API 与 OpenAI 实现尚未完全对齐。值得注意的是,qwen3.6-max-preview 和 deepseek-v4-pro 目前不在 Responses API 支持的模型列表中,仅支持 Chat Completions。如果路由策略动态选择模型,需要同时追踪哪些模型支持哪种 API 接口,而不仅仅是哪个 provider 支持哪个模型。

有状态上下文带来新的故障模式。 使用 previous_response_id 时,一次失败或过期的响应会中断整个对话链。7 天的 TTL 意味着暂停超过一周的长时间 agent 工作流会静默丢失上下文。构建多日 agent 循环的 operator 需要显式的检查点逻辑,而不能仅依赖失败重试。

区域选择影响延迟和数据驻留。 四个 DashScope Responses API 区域并不等价:北京端点服务中国区流量;新加坡和美国服务国际工作负载。对于有数据驻留要求的团队,法兰克福端点的 URL 中需要包含 Workspace ID,这与其他三个区域的认证方式不同。将四个端点视为可互换的路由策略会在法兰克福请求上触发认证错误。

计费结构变化。 DashScope 的响应对象包含 x_details 数组,其中 x_billing_type: "response_api" 是独立于 Chat Completions 的计费类别。如果成本对账流水线解析 usage 对象,需要处理这个新字段。推理 token 在 output_tokens_details.reasoning_tokens 下报告,格式与 OpenAI 一致。

旧版 URL 路径弃用。 任何硬编码了 /api/v2/apps/protocols/compatible-mode/v1/responses 的代理或 gateway 在 DashScope 下线该路径后都会中断。现在就审查你的 base URL 配置。

TheRouter 用户应关注什么

如果你目前通过 TheRouter 将 OpenAI Responses API 流量路由到 OpenAI,架构层面的问题是:是否将 DashScope 作为同一 Responses API 接口的 fallback 或成本优化目标。关键检查点:确认路由层在转发请求时不会剥离 previous_response_id--有状态上下文只有在 session ID 完整到达 DashScope 时才能生效。

对于尚未迁移到 Responses API 的团队,这是评估迁移的合适时机。Chat Completions 在 DashScope 上仍完全支持,但 Responses API 的内置工具和有状态上下文能减少 agent 工作流的样板代码。DashScope 文档中的迁移指南包含了 Chat Completions 与 Responses API 请求格式的对比说明。

值得关注:DashScope 是否会将 qwen3.6-max-preview 和 DeepSeek V4 系列纳入 Responses API 支持的模型列表--这两类模型目前仅支持 Chat Completions。