Coze 进阶：Workflow、多智能体与自动化流程设计

从智能体到工作流

在前一篇基础入门中，我们了解了 Coze 智能体如何通过提示词、知识库和插件来完成任务。但对于更复杂的业务场景——比如需要多步骤处理、条件分支、循环处理——单靠智能体的"自主规划"是不够的。这时候，Coze 的工作流系统就派上了用场。

Coze 提供两种流程编排模式：工作流（Workflow） 和 对话流（Chatflow）。

工作流 vs 对话流

用一句话区分：工作流是为"做事"设计的，对话流是为"聊天"设计的。

工作流适用于功能类的请求——通过顺序执行一系列节点实现某个功能。比如生成行业调研报告、批量处理数据、生成一张海报。工作流的执行是任务导向的，每次调用都是独立的。

对话流是基于对话场景的特殊工作流。它绑定了会话（Session），能够从对话历史中读取上下文。每个对话流运行时都能看到之前聊了什么，因此适合做智能客服、虚拟伴侣这类需要记住对话历史的场景。

什么时候选哪个？

这是一个很实用的决策框架：

• 如果你在搭一个工具类应用（批量处理数据、自动化任务）→ 用工作流
• 如果你在搭一个对话式应用（AI 助手、客服机器人）→ 用对话流
• 如果你希望模型能读取对话历史来生成回复 → 用对话流
• 如果你希望每次执行都是独立干净的 → 用工作流

共同的核心：节点

无论工作流还是对话流，核心都是"节点"。每个节点是一个具有特定功能的独立组件，负责处理数据、执行任务。

所有流程都默认包含开始节点和结束节点。开始节点定义输入参数，结束节点返回运行结果。中间通过引用节点的输出参数，将各个节点连接成一个完整的处理链条。

核心节点详解

大模型节点（LLM Node）

这是最常用也最灵活的节点。大模型节点可以根据输入参数和提示词生成回复，用于文本生成、总结、扩写等任务。

技能配置是 LLM 节点的杀手特性。你可以在大模型节点内部直接挂载插件、工作流或知识库——大模型会自动判断什么时候调用它们。这相当于把一个独立的智能体嵌入到了工作流的某个步骤中。

比如你做一个穿搭推荐工作流：传统做法是先调用天气插件查天气，再传给 LLM 节点生成推荐。但在 LLM 节点中配置天气插件后，大模型会自己决定调用时机，流程更简洁。

续写功能是另一个实用特性。当模型输出超过最大 token 限制时，开启续写后会自动拼接多次调用的结果，适合长文本生成场景。

异常处理方面，支持超时时间设置（0.1-600 秒）、重试（可指定备用模型）、中断/返回设定内容/执行异常流程三种异常处理方式。

代码节点（Code Node）

Code Node 支持 JavaScript 和 Python 两种语言，可以在工作流内执行自定义逻辑。

JavaScript 基于 V8 引擎（对应 Node.js 20.3.1），内置 dayjs 和 lodash。 Python 基于 3.11.3，内置 requests_async 和 numpy。

需要特别注意：

• 单请求限制 60 秒
• 不支持 HTTP 以外的协议
• 每个工作流最多 50 个代码节点
• 推荐使用 asyncio.sleep() 而非 time.sleep()

Coze 还提供了网页版代码 IDE，带有自动补全和调试功能，可以让开发体验接近本地 IDE。

HTTP 请求节点

让工作流与外部 API 通信的关键节点。支持 GET/POST/PUT/DELETE 等常见方法，支持 Bearer Token 和自定义鉴权。

最实用的是导入 cURL 功能——你可以直接从浏览器 DevTools 复制 cURL 命令，一键导入节点配置。

超时默认 120 秒，最长 600 秒；重试默认为 3 次。还有异常忽略功能，允许某个 API 调用失败后工作流继续执行，适合非关键路径的 API 调用。

选择器节点

本质上是 if-else 分支。支持多个条件分支，每个分支可以组合多个判断条件（且/或），通过拖拽调整优先级。

假设你要做一个客服机器人工作流：开始节点接收用户问题 → 大模型节点判断意图 → 选择器将"售后问题"分流到知识库分支，"售前咨询"分流到另一个分支，"闲聊"直接回复。这就是选择器节点的典型用法。

循环节点

循环有三种模式：

1. 使用数组循环（forEach）：遍历数组中的每个元素执行同样操作，适合长文分段生成、批量问卷调查
2. 指定循环次数：固定循环 N 次，适合需要重复执行 N 次的任务
3. 无限循环（while）：通过条件判断是否终止，适合回合制游戏、增强搜索等

循环节点支持中间变量，可以在每次循环之间传递数据——比如长文生成时，把上一段的内容传递到下一次循环，让段落之间衔接更自然。

批处理节点

循环是串行的，批处理是并行的。批处理节点会一次性并行处理数组中的所有元素，适合图片批量分析、批量 API 调用等场景。

默认每批并行运行 10 次，最多 200 次。每一批内部并行执行，如果要串行执行可以将并行数量设为 1。

一个很好的场景：你有一组图片 URL 需要视觉理解模型批量分析——用批处理节点包裹一个大模型节点，所有图片同时分析，比循环串行处理快得多。

三大编排模式

理解了节点之后，Coze 的三大编排模式就清晰了。

单 Agent 模式（自主规划）

默认模式。智能体根据用户输入，自主决定调用哪些工具、知识库和工作流。适合功能相对单一、用户意图明确的场景。

