ZAC / NOTES
← 返回文章

DeepSeek 一周年进展：从 R1 影响力到 V4 的 Agent 化

·16 分钟阅读·AI 系统 · 模型演进 · DeepSeek

沿着模式统一、Agent、稀疏注意力、长上下文与开放部署五条线，重建 DeepSeek 从 V3.1 到 V4 Preview 的一年演进。

DeepSeek 一周年进展：从 R1 影响力到 V4 的 Agent 化

过去一年，DeepSeek 的主线从 R1 / V3 的开源影响力，转向更工程化的 Agent 模型体系：V3.1 把思考和非思考并入同一模型，V3.2 把稀疏注意力和工具中思考推到前台，V4 Preview 则把 Pro / Flash 双层结构和 1M 上下文变成官方服务能力。

如果只看版本号，这像是一串连续升级；如果沿着模型组织、上下文效率、工具调用和 API 表面去看，它更像一次平台重构。

三个结论先行

产品线从“模型分工”转向“单模型双模式”

在 R1 与 V3 的阶段，推理模型和通用聊天模型更像两条分开的产品线。V3.1 开始把 Think / Non-Think 设计成同一模型的两种运行方式；到了 V4，官方模型同时支持非思考、Think High 与 Think Max 等运行模式。

这改变的不只是模型选择。调用方可以在同一套模型能力上，根据任务风险、时延目标和成本预算切换推理强度。

效率路线贯穿全年

DeepSeek 一直把“能力增长不等于等比例增加推理成本”放在显性位置。V3.2-Exp 引入 DeepSeek Sparse Attention，V4 又通过压缩注意力和稀疏注意力支撑百万 token 上下文。

因此，1M context 不是一个孤立的窗口数字。真正值得观察的是：模型如何减少长上下文下的计算量、KV cache 压力，以及这套效率设计能否进入公开权重与主流推理框架。

Agent 能力成为版本迭代的主战场

从 V3.1 的工具使用、多步 Agent 与复杂搜索，到 V3.2 的 thinking in tool-use，再到 V4 的 agentic coding 集成，DeepSeek 的产品叙事已经从“回答更难的问题”转向“在工具和环境中完成更长的执行链”。

对工程团队而言，这意味着评估重点也必须变化：除了静态 benchmark，还要测试工具调用合法率、长链路稳定性、失败恢复、上下文复用和单位任务成本。

先区分一年窗口、基线节点和当前状态

本文以 2025-06-22 至 2026-06-22 为主要观察窗口。DeepSeek-V3-0324 与 DeepSeek-R1-0528 早于窗口起点，但它们分别代表当时非推理线与推理线的成熟基线，因此保留为背景。

窗口内覆盖五组主要节点：

  • DeepSeek-V3.1
  • DeepSeek-V3.1-Terminus
  • DeepSeek-V3.2-Exp
  • DeepSeek-V3.2 / V3.2-Speciale
  • DeepSeek-V4 Preview

本文只使用 DeepSeek 官方发布页和官方模型卡来建立事实节点，不扩展到第三方微调、量化封装或社区传闻。2026-07-28 的更新只校订官方 API 的当前模型名，不把观察窗口扩写成另一篇“最新消息”。

四个阶段：从双线模型到长上下文 Agent 平台

阶段模型组织关键工程变化对使用者的含义
V3 / R1 基线通用聊天与推理两条线MoE、开放权重、JSON 与函数调用逐步成熟在通用模型和推理模型之间选型
V3.1 / Terminus同一模型支持 Think / Non-Think128K、Anthropic API、严格函数调用、Agent 稳定性修补一套模型覆盖聊天、推理与基础 Agent
V3.2 / Specialereasoning-first models built for agentsDSA、工具中思考、Agent 数据合成更适合搜索、代码与复杂多步执行
V4 PreviewPro / Flash 双层，均支持多种推理模式1M context、混合注意力、OpenAI / Anthropic API把能力、时延和成本分层放进同一服务架构

这里有两个同时发生的变化。一是“一体化”：聊天、推理和工具使用不再需要完全分开的模型产品。二是“效率化”：上下文越来越长，但架构必须主动压低注意力和缓存成本。

按时间顺序重建关键节点

窗口外基线：V3-0324 与 R1-0528

DeepSeek-V3-0324 模型卡记录了推理、前端开发、中文写作、中文搜索和 function calling 等方向的改进，并延续 MIT License。

DeepSeek-R1-0528 发布说明则把推理线的升级集中在 benchmark、前端能力、幻觉控制、JSON output 和 function calling 上。它们共同构成后续“统一模型双模式”的起点。

2025-08-21：V3.1 把双模式放进同一模型

V3.1 官方发布页把它称为迈向 Agent 时代的第一步。核心变化是 hybrid inference：同一模型支持 Think 和 Non-Think 两种模式，并强化工具使用、多步 Agent 任务与复杂搜索。

API 当时仍保留 deepseek-chat 和 deepseek-reasoner 两个名称，分别映射到非思考和思考模式，同时提供 128K context、Anthropic API 格式与严格函数调用 Beta。

2025-09-22：V3.1-Terminus 修补稳定性

V3.1-Terminus 更新不以全新架构为卖点，而是处理真实 Agent 工作流中更容易暴露的问题：语言一致性、中英混杂、随机字符，以及 Code Agent 和 Search Agent 表现。

这类版本很重要。它说明从 benchmark 走向执行型工作流后，输出稳定性与格式可靠性开始和“答对多少题”同样重要。

