2 篇博文 含有标签「workflow-orchestration」

一个每步成功率为 95% 的智能体并不是一个 95% 可靠的智能体。将 20 个步骤串联起来，端到端的完成率就会下降到 36%。这是大多数团队在智能体上线生产环境后才发现的算数逻辑，也是为什么这么多“运行良好”的原型在真实流量涌入的瞬间就会陷入停滞。解决方法不是更好的提示词或更大的模型，而是一个乏味的分布式系统基础设施，大多数 AI 团队在第三次宕机被迫应对之前都会试图避开它。

这种基础设施就是“持久化执行”（durable execution）——这是一种让多步骤工作流在崩溃、重启和局部故障中幸存且不丢失进度的准则。这并不是什么新鲜主意。Temporal、Restate、DBOS、Inngest 和 Azure Durable Task 已经为此推销多年。2026 年的新变化是，每个严肃的智能体框架都已悄然承认持久化执行是入场券：LangGraph 现在内置了 PostgresSaver 检查点，OpenAI Agents SDK 暴露了 resume（恢复）原语，Anthropic 的 Managed Agents 运行在内部的持久化基座上。如果你的智能体架构仍然依赖 Celery 队列和乐观主义，那么你是在 2026 年解决一个整个行业在 2024 年就不再假装视而不见的问题。

本文探讨的是无状态 LLM 与必须包装它的有状态工作流引擎之间的架构接缝。接缝之处正是可靠性所在，也是大多数团队目前编写 Bug 的地方。

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

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