NocoBase AI 员工节点审批机制完全指南：通知、批准、修改与拒绝

NocoBase AI 员工节点审批机制完全指南：通知、批准、修改与拒绝

【免费下载链接】nocobaseNocoBase is an open-source AI + no-code platform for building business systems fast. Instead of generating everything from scratch, AI works on top of production-proven infrastructure and a WYSIWYG no-code interface, so you get both speed and reliability.项目地址: https://gitcode.com/GitHub_Trending/no/nocobase

在 NocoBase 中，当工作流里的 AI 员工节点输出完内容后，可以接入"节点审批"环节，由人工审核人把关后再让工作流继续流转。本文基于当前仓库中的官方文档 节点审批 与 AI 员工节点，结合 plugin-ai 与 plugin-flow-engine 的源码实现，系统讲解审批通知从哪来、审批卡片长什么样、Approve / Revise / Reject 三种操作分别做什么，以及背后的任务状态机与数据模型。读完本文，你将能完整掌握 AI 员工节点的审批闭环，并能结合源码理解其底层原理。

前置概念：什么时候会触发节点审批

"节点审批"并不是一个独立可添加的节点类型，而是 AI 员工节点自身的一个可选环节。在配置 AI 员工节点时，"反馈与通知"一栏中的"审批设置"决定了节点是否需要人工审核，共三种模式（见 AI 员工节点配置）：

• No required：AI 输出内容不需要人工审核，AI 结束输出后工作流自动继续流转；
• Human decision：AI 输出内容必须通知审核人进行人工审核，人工审核后工作流才继续流转；
• AI decision：由 AI 决定是否通知审核人对输出内容进行人工审核。

如果审批模式不是No required，则必须为节点配置一个或多个审核人。当 AI 员工节点中的 AI 输出完所有内容后，会给该节点配置的所有审核人发送通知；只需要被通知的审核人中的一人完成审批操作，工作流即可继续流转。

这一设计在源码中有明确的常量定义，位于 constants.ts：

export const REQUIRES_APPROVAL = { NO_REQUIRED: 'no_required', AI_DECISION: 'ai_decision', HUMAN_DECISION: 'human_decision', } as const;

由此可见，前端三种审批模式与后端存储值一一对应：no_required、ai_decision、human_decision，该值会被写入工作流任务的requiresApproval字段。

通知：审批人如何感知待审批任务

主页红点提示

工作流中的 AI 员工节点被触发后，节点中配置的审批人可以在主页的 AI 员工入口看到红点提示，提示有新的待审批事项需要处理。

红点提示对应的底层数据，是"审核人-任务"的关联关系。在 ai-workflow-tasks.ts 中可以看到，任务与用户通过多对多关联建立联系：

{ type: 'belongsToMany', name: 'users', target: 'users', foreignKey: 'aiWorkflowTaskId', otherKey: 'userId', through: 'usersAiWorkflowTasks', }

每个被通知的审核人都会在usersAiWorkflowTasks关联表中有一条记录，其中携带read标记（是否已读）。服务端读取任务详情时会把read一并返回（见 aiWorkflowTasks.ts），前端据此渲染"未读 → 红点"的提示状态。

会话列表中的待审批任务

进入 AI 员工会话列表，可以看到标记为待审批的工作流任务。点击任务即可进入对应的会话窗口。

在服务端任务列表中，任务的展示信息来源于aiWorkflowTasks集合，其核心字段包括（见 ai-workflow-tasks.ts）：

其中sessionId与jobId均带有唯一约束，保证一个审批任务唯一对应一个 AI 会话与一个工作流执行。

审批：进入会话查看 AI 输出

点击工作流任务打开会话窗口，窗口内展示 AI 员工的历史消息，AI 员工最后发送的卡片就是当前节点需要审批的内容。

这张卡片在前端由 WorkflowTaskOutputCard.tsx 渲染：卡片标题以-分隔展示工作流标题与节点标题，卡片内容按照节点配置的结构化输出 Schema 逐字段渲染 AI 生成的结果，字符串、数字、布尔值直接展示（Markdown 渲染），对象类型则按 JSON 格式化展示。

卡片顶部提供的操作区即原文档所述的三种操作：Approve（批准）、Revise（修改）、Reject（拒绝）。在源码中对应三个动作标识：

const [action, setAction] = useState<'approve' | 'reject' | 'revise' | null>(null);

同时，按钮是否可点击受到严格约束（见 WorkflowTaskOutputCard.tsx）：

const disabled = toolCall.invokeStatus !== 'interrupted' || Boolean(action) || readonly;

