VM0 工作流跑到一半就停住 / 是触发条件写错还是工具没授权？

工作流能启动、走到某个动作就停住，最常见的原因不是“整条流程挂了”，而是卡在单个节点上：要么这次运行的入参没命中触发条件或分支判断，要么该节点调用的外部工具在权限、参数或超时上出了问题。判断顺序建议从运行记录入手，先把中断点从整条流程缩小到一个节点，再回头核对触发条件，然后确认工具授权范围，最后单独重放该节点的入参拿到真实错误。这样做的目的是避免在错误的层级反复改配置——触发条件写错却去调权限，或者外部系统慢却反复改分支写法，都会让排查绕圈。

流程中断时，先不要猜是触发还是授权问题。建议按“运行记录→触发条件→工具授权→单独重放→顺序或超时”五步走：记录里定位停止节点的名称、入参和状态，确认这次运行是否命中分支；再对照该节点工具的只读/读写权限是否覆盖本次调用；然后把失败节点入参单独重放，记录返回的错误类型（鉴权失败、参数不合法、超时、业务拒绝）；最后区分是节点执行顺序不对还是外部系统超时，分别改编排顺序或超时/重试配置。每一步都以可观察的日志、返回码或页面状态为依据，不靠推测下结论。

在运行记录里找到停止的那个节点并抄下它的输入

整条流程显示“失败”或“已结束”时，它给的信息太少，先把它拆到节点级别。打开这次运行（run）的详情，重点看三类字段：节点名称、该节点的入参、该节点的执行状态。不同平台叫法不同，通常对应 Run / Execution 详情里的 Step 列表、Input / Payload、Status 或 Result。

节点名称（step / node name）：确认到底是哪个动作停住，而不是看流程整体的最终状态。
入参（input / payload / context）：抄下这次运行真正传给该节点的字段和值，这是后面核对触发条件和重放的依据。
状态（status / result）：区分 paused、waiting、failed、timeout 还是 skipped。状态不同，后面的排查方向不同；waiting 往往意味着还没返回，failed 通常有错误体。

如果记录里根本没有这个节点的入参，只有一个“流程失败”，那么问题可能出在前一个节点没有产出期望字段，先检查上游节点的输出是否为空。把节点名称和入参抄到一张临时表里，后面几步都围绕这份记录展开。

回头核对触发条件，这次运行的入参是否命中判断分支

流程能启动说明入口触发基本成立，但“启动”不等于“走对了分支”。很多流程会先做一次条件判断，再决定进入哪个节点。如果这次入参不满足任何分支条件，常见表现是流程不报错、直接结束，或者走到一个默认的空分支就停了，看起来像“跑到一半停住”。

分支条件建议写得可读、可核对，例如（伪配置，字段名按你平台的写法替换）：

conditions:
  - name: need_sync
    when: "{{ trigger.type }} == 'order.created' and {{ trigger.amount }} > 0"
    next: sync_to_downstream
  - name: skip_all
    when: "true"
    next: end

核对时把运行记录里抄下的入参代进去，逐条比对字段名和值：字段是否真叫 trigger.type，大小写和类型是否一致，数值是不是字符串。入参不满足条件时的实际表现一般是走 default 分支、被标记 skipped，或流程提前结束而不进入目标节点。如果确认是条件没命中，改的是触发条件或上游输出的字段映射，而不是工具的授权。

检查该节点所用工具的授权范围是否覆盖本次调用

触发条件命中、节点也确实执行了，却停在这一步，接下来看该节点绑定的工具授权。授权不足和调用失败在日志里表现不同，值得区分。

只读权限：通常覆盖查询、列表、读取单条记录。这类调用不修改外部系统状态。
读写权限：在只读基础上覆盖创建、更新、删除、发送等写入动作。如果节点要写数据但只授权了只读，通常会被拒绝。

判断方式：先看这个节点实际要做的是读还是写，再看它绑定凭证的权限范围是否包含该动作。授权不足时的返回特征通常是明确的鉴权类错误，例如 401 / 403、permission denied、insufficient scope、access denied，错误信息里往往带 scope 或 role 字样。如果错误是参数不合法、资源不存在或超时，那就不是授权问题，不要先去改权限。需要结合你的平台确认错误码含义，不要只看错误文案的字面。

把失败节点的入参单独重放一次，记录返回的错误类型

只看整条流程的失败，拿不到可比较的错误。把上一步抄下的该节点入参，单独向那个工具发一次请求，观察真实返回。通用请求骨架如下（占位符按你实际的工具与鉴权方式替换）：

POST /your-tool-endpoint
Authorization: Bearer <token-or-scope>
Content-Type: application/json

{
  "field_a": "<来自运行记录的实际值>",
  "field_b": "<来自运行记录的实际值>"
}

返回体里重点记录这些字段：状态码（HTTP status 或业务 code）、错误类型（error / type）、错误信息（message）、以及是否带 scope、role、timeout 等提示。把结果归类记录，方便对比是鉴权、参数还是超时问题：

鉴权类：401 / 403、permission denied、insufficient scope —— 指向授权范围。
参数类：400、invalid argument、missing field —— 指向入参或字段映射。
超时类：timeout、deadline exceeded、连接被断开 —— 指向外部系统响应或超时配置。
业务类：409、rate limited、资源已存在 —— 指向外部系统当前状态，需要看是否可重试。

重放时建议用一次、小范围、可回滚的调用，避免写入动作误改真实数据；如果节点本身是写操作，先确认是否可以先用查询接口验证凭证是否有效。

判断是节点顺序问题还是外部系统超时，再决定改哪一层

拿到错误类型后，最后区分是编排顺序错了，还是外部系统响应慢导致超时，因为这两类的修改位置完全不同。

顺序问题：表现是该节点依赖的上游字段还没产出、或节点执行时机早于数据准备完成，典型错误是字段为空、资源不存在（404 / not found）、前置状态未就绪。修改位置在流程编排本身：调整节点顺序、补上等待或前置节点、修正字段映射。
外部超时：表现是该节点已经发起了调用，但外部系统在设定时间内没返回，典型错误是 timeout、deadline exceeded、连接中断；单独重放同一入参有时成功有时失败。修改位置在该节点的超时与重试配置，或外部系统本身的响应能力，而不是改分支条件。

可观察差异可以这样区分：如果单独重放立刻返回明确错误，多半是顺序、参数或授权；如果单次重放偶发成功、失败时耗时接近设定的超时阈值，更偏超时。改配置时一次只动一层，改完用同一条运行记录对比状态变化，确认问题确实落在这一层，再继续下一步。