摘要：Dify应用平台在内部使用的主要问题在于：当前无法确定一个稳定版本用于生产环境。目前Dify发布的新版本中总会引入新的不可预知的问题，以最近发布的1.9.0~1.9.2版本为例进行说明（仅描述个人发现的问题）：

1.9.0版本：新增知识库流水线功能，即允许用户更加灵活的方式设计和实现知识库，这个是非常有吸引力的一个功能点。但是在试用这个版本过程中发现，迭代器中的LLM节点无法运行，这个问题稍微有点麻烦，已经影响了复杂任务的正常编排。

1.9.1版本：修复了上面的迭代器中LLM无法运行问题，但是引入新的问题，即流水线知识库不可用，提示“instance not bound to a Session”，以及workflow工作流发布页面中文件无法正常上传；

1.9.2版本：甚至出现了流水线知识库以及原知识库均出现不可用的问题。

因此这里引出两个问题：

1、如何构建一个相对稳定的版本用于内部使用？

2、在得到一个相对稳定的版本的基础上，针对Dify升级如何进行跟进？在保证引用Dify新特性的同时，如何保证生产环境的稳定性？

二、问题思考

这里需要针对Dify平台设计一套的公司内部测试方案，包括应用编排测试以及API接口测试。保证测试方案能够尽可能覆盖Dify应用场景。通过内部集中测试的形式来保证Dify内部版本的稳定性。

从目前来看，1.9.0版本是相对稳定版本，至少知识库是可用的，而且有些已知问题在新版本已经得到解决。我们可以以该版本为基础版本，进行内部稳定版本测试及构建，主要包括以下两种场景：

（1）针对Github上已知且在新版本已解决问题，进行小范围代码合并并验证；

（2）针对集中测试过程中新发现的问题，需评估其影响程度，视情况进行修复；

内部稳定版本测试通过后，首先在实验室环境部署上线，并持续运作两周时间。在此期间，告知Dify用户可在实验室环境下对自己的已发布应用进行功能二次验证。同时针对发现的问题及时沟通，并修复。

实验室环境中稳定运行两周时间后，再将稳定版本正式上线生产环境。

首先，这里不建议生产环境频繁跟进Dify升级进度，一方面是其有一部分更新内容和我们的内网环境应用关系不大（例如云存储），另外就是升级过程中往往会引入不可预见的问题，为了保证升级版本的稳定，需要投入较多的人力进行测试、验证。

这里建议采用以下方式进行跟进：

1、针对小范围功能优化，我们可以参考Github上面的代码提交记录，直接合并到我们的稳定版本中。

2、针对大版本升级以及大的功能合入（例如这次的流水线知识库），则需要对升级版本进行完整的功能测试后，再进行上线试用。另外，也可以在大版本出来之后，观察社区的问题反馈情况，根据问题反馈情况决定是否进行升级。

生产环境，用于生产AI应用部署并对外发布应用及服务，需保证平台版本的稳定性；

实验室环境，用于小范围进行Dify新版本验证，不保证平台版本的稳定性；

发布要求：正式对外发布应用或后端服务，必须部署到生产环境中。

另外，应该还有开发环境以及测试环境，用于本地版本的开发与维护，不再赘述。

三、写在最后

以上，是针对Dify产品如何在企业中进行实际落地的一点想法，也欢迎大家在留言区进行交流、分享，你们是如何保证Dify平台在本地稳定运行的呢？再次声明，以上仅代表自己的一点不是很成熟的想法，仅作参考。另外，有没有小伙伴购买了企业版的Dify，能否分享一下企业版Dify的使用体验？

来源：正正杂说