AI 工作流的状态管理：不要让“正在处理”成为终点

业务状态与程序状态需要对应

程序返回成功，可能只代表请求已经送出，未必代表业务系统完成了处理。“正在处理”也可能掩盖排队、等待确认或已经超时等不同情况。状态设计应接近用户实际关心的进展。

例如，资料生成完成与资料审核完成应分别表示。只有经过审核才允许进入下一业务阶段时，不能因为文件已经存在，就把整个任务标成完成。

状态变化应有明确条件

每一次变化需要说明由什么事件触发、检查哪些条件、记录什么结果。对于跨系统动作，保留任务标识与外部记录的对应关系，方便查证。

同一事件可能重复到达，状态也可能在等待期间发生变化。执行前重新核对当前状态，可以避免旧事件把任务退回过去，或重复触发已完成动作。具体规则应由业务流程决定。

恢复应从已知事实开始

中断之后，先检查哪些动作已经产生外部结果，再决定恢复位置。不能因为本地没有收到响应，就认定对方没有执行。查询外部状态与幂等设计可以减少重复动作。

人工接手时，应能看到最后确认的状态、相关资料与未完成事项。操作界面可以提供明确的恢复入口，但不宜允许任意跳转到“完成”而不留依据。

状态清楚，组织才敢于依赖自动化

员工不需要知道每个技术节点，却需要知道任务是否还在推进、是否轮到自己处理，以及异常由谁负责。状态信息因此也是协作界面。

工作流的成熟程度，往往在中断时最容易看清。正常路径可以演示效率，而准确的状态与恢复能力决定它能否承受日常变化。

让中断后的人知道接哪一步

为待补资料、待确认、执行中、完成和异常定义进入条件与处理角色。断网恢复时先查外部结果，再更新状态；不能只把程序成功或聊天中一句完成当作业务已经结束。