在 2025 年 8 月，中国 AI 初创公司 DeepSeek 宣布发布 DeepSeek-V3.1，这是一次代际中期升级，被公司视为迈向“代理时代”的第一步。此次更新带来了混合推理模式（同一模型可运行于“思考”或“非思考”模式）、显著更长的上下文窗口，以及针对工具调用与多步骤代理行为的后训练改进。
什么是 DeepSeek-V3.1，为什么重要？
DeepSeek-V3.1 是 DeepSeek 的 V3 系列最新的生产级更新。宏观而言，它是一套混合 MoE 语言模型家族（V3 系列），DeepSeek 在其基础上进行了后训练并扩展以支持两个对用户可见的运行模式。你会看到两个主要变体：DeepSeek-V3.1-Base 和完整的 DeepSeek-V3.1：
- Non-thinking（deepseek-chat）： 一种针对速度和对话使用优化的标准聊天补全模式。
- Thinking（deepseek-reasoner）： 一种代理型推理模式，优先进行结构化的多步骤推理以及工具/代理编排。
此次发布聚焦于三项可见改进：平衡延迟与能力的混合推理管线、更智能的工具调用/代理编排，以及显著扩展的上下文窗口（标注为 128K tokens）。
为什么重要： DeepSeek-V3.1 延续了行业更广泛的趋势：将高效的大规模 MoE 架构与工具化原语和超长上下文窗口结合。在企业代理、搜索加推理工作流、长文档摘要以及工具驱动的自动化场景中，这种组合尤为关键，因为既需要高吞吐，也需要能够以确定性方式“调用”外部工具的能力。
DeepSeek-V3.1 与以往 DeepSeek 版本有何不同？
混合推理：一模型，两种运行模式
最显著的架构变化是混合推理。DeepSeek 表示 V3.1 在同一模型实例中支持“思考”模式与“非思考”模式，可通过更换聊天模板或 UI 切换（DeepSeek 的“DeepThink”按钮）进行选择。实践中，这意味着模型可以按需生成内部推理轨迹（有助于链式思维类的代理工作流），或者直接响应而不暴露中间推理 tokens——取决于开发者需求。DeepSeek 将此视为迈向更代理化工作流的路径，同时让应用能选择延迟/冗长度的权衡。
更大的上下文窗口与控制 token 原语
官方发布说明称 V3.1 的上下文窗口大幅增大；社区测试与公司帖子显示某些托管变体的扩展上下文达128k tokens，可显著支持更长的对话、多文档推理或将大型代码库放入同一会话。与此相辅相成，DeepSeek reportedly 引入了一些特殊控制 token（例如 <｜search_begin｜>/<｜search_end｜>、<think>/</think>），用于在内部结构化工具调用、划定“思考”片段——这是一种简化与外部工具协调的设计模式。
更锋利的代理/工具能力与延迟改进
DeepSeek 称 V3.1 经过后训练优化，重点针对工具调用与多步骤代理任务：在“思考”模式下，模型据称比此前的 DeepSeek R1 构建更快达到答案，并在调用外部 API 或执行多步骤计划时更可靠。这种定位——更快且更具代理能力的推理——对于构建助手、自动化或代理工作流的团队而言，是一个明确的产品差异点。
DeepSeek-V3.1 的架构是什么？
DeepSeek-V3.1 构建于 DeepSeek-V3 家族的核心研究之上：一个**专家混合（MoE）**骨干，并辅以面向效率与规模的一系列架构创新。DeepSeek-V3（底层家族）的公开技术报告描述了：
- 一个大型 MoE 设计，拥有数千亿总参数，但每个 token 的激活参数更小（模型卡列示总参数 671B，每 token 激活约 37B）。
- 多头潜在注意力（MLA）以及自定义的 DeepSeekMoE 路由与缩放方法，在保留容量的同时降低推理成本。
- 训练目标与负载均衡策略，去除了对辅助负载均衡损失项的需求，并采用多 token 预测目标以提升吞吐与序列建模效果。
为什么选择 MoE + MLA？
专家混合让模型维持高的理论参数规模，同时每个 token 仅激活一部分专家——从而降低单 token 计算。MLA 是 DeepSeek 的注意力变体，帮助模型在众多专家与长上下文下高效扩展注意力操作。二者的组合使得训练与服务超大检查点成为可能，同时为多种部署保留可用的推理成本。
DeepSeek-V3.1 在基准测试和真实场景中的表现如何？
V3.1 的对比（文字版）
- 相较 V3（0324）： V3.1 全面升级——在编码与代理任务上尤为明显。示例：LiveCodeBench 从 43.0 → 56.4（非思考）并**→ 74.8**（思考）；Aider-Polyglot 从 55.1 → 68.4 / 76.3。
- 对比 R1-0528： R1 仍是强劲的“推理微调”对照，但V3.1-Thinking 在 AIME/HMMT、LiveCodeBench 上常与 R1-0528 相当或更优，同时还提供非思考路径以获得低延迟。
- 通识知识（MMLU 变体）： 在“思考”条件下，V3.1 略低于 R1-0528，但高于旧版 V3。
通识与学术
| Benchmark (指标) | V3.1-NonThinking | V3 (0324) | V3.1-Thinking | R1-0528 |
|---|---|---|---|---|
| MMLU-Redux（Exact Match） | 91.8 | 90.5 | 93.7 | 93.4 |
| MMLU-Pro（Exact Match） | 83.7 | 81.2 | 84.8 | 85.0 |
| GPQA-Diamond（Pass@1） | 74.9 | 68.4 | 80.1 | 81.0 |
含义： V3.1 在知识/学术任务上较 V3 有提升；“思考”模式缩小了在高难科学问题（GPQA-Diamond）上与 R1 的差距。
编码（非代理）
| Benchmark (指标) | V3.1-NonThinking | V3 (0324) | V3.1-Thinking | R1-0528 |
|---|---|---|---|---|
| LiveCodeBench（2408–2505）（Pass@1） | 56.4 | 43.0 | 74.8 | 73.3 |
| Aider-Polyglot（Accuracy） | 68.4 | 55.1 | 76.3 | 71.6 |
| Codeforces-Div1（Rating） | — | — | 2091 | 1930 |
注释：
- LiveCodeBench（2408–2505） 表示一个聚合窗口（2024 年 8 月→2025 年 5 月）。更高的 Pass@1 反映在多样化编码任务上的首次尝试正确率提升。
- Aider-Polyglot 模拟跨多语言的助手式代码编辑；V3.1-Thinking 领跑该组，V3.1-NonThinking 相对 V3（0324）也有显著跃升。
- 模型卡显示 V3（0324）在 Aider 为 55.1%——与该版本在 Aider 公开榜单上的记录一致。（V3.1 的更高分数为模型卡上的新数据。）
编码（代理任务）
| Benchmark (指标) | V3.1-NonThinking | V3 (0324) | V3.1-Thinking | R1-0528 |
|---|---|---|---|---|
| SWE Verified（Agent mode） | 66.0 | 45.4 | — | 44.6 |
| SWE-bench Multilingual（Agent mode） | 54.5 | 29.3 | — | 30.5 |
| Terminal-bench（Terminus 1 框架） | 31.3 | 13.3 | — | 5.7 |
重要说明： 这些是使用 DeepSeek 内部框架进行的代理评测（工具、执行多步骤），而非纯粹的下一 token 解码测试。它们反映“LLM + 编排”的整体能力。将其视作系统结果（复现性可能依赖具体代理栈与设置）。
数学与竞赛推理
| Benchmark (指标) | V3.1-NonThinking | V3 (0324) | V3.1-Thinking | R1-0528 |
|---|---|---|---|---|
| AIME 2024（Pass@1） | 66.3 | 59.4 | 93.1 | 91.4 |
| AIME 2025（Pass@1） | 49.8 | 51.3 | 88.4 | 87.5 |
| HMMT 2025（Pass@1） | 33.5 | 29.2 | 84.2 | 79.4 |
结论： “思考”模式在数学竞赛集上带来非常大的提升——在所报告的运行中，V3.1-Thinking 在 AIME/HMMT 上略超 R1-0528。
搜索增强 / “代理型”问答
| Benchmark (指标) | V3.1-NonThinking | V3 (0324) | V3.1-Thinking | R1-0528 |
|---|---|---|---|---|
| BrowseComp | — | — | 30.0 | 8.9 |
| BrowseComp_zh | — | — | 49.2 | 35.7 |
| Humanity’s Last Exam（Python + Search） | — | — | 29.8 | 24.8 |
| SimpleQA | — | — | 93.4 | 92.3 |
| Humanity’s Last Exam（text-only） | — | — | 15.9 | 17.7 |
说明： DeepSeek 表示其搜索代理结果采用内部搜索框架（商业搜索 API + 页面过滤，128K 上下文）。方法学在此很重要；复现需具备类似工具链。
有哪些限制与未来方向？
DeepSeek-V3.1 是一次重要的工程与产品推进：将长上下文训练、混合模板与 MoE 架构缝合为一个普适可用的检查点。然而，限制仍然存在：
- 真实世界中的代理安全、长上下文摘要的幻觉，以及对抗性提示行为仍需系统级缓解。
- 基准表现虽鼓舞但不完全一致：性能随领域、语言与评测套件而波动；需要独立验证。
- 地缘政治与供应链因素——硬件可用性与芯片兼容性——曾影响 DeepSeek 的时间表，也可能影响客户的大规模部署方式。
通过 CometAPI 开始使用
CometAPI 是一个统一的 API 平台，将来自领先提供商的 500 多个 AI 模型（如 OpenAI 的 GPT 系列、Google 的 Gemini、Anthropic 的 Claude、Midjourney、Suno 等）聚合到一个对开发者友好的接口中。通过提供一致的认证、请求格式与响应处理，CometAPI 大幅简化了将 AI 能力集成到你的应用中的过程。无论你在构建聊天机器人、图像生成器、音乐作曲器或数据驱动的分析管线，CometAPI 都能让你更快迭代、控制成本并保持供应商中立，同时获取 AI 生态的最新突破。
开发者可通过 CometAPI 访问 DeepSeek R1（deepseek-r1-0528）与 DeepSeek-V3.1，相关模型版本以文章发表日期为准。开始前，可在 Playground 探索模型能力，并参考 API guide 获取详细说明。在访问前，请确保你已登录 CometAPI 并获取 API key。CometAPI 提供远低于官方价格的方案，帮助你更好地集成。
结论
DeepSeek-V3.1 是一次务实、工程导向的更新：更大的上下文窗口、混合思考/非思考推理、更好的工具交互，以及兼容 OpenAI 的 API，使其成为构建代理型助手、长上下文应用与低成本的代码导向工作流团队的有吸引力的选择。