JOJO/agent-Specialization
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
9602875391
agent-Specialization/workflow_research/paradigm_elements/paradigm_elements.md
JOJO d071292c81 feat(workflow): 工作流编辑器——可视化画布编辑 + WORKFLOW.md 落盘 + REST CRUD + 侧边栏入口 
- 编辑器：/workflows 库页 + /workflow/<name> 编辑器（Vue Flow 画布，开始/结束/阶段/审核/分支五类节点，白前进/蓝通过/红驳回三色语义连线，dagre 自动排版）
- 落盘：modules/workflow_manager.py；host 存运行态根 workflows/，web/docker 存 users/<user>/personal/workflows/；源码树 workflows/ 为内置种子，用户库同名覆盖、内置不可删
- REST：GET/PUT/DELETE /api/workflows[/<name>]，保存时后端强制 error 级结构校验
- 路由根治：新增 isConversationIndependentRoute() 统一谓词（URL 派生），收敛全部 9 处对话接管/URL 写回判断点，根治 /workflows 下地址栏被拽回对话的问题
- 深色主题 token 提亮（surface-soft/card/muted 去近黑色阶）
2026-08-21 01:38:03 +08:00

40 KiB
Raw Blame History

工作流/流程图编排范式元素体系与「审核」建模方式调研报告

调研目的：为「AI 智能体工作流编辑器（类 ComfyUI 拖拽画布、节点为 LLM 执行阶段）」的数据模型设计做前期调研，重点回答：「审核」应建模为独立节点、节点的属性、还是边的属性？

调研范围：BPMN 2.0（权威标准）、国内审批流产品（钉钉/飞书/企业微信等）、AI 工作流产品（Dify/Coze/n8n/LangGraph）、状态机理论（XState）。 本报告基于公开文档与第三方文章整理，所有结论标注了来源；官方文档与第三方文章分别注明。

目录

  1. 各范式的元素体系清单（表格）
  2. 审核/审批建模方式的产品对比（表格）
  3. 三种审核建模方式的利弊分析
  4. 对「AI 智能体工作流」场景的建模建议
  5. 来源 URL 汇总

1. 各范式的元素体系清单（表格）

1.1 BPMN 2.0 元素体系（权威标准，重点）

BPMN 2.0 是 OMG 制定的标准（ISO/IEC 19510），元素分五大类：流程对象（Flow Objects）、数据（Data）、连接对象（Connecting Objects）、泳道（Swimlanes）、制品（Artifacts）。以下按官方符号参考整理。

