第8章 工作流编排入门：节点、连线、条件分支与循环
AI智能体实战训练营 · 章节 8/33 · 45 学时
工作流编排入门：节点、连线、条件分支与循环
如果说Prompt是智能体的"灵魂"，那么工作流就是智能体的"骨架"。工作流编排（Workflow Orchestration）是把复杂任务拆解成一系列有序的步骤，通过节点和连线把这些步骤组织成一个可执行的流程。它是智能体开发中最核心、最实用的技能之一。
本章将带你从零开始学习工作流编排的基础知识，包括节点、连线、条件分支、循环等核心概念，以及如何在实际中设计和调试一个工作流。
💡 为什么要学工作流编排？
• 稳定性：工作流把任务拆解成固定步骤，每一步的输入输出明确，结果可预测、可复现
• 可调试：出了问题可以定位到具体哪个节点，而不是面对一团乱麻
• 可复用：工作流中的节点可以在其他流程中复用，提高开发效率
• 可监控：每个节点的执行状态、耗时、结果都可以记录和监控
• 团队协作：工作流是可视化的，团队成员都能理解和维护
• 稳定性：工作流把任务拆解成固定步骤，每一步的输入输出明确，结果可预测、可复现
• 可调试：出了问题可以定位到具体哪个节点，而不是面对一团乱麻
• 可复用：工作流中的节点可以在其他流程中复用，提高开发效率
• 可监控：每个节点的执行状态、耗时、结果都可以记录和监控
• 团队协作：工作流是可视化的，团队成员都能理解和维护
一、工作流的基本概念
1.1 什么是工作流？
工作流（Workflow）是一系列有序的、可重复的任务步骤的集合。它定义了"先做什么、后做什么、什么条件下做什么、做完之后输出什么"。
在智能体开发中，工作流通常是可视化的——你用拖拽的方式把节点拖到画布上，用连线把节点连起来，设置好每个节点的参数和条件，然后运行整个流程。
📋 生活中的工作流示例：煮一碗面
节点1【烧水】：把水烧开
→ 节点2【煮面】：水开后下面，煮3分钟
→ 条件分支【要不要加蛋？】
→ 如果要：节点3a【煎蛋】：煎一个荷包蛋
→ 如果不要：跳过
→ 节点4【调味】：加盐、酱油、葱花
→ 节点5【出锅】：把面盛到碗里
这就是一个简单的工作流：有节点（烧水、煮面、煎蛋...）、有连线（顺序执行）、有条件分支（要不要加蛋）、有最终输出（一碗面）。
节点1【烧水】：把水烧开
→ 节点2【煮面】：水开后下面，煮3分钟
→ 条件分支【要不要加蛋？】
→ 如果要：节点3a【煎蛋】：煎一个荷包蛋
→ 如果不要：跳过
→ 节点4【调味】：加盐、酱油、葱花
→ 节点5【出锅】：把面盛到碗里
这就是一个简单的工作流：有节点（烧水、煮面、煎蛋...）、有连线（顺序执行）、有条件分支（要不要加蛋）、有最终输出（一碗面）。
1.2 工作流 vs Agent自主决策
在第6章我们讲过，智能体有两种基本模式：固定工作流和Agent自主决策。它们各有优缺点，适用于不同场景：
| 维度 | 固定工作流 | Agent自主决策 |
|---|---|---|
| 流程确定性 | 流程固定，每一步都预设好 | 流程动态，由Agent自主决定 |
| 结果可预测性 | 高，相同输入基本相同输出 | 较低，每次执行路径可能不同 |
| 灵活性 | 低，只能处理预设场景 | 高，能应对未预设的情况 |
| 调试难度 | 低，可以定位到具体节点 | 高，需要追踪Agent的思考过程 |
| 成本 | 低，token消耗可控 | 高，可能多次调用大模型 |
| 适用场景 | 标准化、重复性高的任务 | 复杂、开放式、需要灵活应对的任务 |
实践建议：在实际项目中，最好的方式是"工作流为主，Agent为辅"——整体框架用工作流保证稳定性，在需要灵活判断的节点用Agent。比如，一个"客户投诉处理工作流"：接收投诉（固定节点）→ 分类投诉类型（Agent节点）→ 根据类型走不同处理流程（条件分支）→ 生成回复（Agent节点）→ 审核回复（固定节点）→ 发送回复（固定节点）。
二、工作流的核心元素详解
2.1 节点（Node）
节点是工作流的基本处理单元，每个节点完成一个特定的任务。节点有输入、有处理逻辑、有输出。
常见的节点类型：
| 节点类型 | 功能 | 典型应用 |
|---|---|---|
| 开始/结束节点 | 标记工作流的开始和结束 | 每个工作流都有一个开始节点和一个或多个结束节点 |
| 大模型节点（LLM） | 调用大模型进行文本生成、分析、推理 | 写报告、分析数据、生成回复、翻译 |
| 工具调用节点 | 调用外部工具或API | 搜索、查询数据库、发送邮件、调用企业系统API |
| 知识库检索节点 | 从知识库中检索相关信息 | RAG场景，检索文档、案例、政策 |
| 条件判断节点 | 根据条件选择执行路径 | 如果是VIP客户走特殊流程，如果是普通客户走标准流程 |
| 数据处理节点 | 对数据进行转换、过滤、聚合 | 格式化输出、提取关键字段、合并数据 |
| 循环节点 | 重复执行某个子流程 | 批量处理多条数据、反复修改直到满足条件 |
| 并行节点 | 同时执行多个分支，最后汇总 | 同时分析多个维度、同时调研多个竞品 |
| 人工审核节点 | 暂停流程，等待人工审核 | 重要内容发布前的人工审核、高风险操作的人工确认 |
| 代码执行节点 | 执行自定义代码（Python/JS） | 复杂的数据处理、特殊的算法逻辑 |
节点设计原则：
- 单一职责：每个节点只做一件事，不要把多个功能塞进一个节点
- 输入输出明确：明确节点需要什么输入、产生什么输出、输出格式是什么
- 可独立测试：每个节点应该可以单独运行和测试，不依赖整个流程
- 错误处理：节点应该有错误处理机制，出错时返回明确的错误信息
2.2 连线（Edge）
连线定义了节点之间的执行顺序和数据流向。连线从一个节点的输出连接到另一个节点的输入，表示"前一个节点执行完后，把输出传给后一个节点执行"。
连线的类型：
- 顺序连线：最基本的连线，前一个节点执行完就执行后一个节点
- 条件连线：满足特定条件时才执行（如"如果审核通过"、"如果分数大于60"）
- 数据连线：只传递数据，不控制执行顺序（用于并行分支之间的数据共享）
连线设计原则：
- 避免交叉：连线尽量不要交叉，保持流程图清晰易读
- 避免循环依赖：不要出现A→B→A的死循环（除非是有意设计的循环节点）
- 数据匹配：前一个节点的输出格式要和后一个节点的输入格式匹配
- 标注清晰：条件连线要标注清楚条件是什么（如"通过"、"不通过"）
2.3 变量（Variable）
变量是在工作流中传递的数据。每个节点的输出都会变成工作流的变量，可以被后续节点引用。
变量的类型：
- 全局变量：在整个工作流中都可以访问的变量，如用户输入、工作流配置
- 节点输出变量：每个节点执行后产生的输出，可以被后续节点引用
- 临时变量：在某个节点内部使用的变量，不传递给其他节点
变量的引用方式：通常用模板语法引用变量，如{{node1.output.text}}表示引用node1节点输出的text字段。不同平台的语法可能略有不同，但核心思想是一样的。
变量设计原则：
- 命名清晰：变量名要能反映内容，如
{{customer_name}}比{{var1}}好 - 结构合理：复杂数据用结构化格式（如JSON），方便后续节点处理
- 避免冗余：不要传递不需要的数据，保持数据流简洁
- 类型匹配：注意变量的类型（字符串、数字、布尔、数组、对象），避免类型错误
2.4 条件分支（Branch）
条件分支让工作流可以根据不同的情况走不同的路径。它是工作流灵活性的重要来源。
条件分支的类型：
- 二元分支（if-else）：满足条件走A路径，不满足走B路径。如"如果是VIP客户，走专属服务；否则走标准服务"
- 多元分支（switch-case）：根据变量的值选择多个路径中的一个。如"根据投诉类型（产品质量/服务态度/物流问题），分别走不同的处理流程"
- 并行分支（parallel）：同时执行多个路径，最后汇总结果。如"同时分析市场、技术、财务三个维度，最后汇总成完整报告"
条件分支设计原则：
- 条件互斥：多个分支的条件应该互斥，避免一个情况同时满足多个分支
- 覆盖全面：考虑所有可能的情况，设置"默认分支"处理未覆盖的情况
- 条件简单：判断条件尽量简单明确，避免复杂的嵌套条件
- 汇合点清晰：分支结束后要有明确的汇合点，后续流程从汇合点继续
2.5 循环（Loop）
循环让工作流可以重复执行某个子流程，直到满足特定条件。它是处理批量任务和迭代优化的重要工具。
循环的类型：
- 计数循环（for）：重复执行N次。如"批量处理10条数据，每条数据走一遍处理流程"
- 条件循环（while）：满足条件就继续执行，不满足就退出。如"反复修改报告，直到审核通过为止"
- 遍历循环（for-each）：遍历数组中的每个元素，对每个元素执行子流程。如"遍历客户列表，给每个客户发送个性化邮件"
循环设计原则：
- 设置最大次数：条件循环一定要设置最大执行次数，避免死循环
- 退出条件明确：循环的退出条件要清晰明确，避免模糊的判断
- 单次执行有意义：循环体内的每次执行都应该有明确的输入输出，不要做无意义的重复
- 注意性能：循环次数太多会导致执行时间过长和token消耗过大，要合理控制
三、工作流设计实战：从需求到流程图
理论讲了这么多，让我们通过一个完整的案例，看看如何从业务需求出发，设计一个工作流。
🏭 实战案例：制造业"客户询盘智能处理工作流"
业务需求：
公司官网有一个"产品咨询"表单，客户填写后会收到一封自动回复邮件。但目前的自动回复是统一模板，无法根据客户需求给出个性化回复，导致转化率低。
需求：设计一个智能工作流，能够根据客户填写的信息，自动生成个性化的回复邮件，包含产品推荐、报价范围、下一步行动建议。高价值客户还要自动通知销售经理跟进。
第一步：梳理业务流程
先把现有的人工处理流程梳理出来：
1. 客户提交咨询表单（姓名、公司、行业、需求描述、预算范围）
2. 销售助理查看表单，判断客户需求类型
3. 根据需求类型，查找相关产品资料
4. 根据预算范围，给出初步报价区间
5. 撰写个性化回复邮件
6. 判断客户价值（高/中/低）
7. 如果是高价值客户，通知销售经理
8. 发送回复邮件
9. 在CRM中创建客户记录和跟进任务
第二步：识别可以自动化的环节
分析每个环节，判断是否适合自动化：
• 步骤1（接收表单）：完全自动化，固定节点
• 步骤2（判断需求类型）：可以用大模型自动分类，Agent节点
• 步骤3（查找产品资料）：可以用知识库检索，固定节点
• 步骤4（给出报价区间）：可以根据预算范围规则匹配，条件判断+数据处理节点
• 步骤5（撰写回复邮件）：可以用大模型生成，Agent节点
• 步骤6（判断客户价值）：可以用规则+大模型判断，条件判断节点
• 步骤7（通知销售经理）：可以自动发送消息，工具调用节点
• 步骤8（发送邮件）：可以自动发送，工具调用节点
• 步骤9（创建CRM记录）：可以调用API自动创建，工具调用节点
结论：9个环节全部可以自动化！
第三步：设计工作流节点
节点1【开始】：接收客户提交的表单数据
→ 输出：{name, company, industry, requirement, budget}
节点2【需求分类】：调用大模型，分析客户需求，分类为（设备采购/系统集成/咨询服务/其他）
→ 输出：{requirement_type, key_points}
节点3【产品检索】：根据需求类型，从产品知识库中检索相关产品资料
→ 输出：{products: [{name, features, price_range}]}
节点4【报价匹配】：根据客户预算范围和产品价格，匹配合适的报价区间
→ 输出：{quote_range, fit_level}
节点5【客户价值评估】：根据行业、公司规模（从公司名推断）、预算、需求紧急度，评估客户价值（高/中/低）
→ 输出：{customer_value: high/medium/low}
节点6【生成回复邮件】：调用大模型，综合客户信息、推荐产品、报价区间，生成个性化回复邮件
→ 输出：{email_subject, email_body}
节点7【邮件审核】：检查邮件内容是否合规（没有虚假承诺、价格在合理范围、联系方式正确）
→ 条件分支：
• 如果审核通过 → 继续
• 如果审核不通过 → 返回节点6重新生成（最多3次，超过则转人工）
节点8【条件分支-客户价值】
• 如果是高价值客户 → 节点8a【通知销售经理】：发送企业微信消息给销售经理，包含客户信息和咨询内容
• 如果是中/低价值客户 → 跳过
节点9【发送邮件】：调用邮件API，把回复邮件发送给客户
→ 输出：{send_status}
节点10【创建CRM记录】：调用CRM API，创建客户记录、咨询记录、跟进任务
→ 输出：{crm_record_id}
节点11【结束】：返回处理结果
第四步：设计容错机制
• 节点2（需求分类）：如果大模型返回格式错误，重试最多3次，仍失败则默认分类为"其他"
• 节点3（产品检索）：如果检索结果为空，返回通用产品介绍
• 节点6（生成邮件）：设置最大重试次数3次，超过则使用模板邮件兜底
• 节点9（发送邮件）：设置超时10秒，重试3次，失败则记录错误并通知管理员
• 节点10（创建CRM）：失败不影响主流程，记录错误后续人工补录
第五步：设计可观测性
• 记录每个节点的输入输出、执行时间、是否成功
• 记录大模型的调用次数和token消耗
• 统计每天处理的询盘数量、分类分布、客户价值分布
• 记录邮件的打开率和回复率，评估效果
• 定期人工抽检回复质量，持续优化Prompt
业务需求：
公司官网有一个"产品咨询"表单，客户填写后会收到一封自动回复邮件。但目前的自动回复是统一模板，无法根据客户需求给出个性化回复，导致转化率低。
需求：设计一个智能工作流，能够根据客户填写的信息，自动生成个性化的回复邮件，包含产品推荐、报价范围、下一步行动建议。高价值客户还要自动通知销售经理跟进。
第一步：梳理业务流程
先把现有的人工处理流程梳理出来：
1. 客户提交咨询表单（姓名、公司、行业、需求描述、预算范围）
2. 销售助理查看表单，判断客户需求类型
3. 根据需求类型，查找相关产品资料
4. 根据预算范围，给出初步报价区间
5. 撰写个性化回复邮件
6. 判断客户价值（高/中/低）
7. 如果是高价值客户，通知销售经理
8. 发送回复邮件
9. 在CRM中创建客户记录和跟进任务
第二步：识别可以自动化的环节
分析每个环节，判断是否适合自动化：
• 步骤1（接收表单）：完全自动化，固定节点
• 步骤2（判断需求类型）：可以用大模型自动分类，Agent节点
• 步骤3（查找产品资料）：可以用知识库检索，固定节点
• 步骤4（给出报价区间）：可以根据预算范围规则匹配，条件判断+数据处理节点
• 步骤5（撰写回复邮件）：可以用大模型生成，Agent节点
• 步骤6（判断客户价值）：可以用规则+大模型判断，条件判断节点
• 步骤7（通知销售经理）：可以自动发送消息，工具调用节点
• 步骤8（发送邮件）：可以自动发送，工具调用节点
• 步骤9（创建CRM记录）：可以调用API自动创建，工具调用节点
结论：9个环节全部可以自动化！
第三步：设计工作流节点
节点1【开始】：接收客户提交的表单数据
→ 输出：{name, company, industry, requirement, budget}
节点2【需求分类】：调用大模型，分析客户需求，分类为（设备采购/系统集成/咨询服务/其他）
→ 输出：{requirement_type, key_points}
节点3【产品检索】：根据需求类型，从产品知识库中检索相关产品资料
→ 输出：{products: [{name, features, price_range}]}
节点4【报价匹配】：根据客户预算范围和产品价格，匹配合适的报价区间
→ 输出：{quote_range, fit_level}
节点5【客户价值评估】：根据行业、公司规模（从公司名推断）、预算、需求紧急度，评估客户价值（高/中/低）
→ 输出：{customer_value: high/medium/low}
节点6【生成回复邮件】：调用大模型，综合客户信息、推荐产品、报价区间，生成个性化回复邮件
→ 输出：{email_subject, email_body}
节点7【邮件审核】：检查邮件内容是否合规（没有虚假承诺、价格在合理范围、联系方式正确）
→ 条件分支：
• 如果审核通过 → 继续
• 如果审核不通过 → 返回节点6重新生成（最多3次，超过则转人工）
节点8【条件分支-客户价值】
• 如果是高价值客户 → 节点8a【通知销售经理】：发送企业微信消息给销售经理，包含客户信息和咨询内容
• 如果是中/低价值客户 → 跳过
节点9【发送邮件】：调用邮件API，把回复邮件发送给客户
→ 输出：{send_status}
节点10【创建CRM记录】：调用CRM API，创建客户记录、咨询记录、跟进任务
→ 输出：{crm_record_id}
节点11【结束】：返回处理结果
第四步：设计容错机制
• 节点2（需求分类）：如果大模型返回格式错误，重试最多3次，仍失败则默认分类为"其他"
• 节点3（产品检索）：如果检索结果为空，返回通用产品介绍
• 节点6（生成邮件）：设置最大重试次数3次，超过则使用模板邮件兜底
• 节点9（发送邮件）：设置超时10秒，重试3次，失败则记录错误并通知管理员
• 节点10（创建CRM）：失败不影响主流程，记录错误后续人工补录
第五步：设计可观测性
• 记录每个节点的输入输出、执行时间、是否成功
• 记录大模型的调用次数和token消耗
• 统计每天处理的询盘数量、分类分布、客户价值分布
• 记录邮件的打开率和回复率，评估效果
• 定期人工抽检回复质量，持续优化Prompt
四、工作流调试与优化
4.1 常见问题与排查方法
| 问题 | 可能原因 | 排查方法 |
|---|---|---|
| 流程执行到某个节点卡住 | 节点超时、外部API无响应、死循环 | 查看节点日志，检查是否有超时设置，确认循环退出条件 |
| 输出格式不对 | Prompt中输出格式要求不明确、大模型没有严格遵守 | 在Prompt中给出格式示例，增加"必须严格按照以下格式输出"的约束，增加格式校验节点 |
| 条件分支走错路径 | 条件判断逻辑错误、变量值不符合预期 | 打印条件判断的变量值，检查判断逻辑是否正确，确认变量传递是否正确 |
| 数据传递丢失 | 变量名拼写错误、节点输出格式不匹配、作用域问题 | 检查每个节点的输出变量名，确认引用的变量名正确，检查变量的作用域 |
| 大模型输出不稳定 | Prompt不够清晰、温度设置过高、任务太复杂 | 优化Prompt，增加示例，降低temperature，把复杂任务拆成多个节点 |
| 执行成本过高 | 大模型调用次数太多、每次调用token太多、循环次数太多 | 减少不必要的大模型调用，用规则判断代替大模型，优化Prompt减少token，控制循环次数 |
4.2 性能优化技巧
（1）减少大模型调用：能用规则判断的就不要用大模型。比如简单的条件判断、数据格式化、字符串处理，用代码节点或数据处理节点就够了，不需要调用大模型。
（2）并行执行：没有依赖关系的节点可以并行执行，缩短整体执行时间。比如同时检索多个知识库、同时分析多个维度。
（3）缓存结果：对于相同输入会产生相同输出的节点（如知识库检索、固定的代码处理），可以缓存结果，避免重复计算。
（4）控制上下文长度：传给大模型的上下文不要太长，只传必要的信息。长上下文不仅增加成本，还可能降低大模型的注意力和准确率。
（5）选择合适的模型：简单的任务用小模型（如GPT-3.5、DeepSeek），复杂的任务用大模型（如GPT-4o、Claude 3.5）。不要所有任务都用最贵的模型。
4.3 持续优化的方法
工作流不是一次设计就完美的，需要在使用中持续优化：
- 数据驱动：收集运行数据（成功率、耗时、成本、用户反馈），用数据发现问题
- A/B测试：对关键节点（如Prompt、条件阈值）进行A/B测试，找到最优方案
- 人工抽检：定期人工抽检输出质量，发现自动化没有发现的问题
- 用户反馈：收集用户反馈，了解哪些地方不满意，针对性优化
- 版本管理：工作流的修改要有版本记录，出问题可以回滚到上一个版本
🎯 本章小结：
• 工作流是一系列有序的、可重复的任务步骤的集合，核心元素包括节点、连线、变量、条件分支、循环
• 节点类型丰富：开始/结束、大模型、工具调用、知识库检索、条件判断、数据处理、循环、并行、人工审核、代码执行
• 工作流 vs Agent：工作流稳定可控，Agent灵活自主，实际项目中"工作流为主，Agent为辅"
• 工作流设计五步法：梳理业务流程→识别可自动化环节→设计节点→设计容错机制→设计可观测性
• 调试优化：常见问题有固定排查方法，性能优化关注减少大模型调用、并行执行、缓存、控制上下文
• 持续优化：数据驱动、A/B测试、人工抽检、用户反馈、版本管理
• 工作流是一系列有序的、可重复的任务步骤的集合，核心元素包括节点、连线、变量、条件分支、循环
• 节点类型丰富：开始/结束、大模型、工具调用、知识库检索、条件判断、数据处理、循环、并行、人工审核、代码执行
• 工作流 vs Agent：工作流稳定可控，Agent灵活自主，实际项目中"工作流为主，Agent为辅"
• 工作流设计五步法：梳理业务流程→识别可自动化环节→设计节点→设计容错机制→设计可观测性
• 调试优化：常见问题有固定排查方法，性能优化关注减少大模型调用、并行执行、缓存、控制上下文
• 持续优化：数据驱动、A/B测试、人工抽检、用户反馈、版本管理
下一章，我们将学习知识库RAG实战——这是让智能体拥有专业知识的核心技术。通过RAG，你可以把企业的文档、手册、案例等知识注入智能体，让它成为懂你业务的专家。
📝 本章练习（5题）
答案与解析请在 互动学习看板 中作答查看。
📚 AI智能体实战训练营 课程目录（33 章）
- 第1章 什么是AI智能体：从聊天机器人到自主决策系统
- 第2章 智能体的四大核心能力：感知·思考·行动·记忆
- 第3章 范式转移：智能体与传统软件的本质区别
- 第4章 2025年主流智能体平台全景对比与选型
- 第5章 智能体应用场景地图：从个人效率到企业级落地
- 第6章 编排思维：如何把大模型变成可执行的业务流程
- 第7章 Prompt工程实战：写出让智能体精准执行的指令
- 第8章 工作流编排入门：节点、连线、条件分支与循环
- 第9章 知识库RAG实战：让智能体拥有你的专业数据
- 第10章 工具调用实战：搜索·计算·API·数据库全掌握
- 第11章 多智能体协作：角色分工、任务分发与结果汇总
- 第12章 Coze/扣子入门：30分钟搭建你的第一个智能体
- 第13章 Coze进阶：插件开发、工作流深度编排与知识库优化
- 第14章 Dify入门：开源可私有化部署的智能体平台搭建
- 第15章 Dify进阶：RAG管道优化、Agent模式与工作流编排
- 第16章 LangChain入门：用代码构建可定制的智能体应用
- 第17章 LangChain实战：自定义Agent、工具链与记忆系统
- 第18章 Agent Harness与新一代框架：2025年智能体开发趋势
- 第19章 平台选型决策树：不同业务场景下的最优平台选择
- 第20章 任务拆解方法论：把复杂问题变成智能体可执行的步骤
- 第21章 提示词编排艺术：System·User·Function的三层协同
- 第22章 记忆系统设计：短期记忆、长期记忆与向量数据库选型
- 第23章 错误处理与容错：智能体执行失败时的兜底策略
- 第24章 评估与优化体系：如何量化衡量智能体的效果并持续改进
- 第25章 安全与合规：智能体应用的数据安全、隐私保护与风险防控
- 第26章 实战项目一：企业知识库智能问答助手（全流程实操）
- 第27章 实战项目二：制造业设备故障诊断智能体
- 第28章 实战项目三：供应链采购智能分析与比价助手
- 第29章 实战项目四：多智能体协同的项目管理办公室（PMO）
- 第30章 实战项目五：智能体与MES/ERP系统的深度集成
- 第31章 智能体落地路线图：从POC验证到规模化应用的完整路径
- 第32章 AI智能体工程师/产品经理的能力模型与成长路径
- 第33章 作品集打造与面试准备：如何拿到AI智能体岗位Offer