Agent 工具调用用 Workflow 吗？

这道题其实问的是，在[[Agent]]系统里，工具调用到底该不该用工作流来管。我的看法是，这不是一个二选一的问题，而是一个分层设计的问题。简单说，确定性任务用Workflow，复杂开放性任务用动态Agent，生产环境往往是混合架构，Workflow兜底，LLM动态规划。

先说说Workflow适合什么场景。说白了，就是那些流程固定、失败成本高的任务。比如金融审批、医疗诊断，还有企业里的售后工单处理。举个例子，一个售后工单流程：用户提交、客服初判、技术分派、维修反馈、用户确认。每一步都很确定，分支也有限。用Workflow的好处是，每个节点都透明可控，异常处理能写死，Token消耗也稳定。而且审计起来很方便，每一步都有日志。反过来，要是让LLM自由发挥，它可能把工单派错部门，或者编个不存在的处理步骤，那风险就大了。

再说说动态Agent的优势。当任务边界模糊、用户意图可能漂移的时候，Workflow就僵了。比如用户问“帮我查下天气，然后推荐穿搭，再生成一张图”，这种工具链组合人类可能没预设过，但LLM能自己串起来。而且业务规则变化快的时候，改Prompt比改代码快得多。所以开放域问答、创意辅助、探索性数据分析这些场景，动态Agent更合适。

但这里有个坑。很多人一上来就想用Agent解决所有问题，结果发现工具调用链一长，LLM规划就崩了。我的经验是，如果工具调用链超过5步，或者失败成本极高，优先用Workflow兜底。比如医疗场景，诊断路径错了可能出人命，这时候Workflow为主，只在分支判断节点内嵌LLM决策。

那实际落地怎么平衡？我倾向渐进式引入。先用LLM跑一批数据，生成执行轨迹，把高频路径沉淀成Workflow模板。然后混合架构：Workflow管主干，比如售后工单的流程框架，但在“是否升级投诉”这种条件分支上，交给LLM判断。最后一定要有逃生舱设计，Workflow执行失败时，降级到动态Agent兜底。

还有一个点值得注意，就是Workflow和Agent的切换时机。我会在Workflow里设一个“不确定性阈值”，比如LLM对分支判断的置信度低于0.6，就自动跳出固定流程，交给Agent动态规划。这其实是个[[ReAct]]循环的变体。

所以我的结论是：别把Workflow和Agent对立起来，它们是一个谱系的两端。我更倾向以Workflow为骨架，在关键节点注入LLM的灵活性，同时保留逃生舱。这样既有可控性，又不会太死板。