大多数团队做 Agent 记忆的第一反应是「多存点」：把聊天记录全文塞进向量库，检索到就往上下文里拼。跑到几十个用户、几个月之后，记忆开始互相污染，回答越来越「像另一个人」。BizBuddy 的做法相反：只记个人画像与偏好，项目细节、知识库内容、工具过程一律不记，并且给记忆配了抽取、合并、净化、回收四道工序。

记忆在工程上不是「存什么」，而是「谁写、谁读、谁清理」。这三件事分不清，就会出现两种典型故障：要么记忆越滚越大、每次对话都在为几个月前的废话付 Token；要么写入不可控，模型把自己的猜测当成用户事实存了下来。下面按「分级—写入—瘦身—净化—关闭」讲一遍完整链路。

一、记忆不是聊天记录：三层职责

关键区别在第一列：会话记忆回答「刚才聊了什么」，长期记忆回答「这个人是谁」。把会话内容原样升级成长期记忆，等于让 Agent 永远记得某次临时需求，下次见面还拿旧结论套新问题。

二、什么该记，什么不该记

长期记忆的抽取提示词是平台写死的，只允许沉淀两类信息：个人画像（角色、行业、习惯）与偏好（表达风格、常用口径）。明确排除项目细节、知识库内容、工具调用过程——这些属于「当时的事实」，应该留在会话里，随会话结束而失效。

这条约束直接决定记忆体积。一个用了半年的账号，长期记忆通常仍是一页纸，而不是几百条对话摘要；注入时按 Token 预算截断，也不会挤占本轮真正要用的上下文。

这也是与「把聊天记录全量向量化」方案的分水岭：向量检索擅长找回某段原文，但不区分「用户是谁」和「当时聊了什么」，召回越准，越容易把过期结论当成本轮事实。记忆要的是稳定画像，不是可检索的历史——需要翻旧账时，去会话里查，而不是让每一轮都背着它。

三、怎么记：水位线加节流

每轮对话结束都可能触发抽取，但不能每轮都抽：重复抽取会把同一句话反复写进流水，合并成本翻倍。平台用两个机制收口：

• 水位线：每个会话记录「已处理到最后一条消息」的位置，只抽水位之后的增量；没有新消息直接跳过，避免空轮占用节流窗口。
• 节流：抽取策略支持 always / throttled / never 三档。默认节流档，同一用户在一个时间窗内只抽一次；窗口内继续聊天不会触发第二次。

抽取是按会话互斥的：同一会话并发两轮时，后到的一轮拿不到锁就跳过，不会出现两份互相覆盖的抽取结果。定时任务会话被显式排除——无人值守的机器对话不该变成用户的长期画像。

水位线按会话存放，新会话是新的 ID，不会继承旧水位——所以「重开一个会话」既不会漏抽，也不会把上一轮的内容误判成已处理。

四、怎么瘦：合并、保留期与回滚

抽取只写「流水」，真正给模型看的是合并后的 MEMORY.md。合并有三道闸：

1. 预算：单次合并可读取的流水有 Token 上限，超出的部分进入下一批，最多连续若干批；不会为了合并一次读完整月流水。
2. 间隔：两次合并之间有最小间隔，避免每轮都重写同一份文件。
3. 收敛口径：合并提示词同样只保留个人画像，并主动清理历史遗留的项目、知识库内容——记忆会自我纠偏，早期误存的内容在后续合并中被洗掉。

再加两道兜底：每日流水、归档目录、隔离备份各有保留天数，到期的物理清理；MEMORY.md 保留最近若干份版本快照，支持一键恢复。恢复本身也会留一个回滚点，避免「恢复错了就没法回头」。

五、怎么防脏：入库前净化

记忆是会被注入 system prompt 的，一旦写进手机号、身份证号或敏感词，后续每一轮都会把它带给模型。所以写入前有一道净化：命中 PII 或敏感词的内容不进主记忆，原文进隔离目录并留审计，隔离文件按保留期清理。

这一步的取舍要说清楚：净化是阻断入库，不是事后脱敏。记忆里没有这条信息，模型后面也就不会「记得」它——对个人信息场景，这是刻意为之的损失。

六、关掉之后：两个开关，两种语义

平台提供全局与专家两级开关，但两者作用范围不同，必须分开理解：

• 全局关闭：不注入记忆、不自动抽取，等于回到「无记忆」状态。
• 专家关闭：该专家不装配记忆配置，不注入、不写自己的记忆。

这里有个容易误解的边界：专家的对话仍会被会话级抽取写进入口智能体的记忆。因为抽取是按会话走的，归属是入口智能体，而不是某次专家调用。所以「关闭专家记忆」准确的含义是「这个专家不用记忆」，而不是「这个专家的对话绝不会沉淀」。如果产品口径要求后者，需要在抽取侧按来源过滤，而不是只加一个开关。

另一条纪律是工具面最小化：框架自带的记忆写入工具全部不注册，只保留只读检索（memory_search / memory_get）。记忆只走「平台抽取 + 平台合并」这一条通路，模型没有直接改写记忆的能力——否则一次提示词注入就能永久污染用户画像。

七、验证与开源

这套链路在仓库里有四层端到端断言，都对着运行中的栈发真实请求：

• 生命周期：记忆落盘 → 净化 → 合并 → 水位推进 → 配置护栏；
• 只读检索：memory_search 能命中写入的事实，且写类工具不出现；
• 分批合并：超预算流水被拆成多批，合并后无剩余；
• 版本恢复：手动快照 → 恢复 → 回滚点保留且正文一致。

BizBuddy 托管在 Gitee，代码与文档同步开源，同一套代码并列支持 PostgreSQL 与 MySQL 两套部署形态，记忆链路的脚本随仓库提供，可在自己环境复跑。

仓库地址：https://gitee.com/zl3624/biz-buddy

记忆做得好不好，不看存了多少条，而看三件事：该记的记没记住、不该记的有没有混进来、关掉之后是不是真的不生效。