DeepSeek V4 Pro 发布后曾一度消失，但其正式发布仍然有效

DeepSeek V4 Pro 进入正式可用状态后，其公开发布痕迹似乎在 24 小时内有所回撤。但模型本身并未消失。

中国媒体报道称，DeepSeek 删除了 DeepSeek-V4-Pro-0813 的网站公告和开放平台通知。不过，该公司的 API 记录仍持续标识这一更新后的模型。这种不一致形成了一种不同寻常的发布状态：开发者仍可使用该模型，但却一度难以通过常规公开渠道确认其状态。

这起事件不只是删除了一个页面。DeepSeek 将这次发布定位为面向编程智能体的生产级模型，并配套推出了新的控制选项和扩展后的 API 格式。因此，公告缺失会影响那些正在决定是否将工作负载从预览软件迁移至生产环境的团队。

在最初报道之后，现有证据也发生了变化。DeepSeek 的官方更新日志如今已列出一条 8 月 13 日的正式可用条目。其文档则罗列了与初次发布期间流传内容相同的模型功能和基准测试说法。

这意味着，最有力的结论比早期标题所暗示的更为有限。DeepSeek 似乎经历了一次发布沟通上的回撤，而非已获确认的模型撤回。剩下的问题是：这些文档是在更正后被恢复，还是仅仅暂时出现了不一致。

DeepSeek V4 Pro 是暂时淡出视野，而非从 API 中撤下

公开记录支持的是暂时性的文档冲突，而不是 DeepSeek V4 Pro 已被确认取消。

根据服务列表和早期开发者报告，此次发布于 8 月 12 日低调启动。随后，模型标识符 DeepSeek-V4-Pro-0813 出现在官方 API 资料中。

8 月 13 日，DeepSeek 将该模型描述为其正式可用版本。正式可用通常简称为 GA，意味着产品已超越预览状态。

该公司表示，该版本已覆盖其 app、网站和 API。开发者只需继续使用 deepseek-v4-pro 模型名称即可访问。

在随后一天内，中国媒体报道称，DeepSeek 的网站公告和开放平台通知已被删除。一则 36Kr 快讯 将该报道归因于 21 世纪经济报道。

另一则平行的市场新闻也提出了相同的核心说法。但两篇报道都未证实 DeepSeek 已禁用模型端点，或将客户回退至预览版本。

这一区别很重要。删除发布页面可能反映发布错误、披露问题、部署暂停，或只是内容管理故障。停止提供一个 API 模型则是另一项运营决策。

DeepSeek 没有就据报的删除行为发布明确解释。在缺少这一解释的情况下，推断其动机将超出证据所能支持的范围。

最重要的留存材料是 API 文档。在更广泛的公开通知据报无法访问期间，它仍展示了带日期的模型标识。

DeepSeek 的官方更新日志如今表述明确。其中包含一条日期为 2026 年 8 月 13 日、标题为“DeepSeek-V4-Pro Update”的记录。

该条目称，GA 版本已在 app、网页界面和 API 中推出。它还列出了基准测试结果、Responses API 支持、思考控制选项以及计划中的定价政策调整。

DeepSeek 的新闻导航也链接至一个专门的 8 月 13 日发布页面。在本文于 8 月 14 日撰写时，这些页面可以访问。

由此形成的时间线确实包含一次回撤，但这是沟通层面的回撤。发布信息先变得可见，其部分公开呈现据报消失，随后官方记录又似乎重新可用。

本文审查的证据中，没有任何内容证实 DeepSeek 撤回了底层模型。模型名称、配套文档和 API 引用都仍然可见。

因此，开发者应当区分三个不同的问题：页面是否被删除？发布声明是否被撤回？服务本身是否被禁用？

现有报道为第一个问题提供了证据。当前文档不支持第三种情况。由于 DeepSeek 尚未解释这一过程，第二个问题仍未解决。

这一区分可以避免将暂时的发布异常误解为一款产品的虚假讣告。它也将注意力重新聚焦于更关键的问题：DeepSeek 的发布流程是否足够可靠，能够满足生产团队的需求。

为什么公告缺失会影响开发者

生产级模型需要稳定的契约，而文档正是该契约的一部分。

API 不只是一个远程模型。它是一项由标识符、行为、限制、文档和变更通知共同约束的依赖项。

工程团队依靠这些记录决定何时更新评测套件、批准迁移，以及修改路由规则。删除发布公告会为每一项决策带来不确定性。