类别 元素 细分类型 语义要点
事件 Events Start / Intermediate / End（按位置分） 如图标所示再按类型分 事件是流程中"发生的事"，是圆；分为 catching（等待触发） 与 throwing（主动发出） 两类
事件类型（与位置组合） None（空白）、Message（消息）、Timer（定时）、Conditional（条件）、Link（链接）、Signal（信号）、Error（错误）、Escalation（升级）、Termination（终止）、Compensation（补偿）、Cancel（取消）、Multiple（多选）、Multiple Parallel（并行多选） 消息=发给特定接收方；信号=广播式通知；定时=时间触发；错误=异常处理（只能做边界/结束）；补偿=撤销已完成的活动的副作用
边界事件（Attached/Boundary） 中断式（实线）与非中断式（虚线） 挂在活动边界上；中断式：事件触发即取消当前活动走异常流；非中断式：克隆 token 并行继续
活动 Activities Task（任务，原子活动） Undefined（未定义）/ Manual（人工，无系统辅助）/ User（用户任务，有系统辅助）/ Receive（接收）/ Send（发送）/ Script（脚本）/ Service（服务）/ Business Rule（业务规则） User Task 即"审批/表单填写"等需要人与系统交互的任务（Camunda 8 官方文档：user task = 需要人工完成、由工作流引擎/软件辅助的工作）；Service Task = 自动化服务调用；Script Task = 执行内联/外部脚本
Subprocess（子流程，复合活动） 内嵌 Subprocess（embedded）／全局 Subprocess 通过 Call Activity（调用活动，粗边框）引用 子流程内部有独立的起止事件；父流程 token 等待子流程完成。另有 Event Subprocess（虚线框，由事件触发，可中断/非中断）与 Ad-hoc Subprocess（波浪线标记，内部活动任意顺序/跳过）
标记（Markers） Loop（循环）、Multiple Instance（多实例，可并行/串行）、Compensation（补偿） 附着在任务/子流程上，扩展其执行语义
网关 Gateways 排他网关 Exclusive（XOR） — 恰好走一条路径（数据条件互斥时用）；经典"是/否、通过/拒绝"决策
并行网关 Parallel（AND） — 所有路径同时走，合并时等待所有分支到达（漏掉 AND 合并会导致活动重复执行）
包容网关 Inclusive（OR） — 一条或多条条件为真则都走，合并时等待所有激活分支
基于事件网关 Event-based — 不按数据路由，而是等待先发生的那个事件（如收到消息 vs 计时器超时）
复杂网关 Complex — 复杂的组合条件规则（ProcessMind 指南）
流向/连接对象 Sequence Flow（顺序流） — 连接流程对象，表达执行顺序；可在每条出边上写条件表达式（如 Camunda/Flowable：#{approved}、ProcessMaker：@@DocumentationReview == 'yes'、@#amount >= 1000），条件为 true 的边被选中
Message Flow（消息流） — 跨参与方（泳道/池）之间的消息传递
Association（关联） — 把注释/数据对象关联到元素
泳道 Pool（池）、Lane（泳道） — Pool=一个参与方/编排边界；Lane=责任划分（角色/部门/人员）
数据 Data Object / Data Store / Input / Output — 建模数据的输入输出与持久化状态
制品 Group（分组）、Annotation（注释） — 辅助说明

关键认知：网关不是任务——它不做任何工作，只是根据已有数据/事件决定走哪条路（Camunda 官方最佳实践：把决策问题放在网关前，各答案分别建模为一条出边）。

1.2 国内审批流产品的节点模型（钉钉/飞书/企业微信等）

产品 节点类型清单 审批是否独立节点 多人审批规则 特色操作
钉钉宜搭（官方帮助中心） 发起人节点、审批人节点、抄送人节点、执行人（办理人）节点、条件分支节点、结束节点；节点上可配置"条件模式"（不同条件路由到不同审批人） 是，审批人是独立一等节点 会签（全部同意）/ 或签（一人同意）/ 依次审批；或签时第一个提交结果者决定结果 审批按钮：同意、拒绝、保存、转交、加签、退回、收回；超时处理；审批人为空处理
飞书审批（官方帮助中心） 发起节点、审批人节点、抄送人节点、办理人节点、条件分支节点、结束节点 是，审批人是独立一等节点 会签 / 或签 / 依次审批 审批类型：人工审批 / 自动通过 / 自动拒绝；审批人类型 11 种（上级、部门负责人、角色、用户组、指定成员、提交人自选、提交人本人、节点审批人、连续多级上级、表单内联系人、表单内部门）；操作权限：允许转交、允许加/减签（前/后/并加签）、允许回退；审批人为空、审批人与发起人相同时的特殊处理；抄送：发起时/中间/结束时，支持"仅同意时抄送"
企业微信审批（官方开发者文档） 节点类型 node_type：1=审批人、2=抄送人、3=办理人；多人办理方式 apv_rel：1=会签、2=或签、3=依次审批 是，节点类型字典中审批人是独立类型 会签 / 或签 / 依次审批 每个节点有状态 sp_status：1 审批中、2 同意、3 驳回、4 转审、11 退回给指定审批人、12 加签、13 同意并加签、14 办理、15 转交——「同意/驳回/退回」是节点级状态
明道云（官方帮助） 发起审批节点、审批节点、抄送节点、条件分支等 是 会签 / 或签 / 按通过比例 审批按钮：同意、拒绝、退回；转审；加签（通过后加签 / 审批前加签）；退回范围：可退回到所有节点 / 仅上个节点 / 指定节点 / 发起节点；退回流程不结束，驳回（拒绝）流程结束
简道云（官方帮助） 发起节点、审批节点、抄送节点、条件分支、结束节点 是 — 节点操作：保存草稿、流程回退、流程否决、流程暂存、流程加签、流程转交、批量处理；回退：可回退到「上一节点」或「指定范围内节点（多选）」；回退节点重新提交时可选：按流程顺序审批 / 直达当前节点 / 由回退人决定；节点回退 ≠ 流程撤回
氚云（官方帮助） 发起（经办）节点、审批节点、抄送节点、办理（经办）节点、子流程、汇合点、连接线 是 会签 / 或签（可设同意比例、驳回人数） 明确区分「退回」与「驳回」：驳回＝按节点流转规则（会签/或签）返回到前面节点或终止流程，审批人不可自由调节点；退回＝由单个审批人指定任意前序节点退回

