工作流引擎何时优于LLM智能体：确定性编排的决策框架

Gartner预测，到2027年底，超过40%的智能体AI项目将被取消——主要原因是成本不断攀升、业务价值不明确以及风险管控不足。行业调查显示，自主AI智能体的生产成功率介于5%至11%之间。这些数字揭示了一个重要事实：在团队交给智能体处理的大量任务中，确定性工作流引擎本可以更快、更便宜、更可靠地完成工作。

这不是反AI的论点，而是架构层面的思考。问题不在于LLM是否有能力——而在于自主的开放式推理是否是你所构建任务的正确执行模型。对于相当大一类结构化业务流程而言，答案是否定的。

自主化默认选项正在让团队付出代价

2023年至2024年间，当LLM智能体变得触手可及时，一件可以理解的事情发生了：团队开始将其视为解决所有自动化问题的万能方案。需要处理客户退款请求？用智能体。需要编排文档审批工作流？用智能体。需要按计划重新索引数据管道？还是用智能体。

这种直觉并非没有道理：智能体能够处理边缘情况，适应意外输入，并在模糊情境中进行推理。但这种灵活性带来的成本结构和可靠性特征，使其对大多数结构化流程而言并不合适。

一项针对多智能体LLM系统的研究分析了超过1600条生产追踪记录，发现失败率从41%到86.7%不等。失败原因可分为三大类：

• 系统设计失败（41.8%）： 任务误解、角色定义模糊、缺少终止条件
• 智能体间不对齐（37%）： 智能体相互矛盾、丢失共享上下文、追求不同目标
• 任务验证失败（21.3%）： 校验机制薄弱，导致错误的中间输出级联成整体任务失败

这些并非边缘情况，而是自主系统应用于结构化工作时的主要失败模式。成本还会叠加：token消耗倍增、上下文膨胀、因幻觉引发的重试循环，以及每次运行产生不同输出的监控系统所带来的工程开销。

工作流引擎真正提供了什么

Temporal、AWS Step Functions和Apache Airflow解决的是与LLM智能体截然不同的问题，而且解决得非常好。

Temporal 专为持久、长时运行的执行场景而构建，工作流必须能在进程崩溃、数据异常和网络故障中存活。其事件历史机制允许精确回放执行状态——如果某个工作节点在工作流中途崩溃，Temporal会重放历史记录以重建状态，而无需重新执行已完成的步骤。Netflix通过Temporal运行整个CI/CD流水线，Coinbase用它处理加密货币交易。其运营保证是：即使基础设施在周围故障，你的工作流也能正确完成。

AWS Step Functions 为无服务器工作负载提供托管状态机编排。它开箱即用地处理错误路由、重试和分支，与AWS服务目录原生集成，并提供完整的执行历史记录以供审计。对于已在AWS上的团队，它消除了整类原本需要自行构建的可靠性基础设施。

Apache Airflow 针对计划性、有限时长的数据管道进行了优化。其DAG抽象与数据转换之间的依赖关系天然契合。Airflow的优势在于具有明确起止状态的批处理工作——夜间数仓刷新、每周模型重训练作业、每日报告生成。

这三者共享一个LLM智能体从根本上无法提供的特性：相同的输入每次都产生相同的输出，并留有完整的审计追踪。

对于金融、医疗、保险、法律等受监管行业，这种确定性不是锦上添花，而是合规要求。你无法用"智能体决定这样做"来通过监管审计。

决策框架

思考这个问题最清晰的方式是通过两个问题：

1. 所有执行路径是否在设计时就可以枚举？

如果你能画出流程应如何运作的完整流程图——包括所有异常分支——那么你面对的就是一个工作流问题。某些分支很复杂这一事实并不改变这个判断。复杂的确定性流程正是Step Functions和Temporal的设计用途。

如果执行路径真的无法在运行前确定，因为它依赖于对非结构化输入的开放式推理，那你面对的才是智能体问题。

2. 业务是否需要可重现性和可审计性？

如果合规官员需要指向某次特定执行，并解释做出了什么决定、何时做出、为何这样做——你就需要确定性编排。以temperature 0运行的LLM智能体，由于浮点非确定性和批处理效应，仍然是概率性的。"模型这样说"对于金融交易而言不是可接受的审计追踪。

实际应用中，这给出了：

使用场景	正确工具
具有定义阶段的文档审批工作流	Temporal或Step Functions
具有依赖排序的定时ETL管道	Airflow
失败时需补偿的支付处理	Temporal
具有固定路由规则的客户支持分流	工作流
从非结构化合同中提取结构化数据	LLM + 结构化输出
回答开放式研究问题	智能体
基于复杂上下文撰写并发送个性化邮件	智能体
编排包含人工审批门的多步骤背景调查	Temporal

