AI Agent 记忆系统：从人类大脑那里学到的设计课

大语言模型有个天然缺陷：它没有记忆。会话窗口一关，它就把你忘得干干净净；多 Agent 协作时更是各干各的，A 客服刚问清楚的客户情况，转头 B 账单 Agent 又要重新问一遍。这不是模型智商问题，而是架构问题——上下文窗口是有限的短期记忆，真正缺的是一套持久、可管理、可检索的记忆系统。

这个问题的灵感来源，是 Dev.to 上一位开发者 lng_l_95dcf5de35ba45ef 的实战文章 I modeled AI agent memory on the human brain. Here's what worked and what didn't。他从零造了一个叫 Agent Brain Hub 的共享记忆中枢，让多个 Agent 共用同一套记忆，并刻意用人类大脑的分区来组织这套系统——丘脑、杏仁核、海马体、小脑……这篇文章最大的价值不是那个开源项目本身，而是作者老老实实记录的"哪些设计有效、哪些踩了坑"。本文就从这篇文章出发，再结合 mem0、Claude Code 等业界方案，聊聊 Agent 记忆系统到底该怎么设计。

先声明一点：大脑只是一个组织记忆系统的隐喻，不是神经科学教程。用隐喻的好处是，它逼着你回答记忆系统的几个关键问题：新信息进来走什么流程？什么值得记住？什么时候忘记？矛盾了听谁的？这些正是记忆系统的本质问题。

一、把大脑分区映射到记忆系统：各分区到底干什么

作者把记忆请求的全链路拆成十来个"脑区"，每一步职责清晰。翻译成工程语言，核心其实就是记忆的生命周期：编码（encode）→ 存储（store）→ 提取（retrieve）→ 巩固与遗忘（consolidate/forget）。我们把原文的脑区映射成一张工程师看得懂的表：

丘脑（Thalamus）——输入路由：收到输入后先做语言识别、意图分类、决定交给哪个 Agent 处理。工程上就是请求预处理和路由层。
脑干（Brainstem）——安全过滤：PII（个人隐私信息）脱敏、危机信息拦截，任何内容在入库前先过安全关。这是真实生产系统必须有的，但经常被教程省略。
杏仁核（Amygdala）——显著性评分：紧急程度和情绪强度决定记忆优先级。对应到系统里，就是"这件事值不值得记"的评分函数——用户愤怒投诉的优先级，天然高于闲聊。
海马体（Hippocampus）——编码写入：每轮对话后把新信息编码成记忆。这是记忆系统的写路径。
前额叶皮层（Prefrontal cortex）——工作记忆：当前会话的上下文，对应模型的上下文窗口。
新皮层（Neocortex）——长期记忆：事实和事件分冷热三层存储（hot/warm/cold），外加矛盾消解。这里对应了向量数据库 + 冲突处理逻辑。
RAS（网状激活系统）——检索管线：按范围过滤、TTL 过期、混合评分、重排、token 预算。这是读路径，而且是可观察的多阶段管线，不是一句"调用向量检索"糊弄过去。
小脑（Cerebellum）——技能库：一个 playbook 在 7 天内成功 3 次才晋升为可复用的技能，版本化管理，可回滚。这是"经验"层面的记忆，而非事实层面。
基底神经节（Basal ganglia）——行动选择：用 Thompson 采样（一种多臂赌博机算法）在多个候选行动里选下一步。这是在处理"探索 vs 利用"的权衡。
胼胝体（Corpus callosum）——Agent 间交接：多 Agent 共享记忆时的事实交接协议。
遗忘与默认模式网络——睡眠循环：离线时跑衰减、巩固、反思。对应离线批处理任务：旧记忆降权、重复记忆合并、从经验里提炼规律。

这张映射的真正价值在于它提醒我们：记忆不是一个数据库，而是一套治理机制。存储只是最不起眼的一环，决定系统成败的是"记什么、怎么记、怎么找、什么时候忘"这一整套策略。这正好呼应了业界越来越明确的一个判断：记忆不是存储问题，是治理问题。

二、什么有效、什么踩坑：原文最值钱的部分

作者列了四个"做对了"的设计和四个"搞砸了"的教训。这部分最实在，因为是真刀真枪跑生产后总结的。

有效的四个设计

1. 从第一天就做作用域（scope）和审计日志。 每条记忆都标注 private / shared / global 三级可见性，每个 Agent 有读写权限，所有读、写、被拒绝的访问都进不可篡改的审计日志。作者原话大意是：没有这套东西，"共享记忆"只是多了几个步骤的数据泄露。这点对国内很多想做多 Agent 客服的团队是当头棒喝——共享记忆和权限治理是一体两面，不能先裸奔再补课。

