自建AI平台:一步步教你搭建Dify,使用Agent工作流并实现AI微信消息生成发送
最近一直在琢磨怎么把那些复杂的AI工作流落地到实际项目中,试来试去,发现自建一个类似Coze的AI应用开发平台,可能是现阶段最靠谱的选择。Coze海外版开始收索免费额度了,这账大家心里都清楚。市面上能支持复杂AI工作流的开源项目,掰着手指头数也就两个:FastGPT和Dify。从网上的反馈和实操体验来看,我个人觉得Dify的操作界面更顺手,支持的模型也更全面一些。下面就把我的实践过程拆开了讲一讲。
Dify是什么
Dify的官方项目地址和介绍大家可以在GitHub上找到,这里不赘述。简单说,它是一套开源的大语言模型(LLM)应用开发平台。它的核心思路是把“后端即服务”(BaaS)和“LLMOps”的理念揉在一起,让开发者能快速把生产级的生成式AI应用搭起来。哪怕不是技术人员,也能参与到应用的定义和数据运营中。
关键在于,Dify内置了构建LLM应用的关键技术栈:从支持数百个模型、可视化的Prompt编排界面,到高质量的RAG引擎、稳健的Agent框架,再到灵活的流程编排和一整套易用的界面与API。这些东西,以往每一个都得花不少时间去“造轮子”,现在它直接帮你打包好了,剩下的精力可以完全集中在业务创新上。
搭建实战
官方文档里有很详细的搭建教程,跟着走基本不会出大问题。核心步骤就是先把GitHub上的开源项目clone下来,然后用docker部署运行。
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d
这里有一个很实际的坑需要注意:官方配置文件里默认的端口是80和443,这在本地环境里十有八九会跟已有项目冲突。一定要记得把`docker/.env`文件里的`EXPOSE_NGINX_PORT`和`EXPOSE_NGINX_SSL_PORT`改成不冲突的端口,比如8080和8443。改完之后,通过修改后的端口访问,设置管理员的账号密码,就能直接进入主应用界面了。
从Coze迁移一个微信消息机器人
安装好之后,我打算把之前在Coze上做的微信消息转发机器人迁移过来试试水。在开始之前,首先要添加大模型供应商。这里有个小门道:OpenAI的API Key可以去某宝上买,性价比很高。在右上角头像的设置里,把OpenAI的ChatGPT-4模型配置好。
接着需要理清一个关键概念:在Dify里,Agent和Workflow是两种完全不同的东西。
Agent
Workflow
在实际应用中,通常是两者结合:让Agent负责理解用户意图和对话上下文,然后调度Workflow去执行具体的、结构化的功能。这次迁移任务,我就是这么干的。
具体步骤:先创建一个Workflow。添加两个输入参数:一个是“好友昵称”,一个是“消息内容”。
然后,在Workflow后面加一个HTTP请求节点,用来调用微信消息发送的API。关于如何获取这个微信发送消息的接口,可以参考我之前分享的文章《独门秘诀,用Coze机器人创建插件调用微信接口代替我发消息》。简单说,就是把接收到的“好友昵称”和“消息内容”组装成API需要的参数格式。
最后,再创建一个“结束”节点,把HTTP请求的返回结果(成功或失败状态)作为最终输出。发布这个Workflow时,记得给它起一个别名,比如`wechat_message`,后面Agent调用时要用到。
接下来创建一个Agent。在Agent的工具箱里,把刚才发布的`wechat_message`工作流添加进来。然后,给它设置一段默认的Prompt,告诉它该怎么使用这个工具:
请确保你作为一个聊天机器人,在处理对话时能够深刻理解对话内容及对话者的意图。使用wechat_message工具时,不要简单地直接转发信息,而应该基于对话的上下文,生成富有洞察力且相关的回复。这样的处理不仅展示了你的语义理解能力,还能有效地提升对话的质量和参与度。

效果实测下来,整个流程跑得非常顺畅。当你给Agent发送一条消息,它会先理解上下文,然后调用`wechat_message`工作流,生成一个符合语境的回复,并通过微信发送出去。跟Coze的效果几乎一致,但整个控制和定制权都握在自己手里了。