DeepSeek Harness的官方GitHub代码仓库里出现了三个DeepSeek此前从未公开过的模型，分别为deepseek-v5、deepseek-v5-open、deepseek-v5-next。

这段代码来自于DSH里账号登录通路的测试文件provider.spec.ts。

用户登录账号后，客户端会向服务端的/models 接口要一份模型清单，再根据清单决定哪些模型能用，哪些要先把DSH本身更新到新版本。

deepseek-v5是最基础的模型，没有声明客户端版本要求，当前版本的内置目录不认识它，所以隐藏，调用时报MODEL_UNSUPPORTED。

deepseek-v5-open代表开放给所有用户。声明的最低客户端版本是0.0.1，也就是任何版本的客户端都能直接使用，会正常出现在模型列表里。

deepseek-v5-next代表着后续更新的模型，需要升级DSH才能使用。要求的最低版本是99.0.0-alpha.1，而目前公开的DSH版本还停留在0.2.x。

很明显，DSH永远不会更新到99.0.0版本，所以deepseek-v5-next只是测试里随手写的一个“永远达不到”的版本，用来稳定触发“版本不够”这个分支。

换句话说，DeepSeek把V5发布时可能遇到的三种局面，提前写进了测试：不用更新DSH就能用的V5，必须先更新DSH才能用的V5，以及当前版本压根不认识的V5。

一些网友认为，测试里的模型都是假数据，这不过是占位符而已。

虽然占位符在软件行业中确实很常见，用来给以后的更新铺路。

但占位符的本质是给工程师用来提前把关的。等V5真上线了，不管用户装的是哪个版本的DSH，软件都不会出问题。

这种保证只有在“V5确实会来”的前提下才有意义。没有人会为一个不在路线图上的名字，去设计分级发布的机制。

何况占位名有那么多选择，随便一个字符串都行，DeepSeek既然选的是V5，就代表要不然V5已经在训练了，要不然V5已经在未来的排期里了。

再看这套机制本身，你会发现DeepSeek想解决的是一个“发布效率”问题。

在以前，新模型要上线，客户端也得同步发版，用户得先把软件更新到新版才能看到。而现在，服务端只要改一下/models的返回内容，新模型就能直接对用户开放，即deepseek-v5-open所对应的方式。

仓库的更新记录里，也出现了“DeepSeek API key适配器现在和账号登录用同样的方式更新模型列表”的改动，说明这套机制正在被推广到更多入口。

这代表DeepSeek V5发布时，除了DSH以外，其他能调用DeepSeek模型的软件，都可以秒切DeepSeek V5，不需要再让用户更新一下客户端。

deepseek-v5-next对应的，则更像是为“新架构、新能力”准备的。如果V5需要新的客户端能力才能用，比如新的推理参数或者新的交互方式，这条路径就派得上用场了。

两条路径同时备好，说明DeepSeek对V5具体的上线方式，已经想得很清楚了。

不过还要补充一点，这三个V5模型并不是今天上传的。实际的上传时间是2026年9月24日，上传者是毕业于清华大学的蒋奕晨。

从GitHub仓库页来看，蒋奕晨是DSH的核心贡献者之一。DSH初期，他的提交数排名项目第二，仅次于崔添翼，参与了模型适配、Web、连接恢复等大量研发工作。

特别声明：本文为合作媒体授权DoNews专栏转载，文章版权归原作者及原出处所有。文章系作者个人观点，不代表DoNews专栏的立场，转载请联系原作者及原出处获取授权。(有任何疑问都请联系idonews@donews.com)