打造永不失忆的 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 就是一个循环：感知、思考、行动。

classAgent:    """最简 AI agent：感知、思考、行动"""    def__init__(self):        self.client = anthropic.Anthropic()        self.model = "claude-sonnet-4-20250514"    defrun(self, user_input: str) -> str:        response = self.client.messages.create(            model=self.model,            max_tokens=1024,            messages=[{"role": "user", "content": user_input}],        )        return response.content[0].text

告诉它"我有 4 个苹果"，再问"我吃了一个，还剩几个？"——它完全不知道你在说哪里的苹果。每次调用都活在自己的孤岛里。

第一层：Python 列表

所有人最先想到的修法：

classAgent:    def__init__(self):        self.client = anthropic.Anthropic()        self.messages = []  # 全部"记忆"就是一个列表    defchat(self, user_input: str) -> str:        self.messages.append({"role": "user", "content": user_input})        response = self.client.messages.create(            model="claude-sonnet-4-20250514",            max_tokens=1024,            messages=self.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 文件来维护状态。

classMarkdownMemoryAgent:    def__init__(self):        self.client = anthropic.Anthropic()        self.history_file = Path("memory/conversation_history.md")        self.facts_file = Path("memory/known_facts.md")    defsave_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")    defload_history(self) -> str:        if self.history_file.exists():            return self.history_file.read_text()        return""    defchat(self, user_input: str) -> str:        self.save_to_disk("user", user_input)        history = self.load_history()        response = self.client.messages.create(            model="claude-sonnet-4-20250514",            max_tokens=1024,            system=f"Previous 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 换成 Postgres，LanceDB 换成 Qdrant/Pinecone/pgvector，Kuzu 换成 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 SearchTypeclassCogneeMemoryAgent:    """带图-向量混合持久化记忆的 Agent"""    def__init__(self, session_id: str = "default"):        self.llm_client = OpenAI()        self.session_id = session_id    asyncdefingest(self, text: str, dataset: str = "main"):        await cognee.add(text, dataset)        await cognee.cognify([dataset])    asyncdefrecall(self, query: str) -> str:        results = await cognee.search(            query_text=query,            query_type=SearchType.GRAPH_COMPLETION,            session_id=self.session_id,        )        return results[0] if results else""    asyncdefchat(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(            model="gpt-4o-mini", messages=messages        )        reply = response.choices[0].message.content        await cognee.add(            f"User: {user_input}\nAssistant: {reply}",            "conversations"        )        await cognee.cognify(["conversations"])        return reply

记忆循环：摄入、提取、存储、检索、回应、再存储。每一轮对话都在丰富知识图谱，增量处理意味着只需为新内容付出索引代价。

会话记忆还能自动处理代词解析：

await cognee.search(query_text="Alice 住在哪里？", session_id="conv_1")await cognee.search(query_text="她是做什么工作的？", session_id="conv_1")# "她"会从会话上下文中解析为 Alice

多租户也是图层面的原生能力，通过每个数据集的权限（读、写、删除、分享）实现——不是命名空间隔离，是真正的图级隔离。

---

该怎么选

如果查询只需要相似性搜索（“找一段和这个类似的对话”），纯向量记忆够用。一旦查询需要跨越实体边界（“Alice 的项目受周二宕机影响了吗？”），就需要图遍历。

自己把向量、图和关系型存储拼起来当然可以，但走这条路的团队通常要烧掉好几周的基础设施工作，最终得到的记忆层还不会从自身的使用中学习。

pip install 一下，四个异步调用，就能跑起来。

说真的，这两年看着身边一个个搞Java、C++、前端、数据、架构的开始卷大模型，挺唏嘘的。大家最开始都是写接口、搞Spring Boot、连数据库、配Redis，稳稳当当过日子。

结果GPT、DeepSeek火了之后，整条线上的人都开始有点慌了，大家都在想：“我是不是要学大模型，不然这饭碗还能保多久？”

我先给出最直接的答案：一定要把现有的技术和大模型结合起来，而不是抛弃你们现有技术！掌握AI能力的Java工程师比纯Java岗要吃香的多。

即使现在裁员、降薪、团队解散的比比皆是……但后续的趋势一定是AI应用落地！大模型方向才是实现职业升级、提升薪资待遇的绝佳机遇！

这绝非空谈。数据说话

2025年的最后一个月，脉脉高聘发布了《2025年度人才迁徙报告》，披露了2025年前10个月的招聘市场现状。

AI领域的人才需求呈现出极为迫切的“井喷”态势

2025年前10个月，新发AI岗位量同比增长543%，9月单月同比增幅超11倍。同时，在薪资方面，AI领域也显著领先。其中，月薪排名前20的高薪岗位平均月薪均超过6万元，而这些席位大部分被AI研发岗占据。

与此相对应，市场为AI人才支付了显著的溢价：算法工程师中，专攻AIGC方向的岗位平均薪资较普通算法工程师高出近18%；产品经理岗位中，AI方向的产品经理薪资也领先约20%。

当你意识到“技术+AI”是个人突围的最佳路径时，整个就业市场的数据也印证了同一个事实：AI大模型正成为高薪机会的最大源头。

最后

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。

我整理出这套 AI 大模型突围资料包【允许白嫖】：

• ✅从入门到精通的全套视频教程
• ✅AI大模型学习路线图（0基础到项目实战仅需90天）
• ✅大模型书籍与技术文档PDF
• ✅各大厂大模型面试题目详解
• ✅640套AI大模型报告合集
• ✅大模型入门实战训练

这份完整版的大模型 AI 学习和面试资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

①从入门到精通的全套视频教程

包含提示词工程、RAG、Agent等技术点

② AI大模型学习路线图（0基础到项目实战仅需90天）

全过程AI大模型学习路线

③学习电子书籍和技术文档

市面上的大模型书籍确实太多了，这些是我精选出来的

④各大厂大模型面试题目详解

⑤640套AI大模型报告合集

⑥大模型入门实战训练

👉获取方式：
有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