# 你的 agent 是无状态的。这就是它们会死的原因。 你的 agent 在自己的笔记本上从头跑到尾，所以你从没见过问题。而生产环境是一个漫长的多步骤过程，跑在会重启、会超时、会中途崩溃的基础设施上——偏偏你的 agent 把所有进度都存在内存里。2026 年的「agentic reckoning」，就是人们终于发现：失败的不是模型，而是运行时。解法既老又无聊：持久化执行（durable execution）。这是诚实版本。 - **Author:** Fedor Chishchin - **Published:** 2026-06-04 - **Tags:** architecture, agents, methodology - **Source:** https://fedorthinks.com/zh/blog/stateless-agents-die --- 在你的笔记本上，agent 一口气从头跑到尾，你从来看不到问题。它思考、调用几个工具、跑完、结束。看起来很扎实。 生产环境是另一种生物。在那里，agent 是一个漫长的多步骤过程，跑在会重新部署、会杀掉占用内存过多的容器、会让连接超时的基础设施上——而且这些是家常便饭，是生活的事实。典型的 agent 把它所有的进度都放在同一个地方：内存。所以进程一眨眼，五十步昂贵的工作就灰飞烟灭，agent 从零开始重来。在一个要跑好几个小时的工作流上这么干，它可能根本就跑不完。 ## reckoning：是运行时的锅，不是模型的锅 如今这种顿悟有了名字。VentureBeat 把它叫做 [「agentic reckoning」](https://venturebeat.com/resources/the-agentic-reckoning-enterprise-ai-organizations-have-a-runtime-problem-not-a-model-problem)， 论点很精确：企业正在发现，**失败点不是模型的推理能力，而是运行时。** 那些用「Python scripts、LangChain 链、临时拼凑的编排」黏起来的 agent 撑不过生产环境，不是因为它们不够聪明，而是因为它们是 _无状态（stateless）_ 的——它们对自己已经做过的事情没有任何持久的记忆。一篇关于运营现实的文章说得很直白：容器重启会抹掉上下文，而对于长时间运行的 agent（超过四小时），没有状态持久化的系统因为一次超时或一次基础设施抖动就会承担 [**高出 90% 的整体任务失败风险**](https://www.indium.tech/blog/7-state-persistence-strategies-ai-agents-2026/)。 这正是每一场「模型够不够聪明」的争论里被漏掉的部分。你的 agent 不是因为不会推理才死的。它是因为它是一个假装成系统的脚本，跑在一个根本不在乎它有多聪明的基础设施上，所以才死的。 ## 而且现在它还是一场烧钱的火 无状态过去只让你损失时间。在 2026 年，它还要外加一份 [token 账单](/blog/the-token-bill-came-due)。当一个 100 步的 agent 在第 47 步崩溃、然后从第 1 步重启时，你损失的不只是时间——你还得为第 1 步到第 47 步已经烧掉的所有 token 再付一遍钱，然后把它们再烧一遍。一个无状态的长时间运行 agent，是一个可靠性问题，也是一个成本控制问题，穿着同一件外套。工作中最昂贵的那部分，恰恰是你不断扔掉、又不断重做的那部分。 ## 解法已经四十年了（又一次） 解药不是更聪明的模型，也不是更巧妙的 prompt。它是**持久化执行（durable execution）**，跟几十年来跑银行批处理作业和订单流水线的，是同一个思路：每完成一步就把它持久化下来，进程死了就从你停下的地方继续，而不是从头开始。 [Temporal](https://temporal.io/)，这方面最知名的引擎，把这个模型描述得很干净：它把工作流的每一步都记录成一份不可变的事件历史，所以 [如果进程在 100 步中的第 47 步死掉，它会重放日志并在第 48 步恢复——而不是第 1 步](https://effloow.com/articles/temporal-ai-agents-durable-execution-guide-2026)。 agent 获得了一份关于自己进度的记忆，这份记忆能熬过崩溃、重启和重新部署。这并不新鲜；这就是检查点、saga 和幂等性——任何严肃的长时间运行作业的管道工程。正如一位工程师所说，agent 工作流不过是在 [重新发现持久化执行](https://nittikkin.medium.com/agent-workflows-are-rediscovering-durable-execution-be110661ed8c)。 市场也认同它是承重墙：Temporal 在 [2026 年初以 50 亿美元（$5B）估值完成了 3 亿美元（$300M）的融资](https://thenewstack.io/temporal-replay-2026-news/)， 而 LangGraph 和 Vercel Workflows 一直在抢着加上同样的保证。 ## 诚实的那个坑 持久化执行是必要的，但不是魔法，而且这里有一个微妙之处，你得尊重它，否则它会反咬你。重放的工作原理，是重新跑你的工作流，并复用它已经做完的每一步的日志（journal）结果。但**一次 LLM 调用是非确定性的**——跑两次会得到两个不同的答案。所以你不能就这么让重放去重跑它。你必须把每一次模型调用（以及每一次有副作用的工具调用）包装成一个被记录下来的 [「activity」，它的结果在第一次运行时被记入日志（journaled），在重放时永远不会被重新执行](https://nittikkin.medium.com/agent-workflows-are-rediscovering-durable-execution-be110661ed8c)。 把这个边界搞错，你的「恢复」就会悄悄地把工作做两遍——并向你收两遍钱。这是实打实的工程，不是一个你撒上去就完事的库。 ## 重点 生产环境里的 agent 是一个长时间运行的分布式进程。我 [以前论证过](/blog/orchestration-is-the-architecture)，一个多 agent 系统 _就是_ 一个分布式系统，也会像分布式系统那样失败；这是同一个真相，往下一层。把 agent 当成它必须成为的那种持久、可恢复的进程来对待——检查点化的状态、幂等的步骤、你真正测试过的恢复——否则就接受每一次容器重启都会把它打回零的现实。 你的 agent 不是因为不够聪明才失败的。它失败，是因为它对自己已经做过的事情没有记忆，而它所栖身的基础设施会不断地从它脚下抽走地毯。给它持久的状态，否则就看着它死在第 47 步——一遍又一遍，每次都付全价。