前面讲了 coze 的相关用法，这边想着用 Dify 也来一遍，刚开始的时候接触的是 Dify，后面才是 coze。Dify 和 coze 的侧重点不同，我个人是更倾向用 Dify 构建工作流就可以了，coze 还是相对全能。
本节用 Dify 也会创建插件，工具，工作流，API 调用，机器人就不在这边描述了(个人感觉不是很好用)
1. 创建工具
Dify 创建工具的方式只有通过 OpenAPI-Swagger 的 json 数据，方式是可以直接贴，或者 URL 导入，但是没有其他办法。
所以，就需要自己生成 OpenApi-Swagger 啦，还不支持 swagger 2.0。本身用的代码 web 框架还是 Gin，这点有点难受，有需求的可以看这篇 【Go】Swagger v2 转 OpenApi v3 CLI - swag2op。
所有接口的调整，也都只能在这个 Schema 里面修改，导入成功后，就只能有对应的子工具了。
有留意之前 coze 创建插件那一篇的朋友，应该感受到一个很大的区别，不过这个区别不在这边讲，见下一篇，或者见下面内容。
2. 创建工作流
创建的步骤就不赘述了，直接看进入工作流后的面板，这边我们用短语音识别来作为例子。
所有工作流的编排，测试，API，请求日志(这个是通过API接口调的)，分析，都在一个页面。
画布上一开始也只有一个节点，开始节点，这意味着可以有多个结束节点。注意，每个节点有且仅有一个子节点。
创建下一个节点的方式，只有在节点左右 2 侧的添加按钮(开始节点只有右侧有，结束节点就只有左侧有)。这样子的方式也挺直觉的，下一个节点要做什么，就在右侧显而易见。
2.1. 开始节点
开始节点的参数，只有 4 种:
- 文本：如果最大长度不设置，就是无限
- 段落：如果最大长度不设置，就是无限
- 下拉选项
- 数字
不设置是指，删除掉，而不是写 0
相对来说是比较少一点的，而且比较固定。
2.2. 工具节点
点击开始节点右侧创建按钮，选择到自定义工具，找到刚才创建的工具，点击即可。
点击后，会自动弹出这个节点的编辑页面，可能你要输入参数什么的，就会让你直接编辑。
选择参数的办法是通过 / 就会出来可以选择的参数，选择的参数也是在当前节点之前，以及开始节点的参数。
按照第二篇的方式，调用完授权接口，就要调实际的 AI 能力接口，同样的方法加入短语音识别的节点。这时候要配置 Authorization 变量，发现只有授权节点的一个 text 输出变量。而这个 text 其实是，auth 接口返回的整个 json 结构体，而不是 Authorization。
这里其实很不方便，如果字段多一点的，就很麻烦。所以 Dify 的工作流可能更倾向于对话的工作流，而不是这种有很多返回变量。因此，我们就要在每个工具调用后，添加一个代码节点，转换出我们要的变量。
修改节点也不用删除节点，再添加，可以直接点击节点右上角有一个更改节点，就可以替换成代码执行节点。
注意，千万要想清楚你的整个流程，再去创建流程，没有 Ctrl + z 回退。如果你的这个节点配置好了所有参数，或者 LLM 节点配置了prompt，一替换就是全部消失(不要问我怎么知道的)。
2.3. 代码执行节点
代码执行节点，支持 python3 和 javaScript 代码。输入变量的赋值，就是上一个节点的 text，解析这个 json object ，然后把你需要的值返回出来。输出变量的名称要跟代码里面的一致，不然会一直报错，也不会告诉你因为变量不同。
这样子提取出来后，就可以复制给下一个工具节点
2.4 配置结束节点
假设我们配置好了短语音识别工具，再用代码提取出来 result 结果，这个结果就可以给 End 节点输出。
2.6. 整体
2.7. 大模型节点
这个工作流没有用到 LLM，但还是想提一下。Dify 的 LLM 节点就是可以配置自己的大模型，也可以在本地部署开源大模型，可以用到比较多的大模型。在 Agent中，用户最多可同时选用 4 个大型模型进行协同测试，这一设计使得 Dify 平台更倾向于为工作流程或 Agent 提供一个环境，让使用者能够集中精力于工作流程的精细打磨与优化。
2.8. 调试工作流
右上角点击运行就是调试页面，调试结果就是呈现在右侧的这么一小条里面，即使是点了展开，宽度也是一样。这样在对长的内容，其实不是很友好，不过每个节点的信息还是记得详细的。
3. API 调用
Dify 对工作流的所有功能都集中在一个页面，这样不用去别的地方找，编排下面就是访问 API。访问 API 页面右上角就是 API 密钥的管理，创建。接口文档也在同一个页面，这样子就很快可以让开发者去实现接口调用。前提一样，要发布这个工作流，也不用别人审批。
我们只列一下 Blocking 模式的接口
鉴权
API 密钥申请
请求地址
http://{IP跟每个人部署时候配置的 HOST 有关}/v1/workflows/run
Header
| 参数 | 取值 | 说明 |
|---|---|---|
| Authorization | Bearer $Access_Token | 用于验证客户端身份的访问令牌，API 密钥 |
| Content-Type | application/json | 解释请求正文的方式。 |
Body
inputs
类型：json object
是否可选：可选
说明：开始节点需要传入的参数
response_mode
类型：string
是否可选：必选
说明：
返回响应模式，支持
streaming流式模式（推荐）。基于 SSE 实现类似打字机输出方式的流式返回。blocking阻塞模式，等待执行完毕后返回结果。（请求若流程较长可能会被中断）。
user
类型：string
是否可选：必选
说明：用户标识
响应字段
| 参数 | 类型 | 说明 |
|---|---|---|
| workflow_run_id | Integer | workflow 执行 ID |
| task_id | String | 任务 ID，用于请求跟踪和下方的停止响应接口 |
| data | String | 工作流执行结果，通常为 JSON 序列化字符串，部分场景下可能返回非 JSON 结构的字符串。 |
| - id | String | workflow 执行 ID |
| - workflow_id | String | 关联 Workflow ID |
| - status | String | 执行状态, running / succeeded / failed / stopped |
| - outputs | Object | 输出内容，响应字段里面的 outputs 就是 end 节点里面配置的结果。如果里面是 result，那 output 里面就是 {"result":"xxxx"}。 |
| - error | String | 错误原因 |
| - elapsed_time | Integer | 耗时(s) |
| - total_tokens | Integer | 总使用 tokens |
| - total_steps | Integer | 总步数（冗余），默认 0 |
| - created_at | Integer | 开始时间 |
| - finished_at | Integer | 结束时间 |
示例
4. API 日志
发布之后的所有调用日志都可以查到，用接口返回的日志 ID 搜索，就可以找到刚才调用的结果，详情及追踪，这个还是很好用的。
不过有一个不好的是，返回的 log id 和 task id 并不能用来做搜索，必须得自己在输入加一个 uuid，然后才能搜索出来。
总结
初步用下来，Dify 挺适合团队内部构建工作流使用的。虽然有一些体验上不是很好，但是适合创建大模型的一些中间应用。而且工作流创建完之后，有一个日志追踪的，省掉了再加一个监控的系统(当然是对测试的时候)。给到其他开发，还是给到产品，都可以快速地体验以及分析其中的问题。如果有些小的体验上做一些优化，那这个工作流的体验其实还是很不错的，尤其是在工具节点的优化上。
最后一篇呢，就列了一些我对比 coze 和 Dify 的一些体验上的不同，Coze使用开放平台接口-【7】Dify 比较篇。