AI工作流演示能跑，上线就失败？HTTP接口与异常恢复的五项检查

一个工作流演示很顺畅：收到请求，调用模型，生成摘要，再写入业务系统。上线后却开始出现重复记录、空结果和长时间等待。页面上的节点大多显示绿色，使用者仍然不知道任务究竟有没有完成。

此时需要检查的，不只是模型输出，还包括输入契约、接口行为、状态保存和恢复路径。成功完成一次演示，只证明这组输入在当时的环境中跑通；它没有覆盖重复触发、网络中断和业务校验失败。

本文以“将内部请求整理为工单草稿”为例，说明从最小流程走向可维护自动化时的五项检查。以下流程和字段为工程示例，不是某个产品可直接导入的配置，也不是实测性能报告。

一、先定义一个足够小的交付结果

Runwise 原文强调从简单流程验证价值、掌握 HTTP 请求能力，并为失败场景预留兜底。对开发团队，可以把这些经验落实为一个很具体的要求：先让一个小任务具备可确认的结果。

例如，第一版只完成“读取指定请求，生成结构化草稿，放入待审核队列”。暂时不把自动回复、分派负责人和关闭工单全部接进去。

阶段	要确认的结果	不足以证明成功的信号
接收	请求被识别并获得任务编号	触发节点亮绿灯
生成	必需字段符合约定	模型返回了文本
校验	字段和值符合业务规则	JSON 能够解析
保存	草稿存在且可回查	接口没有抛异常
交付	使用者能找到草稿及状态	工作流界面显示结束

最小流程不等于不处理错误。任务可以小，但输入、结果和责任范围应当明确。

二、检查一：输入契约是否稳定

先定义什么请求可以进入流程。以工单草稿为例，至少需要稳定的来源标识、原始描述、所属业务范围和接收时间。

{
  "source_request_id": "req_example_001",
  "scope": "internal_support",
  "description": "用户提供的原始问题",
  "received_at": "2026-09-14T09:00:00+08:00"
}

示例时间和编号只是占位值。实际来源标识应由可信系统提供，不能让模型自由生成后用于判断同一请求。

同时定义缺失和异常输入如何处理：描述为空、附件无法读取、请求超出范围，分别应返回什么状态？如果一律让模型“尽力回答”，不完整输入就可能变成看似完整的错误结果。

输入契约变化也应有版本。上游把一个字段从字符串改为列表时，下游应能明确报错或转换，而不是默默丢失内容。

三、检查二：HTTP 节点是否理解业务结果

HTTP 请求节点能补足现成连接器没有覆盖的接口，但它不会自动解决认证、权限、分页和数据语义问题。

接入一个接口前，至少弄清楚以下事项：

项目	应确认的内容
认证与权限	使用哪个执行身份，可以访问哪些对象
参数	必填字段、类型、长度及允许值
返回	同步成功、异步受理和业务失败如何区分
分页	是否只读取了第一页
限流	服务端如何提示等待及配额不足
超时	连接失败与请求已执行但响应丢失如何辨别

例如，收到“已受理”的响应，可能只表示任务进入队列，并不表示草稿已创建。流程应根据接口实际契约，查询处理状态或等待回执，再确认业务对象。

密钥应放在工作流平台或服务端的凭据机制中，不要塞进模型提示、正文示例或普通日志。模型需要知道工具用途，不需要看到认证秘密。

四、检查三：重试会不会制造重复写入

最麻烦的情况往往是：写请求发出后连接超时，调用方不知道服务端是否已完成。此时直接再次提交，可能创建第二份记录。

可以按接口能力选择处理方式：

• 服务端支持幂等键时，同一次业务操作使用稳定的键，重试沿用原键。
• 不支持时，保存操作记录，并根据来源编号或业务唯一键查询结果。
• 无法确认执行状态时，标记为待核，转入人工或专门的核对流程。

下面是状态设计示意：

received → validated → draft_ready → submitting
                                  ├─ 回执确认 → completed
                                  ├─ 明确拒绝 → failed
                                  └─ 结果未知 → needs_reconciliation

“结果未知”应该有独立状态。它与明确失败不同，也不能被当成成功。

重试策略还要设置上限，并遵循接口的等待要求。持续重试权限不足或参数错误，通常不会带来不同结果。对于临时不可用的问题，可以有限退避重试；对于输入和权限问题，应先修正原因。

五、检查四：故障后能从哪里接续

如果模型草稿已经生成，只是在保存时失败，恢复时通常不必重新读取、重新生成全部内容。

建议在有价值的阶段保留检查点：输入摘要或引用、已验证的草稿、目标对象、操作编号以及最后确认的状态。保存内容的范围和期限，应按数据敏感程度与业务需要控制。

恢复逻辑至少回答三个问题：

1. 哪些步骤已被可靠确认？
2. 哪些动作可能已经发生，需要先核对？
3. 下一步可以安全地从哪里继续？

通知人工也需要提供可操作信息。只发一句“流程失败”会迫使接管者重新排查；更有用的是任务编号、失败步骤、已完成部分和待确认事项。

日志应有请求关联标识，能把一次任务的多次尝试串起来。但不要为了排障无差别保存完整敏感输入、密钥或所有返回内容。

六、检查五：上线验收有没有覆盖失败路径

至少准备一组能够区分不同错误的测试输入：

测试场景	预期行为
同一来源请求重复触发	识别已有任务，不重复创建成果
模型返回缺字段结果	校验失败，不进入正式写入
目标接口暂时不可用	有限重试，保留恢复状态
权限不足	明确报错，不反复重试
写入后响应丢失	先核对状态，再决定是否重试
业务字段被拒绝	显示具体失败，保留已生成草稿
任务取消	后续步骤按取消规则停止

测试时用隔离数据或测试环境，避免故意制造真实客户通知、重复订单等副作用。

统计也应区分节点成功率和任务交付率。一个任务经过多次尝试最终交付一份成果，不能按多个成功节点计算成多次业务完成。还应记录人工接管、重复结果和恢复耗时，判断自动化是否减少了实际工作。

七、把构建记录变成维护材料

原文强调记录实践过程。企业内部更有用的记录，通常是“为什么如此设计，以及变更后如何验证”。

每个可共享工作流可保留一份简短说明：输入范围、输出位置、接口依赖、凭据负责人、异常状态、恢复方式和最近测试版本。截图可以辅助说明，但不能替代这些可执行信息。

新增需求时，也先判断它是否属于同一任务。如果一个小草稿流程逐渐被要求承担审批、发送和正式记录修改，就需要重新检查动作权限与交付标准，而不是不断堆节点。

这套检查参考 Runwise 整理的AI自动化实践中的小步验证与失败兜底经验。本文将经验转为输入、接口、重试、检查点和故障验收五个工程环节，帮助团队把一次演示转成能够维护和接续的工作流。