有了之前的文章铺垫，这篇文章开始，我们聊聊如何折腾 AI 工作流，把不 AI 的应用，“AI 起来”。
上个月，我们聊过了《使用 Dify 和 AWS Bedrock 玩转 Anthropic Claude 3[1]》，里面介绍了如何使用交互体验较好的 prompt IDE，来帮助我们方便的调试 AI 应用中的 prompt，以及快速搭建一个 AI 应用。
半个月前，Dify 团队推出了包含 AI Workflow 新功能的 v0.6.0[2]，这个功能虽然从去年年底就在做了，但是因为功能复杂，代码变更量巨大，直至今天 v0.6.4[3] 正式发布，才算进入一个相对稳定期，所以适合写一篇新的文章来聊聊啦。
感受下 Dify 团队在过去两周的发布动作：
•v0.6.0[4] （带有 AI Workflow 功能和一大堆更新，1241 个文件变动）•v0.6.0-fix[5] （紧急修正：Agent 应用的添加功能）•v0.6.1[6] （修复了 23 项内容）•v0.6.2[7]（支持了新的模型、新的图片 Agent，并且修复了 17 项内容）•v0.6.3[8]（增加一堆新功能，比较有意思的是 PgVector，Workflow 支持快捷键操作，prompt 中引用的变量可以自动改名字，修复了 14 项内容）•v0.6.4[9]（支持了代码解释器、月之暗面模型的 FuncCall、SD3，修复了 20 项内容）
小步快跑，干的漂亮。
而获取 API Key 难度很低的 MoonShot，则在最近悄悄上线了 “Tool Use[10]” 功能。在开源社区里，我们一般称这个功能为 Function Call，借助特殊构造的请求结构和提示词，来让模型自动的调用用户预定义的远程函数，实现智能的 RPA 调用。
能够调用“外部工具”的模型功能
我计划将工作流相关的事情拆分为两篇来聊，过程中不太想切换模型，所以就选择了支持 “Function Call” 的它。下篇相关的文章，我们展开聊聊，如何利用这个功能，结合“Workflow”来做一些有趣的自动化。本篇文章是基础篇，我们就先用它的基础功能就好，难度大概是 “有手就行”。
我将本文用到的 Dify 和 WordPress 的 Docker “一键启动”配置相关文件开源在了 soulteary/dify-with-wordpress[11]，如果你感兴趣一些使用和配置上不同于官方的小的优化、维护技巧，可以翻阅下文的“维护优化”小节。
我们先从基础实战开始。
Docker 运行环境
想顺滑的完成实践，我推荐你安装 Docker，不论你的设备是否有显卡，都可以根据自己的操作系统喜好，参考这两篇来完成基础环境的配置《基于 Docker 的深度学习环境：Windows 篇[12]》、《基于 Docker 的深度学习环境：入门篇[13]》。当然，使用 Docker 之后，你还可以做很多事情，比如：之前几十篇有关 Docker 的实践[14]，在此就不赘述啦。
快速初始化 WordPress
在之前的两三篇文章《把 WordPress 变成 BaaS 服务：API 调用指南[15]》、《WordPress 告别 MySQL：Docker SQLite WordPress[16]》、《WordPress SQLite Docker 镜像封装细节[17]》中，我介绍过轻量化的、能够在本地快速运行的 WordPress，以及能够提供 API 交互的 WordPress 方案。感兴趣可以自行翻阅，这里就不展开具体细节啦。
为了能够更简单的折腾本文的内容，我封装了一个开箱即用的、轻量化的、能够提供 API 交互的 WordPress Docker 镜像，项目开源在了 soulteary/docker-wp-api[18]，使用方法非常简单：
使用上面的命令完成 Docker 镜像的下载，然后使用类似下面的配置，可以快速启动这个镜像中的 WordPress：
完整的验证环境
当然，为了更简单一些，我将文章相关的代码和配置都开源到了 soulteary/dify-with-wordpress[19]，你可以在项目中获取所有的代码。项目中的配置将 Dify 和它相关的依赖、WordPress 都打包到了一起：
当我们获取项目代码后，执行 之后，稍等片刻，我们就可以在浏览器中分别访问：
• 来初始化和访问 Dify• 来初始化和访问 WordPress
一路 “Next” 快速初始化 Dify
一路 “Next” 快速初始化 WordPress
当两个应用都初始化完毕后，我们就完成了所有的准备工作。
如果你也经常写文章或者文字材料，那么我相信你或许和我一样，在给写好的内容起合适标题的时候，可能会发愁、挠头。
那么，我们就先来实现一个简单的功能，让 WordPress 能够在我们写好内容的时候，根据内容自动生成一个合适的标题。你可以举一反三，来让其他的“内容生成、优化”也都 AI 化。
初始化 Dify 中的模型配置
点击界面右上角的用户头像，在下拉菜单中点击“设置”，在弹出窗口中选择左侧的“模型供应商”菜单，能够看到 Dify 支持配置使用的所有模型类型。
在 Dify 模型配置中设置模型的 API Token
在列表中往下拉，找到“月之暗面”，然后把我们的模型 API Token 配置到 Dify 中。
设置默认的系统推理模型
配置完毕之后，在这个弹出窗口的顶端选择“系统模型设置”，将“系统推理模型”设置为反应最快、成本最低的 8K 模型。
在 Dify 中配置好的模型
当两个配置都设置完毕后，这个弹出窗中展示的模型在 Dify 中就完全可用啦。
创建一个“AI 文本生成”应用
创建一个文本生成应用
关闭上面的弹出窗口，我们创建一个新的文本生成应用，你可以根据你的喜好来填写应用的标题和描述。
编写我们的提示词内容
根据我们的设想，我们的模型应用应该能够根据我们提供的内容，来自动生成一个合适的标题，为了让模型干活符合预期，我们可以在 Dify 的 IDE 中完成 prompt 的调试和编写工作。
这里建议使用相对有层次的 Markdown 语法来给模型“立一些规矩”，效果会相对好一些，这里假设模型是“机器之心”的记者，擅长挖掘内容和编写标题：
在上面的提示词中，我们设置了一个名为 “” 的变量，在随后的真实模型调用中，我们可以在 API 的请求参数中动态的调整这个数据内容，来让它解决不同的文章的标题生成任务。
设置模型的具体参数
因为我们希望标题生成的相对合理，和内容比较有相关性，并且标题字数比较少，所以我们可以参考上面的方式来进行模型调用参数设置，来让模型的调用时间更短一些。
选择一篇测试内容
既然我们的 prompt 提示词都选择的人设都用了“机器之心”，那么验证测试的文章也选择机器之心的报道好啦，比如，这里我选择的是 “Linus 喷 AI 炒作的一篇报道[20]”。
调试模型输出结果
将测试内容粘贴到调试对话框中，点击“运行”，我们就能够验证模型在这个 prompt 和调用参数下的表现了，你乐意的话，可以打开好几家不同的模型进行调试比较。
这里可以看到，在之前的 prompt 要求下，虽然没有生成出“机器之心”感觉的标题（模型生成的标题相比有些无聊），但是确实按照要求生成了一条符合字面要求的标题，满足继续往下折腾的要求。如果你有更高的要求，可以耐心调整上面的 prompt 提示词。
那么，我们开始在 WordPress 中的折腾。
制作 WordPress 标题生成插件
访问 Dify 应用 API
在 Dify 配置的 AI 应用页面中，我们点击“发布”按钮，在下拉菜单中选择“访问 API”，我们就能得到如何通过 API 访问配置好的 AI 应用的文档说明了。
向模型应用发送请求
我们只需要调用 接口，将刚刚 prompt 中设置的 传入接口即可。
获取当前应用的 API Key
在调用 Dify API 的时候，我们需要进行身份验证，在这个页面的右上角，点击“API 密钥” 按钮，创建一个 API 密钥即可。
创建好 Dify AI 应用的 API Key 后，我们可以将上面文档中的调用写成一个简单的 PHP 模型调用函数。这个函数接收一个参数（文章内容），并将文章内容传入 Dify 的调用结构体中，当 Dify 调用 Moonshot 模型后，我们解析调用结果，取出返回内容中的 字段，就得到了模型生成的标题内容。
而让 WordPress 能够在我们的文章有内容，没有标题的时候，调用上面的函数，就更简单了（借助 WordPress 定制能力中的 hooks/the_post[21]）：
完整的插件程序实现，可以在 soulteary/dify-with-wordpress/title-generate.php[22] 找到，你可以将这个文件放置到你启动 WordPress 程序目录的 位置，然后在你的 WordPress 后台的插件管理中启用这个插件。（注意替换 为你真正部署 Dify 的 IP 地址或域名）
启用 WordPress AI 插件
体验插件能力
这里，我们还是偷懒，暂且用机器之心的一篇文章[23]来作为“标题生成素材”。
找另外一篇机器之心的文章做素材
打开机器之心的文章，复制一部分用于标题生成的文本内容。当然，你也可以自己写一些内容，替换我们直接从网上找的测试验证内容。
在 WordPress 中创建新的内容
接着，打开 WordPress 后台，创建一篇新文章，然后在内容中输入一些内容，我这里偷懒，选择了粘贴刚刚找到的机器之心的文章内容。既然要 AI 来生成标题，标题区域我们留空就好。
点击发布，AI 将迅速的生成标题
当我们点击“发布”按钮后，WordPress 会调用上文中我们配置好的 Dify AI 应用，将我们的文章内容发送给 Dify，构建出一个新的（完整的）提示词，然后向 Moonshot 的模型进行请求，并将模型生成结果填充到标题区域。
当然，因为我们上文中的模型参数设置的相对合理，这个时间应该在 1 秒到 2 秒之间。
因为我们的 prompt 提示词和模型调用参数是维护在 Dify 中的，所以我们如果想完善模型的生成规则、风格、生成数量，我们只需要更新上文中 Dify IDE 中的 prompt 提示词内容，而不需要修改程序，这是不是非常方便呢？
Dify 项目的默认配置目前有比较大的优化空间，可以让配置更简单、更易于长期使用的维护管理。
优化 Docker 配置文件
官方很贴心的在项目中提供了一键启动的配置文件[24]，不过如果你认真浏览，你会发现官方尽可能给出了丰富的选项。
•你能够调整前端服务、后端 API 服务、实际干活的 Worker、代码执行沙盒环境的一些配置。后端服务和实际干活的 Worker 还是一个镜像，省却了一些下载的功夫。•你能够设置或替换 Postgres 数据库、Redis 缓存、Weaviate（默认使用）和 Qdrant （支持全文索引）向量数据库，甚至还有网关程序 Nginx 的细节。
但是，Dify 相关服务的配置目前其实稍显复杂，API 和 Worker 虽然是同一份镜像，但是在不同的工作模式下，他们的配置是有一些不同的。
所以，我们可以通过 Compose File 的 env file[25] 功能，来对官方的配置文件进行抽象和整理，让骨干配置文件更清晰和简洁，比如我们可以将原本 230 多行的配置简化为下面更简洁漂亮的格式：
根据服务需要的环境变量，我们分别将两个服务需要的环境变量（配置）保存在 和 两个文件中，而两个服务共享的数据库相关配置，我们可以保存在 中，做到“共享环境配置”，改一处文件两处服务都受益。
优化 Nginx 配置文件
官方的 Nginx 配置文件应该借鉴了 Nginx Docker 容器中被模块化处理过的配置示例，相关的配置文件一共使用了三个，使用了传统的嵌套配置，并且包含了冗余的反向代理配置，尽管已经努力的抽象了一个名为 的配置。
我们可以用一个简洁的表达方式来完成相同的诉求，甚至让配置变的更加适合 “扩容”，抽象需要分发流量的 “前端” 和 “后端”，在必要的时候，只需要扩展 “服务数量即可”：
关于其他的配置优化、应用配置细节，我们在后面的文章中陆续展开，这里就先聊到这里。
好啦，这篇文章就先聊到这里，后面的文章里，我们继续聊聊如何构建 “AI 工作流”，让你的不 AI 的应用，能够 AI 化。
关于本文中埋的一些未展开的伏笔，其实有很多有趣的玩法，比如可以将 WordPress 变成一个低成本的、简单的 RAG 知识库、带有版本管理的 CMS、搭配模型使用的带版本管理的图床。
我们下篇文章再见。
--EOF
引用链接