我们公司的业务是对很多张数据表查询数据，查询规则很复杂，写在几个专门的算法表中。查询结果需要用文字、表格、统计图来显示。我们搭建了非常复杂的工作流(节点超过了Dify默认的50个限制)，修改、维护都很困难。Dify本身是号称“后端即服务”，提供了http接口来调用，但是我们之前对模型直接问答做了会话管理的功能，所以对接Dify时也需要对Dify返回的流式做进一步解析和转换。 Dify接口单个流式相应返回的字段过多，一开始我们没准确识别出特定节点所有流式的首尾部分（其实可以通过title来识别），而是在单个节点内部使用特定的标签来表示特定内容(如摘要的标题和内容、图表数据)。这个过程很繁琐，但是我们逐渐调整解析逻辑，基本可以处理Dify返回的各种类型的流式响应。 这期间及后来陆续遇到一些问题，包括： 1.不灵活 2.工作流模式下多轮会话实现困难 3.不稳定，时而断开与数据库的连接 4.内部实现难以调整（尽管是开源，但是我们通过使用docker镜像的方式来部署，修改源码之后仍然需要重新编译等操作） 5.Agent节点比较智能，但是其内容不是流式输出的。 此外，产品经理和前端同事也抗议很久，终于在一次公司重大客户会议后，我们换了技术方案，当然这又是另一个坑了。 #dify #工作流搭建 #ai应用开发