这道题其实不是问Workflow好不好,而是问什么时候该用Workflow,什么时候不该用。本质上是在考察工具编排的两种模式,预定义的确定性流程和模型驱动的动态规划,各自的适用边界,以及实际落地怎么组合。
先说Workflow的核心特点。Workflow就是把工具调用顺序、分支条件、并行关系提前固化下来,比如用DAG或者状态机描述。它的好处是执行路径可预测、可追踪,出了问题好审计、好回滚。举个例子,电商的退款流程,典型SOP:先校验订单状态,再检查退款资格,然后走审批,最后通知用户。这个流程非常固定,每一步都有明确规则,用Workflow做就很稳。而且像金融、医疗这种要合规审计的场景,每一步操作都要留痕,Workflow天然满足。
但Workflow的缺点也很明显:它处理不了未预期的中间状态。比如用户说“我订单还没收到,但退款页面显示已签收”,这种模糊需求,Workflow没法动态调整,只能硬走预设路径,要么报错,要么卡住。另外,如果业务迭代频繁,比如今天加个满减政策,明天改个审批规则,Workflow的配置会爆炸,维护成本很高。
反过来,动态规划比如[[ReAct]]模式,靠模型自己决定下一步调什么工具。它的好处是灵活,能应对探索性任务,比如开放域问答或者多跳推理。但问题也很明显:模型可能选错工具、参数填错、调用顺序搞乱,而且不可审计,出问题很难追责。
所以真正落地的时候,我倾向分层架构。上层用动态规划,让模型决定“做什么”,比如意图识别、知识检索、答案生成这些大步骤。下层用Workflow引擎,保障“怎么做”,比如每个子流程内部用Workflow固化校验规则。这样既保留了灵活性,又保证了稳定性。
这里有个坑:如果工具调用成本高,比如付费API,或者有副作用比如发邮件、下单、转账,就不能完全交给模型自由调用。我会把这类高危工具封装成受控接口,参数、权限、副作用都由工程系统兜底,模型只能选择工具,但不能绕过校验。
我举一个具体场景:智能客服处理退款。整体流程用动态调度,先识别用户意图是“退款”,然后查订单,如果订单状态正常,就进入退款子流程。这个子流程内部用Workflow固化:先校验订单是否可退,再检查库存是否恢复,然后创建退款单,最后发支付链接。每一步都有明确的规则和依赖关系,不能搞错顺序。如果让模型自己编排,它可能先发链接再校验,那就出事了。
最后提一个落地风险:Workflow和动态规划之间的接口设计很关键。如果上层动态规划生成的任务太细,Workflow引擎会变成摆设;如果太粗,又没法保证稳定性。我会用“子任务粒度”来控制:每个子任务对应一个可独立验证的原子操作,比如“校验订单状态”是一个子任务,“调用支付接口”是另一个。这样既方便Workflow执行,也方便模型理解。
所以我会把Workflow看成是确定性业务的骨架,动态规划是灵活性的血肉。两者不是二选一,而是根据场景组合使用。如果面试官有兴趣,我可以再展开讲这个接口怎么设计。