2. 同类事实只允许一个写入者（one writer per kind of fact）。 维修领域的事实只由维修 Agent 写，旅行目的地只由旅行 Agent 写。这消灭了一整类"多个 Agent 互相覆盖对方写入"的问题。工程上这就是写权限按事实类型划分，简单、粗暴、有效。

3. 检索管线可视化。 把召回拆成作用域过滤、TTL、评分、重排、token 预算五个阶段，每一步在 trace 里都能看到，排序 bug 一下子就现形了。很多团队把 RAG 检索当成黑盒，效果不好就调 embedding 模型，实际上问题往往出在某个中间阶段——比如 TTL 没配，三年前的旧事实还在被召回。

4. 技能靠"战绩"晋升。 一个 playbook 只有在 7 天内成功 3 次才晋升为技能，每个版本都保留，坏的晋升可以回滚。这解决了经验记忆的核心难题：怎么区分"偶然成功"和"可靠方法"。阈值（3 次/7 天）可以调，但"用证据说话、保留回滚能力"这个原则放之四海皆准。

踩的四个坑

1. 私有数据从侧门泄露。 主检索路径尊重了作用域，但私有细节通过最近几轮对话、Agent 交接摘要、睡眠时的反思总结，悄悄流到了其他 Agent 那里。教训：每条构建 prompt 的路径都需要同样的可见性过滤，不只是主检索路径。做权限的人都懂：访问控制最难的不是主路径，而是所有旁路。

2. 跨语言关键词匹配是个陷阱。 越南语"cửa sổ"（窗户）去掉声调符号后，和关键词"sợ"（害怕）撞上了，于是座位偏好被误判成焦虑情绪。修复方法是输入带声调就保留声调匹配、用词边界，日语因为没有空格改用子串匹配。这个教训对做多语言 Agent 的团队价值千金：文本归一化（normalization）做得越多，语义丢失得越多，检索前的预处理每一步都要问"这一步会不会吃掉有意义的信息"。

3. 探索算法太"急"。 Thompson 采样偶尔会让一个不相关的行动靠运气抽中胜出，收窄探索范围后解决。这提醒我们：学术上优雅的 bandit 算法，落地时要加护栏——探索必须围绕相关性做，不能无约束乱试。

4. 规则和 LLM 互相打架。 规则引擎和 LLM 从同一条消息里各抽出一个事实，单值事实就有了两个值。现在的做法是写入前先合并去重。这是个普遍问题：任何"双通道抽取"（规则+模型）都必须有一个显式的合并仲裁层，不能指望两边天然一致。

作者还诚实地列了局限：embedding 用的是本地特征哈希（feature hashing），离线能跑但效果不如真正的 embedding 模型；事实抽取是规则+可选的 LLM；单进程 SQLite，规模上去要换 PostgreSQL + pgvector。这种"能跑但有上限"的诚实，比很多宣称"生产就绪"的项目靠谱得多。

三、业界方案对照：mem0 和 Claude Code 的记忆观

大脑隐喻给的是设计框架，业界方案给的是经过验证的工程取舍。看两个代表：

mem0：记忆即"事实抽取 + 对账"管线。 mem0 是目前最流行的 Agent 记忆层，据公开资料，它的写路径是四步：Extract（用 LLM 从对话里抽离散事实，而非存整段聊天记录）、Store（向量库 + 键值 + 知识图谱三层混合存储）、Reconcile（新事实和已有记忆对账，决定 ADD 新增、UPDATE 更新、DELETE 删除被推翻的、NOOP 无变化）、Retrieve（检索时跨三层混合搜索，只取相关记忆注入 prompt）。最值得借鉴的是 Reconcile 这一步——它直接解决了"用户说'其实我搬到班加罗尔了'"这类事实变更问题。没有对账机制的记忆系统，跑几周就会变成自相矛盾的垃圾场：旧地址和新地址并存，Agent 随机抽一个用。这和大脑隐喻里的"矛盾消解"（新皮层）是同一个问题，mem0 给了工程解法。

Claude Code：文件即记忆，索引即治理。 Claude Code 的记忆机制走的是另一条路：项目级的 CLAUDE.md（每次会话启动加载，视为权威指令）+ 按项目分的 ~/.claude/projects/<hash>/memory/MEMORY.md（自动记忆，存稳定模式、架构决策、用户偏好），再加 # 快捷指令随时追加记忆。据公开资料，它的写入纪律很值得抄：只存被多次交互确认的稳定模式，不存会话临时状态、不存未经验证的推论、不存与 CLAUDE.md 重复的内容；MEMORY.md 本身只是索引（建议 200 行以内），详细内容分文件存放。这本质上是"大脑隐喻"里海马体编码 + 睡眠巩固的人工版本：不是什么都记，而是只记经得起时间考验的东西，并且保持索引精简。