1.3 AI 工作流产品的节点类型体系

产品 节点/块类型（代表性） 条件分支形态 人工审批（HITL）有无与建模方式 执行模型
Dify（官方产品页 + 第三方源码解析） 开始（用户输入/定时触发/Webhook）、结束、LLM、知识检索、问题分类器、条件分支、迭代、工具、代码执行、HTTP 请求、变量聚合器、模板转换、参数提取、直接回复、人工介入 一等公民节点（IF_ELSE 节点，条件组 cases 判定后返回 edge_source_handle 决定走哪条出边） 有，「人工介入」是独立节点（官方：在敏感数据/权限/合规操作前暂停，由专人审批、修改、评论、转交或超时处理后再继续运行） 图引擎：节点+边（edge），节点可多输出
Coze（扣子）（官方知识库 + 第三方教程） 开始、结束、大模型（LLM）、插件、代码、知识库、条件判断、循环（数组/次数/无限）、变量、数据库、信息、意图识别、子工作流、HTTP 一等公民节点（条件判断节点，IF-ELSE，true/false 两出口） 无专门审批节点；人工介入通常靠「结束节点返回 + 对话式确认」或外部系统实现 可视化节点编排，节点输入输出引用（{{node.output}}）连接
n8n（官方节点 + 第三方深度分析） Trigger、AI Agent、LLM、IF / Switch / Merge、Wait（等待）、Form（表单）、Code / Function、HTTP Request、Sub-workflow、Human in the Loop（Human Review）、Chat 一等公民节点（IF/Switch 节点负责分支；Merge 汇总） 有，两层 HITL：① workflow 级——Wait 节点暂停到指定时间/Webhook/表单到达；② AI 工具调用级——AI Agent 执行特定工具前要求人工批准（更接近 LangGraph interrupts）。审批模式＝Human Review 节点（approve-only 或 approve-and-disapprove）+ 之后的 IF 节点按 true/false 分流 节点流（可并行、子工作流嵌套）
LangGraph（官方文档 + 第三方指南） Node（节点，任意函数）、StateGraph/edges（边）、conditional edges（条件边/路由器）、checkpoint（检查点持久化）、interrupt（中断，HITL）、Command（动态续跑） 条件分支是「边的一等属性」（add_conditional_edges 路由器，写代码定义，不是画布节点） 有，HITL 是第一公民：在节点内调用 interrupt() 暂停并持久化状态，外部（人）输入后通过 Command 恢复；典型模式＝"get_approval 节点 + 条件边 router"（同意→继续，拒绝→取消/改稿） 有向图（节点+边）+ 共享 State + checkpoint 持久化

