如果你正在开发 AI Agent或者使用过 ChatGPT、Claude 这类对话助手一定遇到过这个令人头疼的问题聊着聊着AI 就“失忆”了。它忘了你十分钟前设定的目标重复问你相同的问题或者给出的建议前后矛盾。我们通常把问题归咎于“上下文长度不够”于是开发者们开始追逐更大的上下文窗口——128K、200K甚至 1M。仿佛只要把对话历史全部塞进去AI 就能拥有完美的记忆。但事实真的如此吗一个更本质的真相是人类的记忆乃至 AI 有效的“记忆”从来不是对过去信息的完整“回放”而是基于当前目标和线索的主动“重建”。最近在 GitHub 上涌现的一系列围绕“记忆”与“上下文”的开源项目正在将这一认知转化为工程实践。它们不再单纯地堆砌历史 token而是试图为 AI Agent 构建一套更接近人类工作记忆的机制压缩、提取、关联、刷新。本文将带你深入探讨这一技术趋势的核心。我们不仅会解释为什么“重建式记忆”比“回放式记忆”更有效更会通过分析具体的开源项目如涉及上下文压缩、长期记忆管理、双网络记忆模型等为你展示如何在实际的 Agent 开发中应用这些理念。无论你是想优化自己的 AI 助手还是正在构建复杂的多 Agent 系统理解并实践“记忆重建”都将是你突破现有瓶颈的关键一步。1. 我们到底在解决什么问题从“上下文焦虑”到“记忆本质”在深入技术细节之前我们必须先厘清核心痛点。开发者面临的“记忆”问题通常表现为以下几种场景任务遗忘在长对话中AI 忘记了最初的任务目标。例如你让 AI 帮你写一个项目计划中途讨论了技术选型但当它开始写具体模块时可能又回头问你“我们这个项目的目标是什么”信息冗余与冲突随着对话进行上下文里积累了大量的历史消息。新的查询需要从这堆“历史垃圾”中费力地寻找相关片段并且早期不准确或已被修正的信息可能会干扰最新的判断。成本与性能的权衡将全部历史对话送入大模型意味着极高的 token 消耗和更慢的响应速度。对于需要长期运行或处理大量交互的 Agent 应用这直接转化为高昂的 API 成本和糟糕的用户体验。无效的“记忆”即使上下文窗口足够大AI 也常常无法主动调用关键历史信息。它“知道”信息存在但不知道“何时”以及“如何”使用。传统的解决方案是“上下文窗口竞赛”和“向量数据库检索RAG”。前者治标不治本且成本高昂后者引入了外部存储和检索步骤增加了系统复杂性且检索到的信息是孤立的片段缺乏与当前对话状态的动态关联。因此真正要解决的问题不是“如何记住更多”而是“如何记住更精、更准、更及时”。这引出了“记忆重建”的核心思想我们不需要保存完整的原始对话流而是需要维护一个动态的、结构化的、与当前目标高度相关的“记忆摘要”或“知识图谱”。当需要“回忆”时AI 根据当前的问题从这个摘要中重建出相关的上下文。接下来的章节我们将拆解实现这一目标的技术路径和开源工具。2. 核心概念记忆、上下文与 Agent 工作流在讨论具体项目前明确几个关键概念及其关系至关重要。2.1 记忆 vs. 上下文上下文通常指单次请求中直接输入给大模型的文本序列包括系统提示、历史对话、当前查询等。它是临时的、线性的、原始的。记忆在 AI Agent 的范畴内记忆是一个更上层的、持久化的概念。它指 Agent 在多次交互中积累并结构化存储的信息并能被有选择地、动态地注入到未来的上下文中。简单类比上下文就像你电脑当前打开的所有网页和文档关机就没了。记忆则是你写下的会议纪要、项目笔记和知识库需要时可以随时翻阅并且你会用荧光笔标出重点。2.2 Agent 记忆的类型从工程角度Agent 记忆通常分为两类短期记忆/工作记忆处理当前任务所需的即时信息。它容量小、更新快类似于人类的“大脑缓存”。在技术实现上它常常体现为经过压缩和提炼的“当前上下文摘要”。长期记忆存储跨越多个会话的核心知识、用户偏好、任务结果等。它需要持久化存储数据库、向量库、文件并配备高效的检索和更新机制。一个健壮的 Agent 系统需要在两者之间建立流畅的通道将短期记忆中有价值的部分沉淀为长期记忆又能从长期记忆中快速提取相关信息重构为有效的短期记忆上下文。2.3 相关技术栈关键词RAG检索增强生成。通过从外部知识库检索相关文档片段来补充上下文是解决“知识记忆”的经典方案。Agentic RAG将 RAG 过程 Agent 化让 AI 自主决定何时检索、检索什么、如何利用检索结果。LangGraph / Workflow用于编排复杂、有状态的 Agent 工作流。记忆管理本身就是一种状态管理因此这类框架天然适合集成记忆机制。上下文压缩将冗长的历史对话压缩成简洁的摘要以减少 token 占用并突出核心信息。这是实现“重建”而非“回放”的关键技术之一。MCP模型上下文协议。一种新兴的标准化协议旨在让大模型更安全、更高效地使用工具和访问外部数据。一些记忆管理工具开始与 MCP 集成。理解了这些概念我们就能看懂 GitHub 上那些热门项目究竟在做什么。3. 开源项目全景从记忆管理到上下文工程根据网络热词和趋势我们可以梳理出几个关键的项目方向。请注意以下分析基于公开的技术思路和问题描述部分项目可能处于快速迭代中。3.1 方向一上下文压缩与长对话管理这是最直接的“记忆重建”实践。核心思路是在对话轮次积累到一定长度后自动触发一个“总结智能体”将过往对话压缩成一个精炼的摘要并用这个摘要替代原始的长篇历史作为后续对话的新“记忆起点”。代表性思路/工具deepseek harness或类似模式这不是一个具体项目名而是一种模式描述。“Harness”意为“驾驭、管理”。这类工具通常作为一个中间件监控上下文长度当达到阈值时调用大模型生成总结并智能地决定保留哪些关键细节如用户偏好、任务目标、重要决策丢弃哪些冗余寒暄和中间过程。claudecode压缩上下文命令虽然可能是特定客户端的命令但它反映了一种用户需求主动对当前超长的上下文进行手动或自动压缩以恢复 AI 的响应能力。解决的问题直接对抗“上下文窗口限制”降低 token 成本防止模型因信息过载而性能下降。3.2 方向二结构化长期记忆体系这类项目旨在为 Agent 构建一个可持久化、可查询、可更新的“记忆库”。它超越了简单的向量检索引入了更复杂的结构。双网络记忆模型这是一个非常有趣的概念。它可能指代两种不同的记忆网络协同工作。例如一个网络负责存储“事实”如“用户张三喜欢喝美式咖啡”、“项目A的API密钥是xxx”。这类记忆需要精确存储和检索。另一个网络负责存储“程序”或“经验”如“当用户报告错误时应先询问错误日志”、“完成注册流程需要依次调用A、B、C三个接口”。这类记忆更接近“技能”或“工作流”。两个网络可以相互索引和触发使得 Agent 不仅能记住“是什么”还能记住“怎么做”。langgraph长期记忆LangGraph 本身是一个强大的有状态工作流框架。社区在其基础上构建了长期记忆模块将工作流中的状态如对话历史、工具调用结果、中间变量序列化存储到数据库如 PostgreSQL、Redis并在工作流恢复时重新加载从而实现跨会话的记忆持久化。解决的问题实现 Agent 的“个性化”和“连续性”让 Agent 在多次交互中学习并适应用户并能处理需要暂停和恢复的复杂长周期任务。3.3 方向三记忆化搜索与执行优化这个方向更偏向底层性能优化但其思想与“记忆重建”相通。记忆化搜索这是一个经典的算法优化技术通过存储函数或子任务的结果来避免重复计算。在 Agent 场景下可以理解为当 Agent 需要执行一个与之前类似的任务如“分析这段代码的风格”时它可以直接从“记忆”中获取之前类似分析的结果或模式而不是每次都从头开始推理。这极大地提升了效率。qoder agent记忆插件从名称推测这可能是为某个“Coder Agent”编程助手开发的插件。其功能可能是记忆用户的项目结构、常用代码模式、已解决的错误等从而在用户提出新问题时能给出更贴合项目上下文和个人习惯的答案。解决的问题提升 Agent 的执行效率和准确性避免重复劳动实现经验的积累和复用。3.4 方向四一体化 Agent 开发框架这类项目提供开箱即用的 Agent 系统其中记忆管理是核心内置功能。pi agent一个具体的 AI Agent 项目。从其官网和讨论看它可能集成了对话管理、工具调用、以及长期记忆功能。用户可以与一个具有“记忆”的个性化 AI 进行持续交互。hermes agent等众多以“Agent”命名的开源框架大多会包含基础的状态管理和记忆组件。解决的问题为开发者提供一个高起点无需从零开始搭建记忆系统可以更专注于业务逻辑。4. 实践指南为你的 AI 助手构建“重建式记忆”理论说再多不如动手实践。我们以一个简单的“任务型对话助手”为例演示如何利用现有工具和思想为其添加记忆重建能力。我们将使用 Python 和langchain、langgraph等流行库来模拟这一过程。场景开发一个“旅行规划助手”它能与用户进行多轮对话记住用户的预算、偏好、已选择的航班/酒店并最终生成一份规划。4.1 环境准备确保你已安装 Python (建议 3.9)然后安装必要的库pip install langchain langchain-openai langgraph chromadb tiktoken本例使用 OpenAI 的模型你需要设置OPENAI_API_KEY环境变量。export OPENAI_API_KEYyour-api-key-here # 或者在代码中设置 # import os # os.environ[OPENAI_API_KEY] your-api-key-here4.2 定义记忆数据结构我们首先定义“记忆”里应该存什么。这比简单存储原始对话更重要。# memory_schema.py from pydantic import BaseModel, Field from typing import List, Optional, Dict from datetime import datetime class UserPreference(BaseModel): 用户偏好记忆 budget: Optional[str] None # 预算范围 travel_style: Optional[str] None # 旅行风格如“豪华”“穷游”“家庭” interests: List[str] Field(default_factorylist) # 兴趣点如[美食, 博物馆, 徒步] constraints: List[str] Field(default_factorylist) # 限制如[不吃辣, 需要无障碍设施] class TripFact(BaseModel): 旅行事实记忆已确定的事项 destination: Optional[str] None travel_dates: Optional[str] None selected_flight: Optional[Dict] None selected_hotel: Optional[Dict] None booked_activities: List[Dict] Field(default_factorylist) class ConversationSummary(BaseModel): 对话摘要记忆 summary: str Field(description对当前对话阶段的精炼总结) last_updated: datetime Field(default_factorydatetime.now) key_decisions: List[str] Field(default_factorylist) # 关键决策点 class AgentMemory(BaseModel): Agent的完整记忆体 user_preference: UserPreference Field(default_factoryUserPreference) trip_fact: TripFact Field(default_factoryTripFact) conversation_summary: ConversationSummary Field(default_factoryConversationSummary) # 可以添加向量存储索引用于基于内容的记忆检索 # raw_memory_vectors: Optional[Any] None这个结构化的记忆体就是我们“重建”上下文的基础。4.3 实现记忆更新与压缩逻辑我们需要两个核心函数update_memory和compress_context。# memory_manager.py from langchain_core.messages import BaseMessage, HumanMessage, AIMessage from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from .memory_schema import AgentMemory, UserPreference, TripFact, ConversationSummary import json llm ChatOpenAI(modelgpt-4o-mini) # 使用一个成本较低的模型处理记忆 def update_memory_from_message(current_memory: AgentMemory, new_message: BaseMessage) - AgentMemory: 根据新消息更新记忆体。 这里实现一个简单的规则引擎实际应用中可以用更复杂的LLM调用或模型。 # 这是一个简化示例。真实场景中可以用一个LLM来解析消息并更新记忆。 # 例如检测用户是否提到了预算。 content new_message.content.lower() if budget in content or 预算 in content: # 简单提取实际应用需更复杂的NLP current_memory.user_preference.budget mentioned # 应替换为提取的值 # ... 其他规则 return current_memory async def compress_conversation(messages: List[BaseMessage], current_memory: AgentMemory) - str: 核心的上下文压缩函数。 将冗长的对话历史 当前记忆体压缩成一段给LLM的提示词。 # 1. 将原始消息列表转换为纯文本仅保留最近N条以防过长 recent_messages messages[-10:] # 只取最近10条作为压缩原材料 convo_text \n.join([f{msg.type}: {msg.content} for msg in recent_messages]) # 2. 构建压缩提示 compression_prompt ChatPromptTemplate.from_messages([ (system, 你是一个高效的对话摘要助手。你的任务是根据对话历史和当前的记忆状态生成一个极其精炼的上下文摘要。 这个摘要将用于后续对话因此必须包含 1. 用户的核心目标和当前进展。 2. 已确认的关键信息如预算、地点、日期。 3. 待解决的关键问题或下一步。 请用3-5句话概括。), (human, f 原始对话片段 {convo_text} 当前系统记忆状态 {current_memory.json(indent2)} 请生成最新的对话摘要 ) ]) # 3. 调用LLM生成摘要 chain compression_prompt | llm response await chain.ainvoke({}) new_summary response.content # 4. 更新记忆体中的摘要 current_memory.conversation_summary.summary new_summary current_memory.conversation_summary.last_updated datetime.now() return new_summary4.4 集成到 LangGraph 工作流中LangGraph 非常适合管理这种有状态记忆的对话流。# travel_agent_graph.py from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated, List from langchain_core.messages import BaseMessage, HumanMessage, AIMessage from .memory_schema import AgentMemory from .memory_manager import update_memory_from_message, compress_conversation import operator # 定义Graph的状态 class AgentState(TypedDict): messages: Annotated[List[BaseMessage], operator.add] # 原始消息流 memory: AgentMemory # 结构化记忆体 compressed_context: str # 压缩后的上下文 # 定义各个节点 async def process_input(state: AgentState): 处理用户输入更新记忆 user_input state[messages][-1].content # 更新记忆基于新消息 state[memory] update_memory_from_message(state[memory], state[messages][-1]) return {memory: state[memory]} async def manage_context(state: AgentState): 管理上下文决定是否需要压缩并执行压缩 # 简单的触发策略如果原始消息超过5条就进行压缩 if len(state[messages]) 5: print(触发上下文压缩...) new_summary await compress_conversation(state[messages], state[memory]) state[compressed_context] new_summary # 压缩后可以清空或截断原始messages这里我们选择保留但实际给模型看的是压缩版 # state[messages] state[messages][-2:] # 例如只保留最后一条用户和AI消息 else: # 如果不需要压缩compressed_context 可以是最近几条消息的拼接 state[compressed_context] \n.join([msg.content for msg in state[messages][-3:]]) return {compressed_context: state[compressed_context]} async def call_llm(state: AgentState): 调用大模型生成回复使用压缩后的上下文 # 构建最终提示包含系统指令、记忆摘要、压缩上下文和最新查询 prompt f # 系统角色 你是一个专业的旅行规划助手。 # 记忆摘要对话历史精要 {state[memory].conversation_summary.summary} # 用户偏好与已确认信息 - 预算{state[memory].user_preference.budget} - 旅行风格{state[memory].user_preference.travel_style} - 目的地{state[memory].trip_fact.destination} - 旅行日期{state[memory].trip_fact.travel_dates} # 最近的对话 {state[compressed_context]} # 请根据以上信息回应用户的最新请求 {state[messages][-1].content} # 调用LLM chat_model ChatOpenAI(modelgpt-4o) response await chat_model.ainvoke(prompt) # 将AI回复添加到消息流 state[messages].append(AIMessage(contentresponse.content)) return {messages: state[messages]} # 构建图 workflow StateGraph(AgentState) workflow.add_node(process_input, process_input) workflow.add_node(manage_context, manage_context) workflow.add_node(generate_response, call_llm) # 设置边 workflow.set_entry_point(process_input) workflow.add_edge(process_input, manage_context) workflow.add_edge(manage_context, generate_response) workflow.add_edge(generate_response, END) # 编译图 app workflow.compile()4.5 运行与测试现在我们可以运行这个具有“记忆重建”能力的助手了。# main.py import asyncio from travel_agent_graph import app from memory_schema import AgentMemory from langchain_core.messages import HumanMessage async def main(): # 初始化状态 initial_state { messages: [HumanMessage(content你好我想规划一次去日本的旅行。)], memory: AgentMemory(), compressed_context: } # 模拟多轮对话 user_inputs [ 我的预算大概是2万人民币。, 我对美食和传统文化比较感兴趣。, 时间大概在明年樱花季3月底到4月初。, 刚才说的预算是两个人的总费用吗哦对了我不吃生鱼片。 ] for inp in user_inputs: print(f\n[用户] {inp}) # 将用户输入加入消息流 initial_state[messages].append(HumanMessage(contentinp)) # 执行图 result await app.ainvoke(initial_state) # 获取最新的AI回复 ai_response result[messages][-1].content print(f[助手] {ai_response}) # 更新状态进行下一轮 initial_state result # 打印当前记忆摘要观察变化 print(f-- 当前记忆摘要 --\n{result[memory].conversation_summary.summary}\n) if __name__ __main__: asyncio.run(main())5. 运行效果与深度解析运行上述代码你会观察到与普通对话流不同的行为前几轮原始对话较短compressed_context可能就是原始对话的拼接。助手正常响应。触发压缩当对话轮次超过设定阈值如5条manage_context节点被触发。控制台会打印“触发上下文压缩...”。重建的上下文之后模型收到的prompt中# 最近的对话部分不再是完整的原始历史而是由compress_conversation函数生成的精炼摘要。这个摘要融合了原始对话的要点和当前记忆体的状态。应对“遗忘”测试在最后一轮输入中用户问“刚才说的预算是两个人的总费用吗哦对了我不吃生鱼片。” 这是一个经典的“记忆”测试。传统长上下文模式模型需要扫描所有历史找到“预算2万”那条信息。我们的重建模式在压缩过程中LLM 已经将“用户预算约为2万人民币”作为关键信息写入了conversation_summary.summary。同时UserPreference.constraints也被更新。因此模型从简洁的摘要和结构化的记忆字段中能更快速、更准确地回答“根据之前的沟通您提到的2万预算是指总费用。另外您不吃生鱼片的忌口已经记录在偏好中规划时会避开此类餐厅。”关键优势Token 高效发送给大模型的主要是精炼摘要和结构化数据而非冗长历史。信息突出摘要由 LLM 生成能主动过滤噪音突出任务相关信息和待办事项。结构清晰用户偏好、已确认事实等被存储在结构化字段中查询和更新效率极高。可持久化AgentMemory对象可以轻松序列化JSON并存入数据库实现跨会话记忆。6. 常见问题与进阶挑战在实际部署中你会遇到更多挑战。以下是一些常见问题及思路问题现象可能原因排查与解决思路压缩后丢失关键细节压缩提示词Prompt设计不佳或压缩模型能力有限。1. 优化压缩提示词明确要求保留“数字”、“时间”、“否定语句不、禁止”、“用户明确偏好”等关键信息。2. 使用更强的模型如 GPT-4进行压缩。3. 引入“重要性评分”机制在压缩前先用一个简单模型对历史语句打分确保高分语句被保留。记忆更新逻辑混乱update_memory_from_message函数规则过于简单或存在冲突。1. 将记忆更新也改为由一个小型 LLM 驱动让它根据消息内容判断更新哪个记忆字段。2. 为记忆更新设置置信度对于模糊的信息可以反问用户确认。多轮压缩后信息失真摘要的摘要可能导致信息偏离原意。1. 避免无限压缩。可以保留一个“基线记忆”即最初几轮对话的原始摘要或关键事实列表后续压缩都基于这个基线进行增量更新。2. 定期如每10轮用更完整的上下文重新生成一次“基线记忆”。结构化记忆字段无法覆盖所有情况预定义的Pydantic模型可能无法涵盖所有用户提到的信息。1. 增加一个free_form_memories: List[str]字段用于存储无法归类但重要的信息。2. 结合向量数据库将无法结构化的原始对话片段进行嵌入存储。当需要时通过语义检索召回相关片段作为上下文的补充。这就是“结构化记忆 向量记忆”的混合模式。系统响应变慢压缩和记忆更新步骤增加了延迟。1. 将压缩和记忆更新设置为异步任务不阻塞主响应流。2. 调整压缩触发频率不要每轮都压缩。3. 使用更轻量的模型处理记忆相关任务。7. 最佳实践与架构建议基于现有开源项目的思路和我们的实践以下是构建生产级 Agent 记忆系统的建议分层记忆架构瞬时上下文当前轮次的直接输入输出。工作记忆短期当前任务相关的、经过压缩和提炼的对话摘要与关键事实。存储在内存中更新频繁。长期记忆用户画像、项目元数据、历史决策、学到的技能如工具使用模式。存储在外部数据库SQL/NoSQL和向量库中。外部知识通过 RAG 从文档、知识库中检索的信息。记忆的读写策略写记忆更新不仅要更新“数据”还要更新“摘要”。每次重要的交互后都应触发记忆的提炼和重组。读记忆重建上下文根据当前查询的意图从长期记忆中检索相关片段与工作记忆融合动态构建出最相关的提示上下文。这即是“重建”过程。利用现有框架不要重复造轮子。评估LangGraph状态管理强大、LangChain生态丰富、LlamaIndex数据连接和记忆抽象好等框架看其记忆组件是否符合需求。关注像Pi Agent、Hermes Agent这类一体化项目的设计学习其记忆模块是如何集成的。评估与监控设计评估指标不仅仅是任务完成率还要评估“记忆准确性”如助手是否错误引用了历史信息和“记忆主动性”如助手是否在适当时机主动提及了已知的用户偏好。记录记忆的演变过程便于调试和优化压缩、更新策略。8. 总结从存储到重构记忆工程的范式转变通过本文的探讨和实践我们可以看到AI Agent 的“记忆”问题正在从一个“存储工程”问题转变为一个“重构工程”问题。旧的范式回放追求更大的上下文窗口把越来越多的原始数据塞给模型。这导致了成本、性能和效果的“三重天花板”。新的范式重建承认模型的注意力是有限的宝贵资源。我们通过智能的压缩、结构化的存储和动态的检索只为模型提供它“此刻最需要”的信息。这本质上是在为模型构建一个外部的“工作记忆”系统。GitHub 上活跃的deepseek harness、langgraph长期记忆、双网络记忆模型等项目正是这一范式转变下的工程探索。它们的方向可能不同但目标一致让 AI 更聪明地“记住”而不是更费力地“读取”。对于开发者而言理解这一趋势意味着在构建下一个 AI 应用时你应该将“记忆管理”视为与“提示工程”、“工具调用”同等重要的核心模块。从设计简单的对话摘要开始逐步引入结构化记忆和向量检索最终构建出一个能够真正理解上下文、具备连续性的智能体。记忆不是历史的包袱而是通向更高效未来的阶梯。重建它而不仅仅是回放它。 
长河君 · 2026/8/25 21:21:52 · 阅读 1.2k AI Agent记忆重建：从上下文压缩到结构化记忆的工程实践
如果你正在开发 AI Agent或者使用过 ChatGPT、Claude 这类对话助手一定遇到过这个令人头疼的问题聊着聊着AI 就“失忆”了。它忘了你十分钟前设定的目标重复问你相同的问题或者给出的建议前后矛盾。我们通常把问题归咎于“上下文长度不够”于是开发者们开始追逐更大的上下文窗口——128K、200K甚至 1M。仿佛只要把对话历史全部塞进去AI 就能拥有完美的记忆。但事实真的如此吗一个更本质的真相是人类的记忆乃至 AI 有效的“记忆”从来不是对过去信息的完整“回放”而是基于当前目标和线索的主动“重建”。最近在 GitHub 上涌现的一系列围绕“记忆”与“上下文”的开源项目正在将这一认知转化为工程实践。它们不再单纯地堆砌历史 token而是试图为 AI Agent 构建一套更接近人类工作记忆的机制压缩、提取、关联、刷新。本文将带你深入探讨这一技术趋势的核心。我们不仅会解释为什么“重建式记忆”比“回放式记忆”更有效更会通过分析具体的开源项目如涉及上下文压缩、长期记忆管理、双网络记忆模型等为你展示如何在实际的 Agent 开发中应用这些理念。无论你是想优化自己的 AI 助手还是正在构建复杂的多 Agent 系统理解并实践“记忆重建”都将是你突破现有瓶颈的关键一步。1. 我们到底在解决什么问题从“上下文焦虑”到“记忆本质”在深入技术细节之前我们必须先厘清核心痛点。开发者面临的“记忆”问题通常表现为以下几种场景任务遗忘在长对话中AI 忘记了最初的任务目标。例如你让 AI 帮你写一个项目计划中途讨论了技术选型但当它开始写具体模块时可能又回头问你“我们这个项目的目标是什么”信息冗余与冲突随着对话进行上下文里积累了大量的历史消息。新的查询需要从这堆“历史垃圾”中费力地寻找相关片段并且早期不准确或已被修正的信息可能会干扰最新的判断。成本与性能的权衡将全部历史对话送入大模型意味着极高的 token 消耗和更慢的响应速度。对于需要长期运行或处理大量交互的 Agent 应用这直接转化为高昂的 API 成本和糟糕的用户体验。无效的“记忆”即使上下文窗口足够大AI 也常常无法主动调用关键历史信息。它“知道”信息存在但不知道“何时”以及“如何”使用。传统的解决方案是“上下文窗口竞赛”和“向量数据库检索RAG”。前者治标不治本且成本高昂后者引入了外部存储和检索步骤增加了系统复杂性且检索到的信息是孤立的片段缺乏与当前对话状态的动态关联。因此真正要解决的问题不是“如何记住更多”而是“如何记住更精、更准、更及时”。这引出了“记忆重建”的核心思想我们不需要保存完整的原始对话流而是需要维护一个动态的、结构化的、与当前目标高度相关的“记忆摘要”或“知识图谱”。当需要“回忆”时AI 根据当前的问题从这个摘要中重建出相关的上下文。接下来的章节我们将拆解实现这一目标的技术路径和开源工具。2. 核心概念记忆、上下文与 Agent 工作流在讨论具体项目前明确几个关键概念及其关系至关重要。2.1 记忆 vs. 上下文上下文通常指单次请求中直接输入给大模型的文本序列包括系统提示、历史对话、当前查询等。它是临时的、线性的、原始的。记忆在 AI Agent 的范畴内记忆是一个更上层的、持久化的概念。它指 Agent 在多次交互中积累并结构化存储的信息并能被有选择地、动态地注入到未来的上下文中。简单类比上下文就像你电脑当前打开的所有网页和文档关机就没了。记忆则是你写下的会议纪要、项目笔记和知识库需要时可以随时翻阅并且你会用荧光笔标出重点。2.2 Agent 记忆的类型从工程角度Agent 记忆通常分为两类短期记忆/工作记忆处理当前任务所需的即时信息。它容量小、更新快类似于人类的“大脑缓存”。在技术实现上它常常体现为经过压缩和提炼的“当前上下文摘要”。长期记忆存储跨越多个会话的核心知识、用户偏好、任务结果等。它需要持久化存储数据库、向量库、文件并配备高效的检索和更新机制。一个健壮的 Agent 系统需要在两者之间建立流畅的通道将短期记忆中有价值的部分沉淀为长期记忆又能从长期记忆中快速提取相关信息重构为有效的短期记忆上下文。2.3 相关技术栈关键词RAG检索增强生成。通过从外部知识库检索相关文档片段来补充上下文是解决“知识记忆”的经典方案。Agentic RAG将 RAG 过程 Agent 化让 AI 自主决定何时检索、检索什么、如何利用检索结果。LangGraph / Workflow用于编排复杂、有状态的 Agent 工作流。记忆管理本身就是一种状态管理因此这类框架天然适合集成记忆机制。上下文压缩将冗长的历史对话压缩成简洁的摘要以减少 token 占用并突出核心信息。这是实现“重建”而非“回放”的关键技术之一。MCP模型上下文协议。一种新兴的标准化协议旨在让大模型更安全、更高效地使用工具和访问外部数据。一些记忆管理工具开始与 MCP 集成。理解了这些概念我们就能看懂 GitHub 上那些热门项目究竟在做什么。3. 开源项目全景从记忆管理到上下文工程根据网络热词和趋势我们可以梳理出几个关键的项目方向。请注意以下分析基于公开的技术思路和问题描述部分项目可能处于快速迭代中。3.1 方向一上下文压缩与长对话管理这是最直接的“记忆重建”实践。核心思路是在对话轮次积累到一定长度后自动触发一个“总结智能体”将过往对话压缩成一个精炼的摘要并用这个摘要替代原始的长篇历史作为后续对话的新“记忆起点”。代表性思路/工具deepseek harness或类似模式这不是一个具体项目名而是一种模式描述。“Harness”意为“驾驭、管理”。这类工具通常作为一个中间件监控上下文长度当达到阈值时调用大模型生成总结并智能地决定保留哪些关键细节如用户偏好、任务目标、重要决策丢弃哪些冗余寒暄和中间过程。claudecode压缩上下文命令虽然可能是特定客户端的命令但它反映了一种用户需求主动对当前超长的上下文进行手动或自动压缩以恢复 AI 的响应能力。解决的问题直接对抗“上下文窗口限制”降低 token 成本防止模型因信息过载而性能下降。3.2 方向二结构化长期记忆体系这类项目旨在为 Agent 构建一个可持久化、可查询、可更新的“记忆库”。它超越了简单的向量检索引入了更复杂的结构。双网络记忆模型这是一个非常有趣的概念。它可能指代两种不同的记忆网络协同工作。例如一个网络负责存储“事实”如“用户张三喜欢喝美式咖啡”、“项目A的API密钥是xxx”。这类记忆需要精确存储和检索。另一个网络负责存储“程序”或“经验”如“当用户报告错误时应先询问错误日志”、“完成注册流程需要依次调用A、B、C三个接口”。这类记忆更接近“技能”或“工作流”。两个网络可以相互索引和触发使得 Agent 不仅能记住“是什么”还能记住“怎么做”。langgraph长期记忆LangGraph 本身是一个强大的有状态工作流框架。社区在其基础上构建了长期记忆模块将工作流中的状态如对话历史、工具调用结果、中间变量序列化存储到数据库如 PostgreSQL、Redis并在工作流恢复时重新加载从而实现跨会话的记忆持久化。解决的问题实现 Agent 的“个性化”和“连续性”让 Agent 在多次交互中学习并适应用户并能处理需要暂停和恢复的复杂长周期任务。3.3 方向三记忆化搜索与执行优化这个方向更偏向底层性能优化但其思想与“记忆重建”相通。记忆化搜索这是一个经典的算法优化技术通过存储函数或子任务的结果来避免重复计算。在 Agent 场景下可以理解为当 Agent 需要执行一个与之前类似的任务如“分析这段代码的风格”时它可以直接从“记忆”中获取之前类似分析的结果或模式而不是每次都从头开始推理。这极大地提升了效率。qoder agent记忆插件从名称推测这可能是为某个“Coder Agent”编程助手开发的插件。其功能可能是记忆用户的项目结构、常用代码模式、已解决的错误等从而在用户提出新问题时能给出更贴合项目上下文和个人习惯的答案。解决的问题提升 Agent 的执行效率和准确性避免重复劳动实现经验的积累和复用。3.4 方向四一体化 Agent 开发框架这类项目提供开箱即用的 Agent 系统其中记忆管理是核心内置功能。pi agent一个具体的 AI Agent 项目。从其官网和讨论看它可能集成了对话管理、工具调用、以及长期记忆功能。用户可以与一个具有“记忆”的个性化 AI 进行持续交互。hermes agent等众多以“Agent”命名的开源框架大多会包含基础的状态管理和记忆组件。解决的问题为开发者提供一个高起点无需从零开始搭建记忆系统可以更专注于业务逻辑。4. 实践指南为你的 AI 助手构建“重建式记忆”理论说再多不如动手实践。我们以一个简单的“任务型对话助手”为例演示如何利用现有工具和思想为其添加记忆重建能力。我们将使用 Python 和langchain、langgraph等流行库来模拟这一过程。场景开发一个“旅行规划助手”它能与用户进行多轮对话记住用户的预算、偏好、已选择的航班/酒店并最终生成一份规划。4.1 环境准备确保你已安装 Python (建议 3.9)然后安装必要的库pip install langchain langchain-openai langgraph chromadb tiktoken本例使用 OpenAI 的模型你需要设置OPENAI_API_KEY环境变量。export OPENAI_API_KEYyour-api-key-here # 或者在代码中设置 # import os # os.environ[OPENAI_API_KEY] your-api-key-here4.2 定义记忆数据结构我们首先定义“记忆”里应该存什么。这比简单存储原始对话更重要。# memory_schema.py from pydantic import BaseModel, Field from typing import List, Optional, Dict from datetime import datetime class UserPreference(BaseModel): 用户偏好记忆 budget: Optional[str] None # 预算范围 travel_style: Optional[str] None # 旅行风格如“豪华”“穷游”“家庭” interests: List[str] Field(default_factorylist) # 兴趣点如[美食, 博物馆, 徒步] constraints: List[str] Field(default_factorylist) # 限制如[不吃辣, 需要无障碍设施] class TripFact(BaseModel): 旅行事实记忆已确定的事项 destination: Optional[str] None travel_dates: Optional[str] None selected_flight: Optional[Dict] None selected_hotel: Optional[Dict] None booked_activities: List[Dict] Field(default_factorylist) class ConversationSummary(BaseModel): 对话摘要记忆 summary: str Field(description对当前对话阶段的精炼总结) last_updated: datetime Field(default_factorydatetime.now) key_decisions: List[str] Field(default_factorylist) # 关键决策点 class AgentMemory(BaseModel): Agent的完整记忆体 user_preference: UserPreference Field(default_factoryUserPreference) trip_fact: TripFact Field(default_factoryTripFact) conversation_summary: ConversationSummary Field(default_factoryConversationSummary) # 可以添加向量存储索引用于基于内容的记忆检索 # raw_memory_vectors: Optional[Any] None这个结构化的记忆体就是我们“重建”上下文的基础。4.3 实现记忆更新与压缩逻辑我们需要两个核心函数update_memory和compress_context。# memory_manager.py from langchain_core.messages import BaseMessage, HumanMessage, AIMessage from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from .memory_schema import AgentMemory, UserPreference, TripFact, ConversationSummary import json llm ChatOpenAI(modelgpt-4o-mini) # 使用一个成本较低的模型处理记忆 def update_memory_from_message(current_memory: AgentMemory, new_message: BaseMessage) - AgentMemory: 根据新消息更新记忆体。 这里实现一个简单的规则引擎实际应用中可以用更复杂的LLM调用或模型。 # 这是一个简化示例。真实场景中可以用一个LLM来解析消息并更新记忆。 # 例如检测用户是否提到了预算。 content new_message.content.lower() if budget in content or 预算 in content: # 简单提取实际应用需更复杂的NLP current_memory.user_preference.budget mentioned # 应替换为提取的值 # ... 其他规则 return current_memory async def compress_conversation(messages: List[BaseMessage], current_memory: AgentMemory) - str: 核心的上下文压缩函数。 将冗长的对话历史 当前记忆体压缩成一段给LLM的提示词。 # 1. 将原始消息列表转换为纯文本仅保留最近N条以防过长 recent_messages messages[-10:] # 只取最近10条作为压缩原材料 convo_text \n.join([f{msg.type}: {msg.content} for msg in recent_messages]) # 2. 构建压缩提示 compression_prompt ChatPromptTemplate.from_messages([ (system, 你是一个高效的对话摘要助手。你的任务是根据对话历史和当前的记忆状态生成一个极其精炼的上下文摘要。 这个摘要将用于后续对话因此必须包含 1. 用户的核心目标和当前进展。 2. 已确认的关键信息如预算、地点、日期。 3. 待解决的关键问题或下一步。 请用3-5句话概括。), (human, f 原始对话片段 {convo_text} 当前系统记忆状态 {current_memory.json(indent2)} 请生成最新的对话摘要 ) ]) # 3. 调用LLM生成摘要 chain compression_prompt | llm response await chain.ainvoke({}) new_summary response.content # 4. 更新记忆体中的摘要 current_memory.conversation_summary.summary new_summary current_memory.conversation_summary.last_updated datetime.now() return new_summary4.4 集成到 LangGraph 工作流中LangGraph 非常适合管理这种有状态记忆的对话流。# travel_agent_graph.py from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated, List from langchain_core.messages import BaseMessage, HumanMessage, AIMessage from .memory_schema import AgentMemory from .memory_manager import update_memory_from_message, compress_conversation import operator # 定义Graph的状态 class AgentState(TypedDict): messages: Annotated[List[BaseMessage], operator.add] # 原始消息流 memory: AgentMemory # 结构化记忆体 compressed_context: str # 压缩后的上下文 # 定义各个节点 async def process_input(state: AgentState): 处理用户输入更新记忆 user_input state[messages][-1].content # 更新记忆基于新消息 state[memory] update_memory_from_message(state[memory], state[messages][-1]) return {memory: state[memory]} async def manage_context(state: AgentState): 管理上下文决定是否需要压缩并执行压缩 # 简单的触发策略如果原始消息超过5条就进行压缩 if len(state[messages]) 5: print(触发上下文压缩...) new_summary await compress_conversation(state[messages], state[memory]) state[compressed_context] new_summary # 压缩后可以清空或截断原始messages这里我们选择保留但实际给模型看的是压缩版 # state[messages] state[messages][-2:] # 例如只保留最后一条用户和AI消息 else: # 如果不需要压缩compressed_context 可以是最近几条消息的拼接 state[compressed_context] \n.join([msg.content for msg in state[messages][-3:]]) return {compressed_context: state[compressed_context]} async def call_llm(state: AgentState): 调用大模型生成回复使用压缩后的上下文 # 构建最终提示包含系统指令、记忆摘要、压缩上下文和最新查询 prompt f # 系统角色 你是一个专业的旅行规划助手。 # 记忆摘要对话历史精要 {state[memory].conversation_summary.summary} # 用户偏好与已确认信息 - 预算{state[memory].user_preference.budget} - 旅行风格{state[memory].user_preference.travel_style} - 目的地{state[memory].trip_fact.destination} - 旅行日期{state[memory].trip_fact.travel_dates} # 最近的对话 {state[compressed_context]} # 请根据以上信息回应用户的最新请求 {state[messages][-1].content} # 调用LLM chat_model ChatOpenAI(modelgpt-4o) response await chat_model.ainvoke(prompt) # 将AI回复添加到消息流 state[messages].append(AIMessage(contentresponse.content)) return {messages: state[messages]} # 构建图 workflow StateGraph(AgentState) workflow.add_node(process_input, process_input) workflow.add_node(manage_context, manage_context) workflow.add_node(generate_response, call_llm) # 设置边 workflow.set_entry_point(process_input) workflow.add_edge(process_input, manage_context) workflow.add_edge(manage_context, generate_response) workflow.add_edge(generate_response, END) # 编译图 app workflow.compile()4.5 运行与测试现在我们可以运行这个具有“记忆重建”能力的助手了。# main.py import asyncio from travel_agent_graph import app from memory_schema import AgentMemory from langchain_core.messages import HumanMessage async def main(): # 初始化状态 initial_state { messages: [HumanMessage(content你好我想规划一次去日本的旅行。)], memory: AgentMemory(), compressed_context: } # 模拟多轮对话 user_inputs [ 我的预算大概是2万人民币。, 我对美食和传统文化比较感兴趣。, 时间大概在明年樱花季3月底到4月初。, 刚才说的预算是两个人的总费用吗哦对了我不吃生鱼片。 ] for inp in user_inputs: print(f\n[用户] {inp}) # 将用户输入加入消息流 initial_state[messages].append(HumanMessage(contentinp)) # 执行图 result await app.ainvoke(initial_state) # 获取最新的AI回复 ai_response result[messages][-1].content print(f[助手] {ai_response}) # 更新状态进行下一轮 initial_state result # 打印当前记忆摘要观察变化 print(f-- 当前记忆摘要 --\n{result[memory].conversation_summary.summary}\n) if __name__ __main__: asyncio.run(main())5. 运行效果与深度解析运行上述代码你会观察到与普通对话流不同的行为前几轮原始对话较短compressed_context可能就是原始对话的拼接。助手正常响应。触发压缩当对话轮次超过设定阈值如5条manage_context节点被触发。控制台会打印“触发上下文压缩...”。重建的上下文之后模型收到的prompt中# 最近的对话部分不再是完整的原始历史而是由compress_conversation函数生成的精炼摘要。这个摘要融合了原始对话的要点和当前记忆体的状态。应对“遗忘”测试在最后一轮输入中用户问“刚才说的预算是两个人的总费用吗哦对了我不吃生鱼片。” 这是一个经典的“记忆”测试。传统长上下文模式模型需要扫描所有历史找到“预算2万”那条信息。我们的重建模式在压缩过程中LLM 已经将“用户预算约为2万人民币”作为关键信息写入了conversation_summary.summary。同时UserPreference.constraints也被更新。因此模型从简洁的摘要和结构化的记忆字段中能更快速、更准确地回答“根据之前的沟通您提到的2万预算是指总费用。另外您不吃生鱼片的忌口已经记录在偏好中规划时会避开此类餐厅。”关键优势Token 高效发送给大模型的主要是精炼摘要和结构化数据而非冗长历史。信息突出摘要由 LLM 生成能主动过滤噪音突出任务相关信息和待办事项。结构清晰用户偏好、已确认事实等被存储在结构化字段中查询和更新效率极高。可持久化AgentMemory对象可以轻松序列化JSON并存入数据库实现跨会话记忆。6. 常见问题与进阶挑战在实际部署中你会遇到更多挑战。以下是一些常见问题及思路问题现象可能原因排查与解决思路压缩后丢失关键细节压缩提示词Prompt设计不佳或压缩模型能力有限。1. 优化压缩提示词明确要求保留“数字”、“时间”、“否定语句不、禁止”、“用户明确偏好”等关键信息。2. 使用更强的模型如 GPT-4进行压缩。3. 引入“重要性评分”机制在压缩前先用一个简单模型对历史语句打分确保高分语句被保留。记忆更新逻辑混乱update_memory_from_message函数规则过于简单或存在冲突。1. 将记忆更新也改为由一个小型 LLM 驱动让它根据消息内容判断更新哪个记忆字段。2. 为记忆更新设置置信度对于模糊的信息可以反问用户确认。多轮压缩后信息失真摘要的摘要可能导致信息偏离原意。1. 避免无限压缩。可以保留一个“基线记忆”即最初几轮对话的原始摘要或关键事实列表后续压缩都基于这个基线进行增量更新。2. 定期如每10轮用更完整的上下文重新生成一次“基线记忆”。结构化记忆字段无法覆盖所有情况预定义的Pydantic模型可能无法涵盖所有用户提到的信息。1. 增加一个free_form_memories: List[str]字段用于存储无法归类但重要的信息。2. 结合向量数据库将无法结构化的原始对话片段进行嵌入存储。当需要时通过语义检索召回相关片段作为上下文的补充。这就是“结构化记忆 向量记忆”的混合模式。系统响应变慢压缩和记忆更新步骤增加了延迟。1. 将压缩和记忆更新设置为异步任务不阻塞主响应流。2. 调整压缩触发频率不要每轮都压缩。3. 使用更轻量的模型处理记忆相关任务。7. 最佳实践与架构建议基于现有开源项目的思路和我们的实践以下是构建生产级 Agent 记忆系统的建议分层记忆架构瞬时上下文当前轮次的直接输入输出。工作记忆短期当前任务相关的、经过压缩和提炼的对话摘要与关键事实。存储在内存中更新频繁。长期记忆用户画像、项目元数据、历史决策、学到的技能如工具使用模式。存储在外部数据库SQL/NoSQL和向量库中。外部知识通过 RAG 从文档、知识库中检索的信息。记忆的读写策略写记忆更新不仅要更新“数据”还要更新“摘要”。每次重要的交互后都应触发记忆的提炼和重组。读记忆重建上下文根据当前查询的意图从长期记忆中检索相关片段与工作记忆融合动态构建出最相关的提示上下文。这即是“重建”过程。利用现有框架不要重复造轮子。评估LangGraph状态管理强大、LangChain生态丰富、LlamaIndex数据连接和记忆抽象好等框架看其记忆组件是否符合需求。关注像Pi Agent、Hermes Agent这类一体化项目的设计学习其记忆模块是如何集成的。评估与监控设计评估指标不仅仅是任务完成率还要评估“记忆准确性”如助手是否错误引用了历史信息和“记忆主动性”如助手是否在适当时机主动提及了已知的用户偏好。记录记忆的演变过程便于调试和优化压缩、更新策略。8. 总结从存储到重构记忆工程的范式转变通过本文的探讨和实践我们可以看到AI Agent 的“记忆”问题正在从一个“存储工程”问题转变为一个“重构工程”问题。旧的范式回放追求更大的上下文窗口把越来越多的原始数据塞给模型。这导致了成本、性能和效果的“三重天花板”。新的范式重建承认模型的注意力是有限的宝贵资源。我们通过智能的压缩、结构化的存储和动态的检索只为模型提供它“此刻最需要”的信息。这本质上是在为模型构建一个外部的“工作记忆”系统。GitHub 上活跃的deepseek harness、langgraph长期记忆、双网络记忆模型等项目正是这一范式转变下的工程探索。它们的方向可能不同但目标一致让 AI 更聪明地“记住”而不是更费力地“读取”。对于开发者而言理解这一趋势意味着在构建下一个 AI 应用时你应该将“记忆管理”视为与“提示工程”、“工具调用”同等重要的核心模块。从设计简单的对话摘要开始逐步引入结构化记忆和向量检索最终构建出一个能够真正理解上下文、具备连续性的智能体。记忆不是历史的包袱而是通向更高效未来的阶梯。重建它而不仅仅是回放它。