11月7日15点11分，DeepSeek 的网页和 API 出现部分中断。官方状态页列出的受影响服务包括对话服务、DeepSeek V4 Pro API 和 DeepSeek V4.1 Flash API。15点56分，状态页更新为“本次问题已解决，服务已恢复”。 前后45分钟。DeepSeek Status
这是4天内第二次。11月3日16点58分到18点48分，同一组服务刚断过1小时49分钟。再往前，10月15日8点11分到13点04分，断了4小时52分钟。三次的标题完全相同，都是“DeepSeek 网页/API 部分中断（DeepSeek Web/API Partially Unavailable）”。 官方状态页上能查到的、从10月2日到11月7日的记录，一共9起服务事件，其中3起是这类部分中断。DeepSeek Status
恢复在变快，故障在变密
只看单次，DeepSeek 的处理在进步：4小时52分钟、1小时49分钟、45分钟，一次比一次短。但把记录摊开，故障在变密。8月至11月，V4.1 Flash API 和对话服务（Chatservice）的可用性都是99.56%，V4 Pro API 是99.74%。百分比不算难看，落到“一周两次”上，用户感受到的是另一回事。
段子比事实跑得快
故障发生后，最常见的说法是“新模型要来了”。知乎上有一条回答把这层意思说得很直白：“如果崩溃了，说明有新模型/黑科技正在加紧训练准备上线”。 这是把每次宕机都当成发布预告，官方没有给出任何证据。知乎
另一种说法是“官方说没崩、状态页正常”。状态页明确记录了15点11分到15点56分的部分中断。官方回应是“已实施修复，正监控修复效果”。 不是没崩，是修完之后没有解释为什么崩。第一财经
把“从不补偿”当成结论，也不准确。10月15日那次近5小时的故障后，界面新闻的报道标题就是《DeepSeek就服务系统出现故障致歉，补偿方案公布》。 当时用户晒出的补偿通知显示，平台将把各账号过去7天（10月8日至14日）的消耗金额以赠金形式全额返还。 11月3日和11月7日这两次，截至发稿没有看到同等级别的说明。界面新闻微博
45分钟对聊天是小事，对Agent不是
官方没有说明这次故障的原因。能查到的最近一组官方数据是11月5日 Harness 团队披露的：截至11月4日，以官方 API 用户为统计口径，日活154万，日消耗约92万亿Token。 这个量级至少说明，DeepSeek 承载的不只是聊天框里的几句话，还有大量长时间运行的 Agent 任务。界面新闻
聊天中断45分钟，用户刷新几次、换个模型就过去了；Agent 任务跑到一半断掉，丢的是已经烧掉的 Token 和跑到一半的进度。B站一条评论说得很直接：“气死我了！ DSH崩溃吃了我2Mtok”。 DeepSeek 最近把 Harness、插件、Agent 作为重点在推，但这类产品对稳定性的要求，比聊天高得多。哔哩哔哩
该看的不是下一次发布会
45分钟修好，说明应急响应是有效的；一周两次，说明可靠性还没有跟上产品扩张。这两件事可以同时成立。普通用户能做的，是留一个备用入口，别把正在赶的活押在单一服务上。对 DeepSeek 来说，值得关注的不是“V4.1 Pro 是不是要来了”，而是两件更基础的事：能不能公开这次故障的原因，以及能不能把补偿标准写成一条看得懂的规则。
下一次再崩，先看两件事：原因说不说得清，补偿有没有规则。新模型的事，可以往后放。
