★ FEATURED ARTICLE 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 踩坑实录动态记忆落地后最常修的五个问题换个说法这一节是问题速查表列的是我实际踩完后记录下来的高频问题新手照着这个表排查能省很多时间。症状常见原因解决办法模型回答前后不一致同一件事每次说法不同长期记忆没有被确认机制统一多条矛盾记忆同时注入增加冲突检测最近事件优先只注入合并后的结论上下文 token 消耗暴涨预算控制没生效组装器把高分记忆全塞进去了强制设置总预算打分排序后按预算截断用户隐私删除请求难以执行记忆散落在事件日志、向量库、数据库多处所有记忆保留来源事件 ID按用户维度统一删除新用户冷启动阶段效果特别差记忆为空组装器拿不到任何可注入的事实冷启动时注入少量通用任务提示不做过度检索检索出来的记忆与当前任务完全无关只用了向量相似度没有加任务类型过滤在记忆写入时打上任务标签组装时按标签过滤这里有个容易被忽略的细节记忆删除不能只删向量库里的向量。只要关联的事件日志还在下次重放日志又会生成同样的记忆。我在第一版就踩过这个坑后来统一在写入记忆时记录source_event_id需要删除时从事件层一路删到语义记忆层才把“遗忘”彻底落地。5. 记忆层值得被单独做成服务也值得再往后走一步做到第四步你的 Agent 已经从“静态快照”进化到了“动态上下文”。但这件事做到一半时我最大的体会是记忆不应该只作为框架里的一个插件存在它更适合被拆成独立服务。理由很简单Agent 的记忆读写是跨会话、跨模块的如果每个框架都有一套自己的记忆实现换模型、换编排层时你会把记忆逻辑重写一遍。把记忆做成服务之后事件日志、记忆抽取、上下文组装都可以独立升级也不会拖累主流程的迭代速度。5.1 别一上来就上向量库先用结构化存储顶住很多人在做记忆时第一反应是引入向量数据库。我的建议是除非你的场景真的需要大规模模糊检索否则先用结构化存储。原因很简单向量检索的开销和维护成本一开始不划算而 Agent 长期记忆里真正高频使用的是用户偏好、事实确认、任务状态这些完全可以用结构化字段表达。一开始用 SQLite 或者 PostgreSQL 存事件和三元组跑一段时间再根据检索瓶颈决定是否引入向量索引会是更平滑的路径。我自己在这个问题上走了弯路第一版直接把所有对话丢进向量库看起来什么都存了实际什么都取不准。后来改成结构化记忆加元数据过滤效果反而更好。向量检索适合补充语义相关度不适合承载整个记忆系统的核心逻辑。5.2 给初次上手的开发者一个最稳妥的起步方式如果你现在正准备重构自己的 Agent 项目我建议不要一开始就做完整的三层架构。先把原来的摘要逻辑替换成事件日志给记忆加上衰减和确认规则再用最简单的上下文预算做截断。这套组合拳大概一周内可以完成跑过一轮真实用户测试后你会很清楚自己最需要哪一层。然后再把语义记忆库做起来最后再优化组装器。另外一个小技巧记忆抽取不要每个事件都调用大模型成本会很快失控。批量处理或者只抽取关键事件剩下的保留原始事件日志到组装时按需使用就行。很多看似高级的记忆更新其实不需要模型参与用规则就能完成。5.3 我最后想多说一句项目走到动态上下文这一步并不意味着你可以高枕无忧。记忆是一个持续打磨的模块模型的上下文策略在变用户的使用习惯也在变。即便架构已经稳定我仍然建议定期回看事件日志检查哪些记忆长期没有被使用哪些偏好反复被用户纠正。记忆系统不是越复杂越好它永远应该在“保存足够多”和“遗忘得足够准”之间找平衡。把记忆当作一段有生命周期的状态去维护而不是一份写死的历史文档Agent 的使用体验就会自然上一个台阶。
阅读完成 · 觉得有帮助？