小结：

  • 可视化工作流产品（Dify/Coze/n8n）：条件分支是一等公民节点；只有 LangGraph（代码框架）把条件分支放在边的层面（conditional edges）。
  • 人工审批节点：Dify 有「人工介入」节点、n8n 有「Human Review」节点均为一等公民节点；Coze 无专门审批节点；LangGraph 用节点内 interrupt（暂停原语）+ 条件边实现，本质上是"审批作为节点内事件 + 条件边路由"。
  • 这些产品在这一点上高度一致："人工介入"需要有一个明确的载体（节点或节点内暂停点），因为要挂接审批人、表单、意见、暂停/恢复等多类状态。

1.4 状态机视角（XState / 状态机理论）

概念 定义 与"审核"的对应关系
状态 State 系统在某一时刻所处的确定配置；状态机任一时刻只能处于一个状态 "待审核 / 审核中（pending_approval）"是独立状态
事件 Event 触发状态转换的信号（如 APPROVE、REJECT、REVISE） 审批人的"同意/拒绝/退回"动作 = 事件
转换 Transition 状态+事件 → 确定的下一个状态（确定性：state+event 永远指向同一目标） 审核通过 → 进入下一执行阶段；审核拒绝 → 进入终止/修改状态
守卫 Guard 转换前的条件（cond 谓词，为 true 才允许该转换发生） "审批人是否具有权限""失败重试次数上限"等条件
动作 Action 转换发生时执行的副作用 发送通知、写入审批记录
扩展状态 Context / 层级状态 / 并行状态 上下文变量、嵌套状态、并行区域 审批意见/审批人/超时计时都放 context；"执行中"可嵌套"等待审批"子状态

「审核」在状态机里通常的表达：将审核建模为一个独立状态（等待审批/审核中）+ 事件驱动的转换——APPROVE → next、REJECT → cancelled/rework、REVISE → 回到某前置阶段，必要时用 guard 控制转换合法性。它与工作流图是同构的：工作流的"节点+边"可无损映射为状态机的"状态+转换"，节点间的条件边就是带 guard 的转换。

2. 审核/审批建模方式的产品对比（表格）