2025-09-29：V3.2-Exp 把稀疏注意力推到主线

V3.2-Exp 官方说明首次明确引入 DeepSeek Sparse Attention。它通过细粒度稀疏注意力减少长上下文训练与推理成本，并伴随当时超过 50% 的 API 降价。

这里的重点不是一次短期价格变化，而是架构效率开始直接影响产品定价。

2025-12-01：V3.2 把推理嵌入工具使用

DeepSeek-V3.2 发布页把正式版定位为 reasoning-first models built for agents，并强调 thinking directly into tool-use。官方还披露使用 1,800 多个环境与 85,000 多条复杂指令构造 Agent 训练数据。

这一步把工具调用从“在答案末尾产生一个结构化函数参数”推进到“在多次工具执行之间持续推理”。对于 Agent 系统，后者才是长任务成功率的关键。

2026-04-24：V4 Preview 进入 Pro / Flash 与 1M context

V4 Preview 官方发布页给出两个层级：

  • V4-Pro：1.6T total parameters，49B activated parameters。
  • V4-Flash：284B total parameters，13B activated parameters。
  • 两者均支持 1M context，以及思考与非思考模式。
  • API 同时兼容 OpenAI ChatCompletions 与 Anthropic 格式。

官方模型卡进一步说明 V4 使用混合注意力结构来降低百万 token 场景的计算与 KV cache 成本。对外部使用者来说，Pro / Flash 分层也把“最强能力”和“更低时延、更低价格”变成明确的架构选择。

六条能力线，比版本号更值得追踪

1. 思考与非思考统一

V3.1 之后，thinking 和 non-thinking 不再只是两条模型线，而成为同一模型体系的运行模式。到了 V4，官方 API 通过 thinking 和 reasoning_effort 参数控制是否思考以及 High / Max 强度。

这种设计降低了路由复杂度，但没有消除工程决策。系统仍然需要决定哪些任务默认思考、何时升级到 Max，以及更长推理是否真的提高端到端任务成功率。

2. Agentic Coding

DeepSeek 先后把 Code Agent、Search Agent、SWE / Terminal-Bench、工具中思考和主流编码 Agent 集成放进发布主线。它所指向的能力，不只是代码生成，而是读取上下文、调用工具、修改状态、观察结果，再继续执行。

这类能力不能只靠一次性答案评分。更合理的评估单位是完整任务：成功率、工具错误率、重试次数、上下文增长和最终成本。

3. 长上下文效率

V3.2-Exp 和 V4 的共同技术叙事，是通过稀疏化和压缩降低长上下文成本。上下文从 128K 走到官方服务的 1M，真正的瓶颈会从“能否放得下”转向“首 token 延迟、并发、缓存复用和单位请求成本是否可接受”。

因此，1M 是能力上限，不应自动变成每个生产请求的默认输入长度。

4. 开放权重与本地部署

V3-0324、R1-0528、V3.1、V3.2 和 V4 都持续提供开放权重或模型卡。V4-Pro 与 V4-Flash 的官方模型集合也给出了 vLLM、SGLang 等本地运行入口。

开放权重让研究、私有部署和引擎优化成为可能，但“能加载模型”不等于“能形成生产服务”。完整权重驻留、并行策略、KV cache、尾延迟与输出正确性仍需独立验证。

5. API 兼容与模型名迁移

V4 同时提供 OpenAI ChatCompletions 与 Anthropic API 表面，降低了现有 Agent 工具链的接入成本。不过，协议兼容不代表行为完全一致：思考参数、工具调用中的 reasoning_content 回传和输出限制仍需要按 DeepSeek 文档处理。

V4 发布时宣布 deepseek-chat 与 deepseek-reasoner 会在 2026-07-24 之后退役。截至 2026-07-28，官方模型与价格页只列出 deepseek-v4-flash 和 deepseek-v4-pro。调用方应使用明确的 V4 模型名，不再依赖旧名称的临时路由行为。

6. 成本成为产品能力的一部分

V3.2-Exp 的降价、V4-Flash 的经济型定位，以及长上下文内存成本优化，都说明成本不是部署后的附属问题，而是模型设计与产品分层的一部分。

不过，公开 API 价格会变化，自部署成本也高度依赖利用率、输入输出长度、cache hit、冗余和硬件价格。把某一时点的单价写成长期结论，很容易失真；更稳妥的方式是公开公式、数据日期与敏感性区间。

从模型进展到工程决策

把这一年的变化压缩成选型建议，可以得到四条相对耐用的结论：

  1. 短任务不必默认使用最强推理档。 Pro / Flash 与 Non-Think / High / Max 应形成两层路由，而不是一个全局默认值。
  2. 长上下文要按工作集设计。 1M context 适合提供上限能力，生产默认值仍应由 TTFT、并发与缓存命中决定。
  3. Agent 评估必须进入环境。 工具调用合法率、执行恢复和完整任务成功率，比单轮答案分数更接近真实价值。
  4. 开放部署要把正确性和经济性一起测。 除吞吐外，还要对比输出质量、JSON / tool-call 合法率、p95/p99、OOM、失败重试和空转成本。

换句话说，DeepSeek 的一年演进并不是把 R1 做得更大，而是把推理、工具、上下文和成本逐渐收束成一套可编排的平台能力。

资料来源

事实节点以 DeepSeek 官方 API 文档和官方 Hugging Face 模型卡为主：

阶段划分、能力线与工程结论为编辑归纳；模型参数、发布时间、API 状态和公开能力以以上官方页面为准。