AI Agent 状态解析：持久化记忆与任务进度

关键要点

• AI 智能体状态是记忆、任务进度和上下文的持久记录，使智能体能够经受重启、重试和多步骤工作。
• 截至 2026 年，57% 的组织已将智能体投入生产运行，而输出质量是进一步扩展它们的首要阻碍，超过成本。
• 记忆只是智能体状态的一部分。当出现故障时，任务检查点、工具输出和事务历史同样重要。
• 生产级智能体需要数据库为任何应用提供的相同保证：原子写入、并发进程之间的隔离，以及之后可供审计的记录。

一个在每次调用之间忘记一切的智能体无法完成多步骤任务，无法从工作流中途崩溃中恢复，也无法向你展示它实际做了什么。这就是无状态的现实代价，也是 AI 智能体状态旨在解决的问题。

AI 智能体状态是智能体跨步骤和跨会话持续工作所需的记忆、任务进度、工具输出、文件和支持数据的持久记录。基础的 LLM 调用本身不具备这些。除非模型之外的某个东西记录下发生了什么，并在下次调用时把它交还，否则每个提示都从零开始。

LangChain 的 2026 年智能体工程状况报告指出，57% 的组织已将智能体投入生产，高于前一年的 51%。输出质量仍然是扩展这一采用的首要障碍，32% 的受访者提及这一点，超过成本和延迟。把状态做对是这一质量问题的很大一部分：在任务中途丢失上下文或无法干净地从故障中恢复的智能体，不是任何人放心让其无人监督运行的智能体。

本文将智能体记忆与智能体状态区分开来，逐一介绍各团队正在权衡的架构模式，并涵盖 TiDB 作为底层数据层在何处适用。

什么是 AI 智能体状态？

AI 智能体状态不同于单个提示、聊天记录或模型的上下文窗口。上下文窗口是临时的，一旦会话结束或 token 预算耗尽就会消失。状态是跨越该边界之后仍然存在的东西：智能体需要从它离开的确切位置继续所需的特定事实、决策和进度，即使在重启、崩溃或会话之间相隔一周之后也是如此。

把它想象成对话与案卷之间的区别。对话是说了什么。案卷是对话结束后仍然成立的东西：哪些步骤已完成、智能体在等待什么，以及它已经尝试过什么。

无状态提示与有状态智能体之间的区别

无状态调用接收输入并返回输出，不记得之前发生过什么。同一个问题问两次，两次都从头开始。有状态智能体会在调用之间持久保存它学到和做过的东西，因此工作流中的第十步可以引用第三步发生过的某件事。

智能体状态中应包含什么

至少，智能体状态包括对话历史、任务进度、它调用过的任何工具的输出、用户偏好和身份，以及关于它所运行环境的元数据，例如某个给定步骤运行的是哪个模型版本，或当时哪些权限处于活动状态。这些部分在智能体执行循环内部如何排布，决定了架构的其余部分必须支持什么。

请参阅 AI 智能体状态层架构，以更深入地了解这些部分如何组合在一起。

为什么 AI 智能体状态在生产中很重要

一旦智能体处理的任何内容超过单次交互，缺失状态的后果就会显现。崩溃恢复、任务连续性、并发智能体和重复的 token 消耗，都可追溯到状态处理得好不好。

长时间运行的任务在缺乏持久状态时会中断

一个涉及多个系统、等待外部结果或跨越数天运行的工作流，需要某个地方来存储它中断的位置。没有它，超时或重启就意味着从头开始，而在一个耗时数小时的研究或修复任务上从头开始，既耗费时间，又要重复进行模型调用。

多智能体系统提高了风险

让多于一个智能体处理同一问题，状态就不再是可选项。两个智能体触碰同一条记录，需要一种避免相互干扰的方式，而且两者都需要一个它们可以信任的事实来源。没有隔离和对状态一致的共享视图，多智能体系统产生的不是协作，而是竞态条件。

可靠性取决于数据层

大多数在生产中运行智能体的团队会采用一个碎片化的技术栈：一个用于运营数据的数据库、一个用于检索的独立向量存储、一个用于会话状态的缓存，以及一个用于分析的数据仓库，再用胶水代码把它们拼接起来。这种碎片化通常是可靠性出问题的地方，而不是模型本身。每多一个系统，就多一个状态可能失去同步的地方，也多一个需要手动保持一致性的故障点。这是架构上的结构性问题，适用于各个供应商。

请参阅 AI 智能体 harness 状态管理，以了解更多关于这在智能体执行循环内部如何展开的内容。

完整的智能体状态栈由什么构成？

