04-把记忆塞进Prompt的代价-为什么只能取20条黒漂技术佬的 AI 伙伴AI-Partner源码拆解系列。前面三篇把记忆怎么存、怎么查、怎么注入讲完了。本篇算一笔容易被忽略的账把用户的记忆塞进系统提示词到底要花多少 Token、多少延迟、多少银子以及为什么只能取 20 条是个不得不做的取舍。一、先建立直觉系统提示词是每轮都重发的固定成本很多人以为记忆注入只发生一次。错。在 AI 伙伴AI-Partner里每次用户发一句话后端都会走PersonaProvider.buildSystemMessage(userId)重新拼一遍系统提示词连同这句用户消息、短期记忆窗口一起发给大模型。也就是说系统提示词 每次对话都付一次的固定开销。记忆越多、写得越啰嗦这个固定开销就越大。它不是一次性的是对话次数 × 系统提示词长度的累积。所以取多少条记忆不是体验问题是钱和延迟问题。二、Token 成本量化估算先说计数口径。项目里ChatService.estimateTokens的规则是中文字符约 1 字 1 token非中文字符约 4 字符 1 token。我们就按中文 1 字 ≈ 1 token粗算系统提示词的构成以下为估算便于建立量级感非精确测量。系统提示词由四段拼成回顾PersonaProvider段落内容估算 Token固定人设PERSONA_RULES性格 能力边界~300【当前时间】形如2026年9月14日 14:30~15【用户信息】昵称/角色/手机/生日 画像摘要(可选)基础 ~80画像摘要最长 ~2000【长期记忆 20 条】每条[类型·重要度X] 内容见下【回复要求】6 条共情/字数/求助等规则~200单条记忆的写法[偏好·重要度3] 用户喜欢喝绿茶前缀约 12 token 正文约 10-30 token取均值约 30 token/条。20 条就是30 token × 20 条 600 token记忆段于是两套典型场景的系统提示词体量场景系统提示词 Token 估算轻量用户无画像摘要20 条短记忆3001580600200 ≈1195 token重度用户画像摘要 2000 字 20 条记忆300152080600200 ≈3195 token再叠加每轮对话本身的用户消息 短期记忆窗口(最多 12 条) 模型回复。即便用户只说在吗系统提示词那上千 token 也已经先发出去了。关键结论系统提示词是沉默的固定税。一次对话真实消耗的 Token ≈ 系统提示词(固定) 短期记忆窗口 当轮问答。记忆段是系统提示词里最大、也最该被压缩的一块。三、上下文膨胀对延迟和费用的双重打击把记忆无节制地塞进去会从两头反噬1. 费用输入 Token 累积。虽然输入 Token 单价通常低于输出但系统提示词每轮重发对话量一大就是实打实的开销。假设系统提示词 1200 token、日均单用户 30 轮对话那就是1200 × 30 36000 token/天/用户纯系统提示词消耗——而且这还没算问答本身。用户上了规模记忆段每多塞 10 条成本线性上涨。2. 延迟首字时间被拖长。大模型处理请求时要先读完整个上下文才开始吐字。系统提示词越长****首字延迟time-to-first-token****越大用户会明显感觉机器人反应慢了。陪伴场景里慢半秒都影响像家人的体感。3. 注意力稀释贵且效果差。更隐蔽的代价——上下文越长模型越容易在海量记忆里视而不见真正该用的记忆被淹没。这叫lost in the middle现象。所以塞得多 ≠ 陪得好反而可能更差。四、为什么只能取 20 条一个工程取舍回到源码两处硬截断到 20PersonaProvider.buildSystemMessage.limit(20)注入系统提示词。MemoryService.search.limit(20)工具检索返回上限。20 是三层约束下的平衡点约束对条数的拉扯Token 预算希望越少越好省钱、快个性化质量希望越多越好记得全注意力上限希望精选而非堆量避免稀释20 条在够个性化和不撑爆上下文之间取了中间值。配合第 03 篇讲的importance DESC排序保证被截掉的 20 名开外本来就是相对不重要的记忆——截断有优先级保护不是随机丢。但要诚实指出20 是个经验值不是算法最优解。它的成立依赖重要度排序靠谱。如果模型把闲聊都打 5 分第 02 篇提到的风险20 条里就会混进噪音截断也救不了。五、当前实现里一处可优化冗余读PersonaProvider源码会发现一个小浪费同一条记忆可能出现在两个地方。系统提示词先写【用户信息】段里面含personaSummary画像摘要来自MemoryService.refreshPersonaSummary取前 10 条记忆的content用拼成随后又写【长期记忆】段取前 20 条记忆。于是前 10 条记忆既在画像摘要里又在记忆列表里——重复注入了。// 示意系统提示词里前 10 条记忆出现两次 【用户信息】 - 画像摘要用户喜欢喝绿茶用户有一只叫团团的猫...前10条 【关于这位用户你记得长期记忆】 [偏好·重要度3] 用户喜欢喝绿茶 ← 重复 [关系·重要度3] 用户有一只叫团团的猫 ← 重复 ...前20条这不算 bug画像摘要和记忆列表角色不同一个是一句话印象一个是可逐条引用但从 Token 角度看前 10 条记忆被算了两次。重度用户那 2000 字画像摘要和记忆段高度重叠正是系统提示词膨胀的主因之一。优化的第一刀就该切这里。六、进阶方案三层记忆与召回打分想既记得多又塞得少业内通用思路是不要把所有记忆都常驻提示词而是分层 按需召回。方案 A分层注入hot / warm / cold层内容是否进系统提示词热记忆 hot最近 高重要度如 top 8常驻注入温记忆 warm其余生效记忆不注入模型用searchMemory按需翻冷记忆 cold历史/低频不注入归档这样系统提示词只背最该当下用的少量记忆模型需要时再调工具翻笔记——和第 02 篇的searchMemory天然契合。方案 B摘要压缩personaSummary已经是摘要思路的雏形。可进一步把 20 条压成 3-5 句用户画像简介常驻细节全走按需检索。相当于给人设喂简历不给档案。方案 C召回打分向量/语义当前排序只按importance createdAt是规则排序理解不了用户问猫该调出团团那条。引入 Embedding 后可按当前对话语义 × 记忆相似度打分挑最相关的 20 条——解决第 03 篇说的字面匹配近义词盲区。代价是要接向量库项目目前没接属可扩展方向。诚实边界上面 A/B/C 均不是当前t_memory/PersonaProvider的现有实现。项目用的是重要度排序 20 条截断 画像摘要三板斧已能跑通进阶方案是给二次开发指的路别当成已完工的功能写进文档。七、一个具体的量级推演光说贵没感觉我们代入一组假设数字看记忆段膨胀如何放大成月度账单。口径仍是中文约 1 字 1 token且仅算系统提示词里的记忆段便于看清趋势。假设单用户日均对话 30 轮分三种记忆体量记忆体量系统提示词记忆段 Token系统提示词合计(估)日系统提示词 Token月系统提示词 Token轻度8 条短记忆~240~835~25,050~75 万当前默认20 条~600~1,195~35,850~107 万贪婪50 条~1,500~2,095~62,850~188 万只看记忆段从 20 条涨到 50 条这一步系统提示词月消耗从约 107 万跳到 188 万涨了约 75%而用户感知到的陪伴质量未必同步提升——因为 50 条里大量是低重要度闲聊模型反而更易lost in the middle。这正好反证掐在 20 条的合理性边际记忆带来的体验收益远抵不过边际 Token 成本。再叠加短期记忆窗口最多 12 条第 02 系列讲过memory-window-size12和用户消息每轮真实消耗还会更高但那是对话本身的开销记忆段是其中唯一可由我们主动压缩的大头。所以优化记忆注入是性价比最高的一刀。八、可落地的优化清单如果你要在现有代码上动刀按性价比排个序消除重复注入系统提示词里画像摘要与记忆段去重或二选一精简省下重度用户近 2000 token。下调常驻条数做 A/B把limit(20)抽成配置项如memory-inject-size默认 20按需调到 8-12 观察陪伴质量。// 示意把硬编码的 20 提为可配置项Value(${ai.partner.llm.memory-inject-size:20})intmemoryInjectSize;// 使用处.limit(memoryInjectSize)缩短content存储存记忆时让模型写精炼一句避免塞进整段闲聊1000 字上限别用满。系统提示词缓存同一userId在记忆未变时缓存buildSystemMessage结果别每次查库重拼注意时间字段需单独刷新。// 示意用 userId - 系统提示词 的缓存记忆变更时失效MapLong,StringsystemCachenewConcurrentHashMap();// save/remove 触发 refreshPersonaSummary 后一并 systemCache.remove(userId)监控 Token 用量Conversation.tokenUsage已在落库定期看均值定位记忆肥胖用户。引入向量召回远期接 Embedding 服务把重要度排序升级为语义相关度排序提升 20 条的命中率。合规提醒把个人记忆注入提示词等于把用户的生活片段可能含健康、家庭、位置每轮都外发给大模型服务商。请务必① 仅注入陪伴所必需的记忆遵循数据最小化② 对外发内容做脱敏评估敏感字段如精确手机号、详细住址谨慎进入提示词③ 明确告知用户数据会被用于处理对话并取得授权④ 老人/儿童数据采用更保守的注入策略。记忆越全责任越重。算清这笔账后会发现陪伴机器人记得多的浪漫背后是 Token、延迟和隐私的三重成本。取 20 条不是偷懒是在成本与体验之间画的的一条理性分界线。