压力首先落在那些在低调发布期间采用该模型的开发者身上。他们需要知道，自己的请求是否确实到达了目标的 0813 版本。

稳定别名可能掩盖后端变化。DeepSeek 要求用户继续调用 deepseek-v4-pro，这降低了迁移工作量，却使版本验证变得更加重要。

如果一个别名从预览切换至 GA，却没有单独的版本化端点，团队就必须依赖文档和响应元数据。他们还需要可重复的评测，以识别行为变化。

第二个承压对象是平台层。模型路由器、编程助手和企业网关必须说明它们实际提供的是什么。

供应商列出 0813 模型，看上去可能比 DeepSeek 自己的稳定别名更精确。不过，只有当供应商确认其上游版本时，这种精确性才有帮助。

第三个承压对象是 DeepSeek 自身。该公司在很大程度上凭借广泛访问、开放权重和更低的部署门槛建立了声誉。

这种声誉提高了对透明发布的期待。一个被定位于严肃智能体工作的模型，需要比实验性聊天机器人更新更清晰的运营沟通。

该模型宣传的功能进一步强化了这一需求。DeepSeek 表示，V4 Pro 现已原生支持 OpenAI Responses API 格式。

Responses API 格式通过通用接口组织多步骤模型交互、工具调用和结构化输出。DeepSeek 表示，其实现已针对 Codex 工作流进行了适配。

DeepSeek 还新增了 low、high 和 max 三档思考强度设置。这些控制项让开发者能够在响应深度、延迟和资源消耗之间权衡。

这类控制项可能显著改变应用行为。配置在某一强度等级下的编程智能体，可能会在另一等级下产生不同的计划、工具调用和完成时间。

该公司还宣布，自 8 月 16 日起，API 将实施高峰与非高峰时段安排。这里具体的商业数字不如其传递的运营信号重要。

DeepSeek 正要求客户围绕容量状况安排工作负载。这表明 GA 发布不仅与模型质量有关，也与资源管理有关。

在这种背景下，文档不稳定的影响更为严重。团队需要知道新的使用政策、模型行为和可用日期是否已最终确定。

对于长时间运行的智能体而言，问题尤为突出。这些系统会执行多个相互依赖的步骤，通常跨越代码仓库和外部工具。

微小的行为变化可能在较长的执行轨迹中累积。智能体可能选择不同的文件、调用不同的工具，或以不同方式从错误中恢复。

聊天用户可以直接重新生成一个不理想的回答。而生产环境中的编程工作流，可能在任何人注意到模型发生变化之前就创建了存在缺陷的补丁。

正在评估 DeepSeek V4 Pro 的组织，应在每次审批决策时留存相关文档。API 提供响应指纹时，也应记录这些信息。

可检索的内部记录能够帮助团队将规格说明与观察到的行为进行比较。一套工程知识库可以将这些决策与测试和事故记录一并保存。

这种做法无法弥合 DeepSeek 的沟通缺口。但当供应商页面在部署决策后发生变化时，它可以限制由此造成的损失。

真正的冲突在于发布信心与发布速度之间

DeepSeek 的快速推出创造了势头，但公告回撤削弱了人们对模型周边流程的信心。

核心对手并不是 DeepSeek 与某一家美国或中国竞争者之间的较量，而是 DeepSeek 对生产就绪性的承诺，与其不清晰发布记录这一现实之间的冲突。

DeepSeek 此前已于 4 月 24 日发布 V4 预览系列。预览版包括 V4 Pro 和较小的 V4 Flash。

根据该公司的预览公告，V4 Pro 使用混合专家架构，总参数量为 1.6 万亿，激活参数量为 490 亿。

混合专家模型会将每个 token 路由至选定的专家组件。它避免为每个 token 激活整个网络。

DeepSeek 还宣传了 100 万 token 的上下文窗口。上下文窗口是指模型在一次交互中能够考虑的输入和生成内容总量。

这些规格将 V4 Pro 确立为该系列中规模更大、能力更强的成员。V4 Flash 则瞄准更快、更经济的使用场景。

DeepSeek 于 7 月 31 日发布了更新后的 V4 Flash，随后表示正式版 V4 Pro 将跟进。8 月 13 日的更新完成了这一预期中的发布顺序。