把三者放在一起看，一个清晰的共识浮现了：

写路径必须有"值不值得记"的判断（显著性评分 / LLM 抽取 / 稳定模式确认），不能全量存聊天记录。
必须有冲突处理（one writer / Reconcile 对账 / 合并仲裁），否则记忆随时间腐烂。
必须有遗忘机制（TTL / 冷热分层 / 索引行数上限），记忆系统的敌人是膨胀。
权限和审计不是可选项（scope + audit log），尤其在多 Agent 共享记忆时。

四、落地建议：从零搭建记忆系统的最小可行方案

如果你现在要给自家 Agent 加记忆，不必一上来就复刻整套"大脑"。按优先级，我建议分三步走：

第一步：先把"记住事实"跑通（1-2 周）。 用 mem0 这类现成记忆层，或者自己实现一个最小管线：每轮对话后调 LLM 抽取事实（用户偏好、实体、决策三类），存进向量库 + 关系库，检索时按用户/会话作用域过滤后注入 prompt。这个阶段的目标是让 Agent"跨会话记得住用户是谁"。

# 记忆写入/检索的最小管线（伪代码）
def on_turn_end(user_id: str, messages: list):
    facts = llm_extract(messages, schema=["preference", "entity", "decision"])
    for f in facts:
        action = reconcile(f, store.search(user_id, f.text))  # ADD/UPDATE/DELETE/NOOP
        if action != "NOOP":
            store.write(user_id, f, scope=classify_scope(f))  # private/shared/global

def on_turn_start(user_id: str, query: str) -> str:
    hits = store.search(user_id, query, top_k=5, ttl_filter=True)
    return build_prompt_block(hits, token_budget=1500)  # 只注入相关记忆

第二步：加上治理（第 3-4 周）。 事实类型划分写入者、加 TTL 和冷热分层、检索管线分阶段可观测、审计日志。这是决定系统能跑三个月还是三年的分水岭。特别注意原文的教训：所有构建 prompt 的旁路（交接摘要、离线反思）都要过同一套可见性过滤。

第三步：经验层和离线巩固（按需）。 当事实记忆稳定后，再考虑技能晋升机制（成功 N 次才固化为 playbook，可回滚）和离线睡眠循环（合并重复记忆、提炼规律、衰减旧记忆）。这一步之前，先回答一个问题：你的 Agent 每天产生的经验，真的多到需要自动化巩固吗？很多团队在这一步过度设计。

还有三条红线，来自原文的坑和业界共识：一，多语言场景下，检索前的文本归一化每一步都要做"语义损失"检查；二，规则和模型双通道抽取必须有合并仲裁层；三，探索类算法（bandit、采样）上线必须加相关性护栏，别让"运气"决定生产行为。

结论：隐喻是脚手架，治理是地基

回到开头那篇 Dev.to 文章。它最打动我的不是"用大脑分区命名模块"这个创意——说实话，名字叫什么不重要，叫 pipeline stage 也一样跑。真正有价值的是两点：第一，它用隐喻逼着自己把记忆的完整生命周期想清楚，而不是只做"存进去、搜出来"；第二，它诚实地记录了四个坑，尤其是"私有数据从侧门泄露"和"跨语言匹配陷阱"这种只有真跑生产才会遇到的问题。

如果你只从这篇文章带走三句话，我希望是这三句：记忆不是存储问题，是治理问题——记什么、谁能写、矛盾听谁的、什么时候忘，这四件事决定了记忆系统的寿命；共享记忆必须从第一天就做作用域和审计，否则就是换了个名字的泄露；检索必须是可观察的多阶段管线，黑盒检索调优纯属碰运气。

大脑花了几亿年进化出这套机制，我们当然可以直接抄它的"需求文档"——但别忘了，我们抄的是需求，不是实现。工程上最终落地的，还是一套朴素的管线：抽取、对账、作用域、检索、遗忘。把这五件事做扎实，你的 Agent 就不会再每次会话都从零开始了。

本文灵感来源：I modeled AI agent memory on the human brain. Here's what worked and what didn't（Dev.to），原文项目 Agent Brain Hub 开源在 GitHub（MIT 协议）。业界方案事实部分参考 mem0 与 Claude Code 的公开文档整理，细节以官方文档为准。