Agent记忆重构：从静态摘要到动态上下文的工程实践

1. 为什么 Agent 的记忆会成为瓶颈

做 Agent 应用的前半年，我被同一个问题反复折腾了无数个晚上：记忆。模型能力再强，只要对话一长，它就会把五分钟前说过的结论忘掉；用户第一次交代的偏好，到第四轮就被淹没在历史文本里。后来我接触了不少开源 Agent 框架，发现这个问题几乎是通病，才意识到症结不在模型，而在“记忆”这一层到底是怎么设计的。于是我把目标从“调大上下文窗口”改成了“重新设计记忆系统”，也顺着这个方向看了很多同行的方案。标题里那句“从静态记忆到动态上下文”，本质上就是在讲这两年 Agent 工程化绕不开的一次重构。

我最早做的一个客服类 Demo，用的是最简单的方式：把用户历史对话转成摘要，塞进每次请求的系统提示词里。听起来没毛病，跑起来处处是坑。用户刷新页面后问了一句“上次那个订单处理到哪了”，Agent 一脸茫然；用户纠正过一次称呼习惯，后面每轮又变回旧说法。原因很清楚：摘要是一种“静态记忆”，它是会话结束时或者固定时间点生成的一张快照，而不是随着交互持续更新的状态。你往提示词里塞的只是过去的投影，不是真正可读、可改、可失效的记忆。

这不是某一个框架的问题，而是所有把“记忆”简单等同于“摘要 + 向量检索”的项目都会遇到的问题。我自己的实践和社区里很多方案最后都收敛到了同一套思路：把记忆拆分成事件、结构化事实、上下文组装三个阶段，让每次请求看到的都是系统按当前需求动态拼出来的上下文。这篇文章就把这套思路完整拆开，讲讲为什么要从静态走向动态，以及具体应该怎么落地。

1.1 记忆不是模型能力问题，而是系统设计问题

很多人觉得 Agent “记不住”是因为模型不够聪明，换一个更大参数量的模型就能解决。我踩过这个坑之后可以明确告诉你：不可能。上下文窗口再大，也是有上限的；就算窗口大到能塞下全部历史，模型在处理后面的任务时也很难对前面埋下的每条细节给予同等关注。这有点像人的注意力，你不可能一边回忆三年前的旅行细节，一边流畅地帮用户填今天的报销单，所有记忆在接收时都经过筛选和分级。

真正的问题出在系统设计。你给模型喂的上下文越原始、越混杂，模型就越容易抓错重点。一个合理的记忆系统至少要做三件事：记录发生了什么、提炼出值得长期保存的结论、在每次请求前决定哪些信息值得被放进上下文。静态记忆方案普遍只做了第一件事，或者只做了第一件和第二件事的粗糙版本，偏偏跳过了最关键的第三件事。动态上下文要解决的，正是“模型应该看到什么”的问题。

1.2 静态记忆和动态上下文到底差在哪

我见过不少团队把“把历史存进向量数据库再检索”叫做动态记忆，这是个很大的误解。向量数据库只是一个检索工具，它不会自动帮你判断某条信息是否过期、是否和当前任务有关、是否重要到值得占用 token。真正的动态上下文，指的是记忆系统能随着交互实时更新，并且每次新请求到来时都重新计算一次上下文内容。

我在本地跑过一个对比实验。同样是记住用户的三个偏好，静态方案在对话前二十轮表现尚可，三十轮之后开始频繁出错，原因是早期塞进去的偏好被后面新增的零散信息稀释了。动态方案则在每一轮结束后把新提炼的偏好写进结构化存储，下一次对话直接基于最新状态组装上下文，没有明显衰减。实验不复杂，但结论让我把整个项目重写了一遍：记忆不是存储问题，更新机制才是核心。静态方案省的是开发时间，赔的是 Agent 的长期可用性。

1.3 与其重启对话，不如换一种记忆写入方式

社区里有个说法我很认同：整个 Agent 行业目前还没到拼模型推理能力的阶段，先在“记忆”上补齐差距的团队会领先一个身位。那些经常被拿来对比的开源框架，默认实现大多还是“固定角色设定 + 对话历史摘要 + 向量检索补充”，这种设计在短会话里很稳，一旦进入需要跨天、跨任务、持续学习用户偏好的场景，立刻露馅。

我后来把记忆相关逻辑单独拆出来，做了事件日志、语义记忆库和上下文组装器三个模块。拆完以后，原先那些“记不住”“张冠李戴”“被旧信息带偏”的问题，大部分变成了可以定位、可以测试、可以回滚的普通 Bug，而不是玄学级别的模型问题。这也是我特别想把静态和动态这条分界线讲清楚的原因：不是所有记忆问题都需要用更贵的模型解决，很多时候只是写入和读取的姿势不对。

