概览
NocoBase 3 工作流用于实现具有独立生命周期的业务过程。应用开发者描述需求并审核方案，由应用 Agent 在源码中定义和接入处理步骤；系统在后台执行并保存每次运行记录，业务管理员则通过界面控制启用状态、设置有限参数和查看执行结果。
适用场景
默认节点能够表达、并且通常适合使用工作流的场景包括：
- 订单履约需要依次校验、预留库存、安排发货和记录结果；
- 客户入驻需要检查资料，并根据风险结果进入不同处理路径；
- 库存变化后需要在后台判断是否补货，并避免重复通知造成重复补货；
- 报价提交后需要计算风险、选择处理路径并保留每次决策记录；
- 业务管理员需要查看每次处理的实际路径和失败位置；
- 流程版本、流程触发去重、超时或恢复策略会影响业务正确性。
审批、人工确认、补充资料后继续、等待外部回调等过程，在业务上也适合工作流，但默认插件不能直接表达这类持久化暂停与恢复。只有目标应用已经安装并注册相应的扩展节点时才能采用；否则应先调整设计或开发可复用的 Instruction。
以下情况通常更适合普通类型化代码：
- 一次请求内即可完成的简单查询或计算；
- 必须在同一个数据库事务中完成的原子写入；
- 以算法或数据转换为主、无需独立运行记录的逻辑；
- 即使失败，只需要向调用方返回错误，不需要持续观测过程。
多个代码步骤是否就应该使用工作流
不一定。一个函数可以调用多个查询或服务，但只要这些操作仍属于一次原子请求，并且业务不关心中间状态，就没有必要引入工作流。
判断标准是：业务过程是否需要一个独立、持久化、可观测的生命周期，而不是代码行数、函数数量、是否异步或是否存在条件分支。
工作流与普通业务代码如何配合
工作流和普通业务代码通常共同完成一项功能：
例如，库存补货工作流可以负责“计算缺口 → 判断 → 创建补货或记录库存充足”的路径，而库存读取、缺口计算和补货记录写入仍由应用中的类型化 Service 完成。
应用开发者与业务管理员如何协作
NocoBase 3 的应用开发以 Agent 为主要实现者。应用开发者负责向 Agent 提供业务信息并审核结果，而不是手工记忆 DSL 或逐行编写流程代码。
应用开发者负责：
- 向应用 Agent 描述业务目标、规则和影响边界；
- 审核 Agent 对工作流与普通业务代码的选型；
- 确认流程阶段、输入和允许管理员调整的参数；
- 审核节点调用的业务 Service 和真实事件接入方式；
- 确认高风险或不可逆副作用；
- 验收 Agent 提供的测试、构建和运行证据。
应用 Agent 负责检查现有 Schema、Service、插件和节点能力，完成流程定义、业务接入、测试、构建与诊断，并明确报告假设、未验证边界和需要人工确认的事项。
业务管理员负责：
- 查看应用已提供的工作流；
- 设置开发者开放的参数；
- 启用、停用或切换版本；
- 在明确影响后手动运行；
- 查看运行状态并将异常证据反馈给开发者。
当前能力与边界
工作流插件当前内置以下流程能力：
- 按顺序执行节点；
- 根据布尔条件进入
yes或no分支； - 从主路径或分支中提前终止整个流程；
- 运行应用服务端代码；
- 在队列中异步执行，并通过事件标识进行流程触发去重；
- 保存流程版本、运行记录和节点级诊断信息。
工作流支持通过其他插件注册自定义节点，扩展特定业务能力，例如审批。
管理界面是否是工作流设计器
不是。流程结构由应用开发者在源码中定义，管理界面提供只读流程图。业务管理员只能在开发者预留的范围内配置参数、控制版本、手动运行和查看记录。