你的 agent 是无状态的。这就是它们会死的原因。

在你的笔记本上，agent 一口气从头跑到尾，你从来看不到问题。它思考、调用几个工具、跑完、结束。看起来很扎实。

生产环境是另一种生物。在那里，agent 是一个漫长的多步骤过程，跑在会重新部署、会杀掉占用内存过多的容器、会让连接超时的基础设施上——而且这些是家常便饭，是生活的事实。典型的 agent 把它所有的进度都放在同一个地方：内存。所以进程一眨眼，五十步昂贵的工作就灰飞烟灭，agent 从零开始重来。在一个要跑好几个小时的工作流上这么干，它可能根本就跑不完。

reckoning：是运行时的锅，不是模型的锅

如今这种顿悟有了名字。VentureBeat 把它叫做 「agentic reckoning」， 论点很精确：企业正在发现，失败点不是模型的推理能力，而是运行时。 那些用「Python scripts、LangChain 链、临时拼凑的编排」黏起来的 agent 撑不过生产环境，不是因为它们不够聪明，而是因为它们是 无状态（stateless） 的——它们对自己已经做过的事情没有任何持久的记忆。一篇关于运营现实的文章说得很直白：容器重启会抹掉上下文，而对于长时间运行的 agent（超过四小时），没有状态持久化的系统因为一次超时或一次基础设施抖动就会承担 高出 90% 的整体任务失败风险。

这正是每一场「模型够不够聪明」的争论里被漏掉的部分。你的 agent 不是因为不会推理才死的。它是因为它是一个假装成系统的脚本，跑在一个根本不在乎它有多聪明的基础设施上，所以才死的。

而且现在它还是一场烧钱的火

无状态过去只让你损失时间。在 2026 年，它还要外加一份 token 账单。当一个 100 步的 agent 在第 47 步崩溃、然后从第 1 步重启时，你损失的不只是时间——你还得为第 1 步到第 47 步已经烧掉的所有 token 再付一遍钱，然后把它们再烧一遍。一个无状态的长时间运行 agent，是一个可靠性问题，也是一个成本控制问题，穿着同一件外套。工作中最昂贵的那部分，恰恰是你不断扔掉、又不断重做的那部分。

解法已经四十年了（又一次）

解药不是更聪明的模型，也不是更巧妙的 prompt。它是持久化执行（durable execution），跟几十年来跑银行批处理作业和订单流水线的，是同一个思路：每完成一步就把它持久化下来，进程死了就从你停下的地方继续，而不是从头开始。

Temporal，这方面最知名的引擎，把这个模型描述得很干净：它把工作流的每一步都记录成一份不可变的事件历史，所以 如果进程在 100 步中的第 47 步死掉，它会重放日志并在第 48 步恢复——而不是第 1 步。 agent 获得了一份关于自己进度的记忆，这份记忆能熬过崩溃、重启和重新部署。这并不新鲜；这就是检查点、saga 和幂等性——任何严肃的长时间运行作业的管道工程。正如一位工程师所说，agent 工作流不过是在 重新发现持久化执行。 市场也认同它是承重墙：Temporal 在 2026 年初以 50 亿美元（$5B）估值完成了 3 亿美元（$300M）的融资， 而 LangGraph 和 Vercel Workflows 一直在抢着加上同样的保证。

诚实的那个坑

持久化执行是必要的，但不是魔法，而且这里有一个微妙之处，你得尊重它，否则它会反咬你。重放的工作原理，是重新跑你的工作流，并复用它已经做完的每一步的日志（journal）结果。但一次 LLM 调用是非确定性的——跑两次会得到两个不同的答案。所以你不能就这么让重放去重跑它。你必须把每一次模型调用（以及每一次有副作用的工具调用）包装成一个被记录下来的 「activity」，它的结果在第一次运行时被记入日志（journaled），在重放时永远不会被重新执行。 把这个边界搞错，你的「恢复」就会悄悄地把工作做两遍——并向你收两遍钱。这是实打实的工程，不是一个你撒上去就完事的库。

重点

生产环境里的 agent 是一个长时间运行的分布式进程。我 以前论证过，一个多 agent 系统 就是 一个分布式系统，也会像分布式系统那样失败；这是同一个真相，往下一层。把 agent 当成它必须成为的那种持久、可恢复的进程来对待——检查点化的状态、幂等的步骤、你真正测试过的恢复——否则就接受每一次容器重启都会把它打回零的现实。

你的 agent 不是因为不够聪明才失败的。它失败，是因为它对自己已经做过的事情没有记忆，而它所栖身的基础设施会不断地从它脚下抽走地毯。给它持久的状态，否则就看着它死在第 47 步——一遍又一遍，每次都付全价。