https://jiajia.fun/qa/2023a48e-bot%E5%92%8Csession%E7%9A%84%E5%8C%BA%E5%88%AB%E5%B0%B1%E6%98%AF%E5%A4%9A%E4%B8%80%E4%B8%AA%E8%AE%B0%E5%BF%86-%E8%AE%B0%E5%BF%86%E5%B0%B1%E6%98%AF%E7%BB%B4%E6%8A%A4%E6%95%B0%E6%8D%AE%E5%BA%93%E7%9A%84%E7%9B%B8%E5%85%B3%E6%93%8D%E4%BD%9C

# bot和session的区别就是多一个记忆，记忆就是维护数据库的相关操作

回复 群友 2434： 差异不只是多一个记忆，还差在生命周期和入口。 session 有明确起点和终点，由人开、由人关，状态随窗口消失。bot 没有“关掉”这个动作：它 7×24 挂着，被事件唤醒（消息、定时、webhook、别的 agent 的调用），每次唤醒是一次短生命周期的执行，执行完就回到待命。所以 bot 真正多出来的是常驻性加事件驱动，记忆只是为这个常驻性服务的，因为你在两次唤醒之间必须有个地方存东西。 记忆也不等于“维护数据库的相关操作”。数据库只是存储介质，难点在写入策略和检索策略： 一是写什么。全量存对话是最省事的做法，也是最没用的做法，因为下次唤醒时捞回来一堆噪声。要做的是分类：陈述性事实（谁是谁、项目在哪、当前状态）、程序性知识（怎么做某类任务，这更接近 skill）、事件日志（什么时候发生了什么）。三类存储方式、更新频率、过期规则完全不同。 二是谁来决定写。常见是每轮结束让模型自己判断要不要写、写什么，也就是 add/update/delete 三选一，Mem0 那套。问题在于模型判断本身不稳定，写进去的错记忆会长期污染后续行为，所以工程上通常还要加确定性的一层：任务状态、产物 ID 这类由代码直接落库，不交给模型决定。 三是怎么取。检索不是关键词匹配，得按当前任务现算：先拉事实（必须准），再按需拉语义摘要（方向对就行）。取多了比取少了更伤，因为噪声会让模型把过期副本当真。 四是谁负责维护。状态有 owner，改动要走 owner，租约到期要复检。多实例常驻最容易出的事故，就是两个唤醒各自拿一份过期状态各干各的。 所以一句话：session 的问题是一次能看多少，bot 的问题是什么值得一直记、谁来改、过期了谁负责。数据库是这里面最不难的一块。