智能体状态不是单一的东西。它是若干个协同工作的层，而团队遇到的大部分摩擦，都源于把这些层当作彼此分离的系统，而不是一个相互连接的整体。

用于身份、偏好和回忆的持久记忆

这就是大多数人在说智能体记忆时所指的那一层：用户是谁、他们之前要求过什么、智能体已经对任务了解到了什么。它需要跨会话持久存在，而不仅限于单次对话。

用于长周期工作的文件和工件

生成文档、报告或中间输出的智能体需要一个持久的地方来存放它们，尤其是当工作跨越多个会话或在进行到一半时被移交给另一个智能体时。

用于正确性和恢复的数据库事务

当智能体执行一个必须正确的操作时，例如更新一条记录或完成一个多步审批，该操作需要任何应用程序事务都需要的相同保证：它要么完整完成，要么根本不发生。没有这一点，写入中途的崩溃会让数据处于无人可信的状态。

AI 智能体记忆与状态

人们把“智能体记忆”和“智能体状态”混用，但它们不是一回事。记忆是状态的一个组成部分，是比整体状态更窄的概念。

记忆帮助智能体记住

智能体记忆涵盖智能体所知道的内容：关于用户的事实、过去的交互、学到的偏好、下次被询问时应该回忆起的事情。它主要关乎知识的连续性。

状态帮助智能体继续

状态涵盖记忆所做的一切，以及记忆遗漏的内容：任务当前所处的位置、它已经调用了哪些工具以及这些工具返回了什么、计算过程中的临时变量，以及诸如某一步骤中处于活动状态的是哪个模型或权限集之类的元数据。记忆回答智能体知道什么。状态回答智能体正在做什么以及它在哪里停下。

参见 有状态智能体记忆数据库了解这一区别如何在数据库设计中体现。

哪些状态管理模式最适合 AI 智能体？

没有唯一正确的方式来构建智能体状态。团队往往会落在几种模式之一上，而每种模式都伴随着真实的权衡。

仅追加历史很简单，但会迅速膨胀

最简单的方法是按顺序记录每条消息和每个操作，然后重放日志以重建状态。它易于实现和审计，但日志会无限制增长，而且从长历史中重建当前状态会随着会话运行时间越长而变得越慢。

类型化状态改善了控制和恢复

类型化状态不重放完整历史，而是将当前值直接存储在用于任务状态、变量和输出的结构化字段中。像 LangGraph 这样的框架围绕这一模式构建，其中状态是图在每一步读取和写入的显式模式。它比原始日志需要更多前期工作，但恢复更快，也更容易验证。

显式状态机有助于治理智能体行为

状态机或图定义了在每个时间点哪些转换是有效的，因此智能体不能在不经过中间步骤的情况下从“研究中”直接跳到“已完成”。随着智能体获得通过 MCP（模型上下文协议，一种用于将模型连接到外部工具和数据源的标准接口）等协议调用工具并执行操作的能力，这一点变得更加重要。一组已定义的有效状态限制了错误决策能够传播多远。

由检索支持的长时记忆——相关历史通过相似性搜索返回，而不是留在活动状态中——非常适合跨长时间范围的回忆。它仍然需要与上述模式之一配对，以处理驱动智能体下一步行为的状态。

生产就绪智能体状态检查清单

在智能体系统投入生产之前，其状态层应能满足一小组实际要求。

• 持久性： 状态在重启、部署或崩溃后无需人工干预即可存续。
• 版本控制： 状态的变更会被跟踪，因此除了当前值之外，你还能知道什么发生了变更以及何时发生。
• 检查点： 长时间运行的任务在运行过程中的既定节点保存进度，远早于终点。
• 隔离： 并发智能体或会话不会相互覆盖状态。
• 可审计性： 每一次状态变更都可以追溯到导致它的操作。
• 延迟： 对状态的读写不会成为智能体循环中的瓶颈。
• 成本可见性： 与状态操作相关的 token 和基础设施成本会作为单独条目显示。

一个可用于检验状态层的有用模式：面向一组联网设备的异常检测系统，其中智能体将每个新案例与先前调查的热存储进行比对。当该查找找到接近匹配时，系统会将案例路由到更便宜的模型，而不是默认模型，并且只有当热存储中没有任何看起来相似的内容时才升级。该路由决策之所以有效，只是因为状态是持久且可查询的。如果没有一种快速、可靠的方式来检查“我们以前见过类似的东西吗”，每个案例默认都会得到昂贵的处理。

TiDB 如何支持持久化 AI 智能体状态

