工作流设计
掌握 Coze 工作流设计，让智能体处理复杂多步骤任务
什么时候需要工作流
不是所有智能体都需要工作流。简单的问答场景用 Prompt + 知识库就够了，只有复杂的多步骤任务才需要工作流。
需要多个步骤串联需要工作流
先抓取网页内容 → 再提取关键信息 → 最后生成摘要报告
需要条件判断需要工作流
根据用户输入的语言，走不同的翻译流程
需要调用多个外部 API需要工作流
先搜索天气 → 再查航班 → 最后生成旅行建议
需要数据预处理需要工作流
先用代码清洗 CSV 数据 → 再让 AI 分析
需要人工确认需要工作流
AI 生成方案 → 等用户确认 → 再执行下一步
简单的一问一答不需要
用户问一个问题，AI 直接回答
基于知识库的问答不需要
用户问产品问题，AI 从知识库中检索回答
多轮对话但逻辑简单不需要
聊天式的英语口语练习
基本概念
工作流由三个核心元素组成：节点（做什么）、连线（什么顺序）和变量（传什么数据）。
工作流的基本执行单元。每个节点完成一个特定任务。
| 类型 | 说明 | 用途 |
|---|---|---|
| 大模型节点 | 调用 AI 模型处理文本。最常用的节点类型。 | 文本生成、摘要、分类、翻译等 |
| 代码节点 | 执行 Python/JavaScript 代码。用于数据处理和逻辑运算。 | 数据清洗、格式转换、数学计算等 |
| 知识库节点 | 从知识库中检索相关内容。 | 基于文档的问答场景 |
| 插件节点 | 调用外部插件或 API。 | 搜索、发送消息、调用第三方服务等 |
| 条件节点 | 根据条件走不同分支。 | 路由判断、分类处理等 |
| 变量节点 | 存储和操作变量数据。 | 数据传递、中间结果存储等 |
连接两个节点，表示执行顺序和数据流向。上一个节点的输出会作为下一个节点的输入。
| 类型 | 说明 | 用途 |
|---|---|---|
| 顺序连线 | 最基本的连线，A 执行完后执行 B。 | 线性流程 |
| 条件连线 | 根据条件判断走哪条线路。 | 分支处理 |
在节点之间传递数据的载体。每个节点可以定义输入变量和输出变量。
| 类型 | 说明 | 用途 |
|---|---|---|
| 输入变量 | 节点接收的数据，来自用户输入或上游节点。 | 接收用户问题、接收上一步的结果 |
| 输出变量 | 节点处理后产出的数据，传递给下游节点。 | AI 生成的文本、代码执行的结果 |
| 全局变量 | 在所有节点中都可以访问的变量。 | 用户 ID、会话参数等 |
5 个常见工作流模式
这 5 种模式能覆盖绝大部分工作流需求。复杂的工作流通常是这些基本模式的组合。
最简单的模式：节点按顺序依次执行，上一个的输出是下一个的输入。
输入 → 节点 A → 节点 B → 节点 C → 输出
案例：多语言翻译器
1.用户输入原文
2.大模型节点 A：检测语言类型
3.大模型节点 B：翻译成目标语言
4.大模型节点 C：润色翻译结果
5.输出最终翻译
适合简单的多步处理任务
每个节点只做一件事
注意变量命名的一致性
最适合：线性处理流程，步骤之间有明确的前后依赖
根据条件判断走不同的处理路径。类似 if-else 逻辑。
输入 → 条件判断 → [路径 A] / [路径 B] / [路径 C] → 合并 → 输出
案例：智能客服路由
1.用户输入问题
2.大模型节点：判断问题类型（售前/售后/投诉/其他）
3.条件节点：根据类型分流
4.售前 → 产品推荐流程
5.售后 → 退换货流程
6.投诉 → 转人工 + 记录日志
7.其他 → 通用回答
条件判断要覆盖所有情况，别漏了 else
每个分支可以是独立的子工作流
复杂分支考虑用大模型做分类
最适合：需要根据输入类型做不同处理的场景
重复执行某个步骤直到满足条件。适合迭代优化、批量处理。
输入 → 处理节点 → 检查条件 → [不满足：回到处理节点] / [满足：输出]
案例：文章质量迭代优化
1.用户输入文章主题
2.大模型节点 A：生成初稿
3.大模型节点 B：评估质量（打分 1-10）
4.条件判断：分数 >= 8？
5.否 → 大模型节点 C：根据评估改进 → 回到步骤 3
6.是 → 输出最终版本
一定要设置最大循环次数（防止死循环）
每次循环要有明确的改进方向
循环消耗 token 多，注意成本
最适合：需要迭代优化的生成任务
多个节点同时执行，最后汇总结果。适合需要从多个角度分析的场景。
输入 → [节点 A + 节点 B + 节点 C]（并行） → 汇总节点 → 输出
案例：竞品全面分析
1.用户输入竞品名称
2.并行执行 3 个分析：
A. 产品功能分析
B. 用户评价摘要
C. 定价策略分析
6.汇总节点：整合三方面分析，生成完整报告
并行节点相互独立，不要有数据依赖
汇总节点要处理好多个输入的整合
并行能提升执行速度
最适合：多维度分析、多来源数据整合
在关键步骤暂停，等待人工确认后再继续。适合高风险或重要决策场景。
输入 → AI 处理 → 展示方案 → 等待确认 → [确认：执行] / [拒绝：修改]
案例：自动化邮件发送
1.用户输入邮件目的和收件人
2.大模型节点：生成邮件草稿
3.展示给用户预览
4.用户选择：发送 / 修改 / 取消
5.修改 → 回到生成节点，附上修改意见
6.发送 → 调用邮件 API 发送
AI 可以犯错，关键操作一定要人工确认
展示时提供清晰的预览和修改入口
记录确认/拒绝的数据用于优化
最适合：对外发送、付费操作、不可逆操作
设计原则
遵循这 8 条原则，能让你的工作流更健壮、更易维护、更省成本。
单一职责
每个节点只做一件事。如果一个节点的 Prompt 超过 500 字，考虑拆分成多个节点。
正确
节点 A：分析用户意图 → 节点 B：生成回答 → 节点 C：格式化输出
错误
一个节点：分析意图+生成回答+格式化（Prompt 混在一起）
错误处理
每个可能失败的节点都要有错误处理。API 调用失败、AI 输出异常都要考虑。
正确
代码节点 try-catch → 失败走备选路径 → 给用户友好的错误提示
错误
假设所有节点都会成功，没有任何错误处理
变量命名规范
变量名要见名知义，用英文+下划线命名法。避免 var1、temp 这种含糊命名。
正确
user_question、translated_text、quality_score
错误
var1、tmp、result、data
先简后繁
先做最简单的顺序流程跑通，然后再加分支、循环等复杂逻辑。不要一开始就设计复杂架构。
正确
v1 顺序执行 → v2 加条件分支 → v3 加循环优化
错误
一上来就设计 10 个节点的复杂工作流
测试每个节点
工作流调试时，先单独测试每个节点的输入输出，确认正确后再连接。
正确
节点 A 测试通过 → 节点 B 测试通过 → 连接 A→B 测试 → 加入节点 C
错误
一口气搭完整个工作流，出了错不知道是哪个节点的问题
控制成本
工作流中的每个大模型节点都消耗 token。减少不必要的节点，能用代码解决的不要调 AI。
正确
代码节点做数据格式转换（0 成本）→ 大模型节点做分析
错误
大模型节点做 JSON 格式转换（浪费 token）
可观测性
在关键节点加日志记录，方便排查问题。记录输入、输出和耗时。
正确
每个节点记录：input、output、duration、token_used
错误
什么日志都不记，出了问题只能猜
版本管理
工作流每次修改都要保存版本。标注修改内容和原因，方便回滚。
正确
v1.0 基础版 → v1.1 修复分支 bug → v2.0 增加并行处理
错误
直接在线上改，改坏了回不去