单 Agent 模式（对话流）

将智能体绑定到一个固定的对话流上。用户的每一轮对话都会触发同一个对话流处理。适合流程固定的场景——比如售后服务中，无论用户问什么，都走"意图识别 → 知识库匹配 → 回复生成"这个固定流程。

多 Agent 模式

这是 Coze 最强大的编排模式。你可以在一个智能体内添加多个 Agent 节点，每个 Agent 有独立的提示词、插件和工作流，通过"适用场景"描述来分配任务。

比如做一个翻译智能体：一个父节点接收用户输入，分发到"翻译为中文"、"翻译为日文"、"翻译为韩文"三个子 Agent。每个子 Agent 只负责一个语种，复杂度大大降低。

关键优势：

• 每个 Agent 的错误是独立的，调试只需修复出问题的那个 Agent
• 提示词更简洁，因为每个 Agent 只处理一个子任务
• 可以复用已发布的单 Agent 作为节点（智能体节点）

批处理场景：你要批量分析 10 张产品图片，用批处理节点包裹一个大模型节点（视觉理解模型），所有图片同时分析。如果用循环节点串行处理，总耗时是单次处理 × 10；用批处理并行处理，耗时≈单次处理时间。

三大编排模式实战对比

理解了节点和编排模式后，用一个具体案例来说明如何选择：假设你要做一个"智能客服"。

如果用单 Agent 自主规划模式：一个智能体处理所有问题。你需要在提示词中写清楚"如果用户问售后问题，调用售后工作流；如果问产品信息，查询知识库；如果问物流，调用物流查询插件"。优点是配置简单，缺点是提示词会变得非常臃肿——随着功能增加，调试会越来越困难，修改任何一处都可能影响全局。

如果用对话流模式：绑定一个固定的对话流。用户的所有问题都走同一个流程——开始节点接收问题 → 大模型节点识别意图 → 选择器节点分流 → 不同分支分别处理 → 结束节点汇总回复。优点是流程可控、输出稳定，缺点是灵活性降低，无法处理计划外的用户需求。

如果用多 Agent 模式：三个 Agent 分别负责售后、产品咨询和物流查询，通过开始节点的分发逻辑将用户消息切换到正确的 Agent。每个 Agent 的提示词简洁清晰，出错只需修复对应 Agent，不影响其他功能。缺点是配置相对复杂，需要理清 Agent 之间的切换逻辑。

三种模式没有绝对的好坏，取决于你的业务场景。功能简单、需求稳定的场景推荐单 Agent；流程固定、注重输出质量的推荐对话流；功能复杂、需求多样的推荐多 Agent。

实战建议

工作流设计原则

1. 从简单到复杂：先做一个只有 2-3 个节点的原型，验证核心逻辑，再逐步增加节点
2. 善用异常处理：每个可能失败的关键节点都要配置异常处理，否则一个节点失败整个工作流会中断
3. 费用监控：大模型节点和付费插件会产生费用，即使工作流整体失败了，已运行的付费节点仍会收费
4. 异步运行：如果工作流运行超过 2 分钟，建议开启异步运行模式，先返回预设回复，工作流完成后自动给出最终答案

选择正确模式

• 单 Agent 自主规划 → 80% 的场景够用
• 单 Agent 对话流 → 当你有固定的业务流程需要严格执行
• 多 Agent → 当你的智能体需要处理多个差异很大的任务类型

Coze 的工作流系统其实是一个低代码的"函数式编程"环境——每个节点是一个函数，节点之间的连线是数据流。理解了这个本质，你就能像设计系统架构一样设计工作流。

常见工作流设计模式

经过多次实践，我总结了几个常用的工作流设计模式：

模式一：预处理 → 主处理 → 后处理 这是最基础的流水线模式。数据先经过清洗和格式化（预处理），再由核心节点处理（主处理），最后输出整理（后处理）。日报生成器就是典型例子。

模式二：意图识别 → 分流 → 专项处理 用户输入先经过大模型节点做意图识别，然后用选择器节点分流到不同的处理分支。适合客服、查询类场景。

模式三：循环迭代 → 结果聚合 用循环节点反复执行相同的处理操作，每次迭代输出一个中间结果，循环结束后用变量合并节点将所有结果聚合。适合长文生成、数据抓取等场景。

模式四：批处理 → 并行加速 用批处理节点代替循环节点做并行处理。当你的任务可以拆分为互不依赖的子任务时，批处理能大幅缩短总耗时。

选择哪种模式取决于你的业务场景和数据特性。如果数据量大且处理逻辑简单，优先考虑批处理；如果需要保持顺序和状态，用循环；如果流程分支多，用选择器。

成本考量与性能优化

在实际部署工作流时，费用和性能是绕不开的话题。每个运行的大模型节点和付费插件都会产生费用，即使工作流整体运行失败，已成功运行的付费节点仍会照常计费。因此设计工作流时需要注意几点：

• 减少不必要的模型调用：能用代码节点处理的逻辑不要用大模型节点。字符串处理、JSON 解析、条件判断，代码节点更快且完全免费
• 控制上下文长度：大模型节点的输入中只传递必要的上下文信息，不要把全部历史数据和中间结果都带上
• 合理设置超时：不要使用默认值，根据实际处理时间配置。简单的文本清洗设 10-30 秒，复杂的文档分析设 180-600 秒
• 异步模式：如果有任何一个节点预计运行超过 2 分钟，开启工作流的异步运行，避免对话超时导致工作流被中断

实战建议