传统的自动化不是成功就是失败。Zapier 的 zap 将资料从 A 移动到 B——如果 API 呼叫失败，它会重试。每次的输出都相同。
AI 工作流程则不同。模型可能在负载下逾时。速率限制可能会节流你的请求。输出可能有效但未达标。而且因为 AI 工作流程通常有多个步骤,第 3 步的失败不应该让第 1 步和第 2 步的成功结果付诸流水。
针对这些现实情况进行设计,就是你的团队信任的工作流程与他们在第一次不好的体验后就放弃的工作流程之间的差别。
带退避的自动重试
JieGou 会自动以指数退避重试失败的 recipe 步骤。当步骤因暂时性错误而失败时——速率限制 (429)、伺服器错误 (502, 503) 或逾时——系统会等待并重试,以指数方式退避 (2秒、4秒、8秒,最多 30秒),并加入随机抖动以避免惊群问题。
你可以为每个步骤设定最大重试次数。对于大多数 recipe,2-3 次重试就能处理暂时性错误,而不会显著延迟工作流程。对于速率限制常见的高流量工作流程,你可能会设定更高的重试次数。
永久性错误——无效输入、身份验证失败、模型拒绝——会完全跳过重试。重试一个每次都会以相同方式失败的请求毫无意义。
错误分类很重要
并非所有失败都是平等的。JieGou 将错误分类,以便工作流程能适当回应:
- 暂时性错误(可重试):速率限制、伺服器过载、网路逾时。这些会透过重试自行解决。
- 永久性错误(不可重试):错误输入、身份验证失败、内容政策违规。这些需要人工介入或输入变更。
- 部分成功:AI 回传了输出,但未完全符合预期的 schema。工作流程可以使用现有内容继续,或标记问题供审查。
这种分类是自动的。你不需要撰写错误处理逻辑——执行器知道哪些 HTTP 状态码是暂时性的,哪些是永久性的。
核准关卡作为安全网
核准步骤不仅用于业务流程签核。它们也是可靠性检查点。
在任何输出品质对下游步骤很重要的步骤之后放置核准关卡。例如:
- 研究潜在客户(recipe 步骤)
- 审查研究品质(核准关卡)
- 根据研究草拟外展内容(recipe 步骤)
如果研究步骤回传的结果很少——也许公司规模小,公开资讯有限——核准关卡让人类决定是否使用现有资讯继续,或在草拟外展内容前提供额外背景。
如果没有关卡,外展步骤会根据不完整的研究产生电子邮件,产生通用讯息,违背了自动化的目的。
用条件步骤验证输出
使用条件步骤在继续之前检查输出品质:
- 提取发票资料(recipe 步骤)
- 条件:如果 total_amount 存在且 line_items 不为空(条件步骤)
- 则:继续差异检查
- 否则:标记为需人工处理
这能捕捉 AI 未能提取关键栏位的情况——也许发票格式不寻常或文字扫描品质不佳。工作流程不会将不完整的资料传递到下一步,而是将其路由给人类处理。
失败时的 Webhook 通知
工作流程可以在完成时发送 webhook 通知——无论是成功还是有错误。设定输出 webhook 以在工作流程失败时通知你的团队:
- 当排程工作流程遇到错误时发送到 Slack 频道
- 对于需要立即关注的关键工作流程发送到 PagerDuty
- 更新状态仪表板显示工作流程健康状态
Webhook 酬载包含执行 ID、状态、哪个步骤失败以及错误详情。你的团队会获得可操作的资讯,而不只是「出问题了」。
平行执行和部分失败
平行步骤会同时执行多个分支。如果一个分支失败,其他分支会继续。这是设计如此——一个独立分支的失败不应该阻挡不相关的工作。
平行执行完成后,你可以检查哪些分支成功,哪些失败。平行区块后的条件步骤可以根据所有分支是否完成或有些失败来路由工作流程。
为第 95 百分位数设计
大多数 AI 呼叫在第一次尝试时就会成功。大多数输出符合预期的 schema。大多数工作流程执行没有问题。但当你为依赖结果的团队每天执行工作流程时,「大多数」是不够的。
为那 5% 的情况设计你的工作流程:
- 为每个 recipe 步骤新增重试。失败时额外几次 API 呼叫的成本,与工作流程执行失败的成本相比微不足道。
- 在高风险输出前新增核准关卡。如果工作流程产生的内容会发送给客户或高阶主管,应该由人类验证。
- 在提取步骤后新增条件检查。在将资料往前传递之前,验证 AI 实际上提取了你需要的资料。
- 为排程和触发的工作流程设定 webhook 通知。如果没有人在看 UI,当出问题时你需要警报。
目标是能优雅降级的工作流程——将问题浮现给人类,而不是默默产生错误输出。