也就是说，只有当工具调用处于interrupted（等待人工介入）状态、尚未选择操作、且会话未进入只读时，按钮才可点击；一旦做出选择或会话变为只读，操作按钮即被禁用，防止重复审批。

三种操作详解

Approve：批准

点击 Approve，表示批准使用 AI 生成的内容，工作流继续流转。审批完成后，会话变成只读状态，不可以继续和 AI 员工对话。

从状态机的角度看，Approve 意味着任务从"待审批"进入"已批准"。任务的全部状态定义在 constants.ts：

export const AI_WORKFLOW_TASK_STATUS = { PROCESSING: 'processing', PENDING_ACCEPTANCE: 'pending_acceptance', PENDING_APPROVAL: 'pending_approval', APPROVED: 'approved', REJECTED: 'rejected', ABORTED: 'aborted', } as const;

一个完整任务的典型流转为：

processing → pending_acceptance → pending_approval → approved（批准，继续流转） ↘ rejected（拒绝，停止流转）

其中pending_acceptance → pending_approval的转换发生在审核人"接收"任务时。服务端accept动作会校验当前用户是否属于该任务的通知审核人，并将status更新为pending_approval、写入acceptedUserId（见 aiWorkflowTasks.ts）。由于任务要求"一人完成审批即可"，acceptedUserId采用"先到先得"的原子更新语义：只有当acceptedUserId仍为空且状态为pending_acceptance时才允许接收，避免多个审核人同时抢单。

Revise：修改

点击 Revise，向 AI 提出修改意见，发送后 AI 会回复一张新的审批卡片，进入新一轮的审批循环。此时会话保持可交互状态，AI 会根据修改意见重新生成输出，等待再次审批。

从交互设计看，Revise 是三种操作中唯一允许"继续对话"的路径——它没有直接终结任务，而是把控制权交还给 AI，让内容迭代到满足审核要求为止。这与 Approve / Reject 之后"会话变成只读"的行为形成鲜明对比。

Reject：拒绝

点击 Reject，表示拒绝执行 AI 生成的内容，工作流停止流转。会话变成只读状态，不可以继续和 AI 员工对话。

服务端reject动作会将任务状态置为rejected，同时将对应工作流 Job 的状态置为JOB_STATUS.REJECTED，从而中断工作流的后续节点执行（见 aiWorkflowTasks.ts）。与accept类似，reject同样校验任务必须处于pending_approval且acceptedUserId为当前用户，确保只有接收了任务的审核人才能执行拒绝操作。

只读状态：审批后的会话保护

无论 Approve 还是 Reject，审批完成后会话都会进入只读状态，用户不能再继续与 AI 员工对话。这一约束在前端与服务端都有保障：

• 前端：chatBoxModel.readonly为 true 时，审批卡片按钮禁用（见 WorkflowTaskOutputCard.tsx），发送消息的入口同样被关闭；
• 服务端：任务详情接口返回readonly字段，其判定逻辑为task.status !== 'pending_approval' || task.acceptedUserId !== userId（见 aiWorkflowTasks.ts），即任务不在待审批状态、或当前用户不是任务接收人时，一律视为只读。

这套"前端按钮禁用 + 服务端状态判定"的双重保护，确保了已终结的审批任务不会被事后篡改或继续对话。

小结

NocoBase 的 AI 员工节点审批机制可以概括为一条完整闭环：

1. 配置：在 AI 员工节点中设置审批模式（No required/Human decision/AI decision），非免审模式下配置一个或多个审核人；
2. 通知：AI 输出完成后，任务进入待审批状态，所有审核人在 AI 员工入口看到红点提示，并可在会话列表中找到对应任务；
3. 审批：进入会话查看 AI 生成的审批卡片，执行 Approve（批准继续流转）、Revise（提出意见让 AI 重新生成）或 Reject（拒绝并终止工作流）；
4. 收尾：批准或拒绝后会话进入只读状态，防止后续修改。

这一机制使得"AI 自动产出 + 人工关键把关"的分工得以落地：AI 负责批量生成内容与结构化输出，人在节点层面掌控最终决策权，适用于内容审核、业务单据审批、AI 生成结果人工确认等需要人机协同的生产场景。更深入的细节可继续查阅 AI 员工节点配置文档 以及 plugin-ai 中的 任务状态常量、任务集合定义 和 任务资源实现 等源码文件。

【免费下载链接】nocobaseNocoBase is an open-source AI + no-code platform for building business systems fast. Instead of generating everything from scratch, AI works on top of production-proven infrastructure and a WYSIWYG no-code interface, so you get both speed and reliability.项目地址: https://gitcode.com/GitHub_Trending/no/nocobase