Agent 工具执行用 Workflow 吗?
多 Tool 编排的优缺点分析及适用场景判断
原题：在Agent系统中，多个工具（Tool）的执行是否应该组织为Workflow（工作流）形式？这种设计的优缺点是什么，在何种场景下适用？
Agent · 阿里真题
回答与解析
核心判断：不是"是否"，而是"何时"
Workflow是工具编排的一种重要模式，但和动态规划（如ReAct）是互补关系，不是替代关系。
Workflow的核心特征
- 预定义拓扑：工具调用顺序、分支条件、并行关系提前固化
- 确定性执行：给定输入，执行路径可预测、可追踪
- 显式控制流：DAG、状态机或BPMN等形式描述
优缺点分析
| 维度 | 优势 | 劣势 |
|---|---|---|
| 可靠性 | 复杂流程可审计、易回滚 | 难以处理未预期的中间状态 |
| 性能 | 可预优化（并行化、缓存） | 无法根据上下文动态跳过/替换工具 |
| 维护性 | 变更可见、版本可控 | 业务迭代频繁时，配置爆炸 |
| 用户体验 | 可展示进度、预估耗时 | 对模糊需求适应性差 |
适用场景
强推Workflow
- 审批流、工单处理等SOP明确的业务
- 需要合规审计的金融、医疗场景
- 工具调用成本高（如付费API），必须控制调用次数
避免纯Workflow
- 开放域问答、多跳推理等探索性任务
- 工具集合动态扩展（插件市场类场景）
- 用户意图高度不确定的C端对话
工程实践：分层架构
上层：动态规划（LLM决定"做什么"）
↓ 生成执行计划
下层：Workflow引擎（系统保障"怎么做"）
- 子流程内部用Workflow保证稳定
- 跨子流程用LLM动态编排
典型例子：智能客服中，"意图识别→知识检索→答案生成"用动态调度，但"退款子流程"内部用Workflow固化校验规则。
学习建议
建议系统学习该知识点
口语版讲法(约4分钟)
- 1. 题目本质是问Workflow和动态规划的取舍边界
- 2. Workflow适合SOP明确、合规要求高的场景
- 3. 动态规划适合探索性、意图不确定的场景
- 4. 工程实践上分层架构：上层动态规划，下层Workflow引擎
这道题其实不是问Workflow好不好，而是问什么时候该用Workflow，什么时候不该用。本质上是在考察工具编排的两种模式，预定义的确定性流程和模型驱动的动态规划，各自的适用边界，以及实际落地怎么组合。
先说Workflow的核心特点。Workflow就是把工具调用顺序、分支条件、并行关系提前固化下来，比如用DAG或者状态机描述。它的好处是执行路径可预测、可追踪，出了问题好审计、好回滚。举个例子，电商的退款流程，典型SOP：先校验订单状态，再检查退款资格，然后走审批，最后通知用户。这个流程非常固定，每一步都有明确规则，用Workflow做就很稳。而且像金融、医疗这种要合规审计的场景，每一步操作都要留痕，Workflow天然满足。
但Workflow的缺点也很明显：它处理不了未预期的中间状态。比如用户说“我订单还没收到，但退款页面显示已签收”，这种模糊需求，Workflow没法动态调整，只能硬走预设路径，要么报错，要么卡住。另外，如果业务迭代频繁，比如今天加个满减政策，明天改个审批规则，Workflow的配置会爆炸，维护成本很高。
反过来，动态规划比如ReAct模式，靠模型自己决定下一步调什么工具。它的好处是灵活，能应对探索性任务，比如开放域问答或者多跳推理。但问题也很明显：模型可能选错工具、参数填错、调用顺序搞乱，而且不可审计，出问题很难追责。
所以真正落地的时候，我倾向分层架构。上层用动态规划，让模型决定“做什么”，比如意图识别、知识检索、答案生成这些大步骤。下层用Workflow引擎，保障“怎么做”，比如每个子流程内部用Workflow固化校验规则。这样既保留了灵活性，又保证了稳定性。
这里有个坑：如果工具调用成本高，比如付费API，或者有副作用比如发邮件、下单、转账，就不能完全交给模型自由调用。我会把这类高危工具封装成受控接口，参数、权限、副作用都由工程系统兜底，模型只能选择工具，但不能绕过校验。
我举一个具体场景：智能客服处理退款。整体流程用动态调度，先识别用户意图是“退款”，然后查订单，如果订单状态正常，就进入退款子流程。这个子流程内部用Workflow固化：先校验订单是否可退，再检查库存是否恢复，然后创建退款单，最后发支付链接。每一步都有明确的规则和依赖关系，不能搞错顺序。如果让模型自己编排，它可能先发链接再校验，那就出事了。
最后提一个落地风险：Workflow和动态规划之间的接口设计很关键。如果上层动态规划生成的任务太细，Workflow引擎会变成摆设；如果太粗，又没法保证稳定性。我会用“子任务粒度”来控制：每个子任务对应一个可独立验证的原子操作，比如“校验订单状态”是一个子任务，“调用支付接口”是另一个。这样既方便Workflow执行，也方便模型理解。
所以我会把Workflow看成是确定性业务的骨架，动态规划是灵活性的血肉。两者不是二选一，而是根据场景组合使用。如果面试官有兴趣，我可以再展开讲这个接口怎么设计。
关键一句:Workflow和动态规划之间的接口设计，子任务粒度如何划分
面试官还可能这样问
- 问法 1 · 场景切入
假设你在做一个智能客服系统，需要处理订单查询和退款流程。用户问完“我的订单到哪了”之后，可能接着要求退款。你是打算让大模型一步步自己决定调用哪个工具，还是提前把这两个步骤串成一个固定的工作流？
- 问法 2 · 层层追问
你一般怎么让Agent调用多个工具？……如果工具之间依赖关系很强，比如必须查完库存才能发货，你怎么保证顺序？……那要是用户意图经常变呢，固定的流程会不会太死板？
- 问法 3 · 直球架构
在Agent系统中，把多个工具的执行组织成Workflow有哪些优缺点？具体什么场景下应该用Workflow，什么场景应该避免？说说你的设计思路。