很多团队第一次做 AI agent，会把“session”理解成一段聊天历史。这样在 demo 阶段几乎没有问题，因为一个进程、一个上下文窗口、一次短任务，确实还能靠内存和对话记录撑住。
但只要系统进入真实环境，问题马上变样：任务会跨天、会切换 harness、会调用外部工具、会写文件、会等待回调、会被人工审批打断。到了这个阶段，session 再只是聊天记录，系统就会失去两个关键能力：恢复和解释。
真正的 Session Store，本质上不是“把消息存起来”，而是把一次 run 里发生过的关键事实写成可切片、可回放、可恢复的 append-only event log。建议先结合 AI Agent Session Replay 调试指南、AI agent Checkpoint 与断点恢复、AI agent Run Ledger 审计模型 和 AI agent Harness 崩溃恢复与 Wake 流程 一起看。
把 session 留在容器里，系统就会长出“宠物”
最危险的设计，不是没有 session store，而是把 session 状态绑在执行容器或单个进程里。因为一旦容器卡住、滚动重启、网络闪断或需要切到别的执行器，你失去的不是一条对话，而是整条任务链的上下文归属。
一个可用的 session store 至少要满足这 4 个条件：
| 能力 | 为什么必须有 |
|---|---|
| append-only | 故障复盘时不能靠覆写后的最终状态猜过程 |
| durable | harness 挂了以后状态还能被别的进程接着读 |
| sliceable | 新进程需要按时间、事件类型、checkpoint 取局部上下文 |
| redactable | 敏感字段需要在日志可用和隐私保护之间取得平衡 |
如果这 4 个条件缺一个，session 就很容易沦为“平时看着能用，出事时帮不上忙”的半成品。
Session 不是上下文窗口，它是一份可被查询的事实账本
上下文窗口服务的是当前这一轮推理；session store 服务的是整条执行历史。两者的职责不同，不能混在一起。
更稳的做法，是让 session 记录“事实事件”，而不是只记录“模型看过的文本”。一个最小事件集合通常包括：
- 用户输入与系统决策入口
- 工具调用请求、返回和错误
- 状态迁移与审批节点
- side effect 前后的确认记录
- checkpoint、wake、retry 和 stop 相关事件
用结构化方式表达会更清楚：
{
"sessionId": "sess_42",
"eventId": "evt_203",
"type": "tool_result",
"runId": "run_9",
"tool": "fetchCustomerProfile",
"timestamp": "2026-05-12T09:43:12Z",
"payloadRef": "blob://tool-result/evt_203",
"redactionLevel": "masked"
}
这里最重要的不是字段多，而是让 session 能被不同消费者读取：harness 用它恢复，replay 用它复盘，审计系统用它核对，人工控制台用它解释“为什么现在停在这里”。
失败复盘：进程重启后，系统把已经发出的外部通知又发了一次
一个典型事故是这样的：agent 在第 7 步已经向外部系统发送了通知，但进程在写“完成状态”之前崩溃。重启后的新进程只看到了内存里未完成的任务快照，于是重新执行了一遍发送动作。
这个事故真正缺的不是“更聪明的模型”，而是 session store 里没有一条 durable 的 side effect 事实：通知是否已经发出、发给谁、对应哪个幂等键、是否拿到外部确认。
修复思路通常是三层一起补：
- side effect 前先写 intention event
- side effect 成功后写 committed event
- wake 时优先根据 session 里的 committed 事实决定是否跳过重放
这样新进程不需要猜测“上一个进程做到哪了”，它直接查事实。
设计时最容易被忽略的，是查询接口而不是存储接口
很多团队会先设计 appendEvent()，但真正决定系统可恢复性的，往往是这些查询能力：
getEvents(sessionId, afterEventId)getLastCheckpoint(runId)getLastCommittedSideEffect(runId, effectType)getContextSlice(sessionId, fromEventId, toEventId)
如果 session 只能“全量读出”，新进程恢复时不是太慢，就是会把无关噪音重新塞进上下文。可恢复系统依赖的不是“存下来了”，而是“能取出刚好需要的那一段”。
Session Store Checklist
- session 是否被设计成 append-only event log，而不是可覆写状态对象
- 关键事件是否包含 runId、event type、timestamp 和 redaction 信息
- side effect 是否分成 intention 与 committed 两类事实
- harness 重启后能否按 checkpoint 或 event slice 恢复，而不是全量重读历史
- replay、审计和人工控制台是否共用同一份 session 事实源
- 是否能对敏感 payload 做引用存储与脱敏展示
- 查询接口是否支持 afterEventId、event type 和 side effect lookup
这篇真正想留下的判断
AI agent 的 session store，不该是“更长的聊天记录”，而应该是整个执行系统的事实底座。只要你的任务会跨进程、跨时间或跨环境运行，session 就必须先从“对话存档”升级成“可查询、可恢复、可审计的 event log”。
延伸阅读：
