AI Agent 的记忆从何而来？本文剖析跨越会话的上下文持久化机制，涵盖上下文工程、外部记忆系统和记忆生命周期三个层次，并给出个人开发者的实践路径。

AI Agent 的记忆机制：跨越会话的上下文持久化

我们训练了越来越强大的大模型，却常常忽视一个最基础的问题：AI Agent 的记忆从何而来？

当你在凌晨两点向一个 AI 编程助手提问，它凭什么能记住你六个月前那个项目的架构决策？当你在新会话里要求 Agent "继续上次的工作"，它到底记得多少？这种"记忆"背后的技术机制，远比表面上看起来要复杂得多。

会话、会话，然后呢？

大多数人与 AI 的交互止步于单会话上下文窗口（Context Window）。对话结束，窗口关闭，所有信息随Session ID 一起消散。下一次开始，你面对的是一个"失忆"的 Agent——它不认识你，不记得你的项目，甚至不认识你使用的是哪个编程语言。

这是大模型本身的固有限制，而非缺陷。Transformer 的注意力机制天然以当前 Token 序列为边界，历史信息必须通过提示（Prompt）重新注入。上下文窗口无论多大，终究是有限的——GPT-4o 128k Token 的上下文，已经是需要精打细算的昂贵资源。

那么，跨越会话的记忆是怎么实现的？

实践中，AI Agent 的记忆系统分为三个层次，每一层解决不同的问题：

这是最轻量的方案，核心思路是在每个新会话开始时，主动将历史信息注入上下文。

典型做法是维护一个系统提示（System Prompt）模板，在每次对话启动时追加用户的背景信息、项目概况、上一次对话的关键结论。一个结构化的注入片段大概是这个样子：

当前项目：墨千文档平台
技术栈：NestJS + PostgreSQL + Redis
架构决策：采用 CQRS 模式，读写分离
当前 Sprint 目标：完成 RAG 检索模块
上次进展：已完成 Embedding 服务接入，待对接向量数据库

上下文工程的优点是实现简单、无额外成本；缺点是随着信息积累，上下文越来越臃肿，很快就会触及窗口上限。更关键的是，它依赖人工维护信息的结构和质量，一旦信息过载或格式混乱，模型反而容易被干扰。

当上下文工程触及天花板，外部记忆系统就登场了。它的基本思想是：不把信息存在模型里，而是存在独立的存储系统，检索到需要的部分再注入上下文。

一个典型的实现包含三个组件：

记忆存储（Memory Store）：通常是基于向量数据库（如 Pinecone、Milvus、Qdrant）或传统 KV 存储（如 Redis、PostgreSQL JSON 列）。信息以语义向量（Embedding）的形式存入，每条记录关联对话 ID、用户 ID、时间戳和重要性评分。

记忆检索（Memory Retrieval）：新会话启动时，系统根据当前意图生成查询向量，从存储中语义搜索相关记忆。相似度阈值、重新排序（Reranker）和时间衰减因子共同决定最终注入哪些片段。

记忆蒸馏（Memory Distillation）：这是最容易被忽视的一步——原始交互日志不能直接塞给模型，需要经过摘要压缩。用小一些的模型（如 GPT-4o-mini）将长对话提炼为结构化的要点，去除冗余，保留关键决策和当前状态。

外部记忆系统的优势在于容量不受模型限制、可以跨用户和跨项目共享记忆；缺点是系统复杂度显著提升，检索质量高度依赖 Embedding 模型和向量化策略的选择。