曾几何时，大模型开发者的世界是单纯而美好的。无论是 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 来说，这是致命的。这里有两个核心理由，一个是显而易见的“智商”问题，另一个则是反直觉的“成本”问题。
试想一个复杂的编程任务，模型在第一步通过思维链（CoT）决定了代码架构，并调用了 read_file 工具。如果我们在第二轮对话中把这个思维链丢弃了，模型就像“失忆”了一样，它只看到了自己发出的 read_file 命令，却忘记了“为什么要这么做”以及“原本计划下一步做什么”。结果就是模型被迫重新推理，甚至做出与上一步逻辑相悖的决策。
很多人直觉上认为：回传思维链会增加 Input Token 的数量，肯定更贵、更慢。
大错特错。
在支持 Prompt Cache（提示词缓存）的计费体系下（如 DeepSeek、Anthropic 等），缓存命中的 Token 价格通常仅为未命中的 1/10 甚至更低。
思维链（Reasoning）通常位于工具调用（Tool Call）的前面。如果我们完整回传“User -> Reasoning -> Tool Call”，这整个序列作为“上文前缀”，极易触发 Prompt Cache 命中。
这意味着：回传思维链，虽然 Token 变多了，但因为缓存命中率大幅提升，实际推理速度反而更快，综合成本反而更低！ 反之，如果你为了省 Token 删掉了思维链，模型可能因为上下文断裂而不得不输出更多的 Output Token 来“找补”逻辑，那才是真正的昂贵。
为了实现这一目标，各大厂商的 API 协议分裂成了“战国七雄”。回顾 2025 年，我们可以清晰地看到这场协议演进的时间线。
当整个行业还在摸索如何处理推理模型的思维链时，Anthropic 在 2025 年 2 月发布的 Claude 3.7 Sonnet 中，率先展示了什么是“原生支持”的交错思考。
在 Anthropic 的 Messages API 中，思维链不再是附属品，而是 extended thinking 协议的核心。它强制要求回传思维链，并且引入了 signature 字段进行防篡改签名。
这种设计非常清晰、严谨。以至于后来的 MiniMax 和 DeepSeek V3.2 甚至在其官方文档中宣布支持 Anthropic Messages API 格式。这从侧面证明了该协议在设计上的优越性——它是目前做 Agent 对话和多步工具调用体验最好的协议，简单、纯粹，是名副其实的先驱。
面对 Anthropic 的先发优势，老牌霸主们的反应显得有些迟缓和复杂。
OpenAI 直到 2025 年 3 月才推出 Responses API，允许通过 include: reasoning.encrypted_content 回传加密的思维链。这种协议结构复杂，与原有的 Chat Completions 差异巨大，导致生态响应寥寥。
Google Gemini 则在 2025 年 11 月走向了另一条路。它坚定地支持了思维链回传，但它非常“高冷”——这一功能仅在 Gemini 原生 API 中提供。如果你使用的是 Google 提供的 OpenAI 兼容接口，抱歉，不支持补丁，无法回传。这种“曲高和寡”的策略，使得想用一套代码兼容所有模型的开发者必须单独为 Gemini 写一套适配逻辑。
到了 2025 年下半年，国产厂商开始尝试用更直接的方式解决问题。
2025 年 10 月发布的 MiniMax M2 借鉴了 DeepSeek R1 早期的视觉标签概念，并将其强化为一种交错思考协议。它允许模型通过 <think> 标签输出思考过程，并要求用户在下一轮对话中将这些 <think> 内容按原样回传（Interleaved）。虽然也支持拆分字段，但其核心逻辑是在现有文本流中嵌入标签。这相当于给 Chat Completions API 打了一个“文本级”的补丁，虽然解决了问题，但处理字符串解析总是显得不够优雅。
而在 2025 年年底，DeepSeek V3.2 的出现为这场混战带来了新的曙光。
在 2025 年 12 月的更新中，它没有破坏 Chat Completions API 的基本结构，而是允许在输入端（Messages 数组）中直接包含 reasoning_content 字段。
这是一个极其聪明的“协议级补丁”。输入和输出字段高度一致，对现有生态侵入性最小。我认为，DeepSeek 的这种“增强版 Chat Completions”方案，是最有希望在未来重新统一 Chat API 江湖的路径之一。
为了更直观地看清这场混战，我整理了各大模型支持交错思考的关键时间点：
| 时间 | 模型/事件 | 协议/特征 | 评价 |
|---|---|---|---|
我们现在正处在一个“变局”之中。
一方面，Anthropic Messages API 凭借其优雅的设计，正在成为高端 Agent 开发的首选，甚至引发了其他厂商的兼容；另一方面，DeepSeek V3.2 推出的“增强版 Chat Completions”方案，凭借对旧生态的极致兼容，极有可能成为事实上的工业标准。
而最尴尬的，反而是原本的霸主 OpenAI，以及不得不切回原生 SDK 的 Google Gemini。
作为开发者，我们不想陷入这种协议的泥潭。我们需要的是：写一套代码，接入所有模型，并且都能拥有完美的“交错思考”体验，同时还能吃到 Prompt Cache 的红利。
这正是我开发 Sdcb Chats 的初衷。
在最新的 1.9.0 版本中，我重点解决了这个问题：
协议的战争可能还会持续很久，但你的代码不应该为此买单。
如果你也受够了写 if (model == "deepseek")，欢迎来试用 Sdcb Chats，让我们一起以不变应万变。
👉 项目地址： https://github.com/sdcb/chats
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。