产品/范式 审核建模方式 通过路由 拒绝路由 回退/驳回语义
BPMN 2.0（Camunda/Flowable） User Task（活动）+ Exclusive Gateway（网关） 的经典组合：Submit for approval → XOR 网关 → 出边各写条件 XOR 网关的 "approved == true" 出边 → 下一活动（ProcessMind/Gliffy/ProcessMaker 官方示例） XOR 网关 "approved == false" 出边 → 结束事件或修正路径（Gliffy 明确：approval 后加 XOR 网关分 approved/rejected 两条互斥路径） 原生 BPMN 无回退原语：走向先前节点需建模为显式序列流（loop 回边）；动态"退回任意节点"需引擎级处理（Camunda 官方论坛：用 Process Instance Modification 的 cancelActivityInstance + startTransition 实现回退；Flowable 官方论坛：同样要靠引擎 API/迁移实现，官方称"process instance migration API"）
钉钉宜搭（官方） 审批人节点 = 独立一等节点；审批操作 = 节点内按钮（同意/拒绝/转交/加签/退回/收回） 审批人点「同意」→ 节点流转到下一节点（条件模式可路由到不同审批人） 点「拒绝」→ 节点状态为拒绝，流程按规则终止（或签时第一人拒绝即终止） 「退回」按钮可退回指定前序节点；「转交」转给他人；加签分前/后加签；支撑驳回终止与回退重审
飞书审批（官方） 审批人节点 = 独立一等节点；节点类型含"自动通过/自动拒绝" 同意 → 下一节点/结束；可配"仅同意时抄送" 拒绝 → 对应节点拒绝，流程按设计流转（通常是终止） 操作权限勾选"允许回退"后，审批人可回退到 1 个或多个前序节点（所勾选节点均重新审批，重审完回到当前节点继续）；支持转交、前/后/并加签
企业微信审批（官方 API） 审批人节点 = 独立节点类型（node_type=1）；审批结果是节点级状态（同意/驳回/退回等 10+ 种 sp_status） 节点状态=同意 → 流转下一节点（或结束） 节点状态=驳回 → 申请单状态=已驳回 状态机里显式建模：11=退回给指定审批人、15=转交、12=加签、13=同意并加签——回退是节点状态而非图边
明道云（官方） 审批节点 = 独立节点；审批操作：同意/拒绝/退回/转审/加签 同意 → 下一节点 拒绝（否决）→ 整个审批流程结束，需重新发起新流程 退回 → 流程不结束，可退到：所有节点/仅上个节点/指定节点/发起节点；退回意见必填；被退回节点重新提交后按流程顺序或直达当前节点
简道云（官方） 审批节点 = 独立节点；节点操作含"流程否决/流程回退" 同意 → 按流程顺序流转 流程否决 → 流程终止 回退：可退「上一节点」或「指定范围内多个节点」；重提设置：按流程顺序审批 / 直达当前节点 / 由回退人确定；发起/结束节点不可配置回退
氚云（官方） 审批节点 = 独立节点；功能按钮：同意、不同意、暂存、转交、退回 同意 → 下一节点 驳回＝按流转规则（会签/或签、驳回人数）返回前面节点或终止，不可自由选节点 退回＝由单个审批人指定任意前序节点（不受流转规则限制）
Dify（官方） 「人工介入」= 独立节点；节点负责收集审批意见、修改、评论、转交或超时处理 人工放行 → 该节点完成，沿出边继续下一个节点 节点内被驳回/修改后，由条件分支节点按结果路由（或按输出变量走不同出边） 超时处理内建（官方列出的能力）；"转交"内建；暂未见"退回任意节点"的图级原语，通常靠条件边回跳实现
n8n（官方+社区） Human Review 节点（独立）；配置 approve-only 或 approve-and-disapprove、超时 审批值 true → 后续 IF 节点 true 分支继续 审批值 false → IF 节点 false 分支（do nothing / 通知 / 改稿） Wait 节点暂停 + resume URL 恢复；无图级"回退任意节点"，回退逻辑靠条件边回跳子工作流
LangGraph（官方） 节点内 interrupt() 暂停（半独立节点语义）+ 条件边路由；官方模式：get_approval 节点 + router 条件边 条件边读取 resume 载荷，approved → 继续执行 rejected/revised → 条件边路由到取消或修改分支 checkpoint 持久化使"任意点恢复/编辑状态"成为第一公民（可在中断点修改应用状态再续跑），最接近"任意节点回退"
XState（状态机） 独立状态（如 review/pending）+ 事件驱动转换（APPROVE/REJECT/REVISE）+ guard APPROVE 事件 → 转换到下一阶段状态 REJECT 事件 → 转换到终止/返工状态 回退 = 转换到任意前置状态（只要该转换被显式定义）；guard 控制哪些回退合法

提炼共识：

  1. 审批几乎总是被建模为"独立节点/独立状态"（唯一例外是把审核当普通活动属性的场景，未见主流产品这么做）。
  2. 通过/拒绝的路由表达分两派：① 节点多个出口/节点状态值 + 下游条件分支（国内审批产品、n8n IF、LangGraph 条件边）；② 显式排他网关 + 带条件出边（BPMN 正统，与 ① 等价）。
  3. 回退（驳回退回）是超图语义：主流做法是把"退回目标"作为审批节点的内建操作/节点属性（可退回发起人/上一节点/任意指定前序节点/多个节点），由引擎在执行期计算目标节点，而不是在画布上画一条固定的回边——因为退回目标是运行期动态选择的。
  4. 驳回（reject）与退回（rollback）是两回事：驳回=终止或按规则回退、流程可能结束；退回=流程不结束、退到指定节点重审后继续（明道云、氚云、简道云、飞书均如此区分）。

3. 三种审核建模方式的利弊分析

核心问题：「审核」应建模为独立节点、节点的属性、还是边的属性？

方案 A：独立节点（审核把关节点 / Review Node / User Task / Human Review）

