「DeepSeek API 现已原生支持 OpenAI Responses API 格式」——官方更新日志里的这句话（核对时间 2026 年 11 月 2 日），对不写代码的读者可以略过，对开发者则是个省事的信号：把 DeepSeek 接进讲这套协议的工具时，不用再写一层格式转换。这篇讲清它和普通对话调用的差别、适合的场景、接入前要确认的边界。
先分清三个容易混的名字
Responses API 是一种「请求格式」，不是一个新模型。DeepSeek API 目前同时接受多种请求格式：最早支持的对话补全格式、后来加的 Anthropic 系格式，以及这次原生支持的 OpenAI Responses 格式——同一个模型，三种敲门方式。模型还是那些模型（deepseek-v4-pro 与 flash 系），能力随模型版本走，与用哪种格式无关。Codex 是一种「客户端工具」，它只讲 Responses 这套协议——DeepSeek 适配它，本质是说「你的请求格式我看懂了」。三者关系理清，就不会被「是不是出了个新模型」的误读带偏。
与普通对话调用的差别
普通对话调用是无状态的一问一答：每轮把历史对话重新发给模型，服务端不记得上一轮。Responses API 的设计目标更面向工具与多步任务：请求里可以带工具定义、任务在客户端与模型之间多轮往返，直到任务完成——这正是 Codex 这类编程工具的工作方式，也是它把这套协议带火的原因。DeepSeek 原生支持后，开发者用同一家模型服务就能同时服务「老格式」和「讲新格式的工具」两类调用方。
适合的场景很明确：要把 DeepSeek 作为后端接进讲 Responses 协议的现成工具（如 Codex 系）——此时原生支持等于零适配成本。反之，如果只是自己写代码调模型做问答，用原来的对话格式即可，没有迁移的必要。配置步骤见Codex 接入配置一篇。
接入前要确认的几条边界
按官方指南口径，DeepSeek 对 Responses 格式的实现是面向实际工具的适配，不是全量复刻。接入前确认四条（细节以官方 Responses API 指南当前版本为准）：一是会话状态由调用方维护——多轮上下文要自己带着走；二是部分参数与内置工具不被支持——迁移前逐项对照官方支持清单，别假设 OpenAI 侧能用的这里都能用；三是超长请求的处理方式不同——超出上下文窗口可能直接报错而不是被自动截断，长任务的上下文预算要自己做（报错对照见API 报错对照）；四是图片与文件输入的支持范围随版本演进——用到多模态输入前先查当前文档。
提示词起手式（迁移前自查）：「我要把现有程序从 OpenAI 的 Responses API 迁移到 DeepSeek。以下是我用到的参数与工具清单：[逐项列出]。请对照 DeepSeek 官方 Responses API 指南的范围，把清单分成三栏：直接可用、需改写、不支持；不支持的给出替代写法建议。拿不准的项单独标注。」
常见问题
- 用 Responses 格式调用，价格有变化吗？计费按模型与用量走，与请求格式无关；峰谷定价照常生效，账单口径见峰谷与选档一篇。
- 老程序需要迁移到 Responses 格式吗？不需要——原对话格式继续支持，迁移只发生在「要接讲这套协议的工具」时。
- 三档思考强度在这套格式里能用吗？能——思考档位是模型侧能力，按官方文档在请求中设置即可，选法见三档思考强度怎么选。
信息来源
- DeepSeek 官方更新日志（api-docs.deepseek.com/zh-cn/updates，核对时间 2026-11-02）：原生支持 Responses API、针对 Codex 适配、一键配置脚本；
- DeepSeek 官方 Responses API 指南：实现范围与支持清单，以官方当前版本为准；
- 站内条目：DeepSeek接口（工具页）、Codex 配置、API 报错对照。