2. 静态记忆的三宗罪：为什么固定方案会被推翻

静态记忆不是没有优点，它实现成本低，逻辑直观，很多产品在上线初期靠它就能跑通闭环。但只要你把 Agent 放到真实用户面前，让它连续服务几周，静态方案的问题就会一批批浮出来。我总结下来有三个最要命的地方，基本覆盖了我在不同项目里踩过的所有坑。

2.1 快照式注入：所有旧信息一开始就占满窗口

第一种典型做法是把用户画像、历史摘要、过往结论拼成一大段文字，放在每次请求的头部。这种快照式注入的最大问题是：信息密度低，而且顺序不可控。想象一下，用户上次和你聊了三十轮，最后确认了一个收货地址；结果下一次对话开场，系统提示词把“用户第一次提到喜欢蓝色”“第三次提到不喜欢打电话”“第七次提到地址是某小区”全部平铺出来，模型分不清哪条才是重点。

更麻烦的是，快照一旦生成就固定了，中间任何一次对话都不会改变它的内容。你只能在会话结束之后重新生成一份新的摘要，相当于把记忆更新完全寄托在“事后压缩”这件事上。我在测试中经常看到同一份摘要被反复注入，其中已经过时的偏好仍占据宝贵的 token 空间。上下文窗口不是无限大的，开头塞了三万字的旧历史，当前这轮用户真正需要的信息反而挤不上车。

2.2 向量检索被当成记忆，却没有优先级概念

后来很多项目为了避免快照膨胀，改成把历史文本向量化，每次根据当前问题做相似度检索。这个方向比快照先进一点，但离“记忆”还很远。向量检索擅长处理语义相似的模糊召回，它不在乎这条信息是用户十分钟前刚说的，还是三个月前早就推翻的旧设定。它也不在乎这条信息重要不重要——所有向量在检索空间里只是距离远近的区别，没有权重大小之分。

我在一个真实场景里看得特别清楚：用户曾经说过“我不太吃辣”，三个月后又说“最近迷上了湘菜”。如果只做向量检索，两条信息都会被召回，模型拿到两条互相矛盾的记忆，大概率会给出含糊其辞的回答。而一件重要的事实，比如用户的紧急联系电话，在向量空间里的位置未必离当前问题很近，很容易被漏掉。检索层解决的是“找得到”的问题，优先级、时效性、一致性需要专门设计，这已经超出普通向量数据库的能力范围了。

2.3 只增不删：记忆污染比失忆更可怕

静态记忆最常见的结局是只增不删。每轮对话都往历史里追加，向量库里不断写入新文档，旧文档从来不会被合并、修正或删除。时间一长，记忆库里充满了互相矛盾的陈述和毫无价值的闲聊，系统信噪比直线下降。我遇到过最离谱的一次，是 Agent 把用户在某次测试会话里随口说的假地址当成了长期记忆，之后整整两周都在错误的地址上做推荐。

真正需要保存下来的信息其实只有几类：用户明确表达的偏好和事实、任务执行过程中的关键状态、需要跨会话延续的长期目标。至于“今天天气不错”“这个页面加载有点慢”这类瞬时内容，根本不值得进入长期记忆。静态方案不懂得筛选，又不懂得遗忘，结果就是记忆库越大，取出来的内容越没用。动态上下文的核心之一就是给记忆建立生命周期，允许信息进入、更新、合并、失效，再通过组装器决定哪些信息在哪个时刻可见。

3. 动态上下文的解法：记忆拆成三层，上下文按需组装

在参考了社区里各种方案、也重构过自己项目之后，我把动态记忆的实现收敛成三个层。简单来说就是：遇到任何对话事件，先原样记录；然后从中提炼值得长期保存的结构化事实；每次请求前，再根据当前任务、当前时间和当前上下文预算，把最相关、最重要、最新鲜的记忆组装出来。这套分层拆开之后，每个环节都可以独立优化。

3.1 事件层：先有不可变日志，再有记忆

第一层被称为事件层，它对应的是“事实本来的样子”。我不建议让系统直接拿原始对话当长期记忆长期保存，也不建议一上来就提取抽象总结。更稳妥的方式是先保存结构化的事件日志，至少包含几个字段：事件发生的时间、会话 ID、主体、谓语、对象，以及事件所属的任务类型。用户说“我下个月要去上海出差”，你可以把这些信息拆成主体“用户”，谓语“计划前往”，对象“上海”，时间“下个月”。

事件层的设计原则是序列化和不可变。每条事件只追加，不覆盖，因为后续所有记忆更新都依赖对历史事件的追溯。事件日志本身不承担回答问题的职责，它更像一个原始数据仓库，专门给上层做合并、冲突检测和统计。这个设计能解决静态方案里很常见的“旧信息被直接覆盖导致无法回溯”的问题：就算用户更新了偏好，旧偏好的历史事件依然存在，只是不再进入最终的上下文组装。