维度 评价
可视化清晰度 ★★★ 最高。审核点在画布上一眼可见，阶段间"人机交接"的位置明确；审核人、意见、按钮（同意/拒绝/退回）都直观挂在一个节点上
数据模型简洁性 ★★☆ 中等。需要引入一个节点子类型（或节点 kind=review），节点 schema 需含审批人配置、审批表单、超时、多出口定义；但审核自身的复杂度被封装在节点内部，主图模型保持统一（node + edge）
表达力 ★★★ 最高。通过→正常出边；拒绝→终止/改稿出边；退回→节点内建操作（退回目标可运行期计算）；可附加抄送、会签/或签、超时自动通过等复杂规则而不污染图结构
执行引擎复杂度 ★★☆ 中等。引擎需要支持"暂停-等待-恢复"（HITL 暂停原语）与多出口路由；但由于暂停语义集中在一个节点类型里，实现可控
业界采用 主流：钉钉/飞书/企业微信/明道云/简道云/氚云（审批节点）、Dify（人工介入节点）、n8n（Human Review 节点）、BPMN（User Task + 网关）、LangGraph（interrupt 节点内暂停 + 条件边）

方案 B：节点的属性（审核配置挂在某个"阶段/任务"节点上）

维度 评价
可视化清晰度 ★☆ 最低。审核藏在属性面板里，画布上看不出"这个阶段有人工把关"；阶段多时难以区分哪些要审、哪些不要
数据模型简洁性 ★★★ 最高。不新增节点类型，阶段节点上多一个 needsApproval 配置即可
表达力 ★★☆ 中。单点审核勉强可行；但"审核通过后走分支A、拒绝走分支B"这类路由仍需要额外条件节点/条件边；多个审核结果（通过/拒绝/退回不同目标）表达复杂；"阶段间审核"变成"阶段内嵌审核"，颗粒度不符合"阶段间把关"的诉求
执行引擎复杂度 ★★☆ 中。暂停语义仍在（任何节点都可能要暂停），但引擎要为"几乎所有节点"支持 HITL 挂起，暂停点分散，审计/追踪困难
业界采用 极少作为主方案；仅在轻量场景（如一条消息内审）出现；主流产品都选择独立节点以换取可视化与表达能力

方案 C：边的属性（通过/拒绝 = 出边上的条件）

维度 评价
可视化清晰度 ★★☆ 中。路由本身画得清楚（一条边标 approved、一条标 rejected，等价于 BPMN 网关的出边条件），但"审核"这个活动本身（谁审、暂停、意见、超时）没有载体，审核过程不可见
数据模型简洁性 ★★☆ 中。边需要挂条件表达式；"审核"仍需要一个执行体（否则谁产生 approved 变量？），通常退化为"某个节点输出审核结果变量 + 条件边路由"（即 LangGraph 模式）
表达力 ★★☆ 中。对"审核结果路由"表达很好（条件边天然支持）；但对"审核的交互语义"（审批人指派、表单、意见、退回动态目标、抄送）几乎无法承载
执行引擎复杂度 ★★★ 最低（仅就路由而言）。无需暂停原语的话就是普通条件跳转；但只要有真实人工介入，就必须在某处暂停——那时其实又建了一个"伪节点"（LangGraph 的 interrupt 正是如此：暂停点在节点内，路由在边上）
业界采用 作为路由机制广泛使用（BPMN 序列流条件、LangGraph conditional edges、Dify 的 edge_source_handle），但从不单独承载"审核"语义——都是"审核节点/事件 + 条件边"组合

综合对比表

评判维度 方案A 独立节点 方案B 节点属性 方案C 边的属性
可视化清晰度 ★★★ ★☆ ★★（仅路由）
数据模型简洁性 ★★☆ ★★★ ★★☆
表达力（审核结果路由） ★★★ ★★ ★★★（路由部分）
表达力（审核交互：人/表单/意见/超时/抄送） ★★★ ★★ ★☆
回退/驳回动态目标表达 ★★★（节点内建操作） ★☆ ★☆
执行引擎复杂度 ★★☆（暂停点集中、可控） ★★☆（暂停点分散） ★★★（路由简单，但真实暂停仍需节点载体）
业界主流 ✅ 主流 ❌ 罕见 部分（仅作为路由层，与A组合使用）

