企业流程经常要调用订单、财务、人事或消息系统。接口返回成功，只说明对方收到并处理了请求的一部分；工作流还要把回执接回当前任务，更新节点状态，保存可查询的业务编号。缺少这一步，用户看到的页面状态和业务系统里的真实结果就可能不一致。
概念示意图：外部接口回执回到 Workflow 状态，任务才能判断业务是否真正完成。
请求发出后，至少要留下三类信息
每次外部调用都应记录本次任务、执行节点和目标对象。请求编号用于向外部系统查询，节点编号用于回到工作流定位位置，目标对象用于确认这次动作作用在哪条订单、哪张发票或哪个员工记录上。
接口响应还要区分业务成功、业务拒绝、参数错误和结果未知。HTTP 200 只能说明网络层收到响应，不能替代外部系统的业务状态。对付款、写入、发消息等动作，最好保存外部返回的状态和时间。
页面状态和业务状态需要分开看
工作流节点可能处于运行中、成功、失败或等待。外部系统还可能返回已受理、处理中、已完成、已拒绝等状态。两组状态并非一一对应：请求已受理时，节点可以进入等待；业务完成后，节点才适合标记为成功。
| 工作流状态 | 外部回执 | 后续动作 |
|---|---|---|
| 运行中 | 尚未收到 | 等待或按策略查询 |
| 等待 | 已受理、处理中 | 保存编号，等待更新 |
| 成功 | 已完成 | 写入最终结果并通知 |
| 失败 | 业务拒绝、参数错误 | 停止并返回原因 |
| 结果未知 | 超时或连接中断 | 先查外部状态，再决定是否重试 |
超时不能直接当成失败
调用超过等待时间时，外部系统可能根本没收到请求，也可能已经完成动作，只是响应没有回来。此时直接重试，容易产生重复订单、重复通知或重复写入。
更稳妥的路径是保存原请求编号和幂等键，先查询外部系统是否已有对应结果。查到已完成，就把回执补回任务；查到未受理，再根据错误类型决定是否重试；始终无法确认时，保留"结果未知"并交给人工判断。
ZGI Workflow 把状态放回运行链
ZGI Workflow 的运行记录包含版本、节点状态、输入输出和事件信息。接入外部系统时，可以让调用节点输出请求编号、目标对象和响应状态，再由后续节点决定查询、等待、通知或人工处理。
这里需要团队补齐外部接口的业务规则。ZGI 能够承接节点和状态的组织，接口是否支持幂等、查询接口怎样设计、哪些状态允许重试，仍取决于具体业务系统。
用一条真实任务验收
挑一条会写入外部系统的任务，分别模拟正常响应、业务拒绝、网络超时和响应丢失。每种情况都检查工作流节点状态、外部业务编号、重试行为和最终通知。特别关注"请求已成功但响应丢失"这条路径，它最容易被误判成可直接重试。
当运行记录能回答"谁发起、调用哪个接口、作用于哪个对象、外部返回什么、任务现在停在哪里"，排查才有稳定入口。业务系统的最终状态也应成为任务完成条件的一部分。
对于需要异步处理的接口，还要约定查询间隔、最长等待时间和人工接管条件。状态长时间没有变化时，系统可以提醒负责人查看外部系统，而不是让同一节点无期限保持运行。每一次查询都沿用原请求编号，便于把多次回执归并到同一条任务记录。