【DeepSeek 论文精读】15. DeepSeek-V3.2：开拓开源大型语言模型新前沿

欢迎关注[【AIGC论文精读】](https://blog.csdn.net/youcans/category_12321605.html）原创作品
【DeepSeek论文精读】1. 从 DeepSeek LLM 到 DeepSeek R1
【DeepSeek论文精读】14. DeepSeek-V3.2-Exp 技术报告详解
 【DeepSeek论文精读】15. DeepSeek-V3.2：开拓开源大型语言模型新前沿

【DeepSeek 论文精读】15. DeepSeek-V3.2：开拓开源大型语言模型新前沿

- [0. DeepSeek-V3.2 模型发布](#0. DeepSeek-V3.2 模型发布)
- - [0.1 技术特性](#0.1 技术特性)
  - [0.2 开源地址](#0.2 开源地址)
  - [0.3 摘要](#0.3 摘要)
- [1. 引言](#1. 引言)
- [2. DeepSeek-V3.2 架构](#2. DeepSeek-V3.2 架构)
- - [2.1. DeepSeek 稀疏注意力机制 (DSA)](#2.1. DeepSeek 稀疏注意力机制 (DSA))
  - - [2.1.1 持续预训练](#2.1.1 持续预训练)
  - [2.2 性能评估](#2.2 性能评估)
  - [2.3. 推理成本](#2.3. 推理成本)
- [3. 训练后优化](#3. 训练后优化)
- - [3.1 扩展GRPO](#3.1 扩展GRPO)
  - [3.2 工具使用中的思考机制](#3.2 工具使用中的思考机制)
  - - [3.2.1 思维上下文管理](#3.2.1 思维上下文管理)
    - [3.2.2 冷启动阶段](#3.2.2 冷启动阶段)
- [4. 评估](#4. 评估)
- - [4.1 主要结果](#4.1 主要结果)
  - [4.2 DeepSeek-V3.2-Speciale 的评估结果](#4.2 DeepSeek-V3.2-Speciale 的评估结果)
  - [4.3 合成智能体任务](#4.3 合成智能体任务)
  - [4.4 搜索智能体的上下文管理](#4.4 搜索智能体的上下文管理)
- [5. 结论、局限性及未来工作](#5. 结论、局限性及未来工作)
- [6. 附录](#6. 附录)
- - [附录A. MLA 的 MHA 和 MQA模式](#附录A. MLA 的 MHA 和 MQA模式)
  - [附录B. 冷启动模板](#附录B. 冷启动模板)
  - [附录C. 非思考型DeepSeek-V3.2 自主评估](#附录C. 非思考型DeepSeek-V3.2 自主评估)
  - [附录D. IOI、ICPC全球总决赛、IMO及CMO评估方法](#附录D. IOI、ICPC全球总决赛、IMO及CMO评估方法)
  - 附录：聊天模板
- [7. API 使用指南](#7. API 使用指南)
- - [7.1 思考模式 (Thinking Mode)](#7.1 思考模式 (Thinking Mode))

0. DeepSeek-V3.2 模型发布

DeepSeek 于 2025年12月发布了 DeepSeek-V3.2 和 DeepSeek-V3.2-Speciale 模型。

官方网页端、App 和 API 均已更新为正式版 DeepSeek-V3.2，欢迎使用。Speciale 版本目前仅以临时 API 服务形式开放，以供社区评测与研究。

新模型技术报告已同步发布：DeepSeek-V3.2：开拓开源大型语言模型新前沿

0.1 技术特性

推理能力全球领先

DeepSeek-V3.2 的目标是平衡推理能力与输出长度，适合日常使用，例如问答场景和通用 Agent 任务场景。

在公开的推理类 Benchmark 测试中，DeepSeek-V3.2 达到了 GPT-5 的水平，仅略低于 Gemini-3.0-Pro；相比 Kimi-K2-Thinking，V3.2 的输出长度大幅降低，显著减少了计算开销与用户等待时间。
DeepSeek-V3.2-Speciale 的目标是将开源模型的推理能力推向极致，探索模型能力的边界。

V3.2-Speciale 是 DeepSeek-V3.2 的长思考增强版，同时结合了 DeepSeek-Math-V2 的定理证明能力。该模型具备出色的指令跟随、严谨的数学证明与逻辑验证能力，在主流推理基准测试上的性能表现媲美 Gemini-3.0-Pro（见下表）。更令人瞩目的是，V3.2-Speciale 模型成功斩获 IMO 2025（国际数学奥林匹克）、CMO 2025（中国数学奥林匹克）、ICPC World Finals 2025（国际大学生程序设计竞赛全球总决赛）及 IOI 2025（国际信息学奥林匹克）金牌。其中，ICPC 与 IOI 成绩分别达到了人类选手第二名与第十名的水平。

Tips：在高度复杂任务上，Speciale 模型大幅优于标准版本，但消耗的 Tokens 也显著更多，成本更高。目前，DeepSeek-V3.2-Speciale 仅供研究使用，不支持工具调用，暂未针对日常对话与写作任务进行专项优化。

思考融入工具调用

不同于过往版本在思考模式下无法调用工具的局限，DeepSeek-V3.2 是我们推出的首个将思考融入工具使用的模型，并且同时支持思考模式与非思考模式的工具调用。我们提出了一种大规模 Agent 训练数据合成方法，构造了大量「难解答，易验证」的强化学习任务（1800+ 环境，85,000+ 复杂指令），大幅提高了模型的泛化能力。
DeepSeek-V3.2 模型在智能体评测中达到了当前开源模型的最高水平，大幅缩小了开源模型与闭源模型的差距。值得说明的是，V3.2 并没有针对这些测试集的工具进行特殊训练，所以我们相信，V3.2 在真实应用场景中能够展现出较强的泛化性。

图1 | DeepSeek-V3.2及其对应版本的基准测试。对于HMMT 2025，我们报告了二月竞赛的结果，与基线一致。对于HLE，我们报告了仅文本子集。

0.2 开源地址

官方应用：你可以直接通过官方App、网页端或小程序体验DeepSeek-V3.2-Exp模型。

DeepSeek-V3.2 是我们当前正式提供服务的模型，官网网页、APP、API 模型均已由 DeepSeek-V3.2-Exp 升级为正式版 DeepSeek-V3.2，使用方式不变。
开源模型：模型已在Hugging Face和ModelScope（魔搭）等平台全面开源，方便开发者进行深入研究、部署和二次开发。
DeepSeek-V3.2： HuggingFace-DeepSeek-V3.2， ModelScope-DeepSeek-V3.2
DeepSeek-V3.2-Speciale： HuggingFace-DeepSeek-V3.2-Speciale，ModelScope-DeepSeek-V3.2-Speciale

为了方便社区评测与研究，我们非正式部署了 DeepSeek-V3.2-Speciale 的 API 服务，API 用户可以通过设置 base_url="https://api.deepseek.com/v3.2_speciale_expires_on_20251215" 访问该模型。该模型 API 价格不变，只支持思考模式下的对话功能，不支持工具调用等功能，最大输出长度默认为 128K，支持时间截止至北京时间 2025-12-15 23:59。

DeepSeek-V3.2 技术报告： DeepSeek-V3.2

如何本地运行

DeepSeek-V3.2 和 DeepSeek-V3.2-Speciale 的模型结构与 DeepSeek-V3.2-Exp 相同。有关本地运行该模型的更多信息，请访问 DeepSeek-V3.2-Exp 仓库。youcans, XIDIAN

0.3 摘要

我们推出 DeepSeek-V3.2，这是一个在高效计算与卓越推理及智能体性能之间取得平衡的模型。其关键技术突破包括：

（1）DeepSeek 稀疏注意力机制（DSA）：我们提出一种高效注意力机制，在长上下文场景中显著降低计算复杂度的同时保持模型性能。

（2）可扩展强化学习框架：通过实施稳健的强化学习协议并扩展训练后计算规模，DeepSeek-V3.2 性能可比肩 GPT-5。值得注意的是，我们的高计算变体 DeepSeek-V3.2-Speciale 已超越 GPT-5，其推理能力与 Gemini-3.0-Pro 相当，在 2025 年国际数学奥林匹克竞赛与国际信息学奥林匹克竞赛中均斩获金牌级表现。

（3）大规模代理任务合成管道：为了将推理融入工具使用场景，我们开发了一种新颖的合成管道，系统地生成大规模训练数据。这促进了可扩展的代理后训练，提高了在复杂交互环境中的合规性和泛化能力。

youcans, XIDIAN

1. 引言

推理模型的发布（DeepSeek-AI, 2025; OpenAI, 2024a）标志着大型语言模型（LLMs）演进的一个关键时刻，推动着在多个可验证领域的整体性能实现了巨大飞跃。自这一里程碑之后，LLMs 的能力迅速发展。然而，过去几个月出现了一种显著的分化。尽管开源社区（MiniMax, 2025; MoonShot, 2025; ZhiPu-AI, 2025）持续取得进展，但闭源专有模型（Anthropic, 2025b; DeepMind, 2025a; OpenAI, 2025）的性能提升轨迹却以明显更快的速度加速。因此，闭源与开源模型之间的性能差距非但没有缩小，反而似乎在扩大，专有系统在复杂任务中表现出越来越卓越的能力。

通过我们的分析，我们发现了限制开源模型在复杂任务中能力的三个关键不足。首先，在架构上，对原始注意力机制（Vaswani 等人，2017）的过度依赖严重限制了长序列的处理效率。这种低效性对可扩展部署和有效的训练后优化都构成了重大障碍。其次，在资源分配方面，开源模型在训练后阶段存在计算投入不足的问题，限制了它们在困难任务上的表现。最后，在AI智能体语境下，与专有模型相比，开源模型在泛化能力和指令遵循能力方面存在显著滞后（EvalSys, 2025; Li 等人, 2025; Luo 等人, 2025），阻碍了其在实际部署中的有效性。

为了应对这些关键限制，我们首先引入了 DSA，这是一种旨在显著降低计算复杂性的高效注意力机制。该架构有效解决了效率瓶颈，即使在长上下文场景下也能保持模型性能。其次，我们开发了一个稳定且可扩展的强化学习协议，该协议允许在训练后阶段进行大规模的计算扩展。值得注意的是，该框架分配的训练后计算预算超过了预训练成本的 10%，从而解锁了高级能力。第三，我们提出了一种新的流程，以促进工具使用场景中的可泛化推理。首先，我们利用 DeepSeek-V3（DeepSeek-AI，2024）方法实施冷启动阶段，将推理和工具使用统一在单次轨迹中。随后，我们推进到大规模的智能体任务合成，生成了超过 1800 个不同的环境和 85，000 个复杂的提示。这些广泛的合成数据驱动了强化学习过程，显著增强了模型在智能体场景中的泛化能力和指令遵循能力。

DeepSeek-V3.2 在多个推理基准测试中，与 Kimi-k2-thinking 和 GPT-5 达到了相近的性能。此外，DeepSeek-V3.2 显著提升了开源模型的智能体能力，在 EvalSys (2025)、Li 等人 (2025)、Luo 等人 (2025) 引入的长尾智能体任务上表现出卓越的熟练度。DeepSeek-V3.2 成为了智能体场景中极具成本效益的替代方案，在显著降低成本的同時，大大缩小了开源模型与前沿专有模型之间的性能差距。

值得注意的是，为了推动开源模型在推理领域的边界，我们放宽了长度限制以开发 DeepSeek-V3.2-Speciale。因此，DeepSeek-V3.2-Speciale 与领先的闭源系统 Gemini-3.0-Pro（DeepMind，2025b）实现了性能持平。它在 IOI 2025、ICPC World Final 2025、IMO 2025 和 CMO 2025 中均展现出金牌级别的表现。

2. DeepSeek-V3.2 架构

2.1. DeepSeek 稀疏注意力机制 (DSA)

DeepSeek-V3.2 采用与 DeepSeek-V3.2-Exp 完全相同的架构。相较于 DeepSeek-V3.1 系列最终版本 DeepSeek-V3.1-Terminus，DeepSeek-V3.2 在架构上的唯一改动是通过持续训练引入了 DeepSeek 稀疏注意力机制。

DSA 的原型设计

DSA 的原型主要由两个组件构成：一个闪电索引器和一个细粒度令牌选择机制。

闪电索引器用于计算查询令牌 h t ∈ R d h_t ∈ ℝ^d ht∈Rd 与前序令牌 h s ∈ R d h_s ∈ ℝ^d hs∈Rd 之间的索引分数 I t , s I_{t,s} It,s，从而决定查询令牌应选择哪些令牌：

其中， H I H^I HI 表示索引器的头数； q t , j I ∈ R d I q^I_{t,j} ∈ ℝ^{dI} qt,jI∈RdI和 w t , j I ∈ R w^I_{t,j} ∈ ℝ wt,jI∈R 来自查询令牌 h t h_t ht； k s I ∈ R d I k^I_s ∈ ℝ^{dI} ksI∈RdI 来自前序令牌 h s h_s hs。出于吞吐量考虑，我们选择 ReLU 作为激活函数。鉴于闪电索引器的头数较少且可使用 FP8 格式实现，其计算效率非常出色。

细粒度令牌选择机制在获得每个查询令牌 h t h_t ht 的索引分数 { I t , s } \{I_{t,s}\} {It,s}后，该机制仅检索与前 k 个索引分数对应的键值条目 { c s } \{c_s\} {cs}。然后，通过计算查询令牌 h t h_t ht 与稀疏选出的键值条目 { c s } \{c_s\} {cs} 之间的注意力，得到注意力输出 u t u_t ut：

基于 MLA 实现 DSA

考虑到需要从 DeepSeek-V3.1-Terminus 进行持续训练，我们为 DeepSeek-V3.2 基于 MLA (DeepSeek-AI, 2024) 实现了 DSA。在核心层面，为了计算效率，每个键值条目必须在多个查询间共享 (Yuan et al., 2025)。因此，我们基于 MLA 的 MQA 模式 (Shazeer, 2019) ¹ 实现了 DSA，其中每个潜向量（即 MLA 的键值条目）将在查询令牌的所有查询头之间共享。基于 MLA 的 DSA 架构如图 2 所示。我们还提供了 DeepSeek-V3.2² 的开源实现，以明确具体细节。
脚注：
¹ 我们在附录 A 中说明了 MLA 的 MQA 与 MHA 模式之间的区别。
² https://huggingface.co/deepseek-ai/DeepSeek-V3.2-Exp/tree/main/inference

图2 | DeepSeek-V3.2的注意力架构，其中DSA在MLA下实例化。绿色部分展示了DSA根据索引器选择前k个键值对的方式。

2.1.1 持续预训练

我们从一个上下文长度已扩展至 128K 的 DeepSeek-V3.1-Terminus 基础检查点开始，通过执行持续预训练，继而进行训练后优化，最终创建出 DeepSeek-V3.2。

DeepSeek-V3.2 的持续预训练包含两个阶段。这两个阶段所使用的训练数据分布，均与用于 DeepSeek-V3.1-Terminus 的 128K 长上下文扩展数据完全一致。

密集预热阶段。

我们首先使用一个短暂的预热阶段来初始化闪电索引器。在此阶段，我们保持使用密集注意力机制，并冻结除闪电索引器外的所有模型参数。为了使索引器输出与主注意力分布对齐，对于第 t t t个查询令牌，我们首先通过对所有注意力头的分数求和来聚合主注意力分数。然后在序列维度上进行 L 1 L1 L1 归一化，以产生目标分布 p t , : ∈ R t p_{t,:}∈R^t pt,:∈Rt。基于 p t , : p_{t,:} pt,: ，我们设置 KL 散度损失作为索引器的训练目标：

在预热阶段，我们使用 1 0 − 3 10^{-3} 10−3 的学习率。我们仅对索引器训练 1000 步，每一步包含 16 个长度为 128K 令牌的序列，总计消耗 21 亿个令牌。

稀疏训练阶段。

在索引器预热之后，我们引入细粒度令牌选择机制，并优化所有模型参数，使模型适应 DSA 的稀疏模式。在此阶段，我们继续保持索引器输出与主注意力分布的对齐，但仅考虑选中的令牌集合

值得注意的是，我们将索引器输入从计算图中分离出来以进行独立优化。索引器的训练信号仅来自 L I L_I LI ，而主模型的优化仅依据语言建模损失。在此稀疏训练阶段，我们使用 7.3 × 1 0 − 6 7.3×10^{−6} 7.3×10−6 的学习率，并为每个查询令牌选择 2048 个键值令牌。我们对主模型和索引器进行 15000 步训练，每一步包含 480 个长度为 128K 令牌的序列，总计消耗 9437 亿个令牌。

2.2 性能评估

标准基准测试 2025年9月，我们在涵盖多种能力的一系列基准测试上评估了 DeepSeek-V3.2-Exp，并将其与 DeepSeek-V3.1-Terminus 进行比较，结果显示性能相近。尽管 DeepSeek-V3.2-Exp 在长序列上显著提高了计算效率，但在短上下文和长上下文任务中，我们并未观察到其性能相较 DeepSeek-V3.1-Terminus 出现明显下降。

人类偏好评估鉴于直接的人类偏好评估天生容易受到偏见影响，我们采用 ChatbotArena 作为间接评估框架，以近似衡量用户对新开发基础模型的偏好。DeepSeek-V3.1-Terminus 和 DeepSeek-V3.2-Exp 采用完全相同的训练后策略，两者在2025年11月10日的评估中获得的 Elo 分数非常接近。这些结果表明，尽管引入了稀疏注意力机制，新基础模型的性能与上一代持平。

长上下文评估 DeepSeek-V3.2-Exp 发布后，多个独立研究使用先前未见过的测试集进行了长上下文评估。一个代表性基准是 AA-LCR³，其中 DeepSeek-V3.2-Exp 在推理模式下比 DeepSeek-V3.1-Terminus 高出四分。在 Fiction.liveBench 评估⁴ 中，DeepSeek-V3.2-Exp 在多个指标上持续超越 DeepSeek-V3.1-Terminus。这些证据表明，DeepSeek-V3.2-Exp 的基础检查点在长上下文任务上并未出现性能衰退。

2.3. 推理成本

DSA 将主模型的核心注意力复杂度从 O ( L 2 ) O(L^2) O(L2) 降低至 O ( L k ) O(Lk) O(Lk) ，其中 k ( ≪ L ) k(≪L) k(≪L)是所选令牌的数量。尽管闪电索引器仍具有 O ( L 2 ) O(L^2) O(L2) 的复杂度，但其计算量远小于 DeepSeek-V3.1-Terminus 中的 MLA。结合我们的优化实现，DSA 在长上下文场景中实现了显著的端到端加速。图3展示了 DeepSeek-V3.1-Terminus 和 DeepSeek-V3.2 的令牌成本如何随其在序列中的位置变化。这些成本是基于部署在 H800 GPU（租赁价格为每小时2美元）上的实际服务进行基准测试估算得出的。请注意，对于短序列预填充阶段，我们专门实现了一种掩码 MHA 模式来模拟 DSA，这可以在短上下文条件下实现更高的效率。

图3 | DeepSeek-V3.1-Terminus和DeepSeek-V3.2在H800集群上的推理成本。

3. 训练后优化

在完成持续预训练之后，我们执行训练后优化以创建最终的 DeepSeek-V3.2。DeepSeek-V3.2 的训练后优化阶段同样以与稀疏持续预训练阶段相同的方式采用稀疏注意力机制。对于 DeepSeek-V3.2，我们保持了与 DeepSeek-V3.2-Exp 相同的训练后流程，其中包括专家模型蒸馏和混合强化学习训练。

专家模型蒸馏

针对每项任务，我们首先开发专门致力于该特定领域的专用模型，所有专家模型均基于同一个预训练的DeepSeek-V3.2基础检查点进行微调。除了写作任务和通用问答外，我们的框架涵盖六个专业领域：数学、编程、通用逻辑推理、通用智能体任务、智能体编码和智能体搜索，所有领域均支持思维链和非思维链模式。每个专家模型都通过大规模强化学习计算进行训练。此外，我们采用不同模型来生成长思维链推理（思维链模式）和直接响应生成（非思维链模式）的训练数据。专家模型准备就绪后，用于为最终检查点生成领域特定数据。实验结果表明，在蒸馏数据上训练的模型达到的性能水平仅略低于领域特定专家模型，而通过后续的强化学习训练可以有效地消除这一性能差距。
混合强化学习训练

混合强化学习训练对于DeepSeek-V3.2，我们仍采用组相对策略优化（GRPO）（DeepSeek-AI, 2025; Shao等, 2024）作为强化学习训练算法。与DeepSeek-V3.2-Exp相同，我们将推理、智能体和人类对齐训练合并到一个强化学习阶段中。这种方法有效平衡了不同领域的性能，同时避免了多阶段训练范式常见的灾难性遗忘问题。对于推理和智能体任务，我们采用基于规则的结果奖励、长度惩罚和语言一致性奖励。对于通用任务，我们采用生成式奖励模型，每个提示都有其自己的评估标准。

DeepSeek-V3.2与DeepSeek-V3.2-Speciale DeepSeek-V3.2整合了从专家模型蒸馏得到的推理、智能体和人类对齐数据，经过数千步的持续强化学习训练达到最终检查点。为了探索扩展思维的潜力，我们还开发了一个实验变体DeepSeek-V3.2-Speciale。该模型仅在推理数据上进行训练，并在强化学习期间减少长度惩罚。此外，我们整合了DeepSeekMath-V2（Shao等, 2025）的数据集和奖励方法，以增强数学证明能力。

我们将在第3.1节重点介绍如何创建稳定的方法来扩展强化学习计算，在第3.2节介绍如何将思维链集成到智能体任务中。

3.1 扩展GRPO

我们首先回顾GRPO的目标。GRPO通过最大化以下目标函数来优化策略模型 π θ π_θ πθ，该目标函数基于从旧策略 π o l d π_{old} πold 中对每个问题 q q q 采样得到的一组响应 { 𝑜 1 , ... , 𝑜 G } \{𝑜_1, ..., 𝑜_G\} {o1,...,oG}：

其中：

是当前策略与旧策略之间的重要性采样比率。𝜀 和 𝛽是分别控制剪切范围和 KL 惩罚强度的超参数。 𝐴 𝑖 , 𝑡 ^ \hat{𝐴_{𝑖,𝑡}} Ai,t^ 是 𝑜 𝑖 , 𝑡 𝑜_{𝑖,𝑡} oi,t 的优势函数，通过对组内结果奖励进行归一化估计。具体而言，使用一组奖励模型对组中每个输出 𝑜 𝑖 𝑜_𝑖 oi 的结果奖励 𝑅 𝑖 𝑅_𝑖 Ri 进行评分，分别得到 𝐺 个奖励 𝑹 = {𝑅₁, ..., 𝑅𝐺}。 𝑜 𝑖 , 𝑡 𝑜_{𝑖,𝑡} oi,t 的优势通过从输出 𝑜 𝑖 𝑜_{𝑖} oi 的奖励中减去组的平均奖励来计算，即 𝐴 𝑖 , 𝑡 ^ = 𝑅 𝑖 − m e a n ( 𝑹 ) \hat{𝐴_{𝑖,𝑡}}= 𝑅𝑖 − mean(𝑹) Ai,t^=Ri−mean(R)。

接下来，我们概述在GRPO算法基础上，用于稳定RL扩展的额外策略。

无偏KL估计

给定 𝑜 𝑖 , 𝑡 𝑜_{𝑖,𝑡} oi,t 是从旧策略 π o l d ( ⋅ ∣ 𝑞 , 𝑜 𝑖 , < 𝑡 ) π_{old} (·|𝑞, 𝑜_{𝑖,<𝑡}) πold(⋅∣q,oi,<t) 采样的，我们修正 K3 估计量（Schulman, 2020），使用当前策略 π θ π_θ πθ与旧策略 π o l d π_{old} πold 之间的重要性采样比率来获得无偏 KL 估计：

此调整的直接结果是，该KL估计量的梯度变为无偏，从而消除了系统估计误差，促进了稳定收敛。这与原始的 K3 估计量形成鲜明对比，尤其是在采样令牌在当前策略下的概率远低于参考策略（即 π θ ≪ π r e f π_θ≪ π_{ref} πθ≪πref）的情况下。在此类情况下，K3 估计量的梯度会分配不成比例的大且无界的权重来最大化这些令牌的似然，导致噪声梯度更新，这些更新累积会降低后续迭代中的样本质量并导致训练动态不稳定。在实践中，我们发现不同领域受益于不同强度的 KL 正则化。对于某些领域（如数学），应用相对较弱的KL惩罚甚至完全忽略它可以提高性能。

离策略序列掩码

为了提高RL系统的效率，我们通常生成大批量的轨迹数据，随后将其分割成多个小批量用于若干梯度更新步骤。这种做法本质上引入了离策略行为。此外，用于高效数据生成的推理框架通常经过高度优化，其实现细节可能与训练框架不同。这种训练-推理不一致性进一步加剧了离策略程度。为了稳定训练并提高对离策略更新的容忍度，我们掩码那些引入显著策略差异的负序列，该差异由数据采样策略 π o l d π_{old} πold 与当前策略 π θ π_θ πθ 之间的KL散度度量。更具体地说，我们在GRPO损失中引入一个二元掩码 𝑀：

其中：

且 Font metrics not found for font: . 是控制策略差异阈值的超参数。请注意，此处的 π o l d π_{old} πold表示推理框架直接返回的采样概率，因此旧策略与当前策略之间的 KL 散度包含了上述两个离策略来源。同样值得注意的是，我们只掩码具有负优势的序列。直观上，模型通过从自身的错误中学习获益最多，而高度离策略的负样本可能是有害的，可能会误导或破坏优化过程的稳定性。我们通过实验观察到，这种离策略序列掩码操作在某些原本会表现出不稳定性的训练场景中提高了稳定性。

保持路由

混合专家（MoE）模型通过在推理期间仅激活专家模块的子集来提高计算效率。然而，推理与训练框架之间的差异，加上策略更新，可能导致即使是相同输入，在推理和训练期间的专家路由也不一致。这种不一致性会引起活跃参数子空间的突然变化，从而破坏优化的稳定性并加剧离策略问题。为了缓解这个问题，我们保留推理框架在采样期间使用的专家路由路径，并在训练期间强制执行相同的路由路径，确保优化相同的专家参数。我们发现，这种保持路由操作对于MoE模型的RL训练稳定性至关重要，并且自DeepSeek-V3-0324以来，已将其纳入我们的RL训练流程。

保持采样掩码

Top-p 和 top-k 采样是广泛用于提升 LLMs 生成响应质量的采样策略。在RL训练中采用这些策略也是有益的，因为它可以避免将极低概率的令牌作为优化目标进行采样。虽然这种截断保持了样本质量，但它引入了 π o l d π_{old} πold和 π θ π_θ πθ动作空间之间的不匹配，这违反了重要性采样的原则并破坏了训练稳定性。为了解决这个问题，我们在从 π o l d π_{old} πold采样期间保留截断掩码，并在训练期间将其应用于 π θ π_θ πθ，确保两个策略共享相同的动作子空间。根据经验，我们发现将 top-p 采样与保持采样掩码策略结合使用，能有效保持 RL 训练期间的语言一致性。

3.2 工具使用中的思考机制

3.2.1 思维上下文管理

DeepSeek-R1 已经证明，融入思考过程可以显著增强模型解决复杂问题的能力。基于这一见解，我们的目标是将思考能力整合到工具调用场景中。

我们观察到，复制 DeepSeek-R1 的策略------即在收到第二轮消息时丢弃推理内容------会导致显著的令牌效率低下。这种方法迫使模型为每个后续的工具调用对整个问题进行冗余的重新推理。为了缓解这个问题，我们开发了一种严格为工具调用场景定制的上下文管理机制，如图4所示：

仅当对话中引入新的用户消息时，历史的推理内容才会被丢弃。如果只追加与工具相关的消息（例如，工具输出），则推理内容将在整个交互过程中保留。
当移除推理轨迹时，工具调用的历史及其结果仍保留在上下文中。

值得注意的是，某些智能体框架（如 Roo Code 或 Terminus）通过用户消息来模拟工具交互。由于上述上下文管理规则，这些框架可能无法充分利用我们增强的推理持久性优势。因此，我们建议在此类架构中使用非思考模型以获得最佳性能。

图4 | 工具调用场景中的思考保留机制。

3.2.2 冷启动阶段

考虑到已有可用的推理数据（非智能体相关）和非推理的智能体数据，整合这两种能力的一个直接策略是通过精心设计的提示实现。

我们认为模型本身已具备足够的能力来准确遵循明确的指令，从而能够将工具执行无缝地融入到推理过程之中。

为了阐明冷启动机制的实际运作，我们选择性展示了附录表6-8中的训练数据示例。需要特别指出的是，不同的任务提示关联着不同的系统提示。表6-8以一道竞赛编程题目为例进行说明：表6展示了我们推理数据的实例，其系统提示明确要求模型在给出最终答案前进行思考，并使用特殊标签来标注推理路径；表7呈现了非推理智能体数据的提示示例，其中系统提示包含了工具调用的指引；表8则展示了我们设计的系统提示，用于指导模型在推理过程中整合多个工具调用。

通过这种方式，尽管工具使用场景中的推理模式可能尚未达到理想鲁棒性，但模型已能偶尔生成符合预期的轨迹，从而为后续强化学习阶段提供了必要基础。

3.2.3 大规模智能体任务

多样化的强化学习任务对提升模型鲁棒性至关重要。针对搜索、代码工程和代码解析等任务，我们采用真实环境工具，包括实际网页搜索API、编码工具及Jupyter Notebook等。虽然这些强化学习环境本身是真实的，但使用的提示词或源于网络抓取，或通过合成生成，而非来自真实用户交互。对于其他任务类型，环境与提示词均通过合成方式构建。我们所采用的智能体任务详见表1 所列。

搜索代理

我们采用基于 DeepSeek-V3.2 的多代理流水线，用于生成多样化、高质量的训练数据。首先，从大规模网络语料库中采样跨多个领域的高信息价值长尾实体。随后，问题构建代理通过配置了深度和广度参数的搜索工具对每个实体进行探索，并将发现的信息整合为问答对。多个具有异构配置（不同检查点、系统提示词等）的答案生成代理，为每个提出的问答对生成多样化的候选回复。具备搜索功能的验证代理通过多轮验证流程对所有答案进行校验，仅保留事实准确且所有候选回复均被证实为错误的样本。该数据集涵盖多种语言、多个领域及不同难度级别。为补充这些可验证样本并更好地反映真实场景应用，我们还从现有实用强化学习（RL）数据集中筛选实例扩充数据集 ------ 这些实例中，搜索工具可带来可量化的性能提升。最后，我们针对多个质量维度制定了详细的评估准则，并采用生成式奖励模型基于这些准则对回复进行评分。这种混合方法能够同时优化事实可靠性与实际实用性。

代码智能体

我们从GitHub挖掘了数百万个问题-拉取请求对，构建了用于软件问题修复的大规模可执行环境。该数据集通过启发式规则和基于LLM的判断进行了严格筛选，以确保高质量，要求每个条目包含合理的问题描述、相关联的黄金补丁以及用于验证的测试补丁。

我们使用了一个由DeepSeek-V3.2驱动的自动化环境设置智能体来为这些配对构建可执行环境。该智能体负责处理软件包安装、依赖项解析和测试执行。测试结果以标准的JUnit格式输出，确保了跨编程语言和测试框架的一致性解析。

仅当应用黄金补丁导致"假正例转为真正例"的测试用例数非零（表明问题已被修复），且"正例转为假反例"的测试用例数为零（表明没有引入回归问题）时，一个环境才被视为成功构建。

利用此流程，我们成功构建了数万个可复现的问题解决环境，涵盖多种编程语言，包括Python、Java、JavaScript、TypeScript、C、C++、Go和PHP。

代码解释器智能体

我们利用Jupyter Notebook作为代码解释器来处理复杂的推理任务。为此，我们精心策划了一套涵盖数学、逻辑和数据科学的多样化问题集，每个问题都需要模型利用代码执行能力来得出解决方案。

通用智能体

为了在强化学习中扩大智能体环境和任务的规模，我们采用了一个自动化环境合成智能体，合成了1,827个面向任务的环境。这些任务难以解决但易于验证。合成工作流程主要包括环境和工具集构建、任务合成以及解决方案生成。具体流程如下：

给定一个任务类别（例如，规划一次旅行行程）和一个配备bash工具和搜索工具的沙盒，智能体首先使用这些工具从互联网生成或检索相关数据，并将其存储在沙盒数据库中。
智能体随后合成一组特定于任务的工具，每个工具都以函数形式实现。
为了创建既具有挑战性又可自动验证的任务，智能体首先基于当前数据库提出一个简单任务，并提供其用Python实现的解决方案和验证函数。解决方案函数仅限于调用工具函数或执行逻辑计算，不能调用其他函数或直接访问数据库，确保任务只能通过工具接口解决。此外，解决方案函数产生的结果必须通过验证函数的验证。如果解决方案未通过验证，智能体将修改解决方案或验证函数，直到解决方案的输出通过验证。随后，智能体迭代地增加任务难度，并更新相应的解决方案和验证函数。在此迭代过程中，如果当前工具集不足以解决任务，智能体将扩展工具集。

遵循此工作流程，我们获得了数千个 <环境, 工具, 任务, 验证器> 元组。然后，我们使用DeepSeek-V3.2在此数据集上进行强化学习，并仅保留通过率（pass@100）非零的实例，最终得到1,827个环境及其对应的任务（总计4,417个）。下面展示了一个合成的旅行规划示例。此示例强调，虽然在大规模组合空间中搜索满足所有约束的旅行计划具有挑战性，但检查给定候选解决方案是否满足这些约束则相对直接。

4. 评估

4.1 主要结果

我们在以下多个基准上评估模型性能：MMLU-Pro（Wang等人，2024）、GPQA Diamond（Rein等人，2023）、仅文本的Human Last Exam（HLE）（Phan等人，2025）、LiveCodeBench（2024.08-2025.04）、Codeforces、Aider-Polyglot、AIME 2025、HMMT Feb 2025、HMMT Nov 2025（Balunović等人，2025）、IMOAnswerBench（Luong等人，2025）、Terminal Bench 2.0、SWE-Verified（OpenAI，2024b）、SWE Multilingual（Yang等人，2025）、BrowseComp（Wei等人，2025）、BrowseCompZh（Zhou等人，2025）、𝜏2-bench（Barres等人，2025）、MCP-Universe（Luo等人，2025）、MCP-Mark（EvalSys，2025）以及Tool-Decathlon（Li等人，2025）。

工具使用类基准采用标准函数调用格式进行评估，模型配置为思考模式。对于MCP-Universe（Luo等人，2025）和MCP-Mark（EvalSys，2025），我们使用内部环境评估所有模型，因为搜索和playwright环境可能与官方设置略有不同。我们将温度参数设置为1.0，上下文窗口设置为128K个标记。

对于数学相关任务，如AIME、HMMT、IMOAnswerBench和HLE，我们使用以下模板进行评估："{question}\nPlease reason step by step, and put your final answer within \boxed{}." 在HLE评估中，我们还使用官方模板评估了DeepSeek-V3.2-Thinking，其得分为23.9。

表2 | DeepSeek-V3.2与闭源/开源模型对比
对于开源模型，我们仅与支持工具使用中思考的模型进行比较。加粗数字代表每个模型类别（开源和闭源）内的最佳得分。𝜏2-Bench的结果通过计算每个类别的平均值得出。

DeepSeek-V3.2 在推理任务上与 GPT-5-high 达到相近性能，但略逊于 Gemini-3.0-Pro。与 K2-Thinking 相比，如表3所示，DeepSeek-V3.2 在显著减少输出令牌数量的情况下获得了可比得分。这些性能提升可归因于分配给强化学习训练的计算资源增加。近几个月来，我们观察到模型性能的持续改善与扩展的强化学习训练预算（目前已超过预训练成本的 10%）相关。我们推测，增加计算预算分配可以进一步增强推理能力。

值得注意的是，本文报告的 DeepSeek-V3.2 性能受到长度约束奖励模型的限制；在解除此限制后，我们观察到模型性能有进一步提升，详见第4.2节。

在代码智能体评估中，DeepSeek-V3.2 在 SWE-bench Verified 和 Terminal Bench 2.0 上均显著优于开源大语言模型，展现了其在真实世界编码工作流中的潜力。关于 Terminal Bench 2.0，如前所述，我们为"思考模式"设计的上下文管理策略目前与 Terminus 框架不兼容；因此，报告的 46.4 分是使用 Claude Code 框架达成的。我们也在非思考模式下使用 Terminus 框架评估了 DeepSeek-V3.2，得分为 39.3。对于 SWE-bench Verified，主要分数使用我们的内部框架获得。在其他设置（包括 Claude Code、RooCode 框架以及非思考模式）下进行的鲁棒性测试产生了一致的结果，分数在 72 至 74 之间。

在搜索智能体评估中，我们使用标准商业搜索 API 评估模型。由于 DeepSeek-V3.2 支持的最大上下文长度仅为 128K，约 20% 以上的测试用例超出了此限制。为解决此问题，我们采用了上下文管理方法来得出最终分数。作为参考，不使用上下文管理的分数为 51.4。更多细节见第4.4节。

在工具使用基准测试中，DeepSeek-V3.2 大幅缩小了开源与闭源大语言模型之间的性能差距，尽管仍低于前沿模型。对于 𝜏2-bench，我们采用模型本身作为用户代理，最终类别得分为：航空 63.8、零售 81.1、电信 96.2。对于 MCP 基准测试，我们采用函数调用格式，并将工具输出放置在指定为 'tool' 角色而非 'user' 角色的消息中。在测试中，我们观察到 DeepSeek-V3.2 频繁进行冗余的自我验证，生成了过长的轨迹。这种倾向常导致上下文长度超过 128K 的限制，特别是在 MCP-Mark GitHub 和 Playwright 评估等任务中。因此，这种现象阻碍了 DeepSeek-V3.2 的最终性能表现。然而，集成上下文管理策略可以进一步提升性能。我们将此视为未来工作的方向，并为用户提供实用参考。尽管存在此问题，DeepSeek-V3.2 的表现仍显著优于现有开源模型。值得注意的是，由于这些基准测试中使用的环境和工具集在强化学习训练中并未遇到过，观察到的改进证明了 DeepSeek-V3.2 将其推理策略泛化到领域外智能体场景的能力。智能体场景中非思考模型的评估见附录表9。

4.2 DeepSeek-V3.2-Speciale 的评估结果

如表3所示，DeepSeek-V3.2-Speciale 通过利用更多的推理令牌，实现了卓越的性能，在多个基准测试中超越了当前顶尖的 Gemini-3.0-Pro。值得注意的是，如表4所示，这一通用模型无需针对性训练，就在 2025 年国际信息学奥林匹克竞赛（IOI）和国际大学生程序设计竞赛全球总决赛（ICPC WF）中达到了金牌级别的表现。此外，通过融入 Shao 等人 (2025) 的技术，该模型在复杂的证明任务上表现优异，达到了 2025 年国际数学奥林匹克竞赛（IMO）和中国数学奥林匹克竞赛（CMO）的金牌水平阈值。详细的评估方案见附录 D。

然而，DeepSeek-V3.2-Speciale 的令牌效率仍显著低于 Gemini-3.0-Pro。为了降低部署成本和延迟，我们在官方 DeepSeek-V3.2 的训练中施加了更严格的令牌约束，旨在优化性能与成本之间的权衡。我们认为，令牌效率仍是未来研究的一个关键方向。

4.3 合成智能体任务

本节我们进行消融实验，以研究合成智能体任务的效果。我们主要关注两个问题：第一，合成任务对于强化学习是否足够具有挑战性？第二，这些合成任务的泛化能力如何，即它们能否迁移到不同的下游任务或现实环境中？

针对第一个问题，我们从通用合成智能体任务中随机抽取50个实例，并评估用于合成的模型以及前沿闭源大语言模型的表现。如表5所示，DeepSeek-V3.2-Exp 的准确率仅为12%，而前沿闭源模型的最高准确率也仅达到62%。这些结果表明，合成数据中包含的智能体任务对 DeepSeek-V3.2-Exp 和前沿闭源模型都构成了挑战。

为了研究在合成数据上进行强化学习能否泛化到不同的任务或真实环境，我们对 DeepSeek-V3.2 的有监督微调检查点（记为 DeepSeek-V3.2-SFT）应用了强化学习。为了排除长思维链和其他强化学习数据的影响，我们仅在非思考模式下对合成智能体任务进行了强化学习。随后，我们将该模型与 DeepSeek-V3.2-SFT 和 DeepSeek-V3.2-Exp（后者仅在搜索和代码环境中进行了强化学习训练）进行比较。

如图5所示，在Tau2Bench、MCP-Mark和MCP-Universe基准测试上，基于合成数据的大规模强化学习相比DeepSeek-V3.2-SFT带来了显著提升。相比之下，将强化学习限制在代码和搜索场景中并不能改善这些基准测试的性能，这进一步凸显了合成数据的潜力。

4.4 搜索智能体的上下文管理

即使拥有128K这样扩展的上下文窗口，智能体工作流（特别是在基于搜索的场景中）仍经常遇到最大长度限制，导致推理过程被过早截断。这一瓶颈阻碍了测试时计算潜力的充分发挥。为了解决这个问题，我们引入了上下文管理策略，当令牌使用量超过上下文窗口长度的80% 时，采用简单策略在测试时扩展令牌预算。这些策略包括：

摘要：总结溢出的轨迹并重新开始推理。
丢弃-75%：丢弃轨迹中前75%的工具调用历史以释放空间。
全部丢弃：通过丢弃所有先前的工具调用历史来重置上下文（类似于新的上下文工具 (Anthropic, 2025a)）。

作为对比，我们还实现了一个并行扩展基线Parallel-fewest-step，即采样N个独立轨迹并选择步骤最少的轨迹。

我们在BrowseComp基准测试（Wei等人，2025）上评估了这些策略。如图6所示，在不同的计算预算下，通过上下文管理使模型能够扩展测试时计算（为执行额外步骤提供更多空间），从而带来显著的性能提升。例如，摘要策略将平均步骤数从140步延长到364步，性能从53.4提升到60.2，但其总体效率相对较低。尽管全部丢弃策略很简单，但在效率和可扩展性方面都表现良好，达到了67.6分，与并行扩展方法相当，但使用的步骤数显著减少。

总之，测试时计算可以通过上下文管理进行串行扩展，也可以进行并行扩展，两者都能有效扩展模型的问题解决能力。然而，不同策略在效率和可扩展性上表现各异。因此，在对模型性能进行基准测试时，考虑实际计算成本至关重要。同时，寻找串行与并行扩展的最佳组合以最大化效率和可扩展性，仍是未来工作的一个关键方向。

图6 | 不同测试时计算扩展策略下Browsecomp的准确性。

5. 结论、局限性及未来工作

本研究介绍了 DeepSeek-V3.2，一个能有效弥合计算效率与高级推理能力之间差距的框架。通过采用DSA，我们在不牺牲长上下文性能的前提下，解决了关键的计算复杂度问题。通过增加计算预算，DeepSeek-V3.2 在推理基准测试上达到了与 GPT-5 相当的性能。最后，我们集成了大规模智能体任务合成流程，显著提升了工具使用能力，为基于开源大语言模型构建更鲁棒、更可泛化的AI智能体开启了新的可能性。此外，我们计算量更大的变体 DeepSeek-V3.2-Speciale，凭借在IMO和IOI中获得金牌级别表现得到验证，为开源大语言模型树立了一个里程碑。

尽管取得了这些成就，我们也认识到与 Gemini-3.0-Pro 等前沿闭源模型相比存在一些局限性。

首要局限是 DeepSeek-V3.2 所具备的世界知识的广度，仍落后于领先的专有模型。这是由于模型训练消耗的总浮点运算量较少。我们计划在未来的迭代中，通过扩大预训练计算规模来弥补这一知识差距。
其次，令牌效率仍然是一个挑战；DeepSeek-V3.2 通常需要更长的生成轨迹（即更多的令牌）才能匹配 Gemini-3.0-Pro 等模型的输出质量。未来的工作将专注于优化模型推理链的智能密度，以提高效率。
第三，在解决复杂任务方面，其能力仍不及前沿模型，这激励我们进一步改进基础模型和训练后流程。

6. 附录

附录A. MLA 的 MHA 和 MQA模式

对于DeepSeek-V3.1-Terminus，MHA模式用于训练和预填充，而MQA模式用于解码。图7展示了MLA的MHA和MQA模式及其之间的转换。

图7 | MLA的MHA和MQA模式的示例。

附录B. 冷启动模板

附录C. 非思考型DeepSeek-V3.2 自主评估

youcans, XIDIAN

附录D. IOI、ICPC全球总决赛、IMO及CMO评估方法

对于所有竞赛评估，模型的最大生成长度均设置为 128K 令牌。评估过程不使用任何工具或互联网访问，并严格遵守竞赛的时间与提交次数限制。

IOI评估方法：我们根据官方竞赛规则设计了提交策略，该规则允许每道题最多提交 50 次，并根据所有子任务中获得的最高分对每次提交进行评分。具体而言，我们首先为每道问题采样 500 个候选解决方案，然后应用一个多阶段筛选流程。在初始阶段，我们剔除了未能通过提供的样例测试用例或超出长度限制的无效提交。随后，我们使用 DeepSeek-V3.2-Exp 模型来识别并移除那些模型明确表示无法或拒绝解决问题的样本。从剩余的有效候选方案中，我们选择思考轨迹最长的 50 个样本进行最终提交。

ICPC评估方法：我们采用了相同的筛选方法，但初始采样规模较小。我们为每道问题生成 32 个候选解决方案，并应用相同的筛选标准来选择提交。

IMO与CMO评估方法：在这两项数学奥赛任务中，我们采用了生成-验证-精炼循环。模型会迭代地改进其解决方案，直至获得完美的自我评估分数或达到最大修订上限，此流程与 Shao 等人 (2025) 的研究中所描述的过程相同。

附录：聊天模板

DeepSeek-V3.2 在其聊天模板中相比之前的版本引入了重大更新。主要变化涉及工具调用格式的修订以及"使用工具思考"功能的引入。

为了帮助社区理解和适应这个新模板，我们提供了一个专门的 encoding 文件夹，其中包含 Python 脚本和测试用例，演示如何将 OpenAI 兼容格式的消息编码为模型的输入字符串，以及如何解析模型的文本输出。

下面是一个简短的例子：

python 复制代码

import transformers
# encoding/encoding_dsv32.py
from encoding_dsv32 import encode_messages, parse_message_from_completion_text

tokenizer = transformers.AutoTokenizer.from_pretrained("deepseek-ai/DeepSeek-V3.2")

messages = [
    {"role": "user", "content": "hello"},
    {"role": "assistant", "content": "Hello! I am DeepSeek.", "reasoning_content": "thinking..."},
    {"role": "user", "content": "1+1=?"}
]
encode_config = dict(thinking_mode="thinking", drop_thinking=True, add_default_bos_token=True)

# messages -> string
prompt = encode_messages(messages, **encode_config)
# Output: "<｜begin▁of▁sentence｜><｜User｜>hello<｜Assistant｜></think>Hello! I am DeepSeek.<｜end▁of▁sentence｜><｜User｜>1+1=?<｜Assistant｜><think>"

# string -> tokens
tokens = tokenizer.encode(prompt)
# Output: [0, 128803, 33310, 128804, 128799, 19923, 3, 342, 1030, 22651, 4374, 1465, 16, 1, 128803, 19, 13, 19, 127252, 128804, 128798]

说明：

本次发布不包含Jinja格式的聊天模板。请参阅上述Python代码。
代码中包含的输出解析函数仅设计用于处理格式良好的字符串。它不会尝试纠正或从模型偶尔生成的错误格式输出中恢复。在没有强大的错误处理机制的情况下，不适合生产使用。
在聊天模板中引入了一个名为developer的新角色。此角色专用于搜索代理场景，并且不用于其他任务。官方API不接受分配给developer的消息。

7. API 使用指南

API 使用文档： api-docs

7.1 思考模式 (Thinking Mode)

DeepSeek 模型支持思考模式：在输出最终答案之前，模型会先输出一个思维链推理过程，以提高最终回答的准确性。您可以通过以下任意一种方式启用思考模式：

设置模型参数："model": "deepseek-reasoner"
设置 thinking 参数："thinking": {"type": "enabled"}

如果您使用的是 OpenAI SDK，在设置 thinking 参数时，需要在 extra_body 中传递：

python 复制代码

response = client.chat.completions.create(
  model="deepseek-chat",
  # ...
  extra_body={"thinking": {"type": "enabled"}}
)

API 参数

输入：
- max_tokens：最大输出长度（包含思维链部分）。默认为 32K，最大为 64K。
输出：
- reasoning_content：思维链的内容，它与输出结构中的 content 字段位于同一层级。详见 API 示例。
- content：最终答案的内容。
- tool_calls：工具调用信息。
支持的功能：

JSON 输出、工具调用、聊天补全、聊天前缀补全（Beta版）
不支持的功能：

FIM（Beta版）
不支持或无效的参数：

temperature、top_p、presence_penalty、frequency_penalty、logprobs、top_logprobs。

请注意，为了确保与现有软件的兼容性，设置 temperature、top_p、presence_penalty、frequency_penalty 不会触发错误，但也不会有任何效果。设置 logprobs、top_logprobs 则会触发错误。

多轮对话 (Multi-turn Conversation)

在对话的每一轮中，模型会输出思维链和最终答案。在下一轮对话中，之前轮次的思维链不会被拼接到上下文中，如下图所示：

API 示例

以下示例代码（以 Python 为例）演示了如何访问模型的思维链内容、最终答案，以及如何进行多轮对话。请注意，在新的一轮对话代码中，仅传递了上一轮输出的 content（最终答案），而忽略了 reasoning_content（思维链）。

python 复制代码

from openai import OpenAI
client = OpenAI(api_key="<DeepSeek API Key>", base_url="https://api.deepseek.com")

# Turn 1
messages = [{"role": "user", "content": "9.11 and 9.8, which is greater?"}]
response = client.chat.completions.create(
    model="deepseek-reasoner",
    messages=messages
)

reasoning_content = response.choices[0].message.reasoning_content
content = response.choices[0].message.content

# Turn 2
messages.append({'role': 'assistant', 'content': content})
messages.append({'role': 'user', 'content': "How many Rs are there in the word 'strawberry'?"})
response = client.chat.completions.create(
    model="deepseek-reasoner",
    messages=messages
)
# ...

工具调用 (Tool Calls)

DeepSeek 模型的思考模式现已支持工具调用。在输出最终答案之前，模型可以进行多轮思考和工具调用，以提高回答的质量。其调用模式如下图所示（或描述如下）：

回答第一个问题（第 1.1 轮到第 1.3 轮）的过程中，模型进行了多轮 "思考 + 工具调用" 后才给出答案。在此过程中，用户需要将模型输出的推理内容 (reasoning_content) 发回给 API，以便模型继续推理。
当开始下一个用户问题时（第 2.1 轮），之前的 reasoning_content 应该被移除，只保留其他元素发送给 API。如果保留并发送了 reasoning_content，API 会忽略它。

示例代码

以下是在思考模式下进行工具调用的一个简单示例代码：

python 复制代码

import os
import json
from openai import OpenAI

# The definition of the tools
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_date",
            "description": "Get the current date",
            "parameters": { "type": "object", "properties": {} },
        }
    },
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get weather of a location, the user should supply the location and date.",
            "parameters": {
                "type": "object",
                "properties": {
                    "location": { "type": "string", "description": "The city name" },
                    "date": { "type": "string", "description": "The date in format YYYY-mm-dd" },
                },
                "required": ["location", "date"]
            },
        }
    },
]

# The mocked version of the tool calls
def get_date_mock():
    return "2025-12-01"

def get_weather_mock(location, date):
    return "Cloudy 7~13°C"

TOOL_CALL_MAP = {
    "get_date": get_date_mock,
    "get_weather": get_weather_mock
}

def clear_reasoning_content(messages):
    for message in messages:
        if hasattr(message, 'reasoning_content'):
            message.reasoning_content = None

def run_turn(turn, messages):
    sub_turn = 1
    while True:
        response = client.chat.completions.create(
            model='deepseek-chat',
            messages=messages,
            tools=tools,
            extra_body={ "thinking": { "type": "enabled" } }
        )
        messages.append(response.choices[0].message)
        reasoning_content = response.choices[0].message.reasoning_content
        content = response.choices[0].message.content
        tool_calls = response.choices[0].message.tool_calls
        print(f"Turn {turn}.{sub_turn}\n{reasoning_content=}\n{content=}\n{tool_calls=}")
        # If there is no tool calls, then the model should get a final answer and we need to stop the loop
        if tool_calls is None:
            break
        for tool in tool_calls:
            tool_function = TOOL_CALL_MAP[tool.function.name]
            tool_result = tool_function(**json.loads(tool.function.arguments))
            print(f"tool result for {tool.function.name}: {tool_result}\n")
            messages.append({
                "role": "tool",
                "tool_call_id": tool.id,
                "content": tool_result,
            })
        sub_turn += 1

client = OpenAI(
    api_key=os.environ.get('DEEPSEEK_API_KEY'),
    base_url=os.environ.get('DEEPSEEK_BASE_URL'),
)

# The user starts a question
turn = 1
messages = [{
    "role": "user",
    "content": "How's the weather in Hangzhou Tomorrow"
}]
run_turn(turn, messages)

# The user starts a new question
turn = 2
messages.append({
    "role": "user",
    "content": "How's the weather in Hangzhou Tomorrow"
})
# We recommended to clear the reasoning_content in history messages so as to save network bandwidth
clear_reasoning_content(messages)
run_turn(turn, messages)

引用

bash 复制代码

@misc{deepseekai2025deepseekv32,
      title={DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models}, 
      author={DeepSeek-AI},
      year={2025},
}

在 Turn 1 的每一个子请求中，该轮生成的 reasoning_content 都会被发送给 API，使得模型能够延续之前的推理。response.choices[0].message 包含了助手消息的所有必要字段，如 content、reasoning_content 和 tool_calls。为简化操作，您可以直接使用以下代码将整个消息对象追加到 messages 列表末尾：

python 复制代码

messages.append(response.choices[0].message)

在开始Turn 2时，我们建议丢弃之前轮次产生的 reasoning_content，以节省网络带宽：

python 复制代码

clear_reasoning_content(messages)

以下是上述示例代码运行时可能生成的输出示例：

bash 复制代码

=== 第一轮对话开始 ===
模型第一轮推理 (reasoning_content):
用户询问北京的天气。我需要调用天气查询工具来获取准确信息。

模型请求调用工具: get_current_weather

=== 第二轮对话 (模型结合工具结果继续推理) ===
模型第二轮推理 (reasoning_content):
工具返回了北京的天气数据：气温22°C，晴朗，湿度65%。这是一个宜人的天气。我将据此给出回答。

最终答案 (content):
北京今天天气晴朗，气温22°C，湿度65%，是一个非常舒适的好天气。

=== 第三轮对话 (新的用户问题) ===
模型新一轮推理 (reasoning_content):
用户现在询问上海的天气。我需要再次调用天气查询工具，但这次参数是"上海"。

这个输出示例清晰地展示了：

第一轮：模型进行推理，决定调用工具。
第二轮：模型接收工具返回的结果，继续进行推理，最终生成给用户的答案。
第三轮：面对新的用户问题，模型丢弃了之前的详细推理链，重新开始推理，并准备调用工具。

本文由 youcans@xidian 对论文【DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models】进行摘编和翻译，只供研究学习使用。

youcans@xidian 作品 ，转载必须标注原文链接：
【DeepSeek论文精读】15. DeepSeek-V3.2：开拓开源大型语言模型新前沿

Copyright 2025 youcans, XIDIAN

Created：2025-12