运行、审批与排错
理解 workflow 为何停住、该不该批准，以及如何安全重试。
真正把 workflow 用起来以后，最常见的问题不是“怎么画”，而是：
- 为什么停住了？
- 这是不是该批准？
- 我该重试哪一步？
- 是节点有问题，还是权限有问题？
先判断卡在哪一层
工作流停住时，通常先分成四层来看：
| 层级 | 常见现象 | 代表什么 |
|---|---|---|
| 输入层 | 一开始就跑不起来 | 入口字段、上下文或前置条件不完整 |
| 节点层 | 某个节点失败或无输出 | 节点配置、能力、数据形状或连接有问题 |
| 审批层 | 明明没报错，但流程不继续 | 正在等待人工决定 |
| 外部执行层 | 审批后仍失败、提交后无结果 | 目标系统、权限、浏览器动作或外部服务没成功 |
运行前先做这五件事
确认输入字段不是空壳，尤其是项目、文件、数据集、目标对象。
确认外部连接、模型和权限处于可用状态。
确认审批点已经放在高影响动作前，而不是事后补救。
先用非敏感测试数据跑最小路径。
决定这轮是验证结构，还是验证真实结果，不要两者混在一起。
常见运行状态怎么理解
| 状态感受 | 用户应该怎么理解 |
|---|---|
| 运行中 | 还在推进，不要急着重复提交 |
| 等待 / paused | 可能在等审批、资源、连接或下一步条件 |
| 完成 | 执行结束了，但仍要看结果是否真可用 |
| 失败 | 要找第一个失败节点，而不是只看最后一句错误 |
| 已停止 | 先弄清是手动停止、策略阻断还是外部失败 |
审批在 workflow 里到底是什么角色
审批不是“多一道麻烦流程”。
它的作用是把这些动作拦在最后的人类判断前：
- 发送消息、邮件、公开内容；
- 提交网页表单；
- 写入外部系统；
- 发布交付物；
- 删除、覆盖、移动重要数据；
- 任何可能产生费用、权限或对外后果的动作。
所以如果你的流程会：
- 发出去；
- 提交掉；
- 改掉别人的东西；
- 让外部世界状态变化；
那就应该认真设计 approval。
哪些审批最容易被放错位置
最常见的错误有三个：
- 在提交之后才审批；
- 在整个流程最后统一审批；
- 把多个后果不同的动作合并成一个审批。
更合理的做法通常是：
- 提交前审批；
- 对外发送前审批；
- 对高风险动作单独审批。
遇到 workflow 停住时的排查顺序
先看这是不是在等审批，而不是先假设系统坏了。
如果不是审批，找到第一个失败节点，而不是最后一个受影响节点。
确认失败来自输入、节点配置、外部连接还是权限。
如果是浏览器或外部动作失败，检查目标系统实际状态，避免重复提交。
只重试安全的那一段，不要默认整条流程从头再来。
什么情况下不要立刻重试
- 你不确定外部动作是否已经生效；
- 失败点发生在发送、提交、支付、删除之后；
- 浏览器动作可能已经点击过提交；
- 同一个 run 里已经有部分交付物写入；
- 你还没看清审批或运行记录里的证据。
这时候更稳的是先回到：
先确认真实状态，再决定是重试、补节点，还是新建 run。
什么时候说明是 workflow 设计问题
通常满足这些情况时，更像是 workflow 本身需要调整：
- 每次都卡在同一类节点；
- 审批总是太晚或太早；
- 节点输入输出长期混乱；
- 同样任务换个输入就完全不可预测；
- 排错时永远分不清谁负责什么。
什么时候更像是环境或权限问题
- 同一节点昨天能跑，今天突然全挂；
- 错误集中在浏览器、外部连接、Provider 或系统执行；
- 审批通过后外部动作仍失败；
- 不同 workflow 在同一能力上一起出问题。
截图占位
后续建议补 4 张图：workflow run 列表、单次 run 详情、待审批项、审批通过后回到运行记录的结果。
录屏占位
后续建议补 2 段短录屏：一段展示 run 失败后的排查路径，一段展示审批前后 workflow 的继续执行。