智能体记忆框架Cognee实践：如何构建“永不失忆”的 AI Agent

LLM 在设计上是无状态的。每次 API 调用都是全新开始。你在 ChatGPT 聊天时感觉到的那种记忆其实是个幻觉——背后是把整段对话历史在每次请求时全部重新发送一遍。这个小把戏在日常闲聊里够用但真要构建一个正经的 Agent它立刻就撑不住了。没有记忆会带来哪些问题随便数数就是七个上下文失忆——Agent 会反复追问你已经说过的信息零个性化——每次交互都冷冰冰毫无温度多步任务失败——中间状态悄无声息地丢失反复犯同样的错——没有情节记忆错误就是死循环知识无法积累——每次会话都从零开始幻觉填补空白——上下文溢出时模型开始自己编身份感崩塌——没有连续性就没有信任感。更长的上下文窗口救不了你面对这些问题第一反应往往是塞更多上下文进去。128K、200K 的 token 窗口看起来应该能解决一切——但事实并非如此。有研究表明当关键信息处于长上下文的中间位置时准确率会下降超过 30%这就是被广泛记录的迷失在中间效应。上下文是个共享预算系统提示、检索到的文档、对话历史、模型输出全都在抢同一块地方。哪怕窗口开到 100K token只要缺乏持久化、优先级排序和显著性判断光靠堆长度也没用。记忆不是把更多文字塞进 prompt而是把 Agent 该记住的东西结构化让它能找到真正重要的那部分。从认知科学借来的框架Lilian Weng 在 2023 年提出的公式已经成为这个领域的默认范式“Agent LLM 记忆 规划 工具使用这个分类框架借鉴自认知科学人类记忆分为三个系统感觉记忆捕捉原始感知输入只保持零点几秒只有被注意到的部分才会传递下去工作记忆是主动思考的场所大约能同时处理 7±2 个元素米勒 1956 年的经典发现一旦失去注意力内容就消失了长期记忆是持久存储容量几乎没有上限瓶颈在于检索——可以存几百万件事但就是想不起来需要的那一个。这三种记忆类型直接映射到现代 Agent 架构的对应组件长期记忆还可以细分情节记忆是具体的过去事件“周二 PostgreSQL 集群宕机了”语义记忆是事实和概念“PostgreSQL 是关系型数据库”程序记忆是技能和工作流“用户申请退款时先核查购买日期”。连接情节记忆和语义记忆的桥梁是记忆巩固把反复出现的具体事件提炼成通用知识。一个 Agent 如果在几十次交互中都注意到用户偏好执行摘要就应该把它转化为一条可复用的规则。没有这个过程Agent 只会不断重播单个事件而不是从中学习。最简 Agent以及它最先在哪里崩掉去掉所有框架Agent 就是一个循环感知、思考、行动。class Agent: 最简 AI agent感知、思考、行动 def __init__(self): self.client anthropic.Anthropic() self.model claude-sonnet-4-20250514 def run(self, user_input: str) - str: response self.client.messages.create( modelself.model, max_tokens1024, messages[{role: user, content: user_input}], ) return response.content[0].text告诉它我有 4 个苹果再问我吃了一个还剩几个——它完全不知道你在说哪里的苹果。每次调用都活在自己的孤岛里。第一层Python 列表所有人最先想到的修法class Agent: def __init__(self): self.client anthropic.Anthropic() self.messages [] # 全部记忆就是一个列表 def chat(self, user_input: str) - str: self.messages.append({role: user, content: user_input}) response self.client.messages.create( modelclaude-sonnet-4-20250514, max_tokens1024, messagesself.messages, # 每次都把完整历史发过去 ) reply response.content[0].text self.messages.append({role: assistant, content: reply}) return reply多轮对话现在能跑了。苹果的问题能答对因为完整的对话历史每次都随请求一起发出去。但两个问题很快暴露出来列表无限增长到第 200 轮左右你就会撞上上下文上限最早的消息悄悄被丢掉。用户在第一轮说的名字早就在昨天的闲聊之前消失了。没有任何优先级机制只有严格的时间顺序。另外所有东西都在内存里Python 进程一结束Agent 对你是谁毫无印象。第二层Markdown 文件持久化下一步自然是把记忆写到磁盘上。Markdown 是个顺手的选择人类可读、Git 友好Agent 也能把它当普通文本读回来。Claude Code 就是用的这个模式通过 CLAUDE.md 和 MEMORY.md 文件来维护状态。class MarkdownMemoryAgent: def __init__(self): self.client anthropic.Anthropic() self.history_file Path(memory/conversation_history.md) self.facts_file Path(memory/known_facts.md) def save_to_disk(self, role: str, content: str) - None: with open(self.history_file, a) as f: f.write(f### {role} at {datetime.now().isoformat()}\n{content}\n\n) def load_history(self) - str: if self.history_file.exists(): return self.history_file.read_text() return def chat(self, user_input: str) - str: self.save_to_disk(user, user_input) history self.load_history() response self.client.messages.create( modelclaude-sonnet-4-20250514, max_tokens1024, systemfPrevious conversation:\n{history}, messages[{role: user, content: user_input}], ) reply response.content[0].text self.save_to_disk(assistant, reply) return reply持久化问题解决了。重启脚本对话记录还在磁盘上。还可以维护一个单独的事实文件让 Agent 随时间提取积累- 用户名字是 Sarah- Sarah 在 Acme Corp 管理后端团队- Acme Corp 是一家 B2B SaaS 公司- 目前正在把生产数据库迁移到新的 AWS 区域用任何编辑器打开文件能直接看到 Agent 知道什么还能手动修改。原型阶段相当好用。有 4 条事实时完全没问题——把整个文件加载进上下文LLM 能回答任何关于 Sarah、她公司或者她所在行业的问题。但快进三个月。Agent 积累了 2000 条提取事实和 200 份对话记录这是 50 万 token 的 markdown 内容而你的上下文窗口只有 128K。再也无法全部加载了只能选择性地检索当前查询相关的内容。而面对平面文件唯一的选项是关键词搜索# 用户问我们的云迁移进度怎么样grep(cloud migration, facts_file)# 返回[]# 磁盘上记录的是正在把生产数据库迁移到新的 AWS 区域# cloud migration这几个字根本没出现过# 用户问哪个团队在负责数据库的工作grep(database team, facts_file)# 返回[]# 一条记录说 Sarah 管理后端团队另一条说团队在迁移生产数据库# 但没有任何一行同时包含数据库和团队小规模时 Markdown 文件很管用真正大规模时就只能靠关键词检索而关键词处理不了同义词、改写表达或者跨越多条事实的关联推理。信息就在磁盘上但你既无法全部加载关键词搜索又太脆弱找不到正确的那一块。“没有智能检索的存储就是一座没有目录的图书馆。第三层向量搜索以及它撞上的那堵墙接下来是接入 Embedding。把 Markdown 切块、嵌入向量、用余弦相似度检索——数据库和PostgreSQL因为在向量空间里距离很近所以能匹配上。同义词的问题消失了。然后撞上新的墙。假设向量库里有这三条事实- Alice 是 Project Atlas 的技术负责人- Project Atlas 用 PostgreSQL 作为主要数据存储- PostgreSQL 集群在周二发生了宕机用户问“Alice 的项目受周二宕机影响了吗”查询里提到了 Alice 和周二的宕机向量搜索会把第一条和第三条排在最前面。但关键的桥接——“Project Atlas 用 PostgreSQL”——既没提 Alice也没提周二这条连接两端的关键事实反而不会浮现出来。每条事实都是嵌入空间里的一个孤立的点把它们串联起来的关联关系对向量来说是不可见的。这不是什么边缘情况而是现实问题的常见形态。业务知识天生就是关系型的人属于团队团队拥有项目项目依赖系统系统有故障记录。任何跨越两跳以上的问题都超出了平面向量检索能回答的范围。能力矩阵每一层都在解决上一层的痛点同时暴露更深的问题要在一个记忆层里同时具备持久化、语义理解和关系推理自己动手搭就意味着要把向量数据库、图数据库、关系型存储、实体提取器、去重管道和边权重系统拼在一起——在写任何 Agent 逻辑之前先烧掉好几周的基础设施工作。Cognee三个存储一个引擎四个接口Cognee 是一个为 Agent 记忆设计的开源知识引擎把向量搜索、知识图谱和关系型溯源层整合进同一个系统。整个 API 就四个异步调用import cogneeawait cognee.add(你的文档内容) # 摄入任何内容await cognee.cognify() # 构建知识图谱 向量嵌入await cognee.memify() # 自我优化记忆await cognee.search(你的查询) # 带推理的检索四个接口背后是三存储架构为什么是三个存储而不是一个因为每种存储都捕捉了其他存储无法替代的知识维度关系型存储管溯源——数据从哪里来、什么时候入库、谁有权限访问向量存储管语义——内容的含义、相似内容的关联图存储管关系——实体如何连接、因果链条、汇报结构。压平任何一层检索准确率就会丢失对应维度的信息。默认技术栈是 SQLite LanceDB Kuzu完全嵌入式、基于文件。pip install cognee加上一个 LLM API key 就能跑起来不需要 Docker不需要外部服务。生产环境可以把 SQLite 换成 PostgresLanceDB 换成 Qdrant/Pinecone/pgvectorKuzu 换成 Neo4j/FalkorDB/Neptune四个接口的 API 保持不变。cognify 在做什么cognee.cognify()运行一个多阶段管道把原始文本转化成结构化的、相互连接的知识先做文档按类型和领域分类检查多租户权限提取遵循段落结构的语义块不是固定长度的切割通过 LLM 提取实体和关系并通过内容哈希自动去重生成用于高效检索的摘要最后双重索引写入向量存储嵌入和图存储边。去重这一步比听起来更关键。如果同一个实体出现在 50 份文档里Cognee 会把它合并成图里的单个节点带有 50 条入边。Agent 眼中的Alice不再是 50 个陌生人而是同一个人。管道默认是增量的只有新增或更新的文件才会重新处理。每个图节点都有对应的向量嵌入。这种双重表示是核心技巧可以从向量入找到语义相似的内容再从图出沿关系找到连接实体也可以反过来。这就是多跳查询能跑通、同时不牺牲语义搜索的原因。memify会自己学习的记忆memify()是 Cognee 和所有摄入再搜索工具的本质区别。它对图运行一个类强化学习的优化过程强化那些带来好检索的有用路径修剪掉一直没被访问的过时节点根据真实使用情况自动调节边的权重并通过识别隐性关系来补充派生事实。一个客服 Agent 的图会自然地强化穿过产品文档和退款政策的路径同时让很少被查的 HR 边慢慢衰减。图会随时间发展出自己对重要性的判断。把 Cognee 记忆接入真实 Agent下面是把 Cognee 整合进感知-思考-行动循环的完整模式import cogneefrom cognee import SearchTypeclass CogneeMemoryAgent: 带图-向量混合持久化记忆的 Agent def __init__(self, session_id: str default): self.llm_client OpenAI() self.session_id session_id asyncdef ingest(self, text: str, dataset: str main): await cognee.add(text, dataset) await cognee.cognify([dataset]) asyncdef recall(self, query: str) - str: results await cognee.search( query_textquery, query_typeSearchType.GRAPH_COMPLETION, session_idself.session_id, ) return results[0] if results else asyncdef chat(self, user_input: str) - str: context await self.recall(user_input) messages [ {role: system, content: 你是一个有帮助的助手请使用记忆上下文回答。}, {role: system, content: f记忆上下文\n{context}}, {role: user, content: user_input}, ] response self.llm_client.chat.completions.create( modelgpt-4o-mini, messagesmessages ) reply response.choices[0].message.content await cognee.add( fUser: {user_input}\nAssistant: {reply}, conversations ) await cognee.cognify([conversations]) return reply记忆循环摄入、提取、存储、检索、回应、再存储。每一轮对话都在丰富知识图谱增量处理意味着只需为新内容付出索引代价。会话记忆还能自动处理代词解析await cognee.search(query_textAlice 住在哪里, session_idconv_1)await cognee.search(query_text她是做什么工作的, session_idconv_1)# 她会从会话上下文中解析为 Alice多租户也是图层面的原生能力通过每个数据集的权限读、写、删除、分享实现——不是命名空间隔离是真正的图级隔离。该怎么选如果查询只需要相似性搜索“找一段和这个类似的对话”纯向量记忆够用。一旦查询需要跨越实体边界“Alice 的项目受周二宕机影响了吗”就需要图遍历。自己把向量、图和关系型存储拼起来当然可以但走这条路的团队通常要烧掉好几周的基础设施工作最终得到的记忆层还不会从自身的使用中学习。pip install一下四个异步调用就能跑起来。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】