AI Agent 为什么必须有“记忆系统”？
导语：大模型不是没有智商，而是经常没有“记性”。真正能长期干活的 Agent，不是靠无限拉长上下文，而是靠一套会压缩、会检索、会遗忘、会治理的外置记忆系统。
一、先给结论：Agent 的记忆系统，本质是“上下文工程”
很多人做 AI 应用，第一反应是：模型上下文窗口越来越长了，是不是把所有历史都塞进去就行？答案是否定的。上下文窗口再长，也不是垃圾桶。它会带来三类问题：成本变高、延迟变长、噪声变多。更麻烦的是，长文本里真正关键的信息不一定被模型稳定抓住。研究“Lost in the Middle”指出，相关信息在长上下文中间位置时，模型表现可能明显下降。
所以，真正成熟的 Agent 系统，必须把“记忆”从一句抽象口号，拆成四件能落地的工程能力：
记什么：把短期任务状态、用户偏好、项目知识、历史经验分层存储。
怎么压缩：把长聊天和工具日志压缩成目标、约束、决策、待办、证据。
怎么找回：通过向量检索、关键词检索、结构化过滤、重排评分，把最相关的记忆拿回来。
怎么放进上下文：在有限 Token 预算里，把最高信号的信息放到最合适的位置。
概念 | 一句话解释 | 工程上怎么做 |
短期记忆 | 当前会话和当前任务的工作台 | 保留最近 N 轮、任务状态、最近工具结果 |
长期记忆 | 跨会话可复用的外部知识 | 向量库、关系库、文档库、用户画像 |
记忆压缩 | 把长历史变成高密度摘要 | 结构化抽取、去重、合并、冲突检测 |
记忆检索 | 按当前问题找回相关记忆 | Query 改写、多路召回、重排、过滤 |
上下文管理 | 决定本轮 prompt 放什么、放多少、放哪里 | Token 预算、优先级、证据区、最近对话区 |
二、为什么不能只靠长上下文？
长上下文确实很重要，但它解决的是“模型能看到更多”的问题，不等于“模型能稳定用好更多”。如果把 200 页文档、50 轮聊天、20 次工具调用结果全部塞进去，模型会面对一个高噪声工作台：有些信息过期，有些信息重复，有些工具日志只是中间过程，有些错误结论甚至会污染后续回答。
一个简单类比：你让人写项目总结，不会把微信群从第一天到今天的聊天记录全部贴给他，而是会整理一份“项目现状”：目标是什么、已经做了什么、关键决策是什么、还剩什么问题、哪些资料可以查。AI Agent 也是一样。
上下文工程要解决的不是“塞得更多”，而是“每一个 Token 都更值钱”。Anthropic 在 context engineering 文章里把 compaction、structured note-taking、sub-agent 等作为长期任务中的关键手段；OpenAI 的短期会话记忆实践也强调 trimming 与 compression，以降低成本、延迟和错误传播。
三、把记忆分成三类：语义、情节、程序
做记忆系统之前，先别急着选向量库。第一步是把“记忆类型”分清楚。LangChain / LangGraph 文档中把 Agent 长期记忆对应到三类：semantic memory、episodic memory、procedural memory。翻成大白话就是：
记忆类型 | 存什么 | 例子 | 典型存储方式 |
语义记忆 | 稳定事实、偏好、配置 | 用户偏好“文章要多图”、项目域名、API平台 | JSON画像、关系表、向量片段 |
情节记忆 | 过去发生过的任务过程 | 上次部署失败原因、某次调试路径、成功案例 | 任务轨迹、案例库、时间线 |
程序记忆 | 如何做事的规则和方法 | 输出格式、编码规范、文章风格、工具调用习惯 | 系统提示词、策略配置、Prompt模板 |
这三类记忆不能混在一个大桶里。用户偏好是稳定配置，应该写进画像；历史调试过程是经验案例，应该可检索；输出风格是程序记忆，应该影响系统提示词。混在一起会导致两个后果：召回时噪声很大，更新时容易覆盖错。
四、记忆压缩：不是“总结一下”，而是把历史变成可执行资产
很多系统的“压缩”只是让模型把聊天记录总结成一段话。这种做法能省 Token，但不一定能让 Agent 变聪明。真正有用的压缩，应该把原始历史变成结构化资产。
建议每次压缩都输出固定字段，而不是自由发挥：
goal：当前任务目标，最好一句话说清楚。
constraints：硬约束，例如预算、技术栈、域名、合规边界。
decisions：已经做出的关键决策，避免下次反复推翻。
facts：可复用事实，必须带来源、时间、置信度。
todos：未完成事项，最好有优先级和负责人。
risks：风险、失败原因、容易踩坑的地方。
evidence：原始证据链接、文件名、日志片段，方便追溯。
压缩的关键指标不是“摘要有多短”，而是“下次恢复任务时，是否还能继续做”。过度压缩会丢掉细节；压缩太弱又省不了上下文。工程上可以先追求高召回：宁可多留一点关键细节；跑通后再逐步提高精度，删掉冗余。
一个实用的记忆摘要 JSON 模板：
{
"memory_type": "project_state",
"scope": "user:xxx / project:coupon-site",
"goal": "搭建优惠券导购站，先用假数据跑通，再接联盟 API",
"constraints": ["域名 deals.eeebb.com", "保留拼多多/淘宝/京东配置位"],
"decisions": ["先搭框架和后台配置，不等待应用审核"],
"todos": ["申请应用", "补齐 API Key", "增加转链日志"],
"confidence": "high",
"source": "conversation_summary_2026-05-25"
}
五、记忆检索：多路召回 + 重排 + 过滤
RAG 的经典思路是让模型结合参数内知识与外部非参数记忆，RAG 论文中就展示了检索增强对知识密集型任务的价值。放到 Agent 记忆里，检索不只是“查知识库”，而是“按当前任务，把过去最有用的记忆找回来”。
一个生产可用的检索链路，建议至少包括五步：
查询改写：把用户口语化问题改写成可检索 query。例如“继续弄那个网站”要改写出项目名、域名、平台、时间范围。
多路召回：向量召回解决语义相近，关键词召回解决专有名词，结构化过滤解决项目、用户、权限和时间范围。
候选过滤：先过滤无权限、过期、低置信度、明显冲突的数据，避免把毒信息送进上下文。
重排评分：不要只看相似度，要综合相关性、新鲜度、重要度、可靠性、冲突惩罚。
上下文打包：最后不是把 TopK 全塞进去，而是去重、压缩、排序、附带来源。
最简单的可落地公式可以这样写：最终分 = 0.45×相关性 + 0.20×新鲜度 + 0.20×重要度 + 0.15×可靠性 - 冲突惩罚 - 重复惩罚。这个公式不需要一开始就完美，但必须能调参、能观测、能回放。
六、上下文管理：决定“放什么、放多少、放哪里”
上下文装配的目标，是把本轮任务变成一份高密度战术简报。它应该包含：稳定规则、当前目标、当前任务状态、关键证据、最近对话、必要工具结果。它不应该包含：重复工具日志、已解决报错、无关闲聊、低置信度猜测。
建议按照预算来管控 Prompt，而不是凭感觉堆内容。对于大多数 Agent 任务，一个可参考的预算是：
上下文区域 | 建议比例 | 内容 | 放置建议 |
系统规则 | 5%-10% | 角色、边界、输出格式、工具规则 | 开头，稳定且短 |
当前目标 | 10%-15% | 用户最新需求、必须完成的动作 | 开头或结尾强化 |
任务状态 | 15%-25% | 项目现状、已完成、未完成、关键约束 | 靠前 |
检索证据 | 25%-40% | 高相关记忆、文档片段、引用来源 | 分条、带来源 |
最近对话 | 10%-15% | 最近几轮交互，保留语气与局部细节 | 适度保留 |
工具结果 | 5%-10% | 本轮必要工具返回，不要塞完整日志 | 只放摘要和关键值 |
一个细节很重要：越关键的信息越不要埋在上下文中间。由于长上下文中间位置可能更容易被忽视，建议把核心任务、不可违背约束、最终输出要求放在开头或结尾；中间区域放可丢失的辅助材料。
七、记忆写入策略：什么该记，什么不该记？
很多 Agent 记忆系统失败，不是因为不会存，而是因为存得太多。只要用户说一句话就写入长期记忆，最后会变成“记忆垃圾场”。写入长期记忆要有门槛。
应该写入 | 谨慎写入 | 不要写入 |
长期稳定偏好：文章要通俗、多图、生成 docx | 一次性情绪表达：今天太烦了 | 敏感隐私、临时验证码、密码、密钥 |
项目级关键配置：域名、技术栈、回调地址 | 低置信度推断：可能喜欢某类风格 | 错误结论、已被用户否定的信息 |
明确决策：先做假数据，再接 API | 短期状态：本轮临时计划 | 大量重复日志、无关闲聊、爬虫噪声 |
反复出现的问题和成功经验 | 工具中间结果：除非能复用 | 无法追溯来源的事实 |
实际工程中，可以把写入分成两条路径：热路径写入和冷路径写入。热路径在回答前或回答后立刻写入，适合关键事实和当前任务状态；冷路径在后台定期整理，适合长会话压缩、经验抽取、相似记忆合并。热路径响应快但容易误写，冷路径质量高但有延迟。
八、数据库怎么设计：一张“记忆表”远远不够
一个可维护的记忆系统，至少应该把原始证据、结构化记忆、向量索引和审计信息分开。否则后期做纠错、删除、权限隔离都会非常痛苦。
表/集合 | 存储内容 | 关键字段 | 作用 |
memory_items | 结构化记忆主体 | id, user_id, scope, type, content_json, importance, confidence, created_at, expires_at | 管理事实、偏好、决策、摘要 |
memory_embeddings | 向量索引片段 | memory_id, embedding, chunk_text, tags | 语义召回 |
memory_sources | 原始来源证据 | memory_id, source_type, source_uri, quote, timestamp | 追溯和引用 |
memory_events | 写入/修改/删除日志 | memory_id, action, actor, diff, reason | 审计与回滚 |
memory_feedback | 质量反馈 | query, selected_memory, used_or_not, user_feedback | 优化检索与重排 |
如果你要做多用户、多项目系统，一定要加 namespace。比如 user_id + project_id + memory_type，避免不同项目的记忆串台。对于企业系统，还要加权限字段和数据生命周期字段，例如 expires_at、retention_policy、delete_reason。
九、记忆治理：让记忆变干净，而不是越积越脏
记忆系统一旦上线，就会遇到“记忆污染”：用户口误被当成事实、模型推断被当成用户偏好、旧配置覆盖新配置、不同项目的资料互相串台。解决办法不是关闭记忆，而是建立治理闭环。
置信度：每条记忆都应该区分“用户明确说过”“系统观察到”“模型推断”。推断类不能直接当事实使用。
时间衰减：越旧的记忆权重越低，除非它被多次使用或被用户确认。
冲突处理：新旧信息冲突时，不要静默覆盖，要保留版本并在必要时提示用户确认。
可删除：用户要求删除某类记忆时，系统必须能定位并清除。
可评估：每次回答使用了哪些记忆，命中了哪些，最终是否有帮助，都要能记录。
十、最容易踩的 8 个坑
1. 把所有历史都塞进 Prompt：这不是记忆，是搬运。结果是更贵、更慢、更乱。
2. 摘要没有结构：一段自然语言摘要看起来顺，但很难检索、更新和冲突检测。
3. 只用向量相似度：专有名词、域名、订单号、API Key 名称经常需要关键词和结构化过滤。
4. 没有来源：模型一旦拿错记忆，无法追溯是谁写的、什么时候写的、证据是什么。
5. 长期记忆不做权限隔离：多用户、多项目场景最怕记忆串台，这是严重事故。
6. 过期记忆不衰减：旧配置、旧方案、旧偏好可能误导模型。
7. 检索 TopK 固定不变：不同任务需要不同数量证据。简单问答可能 3 条足够，复杂规划可能需要 10 条。
8. 没有评估集：没有黄金问题集，就不知道记忆系统是真的变好，还是只是感觉更智能。
十一、从 0 到 1 怎么落地？给一条实战路线
不要一开始就做“全自动长期记忆大脑”。最稳的路线是先做短期连续性，再做结构化压缩，然后接入长期检索，最后做治理与评估。
第一个版本只需要做到三件事：第一，最近 N 轮 + 会话摘要，让 Agent 不要在一个任务里反复失忆；第二，固定摘要字段，把目标、约束、决策、待办沉淀下来；第三，按项目和用户隔离记忆，避免串台。
第二个版本再加向量检索、关键词检索、重排评分和上下文打包。第三个版本再做记忆质量评估、冲突检测、用户可查看/可删除、自动回放测试。
十二、一个最小可用架构：适合个人项目或中小团队
如果你是 0 到 1 做 AI Agent 应用，可以用下面这套轻量架构：
短期记忆：Redis / SQLite / Postgres 存最近对话与会话摘要。
长期记忆：Postgres 存结构化 JSON，pgvector 或独立向量库存 embedding。
原始证据：对象存储或文档表保存关键原文、网页、日志片段。
检索服务：Query 改写 + 混合召回 + rerank + 上下文打包。
治理后台：查看记忆、删除记忆、标记错误、观察命中率。
一个简化的请求流程是：用户输入 -> 意图解析 -> 查询改写 -> 检索记忆 -> 装配上下文 -> 调用模型 -> 输出结果 -> 抽取新记忆 -> 写入或等待后台压缩。
十三、总结：未来的 Agent，不是“记得多”，而是“记得准”
AI Agent 的长期竞争力，不只来自模型参数，也来自上下文工程。一个没有记忆管理的 Agent，就像一个每次上班都清空工位的人；一个有记忆但不治理的 Agent，又像一个桌面堆满垃圾文件的人。真正高效的系统，应该做到：短期记忆保证连续性，长期记忆保证个性化和复用，压缩保证高密度，检索保证相关性，上下文管理保证每一轮都聚焦。
一句话收尾：不要迷信“无限上下文”，要建设“可压缩、可检索、可治理的记忆系统”。这才是 AI Agent 从聊天玩具走向生产工具的关键分水岭。