中间情况——需要一些LLM推理但也需要可靠执行——正是混合模式获胜的地方。

混合的最佳点

经过最充分生产验证的团队并不是在工作流和智能体之间二选一，而是将确定性编排作为骨架，在特定的、有边界的决策点上使用LLM作为推理器官。

这种模式如下所示：一个Temporal工作流驱动整体流程。工作流中的各个活动在真正需要自然语言推理的任务上进行LLM调用——解析模糊输入、生成响应、分类意图。工作流代码本身是确定性的且可崩溃恢复的。LLM调用是非确定性的，但有边界：它们发生在定义了重试、超时和输出契约的活动内部。

这与"调用智能体的工作流"有本质区别。在后者的框架中，智能体仍然掌控执行路径，可能在中间步骤中偏离、循环或产生幻觉。在混合模型中，工作流掌控路径，LLM在特定节点提供有边界的判断。

Temporal的事件历史使这一点特别强大：当崩溃恢复的工作流重放时，它不会重新调用LLM——而是重放原始调用的记录结果。非确定性推理只发生一次；编排层记住了它。

智能体胜出的场景——以及为何了解这一点很重要

精确判断工作流引擎何时优于智能体，同样需要精确判断何时不然。

智能体在以下情况真正优于工作流引擎：

• 执行路径取决于中间结果的内容，且这种依赖无法预先指定
• 异常类型在设计时无法枚举
• 任务需要跨非结构化来源综合信息
• 价值来自于任何固定流程图都无法捕捉的自适应行为

一个研究助手需要根据早期查询中发现的内容来决定查询哪些来源——这是智能体问题。一个多步骤客户引导流程，其中步骤已知且异常已定义——这是Temporal问题。

尽早做出正确分类可以节省数月的调试时间。在生产中以41-86%失败率运行的多智能体系统，往往是用智能体解决工作流问题：任务有已知结构和可枚举异常，却被构建成自主系统，因为这感觉更复杂。

实际迁移注意事项

如果你有一个处理结构化流程的LLM智能体，而它表现不佳——幻觉步骤、跨重试丢失状态或成本超预期——那么正确的问题是：该任务是否具有可提取的隐藏工作流结构。

寻找以下信号：

• 智能体80%以上的时间遵循相同路径。 该路径应成为工作流骨架，LLM推理仅用于变化的决策点。
• 失败集中在特定转换处。 这些通常是智能体需要跨步骤维护状态的地方——而编排原生处理这一问题。
• 任务有人工审批或等待状态。 智能体通常处理这些较差。Temporal有显式原语用于暂停工作流等待外部信号。
• 成本随业务量线性扩展。 智能体因上下文增长和重试而成倍消耗token。工作流每次执行的成本可预测。

迁移不需要放弃LLM，而是识别LLM擅长什么——推理——并将其与编排擅长什么——执行保证——分离开来。

按技术栈的起步方案

对于正在评估选项的团队：

如果你是AWS原生并需要无服务器集成： Step Functions是阻力最小的路径。它处理错误路由，直接与Lambda、SQS和DynamoDB集成，并提供完整的执行历史用于审计。

如果你在管理具有明确依赖和计划的数据管道： Airflow的DAG模型直接映射到你的问题。工具生态系统已成熟，运营模式有充分文档。

如果你有长时运行的事务性工作流、人工审批门或多智能体编排需求： Temporal是生产级选项。其编程模型——跨故障持久化状态的普通代码——比状态机配置更易于推理。Temporal Cloud 99.99%的SLA消除了运营负担。

如果你在上述任何情况中需要一些LLM推理： 将LLM调用放在有边界的活动或任务内。给它一个定义好的输入契约、一个定义好的输出模式和一个重试策略。让编排器掌控执行路径。

40%并非不可避免

Gartner 40%的取消预测描述的不是技术失败，而是模式匹配失败：团队将自主智能体应用于具有完全合适的确定性解决方案的任务，然后太晚才发现成本和可靠性问题。

纠正之道不是对LLM持怀疑态度，而是在每个自动化项目开始时提出更尖锐的问题：这个任务是否需要无法预先指定的开放式推理，还是它具有我选择不去利用的结构？

如果它有结构，就去利用它。Temporal、Step Functions和Airflow的存在，正是因为结构化执行是一个已解决的问题。LLM智能体之所以强大，恰恰在于它超越了这一范围——这意味着在结构用尽的地方使用它们，而非作为结构化执行的替代品。