在典型技术栈中，上文涵盖的大多数状态层最终会分散在彼此分离的系统中：一个数据库用于运营数据，一个向量存储被额外接上用于检索，一个缓存用于会话状态。这些系统之间的每个边界都是状态可能失去同步的地方，也是写入中途崩溃会留下半更新内容的地方。

TiDB 则将其视为单一数据层。它是一个分布式 SQL 数据库，在同一集群中原生支持向量搜索和完整的 ACID 事务，因此运营数据、智能体记忆和向量相似性搜索都处于同一个一致性边界内，而不是由胶水代码拼接起来的三个独立边界。向量搜索在 TiDB 自管理版、TiDB Cloud Starter、TiDB Cloud Essential 和 TiDB Cloud Dedicated 上均可使用，在自管理版和 Dedicated 部署上需要 TiDB v8.4.0 或更高版本，推荐使用 v8.5.0 或更高版本。一些团队将其描述为认知基础模式：他们在 TiDB Cloud 之上构建的持久记忆基底，数据库跨会话保存结构化智能体记忆，而去重、对账和置信度衰减等保管性工作作为普通 SQL 运行，而非独立的计划任务服务。

运营数据、记忆与智能体进度的统一系统

智能体不再从一个系统读取、向另一个系统写入，而是针对 TiDB 直接在其读取运营数据的同一位置查询和更新自身状态，必要时在单个事务内完成。这是一个实用版本的差异：读取层是对现有数据的仪表盘和分析，而一些团队所称的行动层，则是智能体写回、记忆随时间累积、三步之前做出的决策仍可通过一次查询重建的层级。

并行智能体工作的分支与隔离

TiDB Cloud 分支功能目前处于测试阶段，适用于 TiDB Cloud Starter 和 TiDB Cloud Essential，它使用写时复制技术创建数据集的隔离副本，而无需复制底层数据。创建分支通常可在几分钟内完成，且不影响原集群的性能。当多个智能体，或同一智能体的多个版本，需要针对真实状态进行测试，又不触碰生产数据或彼此运行时，这一功能非常有用。

为必须正确的操作提供 ACID 事务

当智能体更新一条记录时，例如确认订单或写入检查点，该写入需要完全完成或完全不发生。TiDB 通过两阶段提交协议协调分布式事务，因此写入过程中的部分失败不会让状态层卡在真相的两个版本之间。

参见 AI 智能体的统一状态和 AI 智能体状态管理的最佳数据库，了解更多关于整合碎片化技术栈的内容。

在更坚实的基础之上构建持久智能体状态

仅靠提示链和向量检索并不能构成状态层。它们可以检索相关文本，但无法保证五分钟前写入的检查点与下一步读取的检查点是同一个，也无法在出现问题后告诉你究竟发生了哪次写入以及何时发生。

生产级智能体需要任何可靠应用在其底层所需的东西：持久存储、事务正确性，以及一个可以查询实际发生情况的系统。将状态视为数据库问题，才能让智能体从演示变为团队可以无人值守运行、并信任其自行恢复的系统。

对于在智能体系统之下构建数据层的团队，TiDB 的 持久智能体状态解决方案涵盖了本文所讨论的相同领域：持久记忆、事务性写入，以及一个随智能体工作负载扩展而非在其下碎裂的单一系统。

AI 智能体状态常见问题

用简单的话说，什么是 AI 智能体状态？

• 智能体所知和所做之事的持久记录，保存在任何单个提示之外。
• 示例：一个研究智能体保存其发现和当前步骤，以便崩溃不会抹去工作成果。

AI 智能体状态与记忆有何不同？

• 记忆涵盖智能体回忆的事实和历史。
• 状态包括记忆以及任务进度、工具输出和临时变量。
• 记忆回答智能体知道什么。状态回答它在做什么。

为什么有状态的 AI 智能体需要数据库？

• 持久性：状态必须在重启和崩溃后依然存在。
• 并发性：多个智能体接触相同数据需要隔离。
• 正确性：写入和批准等操作需要事务性保证。
• 恢复：数据库提供关于发生了什么以及何时发生的可查询记录。

智能体状态层中应存储什么？

• 对话历史和用户偏好。
• 任务检查点和剩余步骤。
• 工具输出和生成的文件。
• 与真实操作关联的事务记录。

AI 智能体状态能在重启和故障后存活吗？

• 可以，如果状态持久化在智能体运行时之外，而不是仅保存在内存中。
• 在定义的步骤设置检查点，可让工作流恢复而不是从头重新开始。
• 数据库级事务可防止写入中途崩溃导致状态只更新一半。

文章 AI 智能体状态详解 首次发表于 TiDB。