发布时间2026-07-09标签AI AgentLLMMemory上下文工程工程实践系列导航上一篇AI Agent 工程实践02为什么 Rules 要分层下一篇AI Agent 工程实践04Review——为什么 AI Agent 必须每天复盘本文是 AI Agent 工程实践 系列的第 03 篇。给 Agent 加上记忆那天我以为它会变聪明。结果三天后它开始答非所问记得住我上周随口提的一句玩笑却忘了当前任务的关键约束。我一度以为是模型不行直到翻了它的上下文——里面塞满了几百条记忆真正有用的不到一成。问题不是它记得太少而是它什么都记于是什么都没记住。本文你将学到✓ 为什么给 Agent 加记忆经常让它更笨而不是更聪明✓ 短期 / 工作 / 长期 / 归档记忆到底该分几层各层边界在哪✓ 项目记忆 vs 用户记忆——为什么必须拆开混在一起会怎样✓ Memory 的完整生命周期什么时候写、什么时候晋升、什么时候清理适合阅读✓ 正在给 Agent / Copilot 做记忆功能的开发者✓ 用 Claude Code / Cursor / LangGraph 且被上下文越来越乱困扰的人✓ 对上下文工程Context Engineering感兴趣的人问题背景在 系列第 02 篇 里我讲了 Rules 怎么分层——那解决的是规则该在什么时候出现。这一篇讲一个更棘手的问题记忆该记什么、记多久。几乎所有 Agent 框架都在宣传我们有 Memory。教程也都在教你怎么把历史对话存起来下次再喂回去。听起来很美好——Agent 有了记忆就像人一样能积累经验。我照做了。然后遇到一连串问题上下文越来越臃肿。每开一次对话Agent 先回忆一大堆历史token 消耗蹭蹭涨响应越来越慢。关键信息被稀释。当前任务真正需要的那几条淹没在几百条陈年记忆里。模型的注意力被无关信息分走输出质量反而下降。旧信息污染新决策。上个项目用的是 FastAPI这个项目用 Flask可它记得FastAPI于是不停给我推 FastAPI 的写法。记忆之间开始打架。我三个月前说喜欢详细注释上周又说代码尽量精简。两条都被记着Agent 到底该听谁的一句话概括加了记忆Agent 没变聪明反而被自己的记忆拖垮了。这不是有没有记忆的问题是怎么管理记忆的问题——和 Rules 分层一样本质是规模问题。错误尝试第一次尝试什么都记全量回灌最朴素的想法把所有历史对话都存下来下次对话时全部塞回上下文。记得越多越聪明嘛。结果上下文迅速膨胀到几千 token 起步。更糟的是模型在长上下文里出现了典型的迷失在中间Lost in the Middle现象——放在开头和结尾的信息还记得夹在中间的关键约束直接被忽略。记得多 ≠ 用得上。第二次尝试只留最近 N 条滑动窗口既然全量太重那就只保留最近 20 条消息老的丢掉。简单粗暴。结果短期是清爽了但把这个项目用红涨绿跌配色这种说过一次、长期有效的关键约定也一起丢了。过几轮它又开始问配色用什么。滑动窗口砍掉的不是噪声是按时间一刀切而重要性和时间根本不成正比。两次尝试指向同一个教训记忆的问题不能用记多少来解决要用怎么分类、怎么流转来解决。关键观察我把 Agent 一周的上下文导出来做了个统计按这条信息在后续任务里被真正用到来分类记忆类型举例后续被用到的比例当前任务上下文正在改的文件、当前报错~95%项目级约定技术栈、目录规范、命名~70%用户长期偏好语言、代码风格、汇报格式~60%一次性事实某次临时路径、搜索结果~3%闲聊 / 情绪随口的玩笑、寒暄~1%pie title Agent 上下文里的信息价值分布 高频复用值得长期记 : 20 当前会话有用用完即弃 : 25 噪声记了反而添乱 : 55记住一切等于什么都没记住。超过一半的记忆是一次性的噪声把它们和真正的长期约定平等地塞进上下文就是在稀释注意力。定位真正原因问题不在记得多少而在所有记忆被平等对待、生命周期完全相同一次性的临时路径和这个项目用 Flask这种长期约定被存在同一个地方、同样长久地活着、同样默认加载。正确思路是给记忆分层让不同价值的信息走不同的寿命和加载策略短期记忆用完即弃长期记忆按需晋升噪声定期清理。这其实和上一篇的 Rule RAG 是同一个哲学不在推理时把所有东西硬塞给模型而是让对的信息在对的时候出现。Rules 管的是规则何时出现Memory 管的是记忆何时出现——两者都是上下文工程Context Engineering的一部分。最终方案四层记忆 生命周期我把记忆拆成四层每层有不同的存活时间和加载策略层级存什么生命周期是否默认加载Conversation对话层当前对话的原始消息流会话内session 结束即弃是但滚动裁剪Working Memory工作记忆本次会话提炼的关键状态、当前任务进度单次会话是精简版Long Memory长期记忆跨会话的持久约定项目记忆 用户记忆长期可更新按需检索Archive归档层冷数据、历史日志、过期记忆永久但压缩否仅显式检索信息在这四层之间单向流动 定期回收新信息先进对话层被判定为有长期价值才晋升到长期记忆长期记忆里过时的再降级到归档。长期记忆为什么要拆成项目和用户这是最容易被忽略、也最关键的一刀。很多 Agent 把两者混成一个大 memory于是换个项目就开始串味。项目记忆Project Memory只在当前项目生效。技术栈、目录规范、命名约定、这个项目特有的坑。换项目就不该带过去。用户记忆User Memory跟着人走、跨所有项目。语言偏好、代码风格、汇报格式、工作习惯。判据很简单问一句换个项目还成立吗成立的进用户记忆不成立的进项目记忆。我喜欢中文回复是用户记忆这个项目用红涨绿跌是项目记忆。分开存才不会拿 A 项目的约定去污染 B 项目。实际收益指标全量回灌分层 生命周期每次对话默认加载的记忆量全部历史数百条精简工作记忆 3 条常驻个位数换项目时的串味频繁旧栈污染新项目基本消除项目记忆隔离关键长期约定的存活易被滑动窗口误删稳定晋升到长期层上下文噪声占比~55%显著下降噪声不晋升数据来自主观经验估算不是严格 A/B Test但反映了分层前后的量级差异。架构图 / 流程图记忆的四层流动关键点越往下越持久、越精炼只有对话层是易失的其余都要落盘。晋升promotion是主动决策不是自动全存。记忆的生命周期状态流转图片多样性这里用了 Mermaid 的 pie / flowchart / stateDiagram 三种图实际发文时可再补一张 ProcessOn/draw.io 版的四层示意图进一步提升 CSDN 图片多样性得分。代码或配置示例记忆的目录结构我把落盘的记忆按归属组织一眼就能看出哪些跟人走、哪些跟项目走# 用户级跨项目跟人走 ~/.agent/ └── MEMORY.md # 用户长期记忆语言、风格、习惯 项目级仅当前项目 project/.agent/memory/ ├── MEMORY.md # 项目长期记忆技术栈、规范、约定精炼 ├── 2026-07-09.md # 每日工作日志append-only短期→归档 └── archive/ # 归档层过期日志压缩沉淀记忆管理策略YAML 配置用配置显式声明每层的寿命和晋升条件而不是让它们自然生长# memory-policy.yaml — 记忆生命周期策略 conversation: scope: session # 会话内有效 max_messages: 30 # 滚动裁剪超出丢弃 persist: false # 不落盘 working_memory: scope: session persist: false distill: true # 会话结束前蒸馏关键状态决定是否晋升 long_memory: project: # 项目记忆 scope: project # 仅当前项目生效 max_chars: 3000 # 超出触发蒸馏压缩 user: # 用户记忆 scope: global # 跨项目生效 max_chars: 4000 promotion: rule: reused 2 OR user_explicit true # 复用≥2次 或 用户明确要求 才晋升 archive: trigger: not_hit_days 30 # 30 天未命中 → 降级归档 compress: true ttl_days: 365 # 归档超期清理写入与晋升逻辑伪代码def on_new_info(info: Info, ctx: Context) - None: 一条新信息进来时的处理 # 1. 一律先进对话层 ctx.conversation.append(info) # 2. 与当前任务相关 → 提炼进工作记忆 if relevant_to_current_task(info, ctx.task): ctx.working_memory.upsert(info) def on_session_end(ctx: Context) - None: 会话结束时决定谁能活下来 for item in ctx.working_memory: if should_promote(item): # 复用≥2 或 用户明确要求 target user if is_cross_project(item) else project long_memory.write(item, scopetarget) # 关键分流到项目/用户 # 对话层直接丢弃不落盘 def cleanup(long_memory: LongMemory) - None: 定期清理去重、降级、蒸馏 long_memory.dedup() # 合并重复/冲突项保留最新 for item in long_memory.stale(days30): archive.move(item) # 长期未命中 → 归档 if long_memory.over_limit(): long_memory.distill() # 超出容量 → 蒸馏压缩代码不多但把三个动作说清楚了分流写入、按条件晋升、定期清理。这三个动作缺一个记忆迟早失控。设计权衡候选方案优点缺点为什么不选全量回灌历史实现最简单绝不遗漏上下文爆炸、迷失在中间、噪声稀释注意力记得多不等于用得上规模一大必崩滑动窗口只留最近 N 条上下文恒定、实现简单按时间一刀切误删长期约定重要性和时间不成正比砍错了对象全部塞向量库用时检索容量无上限、语义召回召回噪声多、无生命周期、冷热不分只解决存没解决该不该记、记多久四层 生命周期冷热分层、项目/用户隔离、可晋升可清理需设计晋升与清理策略选择理由唯一同时管住记什么、记多久、给谁的方案分层不是越多越好。如果你的 Agent 只是个单轮问答机器人压根不需要跨会话记忆——一个滑动窗口就够了。不要在不需要长期记忆的地方强行搭四层。向量检索也不是对立面它可以作为 Archive 层的召回手段和分层是互补而非二选一。总结✅ 记忆的问题不是记多少而是怎么分类、怎么流转——和 Rules 一样是规模问题。✅ 分四层Conversation易失→ Working会话→ Long持久→ Archive冷藏越往下越精炼。✅ 长期记忆必须拆项目和用户——判据是换个项目还成立吗否则必然串味。✅ 晋升是主动决策复用≥2 或用户明确要求不是自动全存。✅ 没有清理机制的记忆系统最终都会被噪声拖垮——去重、降级、蒸馏一个都不能少。参考资料Lost in the Middle 论文Liu et al., 2023→ 为什么长上下文里中间信息会被忽略直接决定了不能全量回灌的结论MemGPT: Towards LLMs as Operating Systems→ 用分层记忆 分页调度管理超长上下文本文四层模型的重要参照Anthropic — Claude 上下文与记忆管理文档待补链接→ 工作记忆与长期记忆分离的工程实践基础Generative Agents (Park et al., 2023)→ 记忆的重要性打分 检索 反思机制启发了本文的晋升与蒸馏设计PARA / Zettelkasten 知识管理法→ 用归属而非时间组织信息是项目/用户记忆拆分的方法论来源系列导航上一篇AI Agent 工程实践02为什么 Rules 要分层下一篇AI Agent 工程实践04Review——为什么 AI Agent 必须每天复盘