状态的五种类型

一句话理解：Agent 要“记住”的东西至少分五种：对话状态、任务状态、工作记忆、长期记忆和业务状态；它们的寿命、存放位置、可信程度都不同，混在一起就会出现“记错”“记太多”或“拿旧记忆当事实”。

“给 Agent 加个记忆”是一句听起来很简单的需求。但追问下去，大家说的往往不是同一件事：

客服主管说的是“用户下次来，Agent 能想起他上次投诉过什么”；
研发说的是“服务重启后，批处理任务能从第 87 个页面继续”；
用户说的是“别每次都问我报表要按大区还是按省份”；
财务说的是“Agent 必须知道这笔订单现在是否已经退款”。

这四句话分别对应四种完全不同的状态。如果不先分类，最后很可能做出一个“什么都往里塞”的记忆库：塞满后召回不准，信息过期后还被当作事实使用。这一课先建立分类，后面四课分别展开。

五种状态一览

类型	回答的问题	寿命	典型存放位置	谁是事实来源
对话状态	我们刚才聊了什么？	一个会话	消息历史、会话存储	会话记录本身
任务状态	这件事做到哪一步了？	一个任务（可跨多个会话）	结构化任务表、检查点	任务状态存储
工作记忆	模型此刻脑子里装着什么？	一次模型调用	上下文窗口	由 Harness 每次装配
长期记忆	这个用户或项目有什么需要长期记住的？	跨会话、跨任务	记忆文件、记忆库	记忆库（需要可纠错）
业务状态	现实世界里现在是什么情况？	由业务决定	业务系统数据库	业务系统，永远以它为准

把它们放进同一张图：四种持久状态各有归属地，Harness 每一步把它们投影成工作记忆，行动结果再写回原处。

图 1 · Memory 与状态全景：四种持久状态投影成工作记忆，行动结果再写回各自的归属地

逐个理解

对话状态：会话里说过的话

用户输入、模型回复、工具调用与工具结果按顺序排成的历史。模型 API 本身通常是无状态的，每次请求都要把需要的历史带上；是由你的应用、SDK 还是平台来保存这份历史，是会话与持久化要讨论的问题。

特点：完整但冗长，越往后越难从中快速找到“当前进度”。

任务状态：做到哪了

长任务的结构化进度：计划、每一步的状态、中间产物的位置、已执行的写操作及其外部 ID、等待中的审批、已花费的预算。它服务于“中断后继续”，详见任务状态与 Checkpoint。

特点：必须是程序可读、可校验的结构化数据，而不是一段聊天记录。

工作记忆：此刻看得见的东西

模型每次调用时上下文窗口里的全部内容。它是其他四种状态的“投影”：Harness 从对话历史、任务状态、长期记忆和业务系统中挑出本步需要的部分，装配进上下文。如何挑选是 Context Engineering 模块的主题。

特点：容量有限、每次重建。模型只能基于工作记忆推理，没被装进来的东西，对模型而言就不存在。

长期记忆：跨会话仍然成立的东西

用户偏好（“周报按大区汇总”）、项目约定（“这个仓库用 pnpm”）、过往纠正（“退货不计入华东销售额”）、经验教训。详见长期记忆。

特点：会过期、会出错、涉及隐私，必须能查看、修改与删除（见记忆的隐私与可控）。

业务状态：现实世界的真相

订单是否退款、页面是否已上线、代码是否已合并。它存放在业务系统里，Agent 只是读取者或通过工具修改它的操作者。

特点：它是唯一的事实来源。Agent 的任何记忆都不能替代对业务状态的实时查询。

同一个场景里的五种状态

以「客服助理 Agent」处理一次退款投诉为例：

图 2 · 同一次调用里的五种状态：记忆只用来调整语气，决定补偿必须看实时业务状态

注意最右边那一列：“上月有一次退款补偿记录”来自长期记忆，可以用来调整沟通语气；但如果要决定“这次能不能补偿”，Agent 必须实时查询订单与支付系统，而不是相信记忆。

最重要的原则：记忆不是事实

五种状态的可信程度从高到低大致是：

图 3 · 可信度阶梯：越往右越可能过期或出错，影响动作的信息要回到最左边确认

由此得出三条设计规则：

凡是会影响执行动作的信息，都要回到业务系统重新确认。 记忆里写着“退款已到账”，不能据此关闭工单。
记忆要带来源和时间。 “2026-08-03 用户在会话中声明：周报按大区汇总”比“用户喜欢按大区汇总”可靠得多。
不要让一种状态冒充另一种。 用对话历史充当任务进度、用长期记忆缓存业务数据，是最常见的两个坏味道。

产品里的五种状态

以 Claude Code 为例，可以清楚地看到这种分层（依据其官方文档）：

状态类型	Claude Code 中的对应物
对话状态	会话记录，保存在本地项目目录下，可以恢复
任务状态	会话中的任务清单（通过任务创建与更新工具维护）
工作记忆	当前上下文窗口，接近上限时自动压缩
长期记忆	人写的 CLAUDE.md 文件，以及 Claude 自己记录的自动记忆（auto memory）
业务状态	代码仓库、Git 历史、测试结果：每次需要时重新读取和运行

其他框架也有对应划分。例如 LangGraph 的文档把记忆分成“线程范围的短期记忆”（通过 Checkpointer 持久化）和“跨线程共享的长期记忆”（通过 Store 保存）；OpenAI Agents SDK 用 Sessions 管理跨运行的对话历史。概念相近，但名字不同，读文档时要先对上号。

另外，Memory 与 Knowledge（企业知识库）也经常被混淆：知识是组织共享的、相对稳定的内容，记忆是在与特定用户或任务交互中积累的内容。详见 Knowledge、Memory 与 Context。

常见误区

“把所有对话都存下来，就等于有记忆了。” 存储不等于记忆。没有筛选、结构和召回策略的历史，只会让上下文越来越长、越来越吵。
“记忆越多，Agent 越懂用户。” 过期或错误的记忆会持续误导 Agent，而且很难被察觉。
“长期记忆可以缓存业务数据，省得每次查询。” 业务数据会变化，缓存进记忆就会过期。需要缓存就用有失效机制的缓存，而不是记忆。

设计要点

需求评审时，把“记忆”需求逐条归到五种类型之一。
为每种状态明确：谁写入、存在哪、保存多久、谁能看、怎么失效。
业务状态只读取、不记忆；关键动作前必须实时查询。
任务状态用结构化数据，不依赖对话历史还原进度。
长期记忆带来源、时间和作用范围（用户、项目、团队）。

练习

拿一个你熟悉的 Agent 场景（销售分析、SEO 诊断或 Coding Agent），用 30 分钟完成下表，每种状态至少写出 2 条具体信息：

状态类型	具体信息示例	存放位置	保存多久	失效或更新条件
对话状态
任务状态
工作记忆
长期记忆
业务状态

然后检查：有没有哪条信息被你放进了“长期记忆”，但其实应该每次实时查询？

下一步

下一课「会话与持久化」从最基础的对话状态讲起：会话怎么存、怎么恢复、怎么分叉、什么时候过期。

状态的五种类型