3.2 语义记忆层：让 LLM 把对话沉淀成结构化事实

第二层是结构化记忆库，也就是真正意义上的长期记忆。它由一组事件触发后异步生成，通过模型从原始事件中提炼出值得长期保存的结论。比如事件层记录了“用户提到不喜欢电话沟通”，语义记忆层就会生成一条偏好记录：沟通方式偏好为文字消息，来源事件编号是多少，置信度多少。如果后续又发现了几条类似事件，置信度会上升，这条记忆就会在上下文中占据更重要的位置。

这一层最关键的是不要直接保存模型生成的整段摘要。摘要太模糊，更新和删除都不方便。我更推荐保存成类似“subject-predicate-object”三元组的结构，再附带时间戳、来源事件 ID 和置信度。这样当新事件与旧记忆冲突时，你可以明确判断应该合并、覆盖还是新增一条并列记录。动态上下文并不是每轮都把所有记忆塞给模型，而是在组装时才计算哪些记忆适合出现。

3.3 上下文组装层：用预算和权重决定系统提示词里放什么

第三层是我认为最接近“动态上下文”本质的部分。它和传统 RAG 最大的区别在于：不是简单检索 Top-K 就往提示词里塞，而是先给上下文设置一个明确的 token 预算，然后按任务类型、相关性、重要性、新鲜度、置信度等多个维度打分，最后挑选出信息量最高的一组记忆，按合适的位置拼接。

我在一个项目里用的是非常朴素但有效的打分公式：

score = ( 0.40 * similarity + 0.25 * importance + 0.20 * recency_decay + 0.15 * confirmation )

其中similarity来自向量检索引擎对当前问题的语义相似度，importance是记忆写入时模型给出的一个重要度标签，recency_decay是一个随时间衰减的函数，confirmation是这条记忆被确认或重复的次数。每次请求到达时，组装器从记忆库中挑出得分最高的一组，再加上最近几轮的工作记忆，统一放进 token 预算内。这样模型看到的上下文每次都不一样，但都是针对当前场景最优的一组记忆。

4. 落地方案：从静态快照迁移到动态上下文的四步

很多人看完前面的理论会觉得方向对，但不知道从哪里下手。下面是我自己迁移时走过的具体步骤，每一步都不复杂，做完一步就能看到一部分效果。这里我默认你已经有一个能跑通的 Agent 框架，只是用它提供的默认记忆方式。

4.1 第一步：把系统提示词里的固定摘要改成事件日志

第一步几乎零风险，就是把原先“每次请求塞摘要”的方式改成“对话内容先落事件日志”。你可以新建一张表，字段不需要多，够用就行：

CREATE TABLE agent_events ( id INTEGER PRIMARY KEY AUTOINCREMENT, session_id TEXT, ts TEXT, actor TEXT, predicate TEXT, object TEXT, metadata TEXT );

每次对话轮次结束后，把这一轮的关键动作整理成一条或几条事件写入表里。暂时不要用它替换原有的摘要逻辑，两者可以并存。这样做的目的是先保证数据不再丢失，同时也让你能回看 Agent 到底接触过哪些信息。我花了大概一个下午完成这一步，之后所有排查问题都比以前轻松很多，因为至少知道系统当时看到了什么。

4.2 第二步：为偏好和事实增加衰减、确认和冲突处理

第二步是给记忆建立更新规则。每一条长期记忆不能只在写入时是一份快照，它必须随着时间变化。我现在会用一个小任务来更新记忆：每当新事件写入，跑一次抽取逻辑，尝试匹配是否已有相同主体、谓语的记忆，如果有，比对对象是否一致。一致就把确认次数加一；不一致就触发冲突处理，以最近一次事件为准，同时保留旧事件供回溯。

衰减逻辑也很简单，不需要复杂公式。我可以给每条记忆设置一个last_confirmed_at时间戳，组装时用如下方式计算新鲜度：

hours = (now - last_confirmed_at).total_seconds() / 3600 recency_decay = 1 / (1 + hours / 168)

这里 168 是一周的小时数。我的经验是重要事实可以放宽到一个月衰减到很低，临时偏好则应该衰减得快一些。具体数字不是标准答案，但引入“衰减”这一动作，比永远不变要好得多。

4.3 第三步：用上下文预算控制注入顺序

第三步是处理上下文组装。先给系统提示词和记忆区分别划出预算。比如总预算 5000 token，核心指令占 800，长期记忆最多 2600，最近几轮工作记忆占 1600。不要试图把所有记忆都塞进去，那是静态思维。每次请求到达时，按前面那个打分公式选出一批记忆，再从事件日志里找出最近几条工作记忆，最后按“核心指令在头部、工作记忆紧跟其后、长时记忆放在末尾”的顺序拼接。

