Workflow 编排复杂任务优劣？

这道题其实问的是，在[[Agent]]系统里，工具的调用逻辑到底应该写成固定的流程图，还是让模型自己实时决定怎么调。说白了就是定式与变式的取舍。我的看法是，工作流适合做骨架，但不能替代自主决策，真正落地往往是两者混着来。

先说工作流的优势。有些场景流程是固定的，比如电商的退货退款，先查订单状态、再校验库存、然后触发退款。这种每一步都有强依赖，走错了用户就投诉。用工作流画成DAG图，执行起来稳定、可审计，而且省token，因为不需要每次让大模型想下一步该干嘛。再比如金融合规里的审批流，要求每一步都可复现，工作流天然满足。

但工作流有硬伤。一旦条件分支多了，比如超过三层if-else，那个图会爆炸，维护成本极高。更麻烦的是异常处理，工具返回格式变了、超时了、权限改了，都得硬编码兜底，大模型那里可能一句话就自适应了，工作流就得改代码。还有一个问题，新工具接入要人工重绘流程，做不到即插即用，灵活性很差。

反过来，如果完全依赖[[ReAct]]循环让LLM自主调用工具，好处是灵活，但坏处也明显：token消耗大、不可控、容易陷入死循环。比如让它查三个条件再决策，一旦上下文长了，它可能忘记前面结果或者自己编一个。所以纯自主在复杂任务里其实很脆弱。

落地的时候我倾向分层设计。顶层是Agent做决策，理解用户意图，选择策略；中间层是工作流引擎，执行那些确定的子流程，比如查询、校验、汇总这种SOP；底层是工具注册中心，标准化工具描述。举个例子，用户说“帮我查一下这笔订单能不能退款”，Agent先理解意图，然后触发一个预置的工作流：先调订单接口查状态，再调库存接口看商品是否在售，最后调风控规则判断是否允许退款。如果中间任何一步异常，比如订单接口超时，工作流就报错退回给Agent，让它自主处理，比如重试或者告知用户。这样既保证了常见路径的效率，又保留了异常时的弹性。

这里有个坑：分层的前提是工具接口和流程边界要清晰。如果工具描述不规范，或者子流程的输入输出定义模糊，工作流根本跑不起来。常见失败场景是，工作流里某一步返回了意外格式，但兜底逻辑没写好，整个流程卡死。上线我会特别关注异常处理覆盖率，每个节点都要有超时、重试、降级策略。

另外，如果任务本身有不确定性，比如“分析这季度的销售趋势并给出建议”，这种没法预定义流程，我就会完全走Agent自主推理，但会给它一个[[Toolformer]]风格的描述，让工具调用和推理交织。这里其实有个延伸点：工作流和自主推理的切换阈值怎么定，比如到底什么程度的确定性才值得固化流程？这个跟业务复杂度和容错率有关，是个挺有意思的设计问题。

所以我会把工作流看成Agent的骨架，自主决策看成肌肉和神经。没有骨架，肌肉撑不住；没有肌肉，骨架动不了。具体选哪个，取决于你面对的是已知已知、已知未知还是未知未知。