从 OpenAI 兼容到 Anthropic 崛起：大模型“交错思考”协议的演进与变局

曾几何时，大模型开发者的世界是单纯而美好的。无论是 OpenAI、Claude，还是后来的 DeepSeek、Moonshot等，大家都在讲同一种语言——OpenAI Chat Completions API。

那时候，我们只需要换一下 base_url 和 api_key，把之前的聊天历史（User/Assistant/Tool消息）一股脑传进去，就能无缝切换模型。工具调用（Function Calling）虽然各家微有差异，但本质逻辑也是通用的。

然而，随着“推理模型”（Reasoning Models）的爆发，这座巴别塔开始摇摇欲坠。特别是当我们需要让 Agent 进行多步工具调用（Multi-turn Tool Use）时，一个核心问题浮出水面：模型之前的“思考过程”，到底要不要传回去？如果传，怎么传？

这就是各大厂商正在混战的焦点——交错思考（Interleaved Thinking）。

为什么我们需要“交错思考”？

在 DeepSeek R1 刚出来的时候，官方文档有一句不起眼的建议：“在多轮对话中，建议舍弃 reasoning_content（思维链内容）。” https://api-docs.deepseek.com/zh-cn/guides/thinking_mode

对于简单的问答，这没问题。但对于 Agent 来说，这是致命的。这里有两个核心理由，一个是显而易见的“智商”问题，另一个则是反直觉的“成本”问题。

1. 拒绝“失忆”：让模型记住决策路径

试想一个复杂的编程任务，模型在第一步通过思维链（CoT）决定了代码架构，并调用了 read_file 工具。如果我们在第二轮对话中把这个思维链丢弃了，模型就像“失忆”了一样，它只看到了自己发出的 read_file 命令，却忘记了“为什么要这么做”以及“原本计划下一步做什么”。结果就是模型被迫重新推理，甚至做出与上一步逻辑相悖的决策。

2. 意想不到的经济账：Prompt Cache 的魔法

很多人直觉上认为：回传思维链会增加 Input Token 的数量，肯定更贵、更慢。
大错特错。

在支持 Prompt Cache（提示词缓存）的计费体系下（如 DeepSeek、Anthropic 等），缓存命中的 Token 价格通常仅为未命中的 1/10 甚至更低。
思维链（Reasoning）通常位于工具调用（Tool Call）的前面。如果我们完整回传“User -> Reasoning -> Tool Call”，这整个序列作为“上文前缀”，极易触发 Prompt Cache 命中。

这意味着：回传思维链，虽然 Token 变多了，但因为缓存命中率大幅提升，实际推理速度反而更快，综合成本反而更低！ 反之，如果你为了省 Token 删掉了思维链，模型可能因为上下文断裂而不得不输出更多的 Output Token 来“找补”逻辑，那才是真正的昂贵。

混乱的演进史：各家厂商的“补丁”与“创新”

为了实现这一目标，各大厂商的 API 协议分裂成了“战国七雄”。回顾 2025 年，我们可以清晰地看到这场协议演进的时间线。

1. Anthropic 的“降维打击”：Messages API 的原生引领

当整个行业还在摸索如何处理推理模型的思维链时，Anthropic 在 2025 年 2 月发布的 Claude 3.7 Sonnet 中，率先展示了什么是“原生支持”的交错思考。

在 Anthropic 的 Messages API 中，思维链不再是附属品，而是 extended thinking 协议的核心。它强制要求回传思维链，并且引入了 signature 字段进行防篡改签名。

这种设计非常清晰、严谨。以至于后来的 MiniMax 和 DeepSeek V3.2 甚至在其官方文档中宣布支持 Anthropic Messages API 格式。这从侧面证明了该协议在设计上的优越性——它是目前做 Agent 对话和多步工具调用体验最好的协议，简单、纯粹，是名副其实的先驱。

2. OpenAI 与 Google：封闭与曲高和寡的跟随

面对 Anthropic 的先发优势，老牌霸主们的反应显得有些迟缓和复杂。

OpenAI 直到 2025 年 3 月才推出 Responses API，允许通过 include: reasoning.encrypted_content 回传加密的思维链。这种协议结构复杂，与原有的 Chat Completions 差异巨大，导致生态响应寥寥。