这个顺序不是随便定的。核心指令在最前面让模型不会迷失方向；工作记忆紧跟其后，保证当前对话的连续性；长时记忆放在后面，相当于给模型一份“参考资料”。我在 A/B 测试中发现，长时记忆放在中间容易被前后内容干扰，放在末尾反而提升记忆召回准确率，原因很可能是模型在生成时更依赖开头和靠近结尾的信息。

4.4 第四步：用三类指标验证记忆是否真的变“活”了

迁移完成之后要量化效果，我建议关注三类指标。第一类是事实召回率，准备一组用户明确说过的偏好，主动询问 Agent 并在回复中检查是否被正确提及。第二类是任务完成率，让 Agent 执行跨会话的多轮任务，比如“帮我安排两周后的行程”，统计在第三、第四次对话中是否还能记住细节。第三类是上下文利用率，观察每次请求实际注入多少 token，以及有多少 token 在最终回答中真正派上用场。

你会看到很有意思的结果：有些场景里，动态上下文只用了静态方案 60% 的 token，任务完成率反而提升了。原因很简单，旧信息不再凑热闹，模型注意力更集中了。如果做完前两步之后发现效果不明显，不要急着怀疑路线，大概率是抽取或打分有问题，回到事件日志里检查看看，是不是该记的没记进来。

4.5 踩坑实录：动态记忆落地后最常修的五个问题

换个说法，这一节是问题速查表，列的是我实际踩完后记录下来的高频问题，新手照着这个表排查能省很多时间。

这里有个容易被忽略的细节：记忆删除不能只删向量库里的向量。只要关联的事件日志还在，下次重放日志又会生成同样的记忆。我在第一版就踩过这个坑，后来统一在写入记忆时记录source_event_id，需要删除时从事件层一路删到语义记忆层，才把“遗忘”彻底落地。

5. 记忆层值得被单独做成服务，也值得再往后走一步

做到第四步，你的 Agent 已经从“静态快照”进化到了“动态上下文”。但这件事做到一半时我最大的体会是：记忆不应该只作为框架里的一个插件存在，它更适合被拆成独立服务。理由很简单，Agent 的记忆读写是跨会话、跨模块的，如果每个框架都有一套自己的记忆实现，换模型、换编排层时你会把记忆逻辑重写一遍。把记忆做成服务之后，事件日志、记忆抽取、上下文组装都可以独立升级，也不会拖累主流程的迭代速度。

5.1 别一上来就上向量库，先用结构化存储顶住

很多人在做记忆时第一反应是引入向量数据库。我的建议是，除非你的场景真的需要大规模模糊检索，否则先用结构化存储。原因很简单：向量检索的开销和维护成本一开始不划算，而 Agent 长期记忆里真正高频使用的是用户偏好、事实确认、任务状态，这些完全可以用结构化字段表达。一开始用 SQLite 或者 PostgreSQL 存事件和三元组，跑一段时间再根据检索瓶颈决定是否引入向量索引，会是更平滑的路径。

我自己在这个问题上走了弯路，第一版直接把所有对话丢进向量库，看起来什么都存了，实际什么都取不准。后来改成结构化记忆加元数据过滤，效果反而更好。向量检索适合补充语义相关度，不适合承载整个记忆系统的核心逻辑。

5.2 给初次上手的开发者一个最稳妥的起步方式

如果你现在正准备重构自己的 Agent 项目，我建议不要一开始就做完整的三层架构。先把原来的摘要逻辑替换成事件日志，给记忆加上衰减和确认规则，再用最简单的上下文预算做截断。这套组合拳大概一周内可以完成，跑过一轮真实用户测试后，你会很清楚自己最需要哪一层。然后再把语义记忆库做起来，最后再优化组装器。

另外一个小技巧，记忆抽取不要每个事件都调用大模型，成本会很快失控。批量处理或者只抽取关键事件，剩下的保留原始事件日志，到组装时按需使用就行。很多看似高级的记忆更新，其实不需要模型参与，用规则就能完成。

5.3 我最后想多说一句

项目走到动态上下文这一步，并不意味着你可以高枕无忧。记忆是一个持续打磨的模块，模型的上下文策略在变，用户的使用习惯也在变。即便架构已经稳定，我仍然建议定期回看事件日志，检查哪些记忆长期没有被使用，哪些偏好反复被用户纠正。记忆系统不是越复杂越好，它永远应该在“保存足够多”和“遗忘得足够准”之间找平衡。把记忆当作一段有生命周期的状态去维护，而不是一份写死的历史文档，Agent 的使用体验就会自然上一个台阶。