【GPT】Coze使用开放平台接口-【6】Dify 也来一遍

前面讲了 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 比较篇。

---

上一篇：Coze使用开放平台接口-【5】API 调用