该公司的基准测试列表高度聚焦于智能体。它报告称，在 Terminal Bench 2.1 上取得 87.9 分，在 NL2Repo 上取得 61.5 分，在 DeepSWE 上取得 62.7 分。

Terminal Bench 评估命令行智能体的表现。NL2Repo 衡量基于自然语言需求的仓库级生成能力，而 DeepSWE 评估软件工程任务。

DeepSeek 还报告称，在 Toolathlon-Verified 上取得 74.1 分，在使用工具的 Humanity’s Last Exam 上取得 60.0 分。这些是公司自行提供的结果，并非独立的生产保障。

该公司表示，GA 模型在生产环境中尤其有所改进。由于基准测试条件会强烈影响智能体结果，这一说法值得验证。

DeepSeek 在 7 月的 Flash 说明中披露，其编程评测使用了内部 DeepSeek Harness 的最简模式。harness 是围绕模型提供提示词、工具和执行规则的软件框架。

该公司表示，该 harness 将在稍后发布。在研究人员能够复现这一设置之前，与其他模型的比较仍不完整。

这正是发布回撤具有战略重要性的原因。DeepSeek 正要求开发者同时信任该模型及其周边评测体系。

公告消失不利于这一诉求。它让外界无法确定，该公司究竟是修正了事实错误、暂停了发布，还是改变了沟通方式。

Anthropic、OpenAI、Google、Alibaba 和 Moonshot AI 等竞争者面临同样的基本挑战。智能体基准测试可以快速提升，而真实代码仓库会暴露脆弱的行为。

它们的发布流程有所不同，但企业买家比较的不只是分数。他们还会评估正常运行时间、版本控制、安全文档、支持服务和通知期限。

Microsoft 的模型目录提供了一个外部迹象，表明 V4 Pro 已进入生产环境的讨论范围。其退役计划将 DeepSeek V4 Pro 列为旧版 DeepSeek 模型的替代方案。

这一列示并不能验证 0813 版本的基准测试主张。但它表明，V4 Pro 系列并非只是由一则已删除公告引发的传言。

DeepSeek 也维护公开的模型资料。其模型仓库标明了 V4 Pro 的架构，并提供了配置材料。

不过，开放模型资料并不会自动揭示某个 API 别名实际提供的是哪个构建版本。托管服务可能已获得后训练更新，而这些更新尚未体现在可下载的权重中。

这使 DeepSeek 承担起沟通责任。快速迭代对开发者很有吸引力，但生产环境用户需要发布版本之间可审计的边界。

公司可以通过稳定的版本标识符、带日期的变更日志、迁移窗口和事故说明，同时满足这两项目标。8 月的事件表明，这些机制并未始终保持同步。

DeepSeek 的基准测试主张不能证明什么

现有分数描述的是 DeepSeek 的测试设置，但无法解释据称为何公开通知会消失。

一种可能的解释是，DeepSeek 在部署后发现了发布问题。该问题可能涉及文档、基准测试呈现方式、容量或模型行为。

目前没有经过验证的来源能够证实上述任何解释。将其中某一种视为事实，会把证据空白变成猜测。

第二种解释则没那么戏剧化。该公司可能按错误顺序发布了页面，随后在协调更广泛公告期间暂时将其移除。

这种解释与先低调上线、后补充正式变更日志条目的情况相符。但 DeepSeek 同样没有确认这一点。

第三种可能是，区域网站或内容管理系统出现了不同步。API 页面、主网站和开放平台可能使用不同的发布流程。

这可以解释为什么一个页面仍保留 0813 标识，而另一个页面失去了公告。不过，这仍是一种推断，而非有据可查的原因。

这种不确定性应当影响读者对基准测试数字的解读。DeepSeek 报告了强劲的智能体结果，但这些数据无法验证发布稳定性。

基准测试回答的是一个更狭窄的问题：经过配置的系统在既定测试中的表现如何。它们并不衡量文档质量、别名一致性或部署治理。

它们也无法保证在某个特定代码仓库中的表现。编程智能体仍然对提示词、工具、沙箱规则、重试逻辑和上下文管理十分敏感。

尚未发布的 DeepSeek Harness 尤其值得关注。如果该 harness 对报告中的提升有实质贡献，开发者可能无法通过其他智能体框架复现这些收益。

社区评论已经反映出这一担忧。一些早期用户报告了强劲结果，另一些人则质疑多轮可靠性以及对 harness 的敏感性。

