DeepSeek兼容 Anthropic API

早期大模型服务商为了降低开发者的迁移成本，基本都照搬了 OpenAI 的 /v1/chat/completions 接口。到了 Agent 阶段，OpenAI 开始主推有状态的 /v1/responses（Responses API），试图把会话状态和工具执行都收拢到云端；DeepSeek 却没有跟进这套接口，反而上线了兼容 Anthropic Messages API 的端点（/anthropic）。

为什么不跟进 /v1/responses

很多人以为 Responses API 只是换了个路径的 Chat Completions，其实两者的工程边界差得很远。Chat Completions 是无状态的文本生成接口，客户端自己维护对话历史，每次请求把完整的 messages 数组发过去。在这套模式下，模型服务商只管推理计算，后台结构简单，可以通过前缀缓存（Prompt Cache）拿到很高的命中率，把推理成本压到最低。

OpenAI 的 Responses API 则是带状态的 Agent 运行时协议。它在云端维护 Thread 和 Session，客户端只传一个 previous_response_id 就能续上历史上下文；同时它还内置了托管工具（Hosted Tools），模型决定调代码解释器或网页搜索时，代码执行和检索动作直接在 OpenAI 云端的隔离沙箱里跑完，循环多次后再把最终结果返回给客户端。

DeepSeek 如果去兼容 Responses API，就得从单纯的算力服务商往云端托管平台跨一步：后端不仅要维护分布式会话存储，还要在服务端起大量隔离容器去跑用户代码。这跟 DeepSeek 轻量、高吞吐、低成本的路线完全冲突。而且由于没有 OpenAI 那套云端工具环境，即便强行把接口格式对齐，依赖云端沙箱的 Agent 也跑不起来。

切入 Claude Code 的开发者生态

相比之下，兼容 Anthropic 接口的账要好算得多，目标也很直接：接入以 Claude Code 为代表的编程 Agent 工具链。

Claude Code 把终端里的自主编程体验做得很成熟，但协议上绑定了自家的 Messages API。长任务跑下来，Claude 的账单非常贵，很多开发者都希望能换用便宜一个量级、推理和写代码能力也够用的国产模型。

Anthropic 的 Messages API 本质上仍然是无状态消息协议。DeepSeek 只需要在网关层做一层很薄的格式转换（Schema Translation），把请求里的模型名映射到自家的模型上，开发者改一下 ANTHROPIC_BASE_URL 和 ANTHROPIC_AUTH_TOKEN 两个环境变量，就能直接拿 DeepSeek 作 Claude Code 的后端。开发成本极低，却能直接把最活跃的一批重度 Agent 用户接进来。

状态外置与推理结构匹配

这两条接口路线也对应了两种不同的生态分工。OpenAI 的 Responses API 把状态、记忆和工具执行都绑在自己的云端基础设施上，一旦业务代码依赖了这套托管能力，后续很难迁走。Anthropic 则通过 MCP（Model Context Protocol）把工具执行和数据接入留在客户端本地或第三方服务，模型只负责理解上下文和分发调用指令。工具在客户端跑、模型在云端算，这种解耦方式正好契合 DeepSeek 只做算力供给的定位。

在协议结构上，Anthropic 的 Messages API 也更适合 DeepSeek-R1 这类推理模型。R1 在输出时包含长段的思考过程和多次工具调用，Anthropic 的协议本身就把 thinking、tool_use 和 tool_result 设计成了线性的内容块数组，表达多轮思考与工具交互比传统的 Chat Completions 自然得多，又不像 Responses API 那样笨重。用一层轻量的兼容接口同时接住 OpenAI 和 Anthropic 两边的客户端生态，对 DeepSeek 来说是性价比最高的选择。