请提供原始标题，我将为您生成优化后的SEO标题。

先给出一个明确的结论：要让扣子工作流与真实的审批系统（飞书、钉钉、自建后台均可）对接，并在人工节点处“阻塞”等待外部审批结果返回后再继续执行，最可靠的方式并非死循环轮询，也不是挂个“暂停等待”节点——这些方案延迟高、容易丢失任务、也无法感知驳回操作。正确的路径只有一个：Webhook 回调。由审批系统主动将结果推回，再由扣子自身恢复流程。

具体搭建方法？四步即可完成。

确认工作流支持 Webhook 触发与回调

登录 coze.cn，进入「工作空间」→「资源库」→「工作流」，找到目标工作流，点击右侧的「…」→「设置」，检查「Webhook 触发」是否已开启。若未开启则启用，然后复制系统生成的 Webhook URL。此地址是回调的唯一入口：所有审批结果必须 POST 到这个地址，且 body 中必须携带 instance_id 字段，二者缺一不可。

注意一点：Webhook 触发仅对配置之后新启动的流程实例生效。已运行的老流程无法中途绑定，必须重新触发一次。

在流程中插入人工审核节点

将“卡住等审批”的环节嵌入工作流，有两种实现方式。

方式一：使用「HTTP 请求」节点模拟挂起
拖一个「HTTP 请求」节点到画布，命名为“等待审批结果”。请求方式选择 GET，URL 填写你自己的中转服务地址，例如 https://your-api.com/wait-for-approval?instance_id={{start.instance_id}}，超时时间设为 86400 秒（即 24 小时）。注意，这里并非真正在傻等，本质上是将流程的控制权临时交出。

方式二：使用「结束节点」主动退出 + 外部唤醒（推荐）
这是更干净的做法。删除默认的结束节点，在需要审核的位置放置一个「结束节点」，输出字段写成 { "status": "pending", "instance_id": "{{start.instance_id}}" }。流程在此处正常终止，但返回了一个 instance_id 给外部。审批系统拿到该 ID 后，携带审批结果调用扣子的 Webhook URL，流程即可被“唤醒”继续执行。

配置审批系统回调扣子

这一步的核心只需三件事：

第一，确保审批系统能够发起 HTTP POST 请求，这通常是标配，不再赘述。

第二，构造回调 payload，必须包含以下字段：

{ 
  "instance_id": "wf_xxx123", 
  "approval_result": "approved", 
  "approval_comment": "同意上线" 
}

第三，将这份 JSON POST 到你之前复制的 Webhook URL，Content-Type 务必设为 application/json。

需要特别强调：扣子只认 instance_id 字段，且必须与流程实例的 ID 精确匹配。字段名写错（如写成 id 或 workflow_id），或值为空，回调都会静默失败，流程永不会恢复，这个陷阱极易踩中。

第四，回到扣子工作流，在「开始节点」后面的第一个节点上，勾选「接收 Webhook 输入」，将 approval_result 字段映射为一个变量，后续条件分支依靠它来判断。

在工作流内处理审批结果分支

结果进入后，需要有一个判断点。

步骤一：从左侧拖一个「选择器」节点，放在 Webhook 开始节点后面。

步骤二：点击配置 → 添加分支，条件设为 {{approval_result}} == "approved"。

步骤三：再添加一个分支，条件设为 {{approval_result}} == "rejected"。

步骤四：Approved 分支连接后续的业务节点（如发送通知、更新数据库）；Rejected 分支连接另一个「结束节点」，输出 {"code": 403, "msg": "审批未通过"}。

这里遵循一个原则：判断逻辑不要交给「大模型节点」处理。会引入不确定性和不必要的 token 消耗。选择器节点本身就是轻量、确定、可审计的分支控制点，最适合此任务。