一位自称"做记忆的人"的工程师，把一套 agent 记忆方案逐条拆开做了评审，值得当模板看：这套方案把记忆做成版本化的、基于对象存储的 markdown 文件——人类也能直接读，部分信息显式更新，另一些通过反思系统合并沉淀，组织记忆与用户记忆分开存放，背景学习进程负责维护，主对话 agent 完全不碰记忆。
作者自己的同主题文章在 dhravya.dev/writing/memory… ，这次评审的对象则是另一篇公开的架构博客。
先说他给好评的五条。第一，方案不秀任何基准数字，重心放在业务结果上——记忆系统的价值本来就该用"回答得更准了吗"衡量，而不是用检索分数。第二，markdown 加版本化带来的是可观测：人能读懂、能审计，这在出了错要追责的场景里是硬需求。
第三，反思式合并让信息按设计保持新鲜，不用人工整理。第四，架构简单到几乎只剩对象存储，维护与托管的成本极低。第五，主 agent 与记忆解耦，记忆由独立的背景进程维护——这与"让干活的模型顺手记东西"的常见做法正好相反，职责切得干净。作者在文末补的那句定性也一致：主 agent 不该同时负责记忆。
批评的部分更能当评估清单用。最大的隐患是把全部用户与组织记忆直接塞进上下文：一个上千条事实的组织，读写都要带着整套记忆跑，写入成本更是指数级——每次写之前都得先读一遍全部。其次的几条同样扎在要害：版本按文件切而不是按知识单元切，跳版本时无从定位；没有矛盾检测机制，两条冲突的事实可能并存；"某事发生在昨天"这类时间性问题没有归属，日期挂在文件而非知识点上；事实没有来源标注，回溯时无法验证；摘要环节可能丢掉关键细节，等于把宝全押在反思模型记得住；旧信息也没有时间衰减或失效机制，多年前的结论和最新事实享受同等权重。
把好坏两侧合起来，记忆系统的设计其实收敛到三块试金石：可读性——人能不能打开看懂，出错能不能追；时间性——知识有没有"新旧"的概念，冲突能不能被发现；归因性——每条事实能不能回到出处。这套方案赢在可读与简单，输在时间与归因，而规模天花板正是从后两者漏出来的。
横向看，当下 agent 记忆的实现大致分三派。第一派把记忆全塞上下文，实现最省事，上限也来得最快——千条事实的组织根本装不下。第二派把记忆交给向量检索，按需取回，规模问题迎刃而解，代价是可读性骤降：人打不开也审计不了，取错了哪条无从知晓。
第三派是这篇评审的方案，站在可读这一端——文件即记忆、版本即历史，用存储的简单换来了透明。三派各自只守住一块试金石，真正难的是同时守住三块：把向量索引与人类可读的文件层做双写、给知识点挂上时间戳与来源、在写入路径上做矛盾检测，每一项都要额外的工程，但每一项也正对应清单上丢分的那条。
时间性与归因之所以是规模的天花板，原因很直接：记忆越长，冲突与过期越多。一个小团队的几十条事实靠反思合并还能兜住，上千条之后没有时间衰减的系统会开始引用作废的结论，没有来源的系统会在一次错误回答后无法定位是哪条记忆在撒谎——两者的共同结果是用户对整套记忆失去信任，而信任一旦丢掉，再准确的记忆也不会被采纳。
这套方案把问题坦白写在明处，反而给评估留了最好的起点：能被批评到这个颗粒度的设计，才说明它真的被认真用过。
给正在选型或自建记忆层的团队一张可执行的清单：先估算上下文占用曲线——记忆翻十倍时，读写分别涨多少；再查版本粒度是否到知识单元、有没有矛盾检测、旧事实会不会过期、事实有没有来源字段。五问里任何一个答不上来，就先在小团队范围内跑，别急着让全组织的记忆都走这一条链路。记忆是 agent 用得越久越值钱的资产，也正因为如此，它坏起来的方式最隐蔽。