结论（对核心问题的回答）：

「审核」应当建模为独立节点（一等公民），并采用"节点多出口/节点输出决策变量 + 条件边路由"的组合式建模——即方案 A 为主体、C 作为路由机制配合（等价于 BPMN 的 User Task + Exclusive Gateway 经典模式）。

理由：

  1. 审核同时是"活动"与"决策点"：它是需要暂停、需要人做事、需要挂表单/意见/指派的活动，同时它的结果决定后续路由。独立节点能同时承载这两个属性；边只能承载路由、属性只能承载配置，二者都承担不了"暂停等人"的交互语义。
  2. 业界共识：从最严谨的 BPMN（User Task + XOR）到国内审批产品（审批人节点），到 AI 工作流产品（Dify 人工介入、n8n Human Review、LangGraph interrupt+条件边），全部采用"审核有独立载体（节点/状态）+ 结果驱动路由"的同一模式。这是被检验过的工程共识。
  3. 回退/驳回是超图语义，必须放在节点内建操作或引擎能力里（退回到发起人/上一节点/任意前序节点是运行期动态选择），无法用静态边表达。

4. 对「AI 智能体工作流」场景的建模建议

场景画像：类似 ComfyUI 的拖拽画布，节点是 LLM 执行阶段（Agent 自主执行），需要在阶段之间插入人工审核把关（阶段产物需人工确认后才能进入下一阶段）。以下为综合上述调研的建模建议。

4.1 总体建议：审核把关节点作为一等公民节点

[开始] → [阶段A(LLM/Agent)] → [审核把关节点] ──通过──→ [阶段B(LLM/Agent)] → [结束]
                                  │
                                  ├──拒绝/终止──→ [结束(失败)] 
                                  └──退回──→ [指定前序阶段重跑]（节点内建操作，运行期计算目标）
  • 审核把关节点（Review Gate Node）：独立节点类型，语义 = "暂停执行，等待人工审核，输出审核结论"。字段建议：approvers（审批人/角色）、review_form（审核表单：展示的阶段产物 + 意见输入）、decision_outputs（通过的决策变量：approved/rejected/revised）、timeout_policy（超时：提醒/自动通过/自动拒绝）、escalation（转交）、notify（抄送，可关"仅通过时通知"）、allow_rollback（退回目标范围：发起阶段/上一阶段/任意前序阶段/多节点）。
  • 通过/拒绝/退回的出口表达：审核节点定义 2~3 个命名出端口（pass / reject / revise）或输出 decision 变量 + 下游条件边（推荐两者都支持：默认出端口直连，复杂分支交给条件节点/条件边，对齐 Dify 的 edge_source_handle 与 LangGraph 的条件边）。
  • 回退语义：放在审核节点的内建操作（"退回"按钮 + 可选目标列表），由引擎执行"取消当前分支 token → 在目标阶段创建重跑 token"，借鉴 Camunda Process Instance Modification（cancelActivityInstance + startTransition）与飞书/简道云"可退到多个指定前序节点"的做法。退回重跑后的再提交语义参考简道云两种模式：按流程顺序重走 / 直达当前审核节点。
  • 与条件分支节点的关系：条件分支节点保留为通用路由节点（AI 自主判断的路由用 if/else 或 LLM 判断）；审核把关节点不是条件分支的替代品——它是"暂停+人工"，条件分支是"即时+规则/模型"。两者分工明确。

4.2 数据模型要点（供后续设计参考）

