近几年，大模型应用正在发生显著变化。模型能够理解更长的文本、调用更多工具，也开始进入客服、运维、研发和数据分析等真实业务。AI 不再局限于回答某个问题，而是逐步参与任务执行、结果分析和后续决策。当一次问答变成一项持续进行的工作，一个新的问题也随之浮出水面：如何记住过去？
这里的记住，远不止保存聊天记录那么简单。Agent 既要知道任务进行到了哪里、尝试过哪些方案、哪些方法已经失败、用户有什么偏好，也需要掌握完成任务所依赖的业务知识。
以 MARS3 的研发和运维为例，一个 Agent 如果要协助解释参数、分析代码或者排查问题，就需要理解 MARS3 的架构设计、存储机制、参数含义和历史案例。这些内容可能来自产品文档、设计方案和技术文章，也可能来自过去的讨论、测试和故障处理记录。当它们能够被持续保存和组织，并在具体任务中重新调用时，也就成为了 Agent 可以利用的记忆。
因此，当 AI 开始持续工作，记忆也就从一个辅助功能，变成了需要单独解决的问题。
对于一次性的问答来说，记忆并没有那么重要。用户提出问题，模型给出答案，本次交互便宣告结束。但对于 Agent 来说截然不同。它可能需要连续执行数十个步骤，调用数据库、搜索引擎、代码仓库和业务系统，并根据每一步返回的结果不断调整后续行动。有些任务持续几分钟，有些任务可能跨越几天，甚至需要在下次会话中继续。
一旦任务链条被拉长，记不住就不再只是偶尔答错一个问题。比如一个 Agent 可能不记得用户已经明确说过的偏好；不清楚上一次任务停在什么位置；可能反复尝试已经被证明无效的方法；也无法将某次成功排障留下的经验用于下一次任务。
一种最直接的做法，是将全部历史对话重新塞给模型，或者在提示词中附上任务摘要。但随着 Agent 工作时间变长，历史信息会越来越繁杂。哪些内容值得保留，哪些只是临时过程，哪些结论已经过时，很快就不再是一个简单的 Prompt 工程问题。
Agent 能否真正参与持续工作，很大程度上取决于它能否逐步积累对用户、业务和任务的理解。如果每一次执行的过程、结果与反馈都随着会话结束而消失，那么它完成的仍然只是一次次彼此孤立的任务，无法从过去的工作中积累经验。这也正是 Agent Memory 开始受到关注的原因。
随着大模型能力的不断提升，上下文窗口也在快速增长。过去，128K 已经被视为长上下文；如今，主流模型已经能够处理百万 Token 级别的输入。几本书、上千页资料，理论上都可以一次交给模型。因此，很多人自然会产生一个疑问：既然模型已经能一次读取大量内容，为什么还需要专门的记忆系统？
我们不妨将上下文理解成一张办公桌。模型当前需要使用的文档、对话和任务指令，都可以放在这张桌子上。但桌子再大，它仍然只是桌子。随着内容越来越多，旧信息需要被裁剪、压缩或替换。即使上下文窗口足够大，把所有历史内容原封不动地放进去，也会带来成本、延迟和信息噪声。
而记忆，更像是一套经过整理的档案系统。当材料不断增加时，仍然需要决定哪些内容应该继续放在手边，哪些可以收起来，哪些已经失效。下一次工作开始时，还要从大量历史记录中重新找出真正相关的部分。记忆系统承担的就是这类工作：选择保存什么，怎样组织，在什么时候重新找到，以及何时更新或删除。
说到从大量历史信息中寻找相关内容，我们很容易联想到 RAG。但 RAG 解决的主要是外部知识检索，和 Agent 记忆仍有区别。RAG 更擅长从产品手册、知识库和业务文档中寻找当前问题需要的资料。比如用户询问退款规则，系统可以检索对应的制度说明。Agent Memory 还要处理运行过程中产生的信息：用户偏好、任务进度、工具调用结果、历史决策和执行反馈。知识库负责告诉 Agent "通常应该怎样做"，记忆则还要告诉它这个用户"以前要求怎样做"、"这个环境中已经做过什么"等等。
最近两年，围绕 Agent 长期记忆的项目开始集中出现，它们的实现路线各不相同，但都在试图让 Agent 跨越单次会话，保存并利用过去的信息和经历。这些项目的出现，说明记忆正在逐渐从 Agent 框架里的一个附加模块，逐渐变成一项需要单独设计和管理的基础能力。Cognee 便是其中具有代表性的开源项目之一。
简单来说，Cognee 是一套面向 AI 应用和 Agent 的记忆基础设施。它将文档、业务数据以及 Agent 运行过程中产生的信息，组织成后续可以检索和使用的记忆，并在每一次模型调用时，为其提供与当前任务相关的上下文。这里最重要的两个关键词，是组织和使用。
企业已经积累了大量产品文档、客户记录、会议纪要、故障案例、操作日志和项目决策。与此同时，Agent 在执行任务的过程中，还会持续产生用户偏好、工具调用结果、执行状态、成功经验和失败原因。如果只是将这些内容原样保存下来，它们仍然只是不断增长的数据。哪些信息值得保留，彼此之间有什么联系，什么时候应该重新找回，以及信息发生变化后如何更新，才是 Cognee 关注的问题。它希望将企业已有的知识与 Agent 运行过程中形成的新经验放在同一套记忆体系中，让 Agent 既能从已有资料中寻找答案，也能在后续任务中利用过去的交互和执行结果。
Cognee 的核心操作可以概括为 remember、recall、improve 和 forget，直译过来便是"记住"、"找回"、"完善"和"遗忘"。
以数据库运维场景为例，假设一个 Agent 正在协助维护生产数据库。日常运行中，可以通过 remember 将产品手册、集群信息、历史工单、操作记录，以及用户确认过的环境特征保存下来。
假设某一天，生产数据库再次出现内存异常。Agent 便可以通过 recall 找回与当前问题相关的记忆：这套集群过去是否发生过类似故障，当时执行过哪些排查，哪些方案没有生效，最终又是如何恢复的。相比只查询一份产品手册，这些来自真实环境的历史经历，通常更接近当前问题。
故障解决后，可以通过 improve 进一步整理和完善已有记忆，将值得保留的 Session 信息纳入长期记忆。经过确认的故障原因、有效的排查方法和最终处理结果，便能够在后续任务中被重新利用。
如果后来发现某项判断错误、集群架构发生了变化，或者某些信息不应继续保留，则可以通过 forget 将对应记忆删除，避免过期或错误信息继续影响后续判断。
以上四个操作对应的，正是一段完整的记忆生命周期：在工作中记住信息，在需要时找回历史，从结果中完善经验，并在信息失效后将其遗忘。
产品手册可以告诉 Agent 某个参数的含义，监控系统可以反映当前发生的异常，历史工单和操作记录则保留了特定环境中的真实经验。Cognee 希望做的，是让这些信息不再随着一次任务结束而消失，而是成为后续任务可以继续利用的记忆。
对于 Agent Memory 来说，保存信息只是第一步。
如果每一句对话、每一次工具返回和每一个中间过程都被永久保留，记忆很快就会充满重复、冲突和过时信息。随着检索范围不断扩大，真正有价值的内容反而容易被噪声淹没。
记忆本身也未必可靠。它可能来自已经失效的文档，可能只是用户在特定情境下的临时表达，也可能包含模型对原始信息的错误理解。如果这些内容没有经过筛选和更新，就可能在后续任务中继续影响 Agent 的判断。
因此，一套真正可用的记忆系统，需要处理信息的筛选、更新与遗忘，也需要明确每条记忆来自哪里、属于谁，以及谁有权访问。走到这一步，Agent Memory 所涉及的已经不只是上下文管理。数据如何组织、如何检索、保留多久、由谁访问，都会影响它能否真正进入业务系统。
如果说模型决定了 Agent 能够处理什么问题，工具决定了它能够连接和操作哪些系统，那么记忆决定的，则是过去的工作能否对下一次任务产生价值。
Cognee 是这一方向上值得关注的开源项目。它尝试在模型之外提供一层持续形成、召回和管理记忆的能力，让 Agent 不必在每次会话结束后重新开始。
文档、对话和执行经历进入 Cognee 后，究竟会怎样被组织成记忆？语义检索、知识关系、Session 与不同类型的存储又是如何协同工作的？下一篇，我们将进一步拆解 Cognee 的内部运行机制。
