四类状态别混在一个数组里
Run State、Session History、Workflow Checkpoint、Long-term Memory 的生命周期和恢复语义完全不同，混成一个 messages 数组必然出问题。
一个 messages 数组装不下 Agent 的全部状态。Run State、Session History、Workflow Checkpoint、Long-term Memory 的生命周期和恢复语义完全不同，混在一起的结果是既不能恢复也不能删除：该丢的丢不掉，该留的留不住。
四类状态，四条生命周期
| 状态 | 范围 | 用途 |
|---|---|---|
| Run State | 一次运行 | 当前步骤、预算、中断 |
| Session History | 一个会话 | 消息连续性 |
| Workflow Checkpoint | 一个流程实例 | 恢复、重放、人工暂停 |
| Long-term Memory | 跨会话 | 用户偏好、已验证事实 |
这张表的实际含义是：四类状态的写入频率、保存期限和删除条件都不一样。Run State 可以随进程结束丢弃，Session History 可以截断摘要，Checkpoint 必须能重放，Memory 必须能按来源撤回。塞进同一个数组，你没法对任何一类单独设规则——想给记忆加有效期，就会顺带让检查点也能过期。
业务事实不能只活在你的框架内存里
框架给你的 memory 对象很方便，但它是缓存，不是数据库。订单状态、审批记录、用户确认过的口径，这些业务事实必须落到你自己的持久化存储里，Agent 只持有引用。理由有三条：它跟框架绑定，迁移一次就丢一次；它在进程内，崩溃就没；它没有来源和有效期，你回答不了"这条事实是谁在什么时候确认的"。
同样重要的是区分模型推断与已验证事实：推断进上下文，事实进账本。两者混写，后来的 Agent 会把上一轮的推测当证据继续推理。
按恢复语义给 Memory 分类
同一个"记忆"词底下其实是五种东西，各有各的一致性和恢复语义 agent-trend-2026：
- 工作状态：能被新的 checkpoint 取代，丢了重算即可，不要为它做持久化。
- 事件历史：追加写，不覆盖。摘要适合压缩上下文，审计必须依赖原始记录。
- 领域知识：保留版本与来源，来源变了要重新验证。
- 偏好：需要衰减和纠错。三个月前的"以后都这样做"，不代表现在还是。
- 凭据与身份：留在专用隐私边界，不进通用记忆库。
判据很简单：能无状态完成的任务就保持短寿命。持久化要付隐私、腐化和迁移三种成本，不是所有东西都值得存。
记忆是增强能力，不是依赖路径
检索失败或超时，就返回空结果并记一条 warning，主流程继续跑。长期记忆和短期上下文并行加载、join 汇合，任何一路慢或挂都不阻塞另一路。
得物在企业级 MultiAgent 平台上的实现值得照抄：请求入口用专用线程池（不用公共线程池，避免和主流程抢线程）并行启动短期和长期两个 Future；长期记忆总预算 4000 token，画像类上限 60%，没用满的部分让给任务经验，截断按行进行以保留单条记忆的完整语义；异步沉淀链先写新记忆、后删旧记忆——外部记忆服务没法用事务包住"新增加删除"，先写后删的最坏情况是多一条冗余，而不是丢一条 poizon-memory。
结构决定你能不能找到它
目录每深一层，AI 定位一条记忆的选择数就翻倍。所以要有硬约束：目录两级封顶，二级下只放文件，内容增长用文件名前缀消化，不新建层级。想再加一层目录，往往是在用新增目录逃避"这条记忆属于哪一类"的判断 personal-ai-memory。
配套两件事。索引先行：总索引里每条一行 title 加 description，AI 先扫地图再决定读哪篇正文；每个目录一份 README，声明装什么、不装什么。跨目录的主题用 tags 补维度，不继续细分目录。不确定的信息显式标成"待补齐"，不要留空假装不知道。
有一套个人记忆系统还故意不做全自动维护：每条记忆写入前都要人确认。取舍很直白——全自动沉淀会把临时的、不够好的判断也写进去，久了记忆库固化的是"现在版本的我"，而不是"更好版本的我"。
存储格式：从一条笔记到可执行状态
"存成什么形状"不是风格问题，它决定了之后所有操作能不能做。四种格式的代价是一条清晰的递进线 ai-agent-book：
| 格式 | 形态 | 代价 |
|---|---|---|
| Simple Notes | 一条最小不可分的事实 | 开销极低、读写 O(1)；信息关联性全部丢光 |
| Enhanced Notes | 含完整上下文的段落 | 语义完整；存储冗余，属性一变要重写多段 |
| JSON Cards | 类别→子类别→键值三层 | 可部分更新、可预测可扩展；假设信息能清晰归类 |
| Advanced JSON Cards | 再加 backstory / person / relationship / 时间戳 | 消歧与跨会话关联最强；生成和维护更贵更慢 |
选择标准是量与关键性：关键且少量走 Advanced JSON Cards，大量且非关键走 Simple Notes，多数生产系统两种混用。刚性分类的代价很具体——"周末用 Python 开发个人项目"同时是时间偏好、技术偏好和活动类型，强行归进单一类别就丢掉另外两维。另一头，少量关键事实结构化后常驻上下文当"概览"、原始对话按需检索当"细节"，两层合起来才撑得起跨会话的主动服务：只常驻会丢细节，只检索看不见全局。
再往前一步，是把记忆从文本换成可执行状态。前四种本质都是文本，召回单条事实没问题，聚合、冲突检测和约束执行全交给 LLM"心算"。另一种做法是把用户状态建成带类型的对象、把规则写成普通函数，并借用"预写日志 + 检查点"：会话结束先把事实追加进只增日志，再定期从完整日志重建派生状态——原始证据留在日志里，可查询、可校验的状态交给代码 ai-agent-book。这条和本章前面的分工完全对齐：证据追加写，状态可重算。
淘汰要非对称
坏经验的淘汰速度应该是好经验强化速度的数倍。一条被证伪的记忆如果和十条被验证的记忆以相同速率累积，几次错误就足以把 Agent 带偏，而纠正它需要十倍的正确样本。规则级记忆尤其危险：它会影响未来所有任务的操作规程，写入前必须人工确认。
三个问题自检：随便挑一条你系统里的长期记忆，它的来源是什么？它什么时候失效？删掉它的路径在哪里？答不上来，说明它只是一段被持久化了的上下文。