5.4 状态持久化与多会话管理

5.4 状态持久化与多会话管理

本节摘要：持久化的价值在多会话场景兑现：智能体在不同时间、不同任务、不同客户端之间保持认知一致。本节讲清跨会话一致性的机制来源、跨任务状态迁移的正确姿势，以及并发写入的边界处理。读完本节，你的智能体可以放心地"活"在长期任务里，而不是活在一个又一个失忆的下午。

一次跨周任务的真实考验

用一个真实感十足的剧本检验你将获得的能力。周一，你让项目助理智能体启动一项供应商评估："收集三家候选的报价与服务条款，整理成对比表。"智能体开始工作，与你多轮交互，记下了评估标准与初步结论。周三，你在另一个客户端问它"评估进展如何"。下周一，评估完成，你让它"把上次的对比表按新预算重排"。

这三个时刻横跨八天、跨越多端，智能体的表现却像从未间断的同一件事：周三它知道周一定了哪些标准；下周一它记得对比表的完整结论。这份"认知连续性"不是对话技巧，而是 2.1 节四步循环里那一步"状态持久化"的复利——每轮对话结束时的落库，把八天串成了同一条状态线。本节要讲的，就是这条状态线在工程上如何站稳。

一致性从哪里来

跨会话一致性的机制来源只有一个，但值得从三个视角各看一遍。数据视角：智能体的全部认知是数据库里的确定记录，会话只是访问这记录的窗口——窗口开开关关，记录原地不动。协议视角：任何客户端接入都从服务端取状态，不存在客户端本地的"副本真相"，这就杜绝了"两个入口看到两个智能体"的经典事故。推理视角：每次响应前，服务端组装的都是最新持久化状态，上一会话的变更天然在场——一致性不是靠同步机制维系的，而是靠"根本不存在第二份状态"。

理解了这一点，就能看穿一个新手误区：担心"会话结束会不会丢上下文"。会话在 Letta 的架构里甚至不是一等概念——它只是两轮消息之间的时间间隔。真正的一等概念是智能体状态与消息流，前者永不丢失，后者全部可回溯。

落到工程习惯上，这份性质改变了"长期任务"的实现思路。传统做法用任务队列表、断点字段、恢复逻辑把"进行中"编码成数据结构；记忆智能体的做法朴素得多——把任务目标与已确认的决定写进记忆，把过程细节交给对话流与存档，任务天然可中断、可恢复。你不需要写"恢复逻辑"，恢复就是下一次对话本身。省掉的这类代码，正是智能体架构对传统任务系统最实在的替代。

跨任务的状态迁移：检索而非携带

多会话之上更难的场景是跨任务：任务 A 产生了大量中间结论，任务 B 只需要其中一部分。比如评估任务沉淀了十几轮对话与一份对比表，新的预算重排任务既不该从头开始（浪费积累），也不该全量携带（污染上下文）。正确的姿势是检索式迁移：任务 B 在需要时，由模型对召回存储与存档存储发起检索，把任务 A 的相关结论捞进当前上下文。

整个交互的机制如下图所示——注意第二段会话开始时，模型主动检索了第一段会话的存档结论，而不是用户手动粘贴背景：

这个姿势的要领在 5.1 节其实已经埋下：persona 里引导模型"接手延续性任务时，先检索历史相关记录"。模型是否主动检索，取决于策略引导；检索是否命中，取决于 5.3 节说的档案质量。跨任务迁移做不好，多数时候病根不在持久化层，而在写入时的粒度——存档里写的是"结论"还是"过程流水"，决定了检索的命中质量。

并发写入：边界情况的处理

多会话并发是持久化的最后一道坎。两个客户端同时向同一智能体发消息，两个会话都在修订记忆——谁赢？Letta 的服务端把每个智能体的推理循环串行化处理：同一智能体的消息按到达顺序排队执行，前后两轮都能看到前一轮的完整变更，记忆不会互相覆盖踩踏。这意味着并发的安全性由框架兜底，你的业务代码无需加锁。

需要你自己设计的是语义层的并发策略。典型问题：一个只读的报表任务和一个高频写记忆的教练任务，共享一个智能体是否合适？答案通常是否——把它们拆成两个智能体，各自有独立的记忆与节奏，需要共享的部分显式放入共享块（下一节的主题）。并发安全的正确用法不是"敢并发"，而是想清楚什么该并发、什么该隔离。

再补一个时间维度的细节：消息的到达顺序决定执行顺序，而跨客户端的到达顺序未必是你心里的顺序。两个客户端几乎同时发消息，服务端按接收先后排队——谁先谁后有偶然性。对顺序敏感的业务（审批流、指令序列），要么把这类操作收进单一客户端，要么在业务层引入显式的序号与确认。把并发想清楚再上线，比出了乱序再补救便宜得多。

关于持久化的常见疑问

问：任务做一半服务重启，进度会丢吗？ 不会丢，但要区分两类"进度"。已固化的部分——写进记忆块的事实、写入存档的结论、完整的对话事件——都在数据库里，重启后原样在场；仅存在于"当前对话惯性"中的部分——比如刚说了半句话、还没落笔的计划——会随最后一条消息一起成为历史，需要在新会话里重新提出。设计长任务时，让智能体"每完成一小步就固化一小步"（写入记忆或存档），重启的损失就趋近于零。

问：能回滚到某个历史时刻的状态吗？ 消息与事件流天然可回溯（召回存储完整保留）；记忆块的当前值是最新态，历史版本取决于存储层的留存策略。对记忆变更有审计要求的团队，做法是让记忆修订走一条有日志的通道——或定期快照记忆块，或用 SDK 在每次批量修改前留存副本。回滚能力不是框架送的，是你在存储策略里自己挣的。

问：两个智能体各做各的任务，互不干扰怎么保证？ 隔离是默认态：不同智能体的记忆与消息完全独立，只要不共享块、不互设工具，就互不相干。需要协作时再显式建立通道（5.5 节）——默认隔离加显式共享，比默认共享加小心隔离安全得多。

本节要点回顾

• 连续性来源：不存在第二份状态——所有客户端共享服务端的唯一记录，一致性是架构性质而非同步技巧。
• 会话非一等概念：真正的单位是状态与消息流，"会话结束丢上下文"是范畴错误。
• 检索式迁移：跨任务靠模型检索历史结论而非全量携带，写入粒度决定迁移质量。
• 并发兜底：同智能体的推理循环被串行化，写入不会互相踩踏；语义层的共享与隔离需要你设计。

下一节把视野扩展到群体：当记忆需要在多个智能体之间流动，共享记忆块如何成为协作的地基。