这些反应可作为有用线索，但并非受控证据。它们来自不同任务、配置和服务提供商。

因此，负责任的立场既不是否定，也不是背书。DeepSeek 已发布足够材料来证实这是一次真实的 GA 发布，但还不足以填补所有验证空白。

团队应在迁移前运行自己的固定任务集。该任务集应包括代码修改、工具故障、长对话，以及首次尝试失败后需要纠正的任务。

测试应记录日期、模型别名、系统指纹、推理强度设置、延迟和最终结果。这能将轶事式印象转化为可比较的发布记录。

团队也应将模型质量与平台质量分开看待。如果别名、限制或政策在没有明确通知的情况下变化，即使模型能力出色，也可能难以运维。

反过来，页面被移除也不能证明模型本身失败了。当前 API 证据不支持作出这种跳跃式推断。

DeepSeek 可以通过一份直接声明减少不确定性。它应说明这些通知是被有意移除、暂时下线，还是经过更正。

该声明还应明确 API 流量是否曾停止指向 GA 构建版本。对开发者而言，这一运维事实比又一张基准测试图表更重要。

在此之前，这次发布应被视为仍在运行、但文档并不完善。对于测试而言，这是可控风险；但对于生产环境迁移，则是值得重视的问题。

三个信号将显示此次发布是否已稳定

接下来的证据应来自模型身份、可复现的智能体测试，以及 DeepSeek 如何处理沟通缺口。

第一个信号是 DeepSeek 的 API、网站、应用和文档之间稳定一致的模型标识。四个渠道都应描述同一个版本，且不应出现无法解释的反复变化。

开发者应关注 deepseek-v4-pro 别名是否始终映射到 GA 模型。版本元数据或指纹应能在未来更新中保持可追溯。

如果 DeepSeek 能维持这种一致性，这一事件看起来会更像一次暂时性的发布故障。若再出现无法解释的不匹配，将加深人们对发布治理的担忧。

第二个信号是独立复现 DeepSeek 的智能体结果。如果公司发布其承诺的 harness，这项工作将更有价值。

研究人员需要获得确切的提示词、工具定义、推理强度设置、重试策略和评分规则。这些细节决定基准测试改进应归因于模型、harness，还是两者兼有。

若能在外部框架中成功复现，将增强 DeepSeek 的生产环境主张。若离开内部 harness 后表现大幅下降，则会缩小这些主张的实际意义。

真实代码仓库测试最为重要。团队应考察 V4 Pro 是否能够规划变更、遵守约束、从工具错误中恢复，并完成多步骤工作。

他们还应将其与 V4 Flash 及当前承担其生产工作负载的模型进行比较。头条级排行榜位置无法取代任务级评估。

第三个信号是 DeepSeek 对据报移除事件的公开回应。沉默会让开发者只能从缓存页面和第三方信息流中重建发布过程。

一份简短的更正即可消除核心不确定性。DeepSeek 只需说明发生了什么变化、何时变化，以及 API 服务是否受到影响。

这样的回应将表明，公司将发布沟通视为可靠性的一部分。持续的模糊表述会让未来的发布通知更难获得信任。

预定的 API 政策过渡提供了一个即时检查点。如果该变更如文档所述推进，同时 GA 模型保持稳定，就支持发布本身仍在持续的观点。

服务状态记录可提供另一项核查。任何与 0813 部署相关的事故都会实质性改变分析结论。

对开发者而言，实际决策很直接。DeepSeek V4 Pro 可供评估，其官方发布记录目前也仍可访问。

不应仅因通知被移除就将其视为已取消。也不应仅因为 DeepSeek 发布了较高的基准测试分数，就将其引入关键工作流。

运行具有代表性的任务，保留测试结果，并在每个迁移阶段前验证模型身份。将供应商文档与自己的测试记录一并保存。

评估该模型的知识工作者也应遵循同样的原则。保存输出、记录日期，并避免假定某个界面反映了所有后端变更。

更深层的问题，是模型与用户之间边界上的信任。DeepSeek 可以快速发布更新，但生产环境采用取决于能否让这些更新清晰可辨。

据报的撤回曾短暂破坏了这种清晰性。恢复的文档修复了记录的一部分，却没有解释背后那段不明的过程。

DeepSeek 会否就哪些内容消失、以及原因何在，发布清晰说明？这个答案将比又一个孤立的基准测试结果更能体现 V4 Pro 的生产成熟度。