正在加载，请稍候
会话内靠窗口，会话间靠摘要落库，长期画像才上向量库。按三层拆解 token 与存储成本、真实场景取舍与回归评测方法。
多轮对话记忆只该分三层：会话内靠上下文窗口，会话间靠摘要落库，长期画像才值得上向量库。分错的代价不是慢，是每月多付几倍存储与推理钱，还换不到召回率。
三层记忆的边界由读取频率和写入量决定：会话内按轮次付费，会话间按行数付费，长期画像按向量维度与索引付费。先认清这三种计费模型，再谈选型，比先选数据库要省事得多。
| 层 | 载体 | 写入粒度 | 主要成本 | 典型失效点 |
|---|---|---|---|---|
| 会话内 | 上下文窗口 | 每轮全量重发 | 输入 token × 轮次，线性上涨 | 超过 20 轮后单轮成本翻倍，首尾之外的内容被注意力稀释 |
| 会话间 | PostgreSQL 摘要表（JSONB） | 每 6–10 轮压缩一次 | 行数 × 摘要长度，可忽略 | 摘要丢关键事实，用户被迫重复说明 |
| 长期画像 | 向量库 + 原文归档 | 事件触发或离线批处理 | 向量维度 + 索引 + 检索注入 token | 召回不准比召回不到更糟，错误记忆污染后续每轮 prompt |
做量级粗算：中文一轮对话约 800 字，粗折 1100 token。若 30 轮全部重发，第 30 轮单次输入累计到 3 万 token 量级；改成每 8 轮压一次 400 token 摘要，同轮输入大约压到 1500 token 量级。这是二十倍量级的差距，跟用哪家模型无关。
所以第一层不必急着落库，第三层不必急着上线。真正需要设计的是第二层——摘要什么时候生成、压掉什么、保留什么。我们的做法是把「用户明确纠正过的信息」和「可长期复用的偏好」抽成结构化字段，其余进自由文本摘要，前者永不被压缩覆盖。三种长期记忆架构的横向对照，见 AI Agent 长期记忆的三种架构与工程取舍，可与本文的分层口径对着看。
架构选型不取决于模型能力，取决于记忆的用途：是用来排序、用来维持人格一致，还是用来给第三方角色看趋势。用途不同，三层的配比完全不同，同一套代码换个场景就会翻车。
先交代口径。截至今日，站内已发布交付案例共 7 个（均为 2026 年项目）：人工智能 2 个、企业服务 2 个、教育培训 2 个、文旅消费 1 个；技术栈上 PostgreSQL 7 个、Next.js 7 个、Go 5 个、React 4 个，其中 1 个含 LBS 位置服务；5 个案例填写了项目周期（样本含 3 周、4 周、6 周），5 个填写了团队规模（3–4 人核心团队）。下面的三类场景就按这个真实分布归纳，模块划分属方案层面的推演，不是逐项目复盘记录，也不宜外推成行业结论。
兴趣匹配类项目里，记忆的价值在于「这个人上次喜欢什么、现在人在哪」。结构化偏好（标签权重、最近一次交互时间、地理围栏）全部留在 PostgreSQL，向量层只放用户自由填写的自我描述。检索时先用 SQL 把候选圈到几百人，再对圈内做相似度，避免全库扫描——这一步能把检索成本压到几乎为零。同类场景的实际项目可参照 友搭搭：从兴趣匹配到同城社交场景的 AI 产品平台。
陪伴类产品的失败点不是答不上来，是「昨天说的事今天就忘」。会话间摘要承担主要职责：称呼、忌讳话题、最近一次情绪事件、约定过的事，抽成有限字段写回用户行。长期画像控制在几百条量级即可，没必要把每句原文灌进向量库。
这是记忆系统里最硬的一条合规约束：青少年端产生的原文只能留在会话表，并设明确保留期；家长端只读聚合指标（互动轮次、情绪标签分布、活跃时段），不可回溯到具体对话。摘要在脱敏之后才允许进入画像层。这样切分的好处是删除链路清晰——用户要求删除时，原文、摘要、向量三处各有一张表可清。双端隔离的落地形态可参考 小云朵 AI 青少年情绪陪伴平台 这一交付案例。
条目数低于一万、查询能写成结构化条件、且没有模糊语义需求时，不该上向量库——此时向量检索只是在 SQL 之上加了一层不可解释的间接层，既贵又难排障。这不是立场问题，是触发条件问题。
反过来，满足以下任一条件就该上：条目数破万且持续增长、查询本质是语义而非字段、需要跨用户相似度推荐、记忆主体是非结构化长文本。第三层之所以叫「长期画像」而不是「长期记忆」，就是因为它服务的往往是推荐与个性化，而不是复述。
顺带说一个被低估的设计：检索为空时的默认行为。正确的默认是追问澄清，而不是让模型硬凑一段听起来合理的记忆。很多「AI 记得住」的翻车都发生在这一步。
记忆系统的验收不看对话是否流畅，只看三件事：冻结样本集上的召回命中率、记忆注入后的答非所问率、以及删号之后记忆是否真的消失。三件事都能量化，才谈得上迭代。
这套流程跟离线记忆架构的实现思路是相通的。Generative Agents 那篇工作把记忆拆成三件事：用自然语言存完整经历、定期合成更高层的反思、再按需动态检索，并在消融实验里验证观测、计划、反思三个组件对行为可信度都有实质贡献（来源见文末参考）。工程上可以照着这个骨架搭，但要注意它的存储是无界的——生产系统必须先想清楚什么该忘。
不一定：只有跨会话、无法用结构化条件表达、且条目数破万的长期画像才需要向量库；会话内用上下文窗口、会话间用 PostgreSQL 摘要表，就能覆盖大多数产品需求。先把第二层做好，比早上向量库收益高得多。
需要：窗口再大也是按次计费，且长上下文里中段信息的注意力会稀释，30 轮以上全量重发会让单轮成本线性上涨。摘要压缩解决的是成本与稳定性两个问题，不只是省钱。
不会：按每用户 200 条摘要、每条约 120 token 估算，十万用户也只在几十 GB 量级，JSONB 加时间分区完全够用。真正的瓶颈是检索质量，不是容量上限。
最小化：原文只留在会话表并设保留期，进检索层的必须是脱敏摘要。第三方角色（家长端、企业后台）只读聚合指标，删除请求要贯穿原文、摘要、向量三处。
如果你正在为已有产品补记忆层，或是在「摘要表够不够用」和「该不该上向量库」之间犹豫，可以把当前的轮次分布、用户规模、合规约束发给我们，我们用 服务方案 里的评审流程做一次分层判断；也可以直接 联系我们 聊具体边界。