Apollo
全部栏目

智能体工作流

工作流预先规定步骤、分支和等待条件，模型在其中处理需要理解与判断的部分，系统负责维持执行秩序。

返回概念图谱 →

理解与应用

工作流是预先定义执行路径的方法：从什么状态开始，经过哪些步骤，在什么条件下进入分支，何时暂停或结束。节点内部可以使用语言模型，但下一步不必每次都由模型自由决定。对于流程相对稳定的业务，这种分工让系统更容易解释和测试。

以补交报销材料为例，流程可以是读取退回原因、整理需补材料、核对新发票、等待用户确认、提交附件。模型适合把退回说明解释给用户，程序则可以根据“发票校验是否通过”决定能否进入提交阶段。如果材料缺失，流程回到等待补充；这条分支不应该靠模型临时想起。

有用的流程图背后还需要状态。系统应知道当前报销单编号、已核验的文件版本、是否收到确认、哪次提交已经拿到回执。保存这些信息后，服务重启才能从等待确认处继续，而不是把前面的工作全部重做。并行读取多份材料时，也要约定何时合并、某一份读取失败怎么办。

工作流与自主智能体并不互斥。一个固定的“研究缺少材料原因”节点可以允许模型动态选择检索路径，外层依然控制提交和结束条件。预设流程也不能自动消除副作用风险：提交附件后网络超时，重试节点可能再次提交。此时仍需要幂等标识或读回状态，而不只是把箭头画回上一步。

关系速览
任务规划应用于 →智能体工作流

已知依赖与验收条件可以固化成工作流，不必每步重新请求模型决策。

智能体工作流应用于 →多智能体协作

工作流可以显式分配多个角色，角色数量不能替代清晰的交接契约。

失败恢复与幂等应用于 →智能体工作流

持久状态、重试预算和补偿操作让中断后的流程可检查地继续。

看一个具体过程：报销材料补交中的暂停与恢复

流程示例强调状态和分支如何衔接。用户确认只允许执行某个已确定的动作，远端回执才说明动作是否真正完成。

以下为教学示意，未连接真实业务系统。

过程示意

当前任务：为 R-204 补交更正后的发票。
已完成：读取退回原因；核对发票抬头；生成待提交附件清单。
保存状态：等待用户确认，附件版本为 invoice-v2。
用户确认后：核对待提交文件仍是 invoice-v2，再进入提交节点。
提交响应超时：转入查询提交状态的节点。

示意结果

若系统中已存在这次附件提交记录：读取回执并结束。
若确认未提交且支持安全重试：按原操作标识重新提交。
若无法判断：保留“结果待核实”，不直接另交一份。

常见误区

  • 只有步骤名称、没有持久状态的流程，在重启后可能重复执行已经完成的动作。
  • 分支如果依据模型一句模糊判断，就很难稳定复现和测试。
  • 把写操作节点设置为自动重试，不会自动获得“只执行一次”的保证。

前置与延伸

建议先读

相关概念

参考与版本

Apollo 原创讲解与教学示例。参考资料用于核对技术定义；核验日不代表资料的发布日期。