扣子 AI 智能体工作流：当“对话”走向“确定性”

如果说大模型是智能体的“大脑”，那工作流就是它的“神经系统”——它把大模型模糊的概率输出，转化为确定的、可预测的业务动作。

从对话到确定性的这一跃，才是 AI 智能体真正走向生产环境的关键一步。扣子（Coze）作为国内主流的 AI 智能体开发平台，其工作流引擎正是承载这一跃迁的核心基础设施。

一、工作流的设计哲学：用“确定性”兜底“概率性”

大模型是一个概率系统——同样的输入，每次可能给出不同的输出。这种特性在创意生成场景中是优势，但在需要精确执行的业务流程中却是隐患。

工作流的本质，就是在大模型的概率性输出外面，套一层确定性执行的“逻辑外壳”。

扣子工作流做的事情，就是把一个复杂任务拆成一个个节点，每个节点只干一件事，通过连线把数据传下去，形成完整的执行链路。一个典型的工作流结构是：开始节点 → 节点A → 节点B → 条件分支 → 节点C/D → 结束节点。

这个结构看似简单，背后却藏着一个重要的工程原则：让大模型只做它擅长的事（意图识别、内容生成），把路由、计算、格式化这些确定性操作交给专用节点。不确定性的范围被框定在可控的边界内，整个系统的可靠性也随之提升。

二、条件分支：工作流中的“决策中枢”

条件分支节点（在扣子中也被称为“选择器”节点）是工作流中最核心的逻辑组件。它对应的，就是编程语言中最基础的 if-else 判断。

2.1 工作原理

条件分支的本质是实时求值上下文变量，并按顺序匹配首个为 true 的分支。

配置一个条件分支，你需要确定两件事：

• 几个分支：需要处理几种不同的情况
• 什么条件：每个分支的入口标准是什么

系统按优先级顺序逐个判断，一旦命中某个条件，数据就流入对应的分支，后续条件不再执行。

举个例子：假设你要做一个“意图识别与路由”的工作流，让用户输入自动分流到不同处理路径。配置逻辑大致如下：

• IF：{{input.text}} 包含“天气” → 调用天气查询插件
• ELSE IF：{{input.text}} 包含“外卖” → 跳转外卖 API
• ELSE IF：{{input.text}} 包含“知识” → 交给知识库检索
• ELSE：返回“没听懂，请换种说法”（兜底策略）

注意：分支顺序决定匹配优先级。如果用户输入“今天天气怎么样，顺便帮我订个外卖”，因为“天气”分支排在前面被先匹配，就不会走到外卖分支——这不是 bug，是设计使然。

2.2 多条件组合

条件分支支持在一个分支内用 “且” 或 “或” 连接多个判断：

• 且（AND） ：所有条件都满足才进入该分支。比如：{{user.role}} == "vip" 且 {{input.text}} 包含“加急” → 触发人工客服
• 或（OR） ：任意条件满足即可进入。比如：用户说“订餐”或“外卖”或“叫饭”，都归到外卖分支

当判断维度超过 3 个时，建议用嵌套分支做分层过滤——先判断是否登录，再判断角色，避免单层堆砌导致维护困难。

三、代码节点：当图形化不够用时

条件分支能处理简单的逻辑判断，但遇到复杂场景时，图形化拖拽的局限性就暴露了。

扣子允许在工作流中插入代码节点，支持 Python 或 JavaScript。每个工作流最多可添加 50 个代码节点。这相当于在画布上开了一扇“任意门”——用代码的灵活性解决图形化的局限性。

最佳实践：代码节点负责“复杂思考”，选择器节点负责“简单指路”。

一个典型的用法是：在代码节点里做复杂逻辑判断（正则匹配、数据清洗、类型转换），输出一个明确的布尔值或分类标签；下游的条件分支节点只需读取这个结果做分流。

# Coze 代码节点示例 —— 判断是否满足发券条件
async def main(args: Args) -> Output:
    params = args.params
    day = params['day']
    hour = params['hour']
    level = params['level']
    
    is_weekend = day in ['Saturday', 'Sunday']
    is_friday_night = (day == 'Friday' and hour >= 17)
    
    if (is_weekend or is_friday_night) and level > 3:
        return {"send_coupon": True}
    else:
        return {"send_coupon": False}

（示例代码示意，非完整可运行版本）

这种“代码算 + 分支走”的模式，把复杂逻辑浓缩进几行代码里，让工作流画布保持清爽整洁。

四、变量体系：最容易踩的坑

扣子工作流的可视化编排降低了入门门槛，但也掩盖了一个事实——节点之间的数据流动，本质上是一套完整的变量体系。不理解这套体系，工作流永远在“碰运气”。

4.1 变量的来源与作用域

扣子工作流中，变量的来源只有两种：

• 输入变量：工作流启动时从外部传入
• 节点输出变量：每个节点执行完毕后产出的数据

关键规则：上游节点的输出变量可以被下游节点引用，但不能被上游节点引用。节点 A 的输出，节点 B 可以引用，但节点 C 如果排在 A 的上游，就引用不到。

4.2 五个最常见的变量错误

错误 1：下游取不到上游的值 根因：99% 是作用域问题——你在节点 B 里引用了节点 A 的输出，但 B 不在 A 的下游。顺着画布上的连接线追踪，确保“生产数据的节点”在“消费数据的节点”之前。

错误 2：类型不匹配 把数组传给了期望字符串的节点，或者把 Object 传给了需要 Number 的地方。用代码节点做显式类型转换。

错误 3：变量名写错 扣子的变量名区分大小写，且没有自动补全。节点 A 输出 userName，节点 B 引用 username → 报错。统一命名规范：全小写 + 下划线（user_name、ai_response）。

错误 4：在分支内引用分支外变量 条件分支会创建独立作用域。在分支里直接写 {{user.level}} 可能判为 undefined。解决方案：在条件节点配置中勾选 pass_through: true，或用“设置变量”节点显式中转。

错误 5：嵌套路径写错 扣子的变量引用走的是 JSONPath 语法，嵌套结构必须写完整路径。不能直接引用叶子节点名称，要把整条路径写清楚。

五、实战案例：从“Hello World”到业务闭环

一个完整的电商客服工作流，串联了上述所有能力：

1. 开始节点：接收用户输入
2. LLM 节点：识别用户意图（查询订单/退货咨询/转人工）
3. 条件分支：根据意图分流到不同路径
4. 插件节点：调用订单查询 API 或知识库检索
5. 代码节点：格式化返回数据、做数据清洗
6. 结束节点：输出最终回复

每个节点各司其职：LLM 负责“理解”，分支负责“路由”，插件负责“执行”，代码负责“加工”。整个流程是可观测、可调试、可迭代的——这和传统软件开发中的“单元测试→集成测试→部署”一脉相承。

六、写在最后

扣子工作流的真正价值，不在于“不用写代码”这个表象，而在于它提供了一种把 AI 能力工程化封装的方法论。

大模型解决的是“理解”的问题，工作流解决的是“执行”的问题。两者结合，智能体才能从“聊天玩具”变成“生产力工具”。

用好工作流，记住三个原则：

1. 先画草图再搭节点：把流程在纸上画一遍，想清楚输入输出，再动手
2. 搭一段、测一段：不要一口气搭完再调试，每加一个节点就跑一次测试
3. 变量是命脉：搞懂作用域、命名规范和类型转换，能避开 80% 的坑

当你的工作流从“一运行就报错”变成“稳定跑完整个流程”的那一刻，你就完成了从“调 API”到“做工程”的跃迁。而这，恰恰是 AI 应用从 Demo 走向生产的关键一步。