会话状态放哪，我的默认答案是进程外的 KV。理由不是性能，是排查成本。进程重启、状态没了，这个 bug 不报错、不崩，只是 Agent 突然忘了用户三分钟前说过的话，你得从日志里一点点往回拼。但这话有反面：单轮工具调用的短会话，放内存完全够，为它引一个 Redis 是给自己找活。
进程内存的问题不是慢，是它一定会没
内存快、零依赖、写起来爽。我不否认。
问题是 Agent 进程重启是常态，不是异常。发版、OOM、扩缩容、容器漂移，随便哪个都能让内存里的 state 蒸发。丢状态的表现还很隐蔽——不是 500，是 Agent 又问了一遍「您偏好哪种格式」。用户觉得它笨，你觉得日志干净得可疑。
这周 OpenAI 那篇存储扩容的文章讲 Habitat 从 Python 库长成全球分布式存储，撑到 10 亿 ChatGPT 用户、每秒 2200 万请求。我看的时候想的不是「好大」，是：到那个量级，状态不可能跟着任何一个进程走。他们的选择题不是「要不要外部化」，是「外部化到什么程度」。
但 Redis 不该是条件反射
反方是对的，我认。用户问一句天气，Agent 调一次工具，返回，结束——这个中间状态活不过几秒。给它建 key、设 TTL、写序列化、再加一层反序列化失败的处理，纯属自嗨。内存变量就完了。
我自己用的分界线只有一条：这份状态要不要跨过一次请求。
跨了，就不该放进程内。没跨，放内存，别多想。至于「以后可能要跨」——等它真要跨了再迁。因为迁的时候你会发现，真正的成本不是搬数据，是当初根本没定义清楚 state 的 schema。这笔账早晚要付，但没必要提前付利息。
写 KV 和写库不是二选一，是分层
命题列了三个选项，工程里通常是两个一起用。
热的放 KV：当前对话轮次、工具调用的中间结果、临时的 plan。TTL 短，可丢，丢了能重建。
冷的落库：用户偏好、任务的最终产物、审计记录。必须落，而且要幂等。
判断方法我自己是这么问的：这条状态丢了，用户会不会察觉。会——落库；不会——KV 就够；只有这次请求用——内存。
有个坑值得说：别把 KV 当库用。我见过把整段会话历史塞成一个 JSON 进 Redis，然后开始在上面写筛选和排序逻辑。写到第三步的时候你就该换 Postgres 了，那时候数据量还小，迁移还便宜。
这周还有几条，沾边但不算强证据
OpenAI Agents API 把 session 做成了 API 的一等公民。信号挺明确：状态管理不再是「你自己想办法」，框架替你兜。代价是绑在它的存储模型上。我还没实测，按现在看，做原型很省事，要长期跑的东西得留条后路。
那篇讲移动 Agent 跑在 VM 里的帖子也值得看一眼。VM 本身就是个状态容器——沙箱文件、进程、网络连接。但 VM 会被回收，所以结论还是同一个：状态得往外写。
danluu 那篇 agentic testing 我扫了一遍，大意是 Agent 的自测和验证能力还不太行。这跟状态的关系在于：验证需要看见中间状态。状态全闷在进程内存里，你事后连复盘都做不了。这条算间接支持，不算直接证据。
我反对的不是内存，是「先放内存以后再说」
如果 Agent 就是一次性的无状态函数调用，那什么都不用存，这是最干净的架构，我不觉得有什么问题。
我反对的是那种「先放内存，以后再改」的默认姿势。因为这个「以后」通常发生在凌晨两点，而且线上。
也许半年后回头看，框架把 session 层全包了，我们根本不用选。但现在——按我手上的项目看——这个选择还是得自己拍。拍错的成本，比多引一个 KV 高得多。