实体 建议 依据
图模型 Graph = { nodes[], edges[ {source, sourceHandle, target, condition?} ] }；边可带条件表达式（BPMN sequence flow 条件、Dify edge_source_handle） BPMN / Dify / LangGraph
节点基类 node = { id, type, name, inputs, outputs }；type 枚举含 llm_stage / agent_stage / review_gate / condition / code / tool / start / end Dify / Coze / n8n 节点体系
审核节点 作为 review_gate 独立子类型；务必建模"暂停-恢复"状态（pending_review → approved/rejected/rolled_back），与状态机视角一致 XState（独立状态+事件转换）、企业微信节点状态字典
条件分支 推荐作为一等公民节点（对齐 Dify/Coze/n8n 的用户习惯）；同时允许边带条件（对齐 LangGraph 与 BPMN）作为高级能力 Dify/Coze/n8n/LangGraph 对比
执行引擎 需要三类原语：① 节点执行（LLM/工具/代码）；② 暂停/等待人工（interrupt/resume，参考 LangGraph checkpoint + interrupt）；③ 分支路由（条件边/多出口）。回退 = 引擎 API（参考 Camunda Process Instance Modification） LangGraph / Camunda
运行状态 每次执行为 DAG 的一次遍历：记录每个节点的输入/输出/决策句柄；审核节点额外记录审批人、意见、时间戳（审计） Dify WorkflowNodeExecutionModel

4.3 为什么这个建议适合"AI 自主执行 + 阶段间审核"场景

  • AI 阶段是"黑箱自动化"，阶段间审核是把控点，必须显式、可见——独立节点让"人在回路的位置"一目了然，符合 Dify 官方"在敏感操作前暂停、关键判断交给人"的实践。
  • 暂停必须有一等公民支持：AI 阶段时长不定（一次 LLM 调用秒级，但一个 agent 阶段可能分钟级），真实人工审核更可能数小时——需要 checkpoint 持久化 + 恢复机制（LangGraph 已验证该模式：interrupt + Command + checkpoint）。
  • 审核结果驱动路由：通过→下一阶段、拒绝→终止或改稿、退回→指定前序阶段重跑——用"多出口 + 条件边"表达，与 LangGraph 的 get_approval + router、n8n 的 Human Review + IF 完全同构，参考实现成本最低。
  • 避免过度设计：不建议"节点的属性"方案（审核不可见、暂停点分散）；不建议纯"边的属性"方案（没有载体承载审批交互与回退语义）。独立节点 + 条件边路由是三方案中可视化、表达力与实现复杂度平衡最优的。

4.4 建议的最小节点清单（供数据模型落地）

节点类型 用途 对应参考
Start / End 输入与输出 Dify、Coze、BPMN 事件
LLM / Agent 阶段节点（可含工具调用） AI 自主执行阶段（可 loop/多实例） Dify LLM/Agent、Coze 大模型、n8n AI Agent、LangGraph node
审核把关节点（Review Gate） 阶段间人工审核，多出口（pass/reject/revise），内建退回/转交/超时 BPMN User Task、钉钉/飞书/企微审批节点、Dify 人工介入、n8n Human Review、LangGraph interrupt
条件分支节点（if/else） AI 或规则驱动的路由 Dify/Coze/n8n
代码/工具/HTTP 节点 通用能力 Dify、Coze、n8n、BPMN Service/Script Task
变量聚合/模板（可选） 数据整理 Dify、Coze

5. 来源 URL 汇总

官方文档（权威来源）

第三方文章/教程（补充说明，标记为第三方）

附：本报告的确定性说明

  • 百分百确认：BPMN 元素分类与网关语义、各产品官方文档中列出的节点类型与审批按钮/状态字典、Dify/n8n/LangGraph 官方 HITL 能力描述——均直接出自官方文档原文。
  • 很大概率：对"业界主流选择是独立节点+条件路由"的归纳——基于上述 12+ 个产品的官方/权威资料的一致性得出；"审批应建模为独立节点"为综合分析结论，属合理推断而非任何官方标准的规定。
  • 可能："回退目标作为节点内建操作、由引擎在执行期计算"的工程建议——综合 Camunda/Flowable 官方论坛做法与国内审批产品的一致设计推断。

（调研日期：2026-08-20；未修改项目任何代码文件。）