工作流介绍
工作流支持通过可视化的方式，对插件、大语言模型、代码块等功能进行组合，从而实现复杂、稳定的业务流程编排，例如旅行规划、报告分析等。
当目标任务场景包含较多的步骤，且对输出结果的准确性、格式有严格要求时，适合配置工作流来实现。
功能概述
工作流由多个节点构成，节点是组成工作流的基本单元。例如，大语言模型 LLM、自定义代码、判断逻辑等节点。 工作流默认包含了 Start 节点和 End 节点。
Start 节点是工作流的起始节点，可以包含用户输入信息。
End 节点是工作流的末尾节点，用于返回工作流的运行结果。
工作流节点
工作流通用节点及说明
| 节点名称 | 描述 |
|---|---|
| 大模型 | 大语言模型节点，该节点支持选择不同的 AI 模型处理文本生成任务。 |
| 代码 | 代码节点。通过 IDE 编写代码处理输入参数，并返回输出值。 |
| 知识库 | 知识库节点。根据输入参数从关联知识库中召回数据，并返回。 |
| 条件 | if-else 逻辑节点。满足设置条件则运行 if 分支，否则运行 else 分支。 |
| 变量 | 变量节点。用于读取和写入 Bot 中的变量。 |
| 循环 | 通过设置循环次数和逻辑，来实现重复执行一系列任务。 |
| 工作流 | 集成已发布的工作流，可以嵌套子任务。 |
coze额外节点及说明
| 节点名称 | 描述 |
|---|---|
| 插件 | coze的插件节点，可以实现指定功能，比如封装的gpt4调用、头条搜索等功能，可以自定义插件。 |
| 图像流 | 集成图像流，可以嵌套子任务。 |
| 数据库 | 可支持对 Database 放开读写控制，用户可读写其他用户提交的数据，由开发者控制。需要提前在 Bot 的 Database 中添加 Table。 |
| 长期记忆 | 用于调用Long-term Memory，获取用户的个性化信息，对应的Bot必须打开了LTM |
| 文本处理 | 用于处理多个字符串类型变量的格式 |
通过使用场景介绍节点功能
简单场景
1、调用插件
比如调用图片理解插件，解析图片内容，当然还有很多插件，其插件特定和功能不一样，可以理解成插件就是封装的应用程序，里面也是代码逻辑、大模型交互等实现。可以自定义插件。
2、调用大模型
通过使用大模型（LLM）节点，设置大模型的模型类型，模型参数，输入参，输出参，提示词等调用大模型。支持批处理。当批处理有能力限制，并发最高10，一批次任务最高200。
3、使用代码实现指定逻辑
以下面为例，处理输入大模型的变量。
复杂场景
调用插件、LLM、子流程、代码、条件等实现特定业务场景，如：分析图片内容，并且优化文本，提炼文本骨干，聚合文本信息
条件判断作用：如何插件获取内容失败，直接结束。
代码作用：作为适配器，调整输入输出参数，方便使用以发布的子流程。
使用循环体
通过循环体实现业务功能
COZE总结
优点：
1、一站式服务，开发成本低，对开发人员要求低。
2、方便快捷的搭建自己的LLM工作流。
3、学习成本较低，上手快。
4、接入方便，可以通过bot或者直接使用工作流的方式接入，bot还可以发布到豆包、飞书等字节旗下平台中。
缺点：
1、使用coze的工作流、大模型、bot都需要收取费用，如果工作流中没有大模型交互也是要有费用产生。调用其他模型也需要key。但整体成本还好，费用不高。
2、coze插件能力有限，除了字节跳动自己应用的扩展功能，如短视频内容提取、头条搜索、抖音搜索等。
3、存在bug，coze还是在不断迭代过程，会出现使用上bug。特别是它集成了很多东西，复杂组合后，出现问题对生产端是致命的。
4、日志体系不完善，调试内调用还可以看出工作流哪里有问题，如果发布成API调用，日志不方便实时查询，排查需要时间。
5、插件、或者发布的工作流存在并发问题
如：图片理解插件其内部实现就是单线程不支持并发，并发报错，这是官方插件，并且插件描述没有提及。这样的坑估计不少。
工作流也会出现并发后连续失败，流程本身没有问题。超过20就出现了。
建议
如果公司以后有规划大模型方向的扩展，建议自己搭建自己的工作流，不依赖coze。
但开发周期和成本确实更高。
参考开源AI工作流：
https://dify.ai/
https://tryfastgpt.ai/
https://n8n.io/