Playbooks:当单一工作流程不够用时

一个 recipe 处理一项任务。一个 workflow 将多个任务串连起来。但有些自动化作业比单一工作流程更庞大——它们需要运行数分钟甚至数小时、协调多个平行工作流,并需要优雅地从故障中恢复。

Playbooks 是 JieGou 对这类需求的解决方案。它们以非同步背景代理的方式执行工作流程,内建检查点、故障恢复和并发控制机制。

Playbooks 的独特之处

标准工作流程执行采用同步方式运行。客户端会等待结果返回。这对于在几秒到几分钟内完成的工作流程很适合。但对于一个包含 30 个步骤、需要处理一批文件、从三个外部来源丰富数据、等待审核,最后生成报告的自动化作业来说——同步执行会遇到实际限制。

Playbook 执行采用非同步方式。您启动 playbook 后会立即获得一个执行 ID。执行会在背景持续进行。您可以随时查看进度,系统会在完成时通知您。

关键的架构差异在于检查点机制。每个步骤成功完成后,playbook 会保存其状态——包括所有步骤输出、执行图中的当前位置,以及任何回圈或分支的上下文。

如果 playbook 在执行过程中崩溃——伺服器重启、暂时性基础设施故障、外部服务超时——它不会从头开始重新执行。它会从最后一个检查点恢复,从中断的地方继续执行。已完成的步骤不会被重新执行。

这对长时间运行的自动化作业很重要,因为重新执行已完成的步骤会浪费时间和金钱(LLM 呼叫并非免费),还可能造成副作用(您不会想重复发送同一封电子邮件)。

Playbooks 能安全地处理平行分支。当 playbook 执行到平行步骤时,每个分支会独立执行,并有适当的并发管理。资源锁定机制可防止冲突操作,playbook 会追踪哪些分支已完成,确保只有在所有分支都完成后,平行步骤才会结束。

当 playbook 在背景运行时,UI 会串流即时进度更新。您可以看到:

这与同步工作流程使用的进度视图相同,但它是透过轮询方式非同步更新,而非长连线。

当 playbook 步骤失败时,系统会套用标准重试策略(指数退避、可设定的最大尝试次数)。如果重试次数用尽且步骤永久失败,playbook 会以错误状态暂停。

从暂停状态,您有三个选项:

失败后能够恢复执行的能力——而非从头重新开始——正是让 playbooks 能实际应用于复杂多步骤自动化作业的关键。

使用标准工作流程的时机:

使用 playbooks 的时机:

Playbook 执行支援与工作流程执行相同的分享模式——私密、部门、帐户或群组可见性。团队成员可以根据其存取权限查看进度、检查步骤输出并审查已完成的执行记录。

Playbook 分析显示执行频率、成功率、平均执行时间和每次执行的成本。这些数据可帮助您识别哪些 playbooks 最有价值,以及哪些需要优化。