Google Gemini 则在 2025 年 11 月走向了另一条路。它坚定地支持了思维链回传，但它非常“高冷”——这一功能仅在 Gemini 原生 API 中提供。如果你使用的是 Google 提供的 OpenAI 兼容接口，抱歉，不支持补丁，无法回传。这种“曲高和寡”的策略，使得想用一套代码兼容所有模型的开发者必须单独为 Gemini 写一套适配逻辑。

3. MiniMax M2：从标签视觉到协议补丁

到了 2025 年下半年，国产厂商开始尝试用更直接的方式解决问题。

2025 年 10 月发布的 MiniMax M2 借鉴了 DeepSeek R1 早期的视觉标签概念，并将其强化为一种交错思考协议。它允许模型通过 <think> 标签输出思考过程，并要求用户在下一轮对话中将这些 <think> 内容按原样回传（Interleaved）。虽然也支持拆分字段，但其核心逻辑是在现有文本流中嵌入标签。这相当于给 Chat Completions API 打了一个“文本级”的补丁，虽然解决了问题，但处理字符串解析总是显得不够优雅。

4. DeepSeek V3.2 的突破：完美的 API 补丁

而在 2025 年年底，DeepSeek V3.2 的出现为这场混战带来了新的曙光。

在 2025 年 12 月的更新中，它没有破坏 Chat Completions API 的基本结构，而是允许在输入端（Messages 数组）中直接包含 reasoning_content 字段。

这是一个极其聪明的“协议级补丁”。输入和输出字段高度一致，对现有生态侵入性最小。我认为，DeepSeek 的这种“增强版 Chat Completions”方案，是最有希望在未来重新统一 Chat API 江湖的路径之一。

大模型“交错思考”演进时间线

为了更直观地看清这场混战，我整理了各大模型支持交错思考的关键时间点：

时间	模型/事件	协议/特征	评价
2025.01	DeepSeek R1	输出 reasoning_content	确立了思维链字段标准，引入 <think> 视觉概念，但当时未标准化回传机制。
2025.02	Claude 3.7	Messages API (Extended Thinking)	SOTA 级设计。必须回传，带签名防篡改。设计最优雅，被多家厂商兼容。
2025.03	OpenAI	Responses API	支持回传加密思维链。协议太重，生态响应冷淡。
2025.10	MiniMax M2	标签包裹 / 原样回传	要求回传 <think> 内容。虽有效，但解析标签增加了协议复杂度。
2025.11	Gemini 3.0 Pro	原生 API 支持	功能很强，但仅限原生 API。OpenAI 兼容接口不支持回传，导致集成成本极高（曲高和寡）。
2025.12	DeepSeek V3.2	增强版 Chat Completions	允许输入端包含 reasoning_content。最具潜力的通用方案，兼顾了兼容性与功能性。
2025.12	GitHub Copilot	v1.107 更新	终于支持通过改造后的 Chat API 回传 reasoning content，体感大幅提升。

变局：开发者该何去何从？

我们现在正处在一个“变局”之中。

一方面，Anthropic Messages API 凭借其优雅的设计，正在成为高端 Agent 开发的首选，甚至引发了其他厂商的兼容；另一方面，DeepSeek V3.2 推出的“增强版 Chat Completions”方案，凭借对旧生态的极致兼容，极有可能成为事实上的工业标准。

而最尴尬的，反而是原本的霸主 OpenAI，以及不得不切回原生 SDK 的 Google Gemini。

作为开发者，我们不想陷入这种协议的泥潭。我们需要的是：写一套代码，接入所有模型，并且都能拥有完美的“交错思考”体验，同时还能吃到 Prompt Cache 的红利。

这正是我开发 Sdcb Chats 的初衷。

在最新的 1.9.0 版本中，我重点解决了这个问题：

1. 统一网关：无论底层是 OpenAI、DeepSeek 还是 Gemini，Sdcb Chats 都能帮你屏蔽差异。
2. 拥抱先进协议：全面支持 Anthropic Messages API 协议格式。你可以用 Claude 的原生体验来调用 DeepSeek V3.2 或 MiniMax，享受一致的思维链回传和防篡改机制。
3. 自动适配：对于支持“增强版 Chat Completions”的模型，网关会自动处理字段映射，你只需关注业务逻辑。

协议的战争可能还会持续很久，但你的代码不应该为此买单。

如果你也受够了写 if (model == "deepseek")，欢迎来试用 Sdcb Chats，让我们一起以不变应万变。

👉 项目地址： https://github.com/sdcb/chats