CrewAI 认知记忆系统：智能体如何真正学会

很多智能体系统每次运行都从零开始。系统和它的智能体们重复发现相同的上下文，调用相同的工具，犯相同的错误，每一次都是如此。这不仅效率低下，更严重限制了智能体系统能做什么。

一个显而易见的解决方案是给系统加上某种记忆功能，存储一切，用向量相似性检索，然后祈祷好运。但简单的记忆实现会带来自己的问题，比如上下文膨胀、过时信息污染新执行过程，智能体产生幻觉，最终用一个更糟的问题替换了原来的问题。

我们亲身经历过这些。CrewAI 处理了数十亿次智能体执行，我们看到了当记忆被当作存储问题处理时会发生什么，也看到了当它不是存储问题时会发生什么。

所以我们从零重构了整个记忆系统，专注于真正支持生产环境的智能体系统。不是作为带搜索层的数据库，而是作为一个认知过程——一个能选择性编码、自主解决矛盾、有意识遗忘、并且知道自己不知道什么的系统。我们有机会使用 LanceDB 作为这个实现的底层数据库，这也带来了不少惊喜，从超级简单的设置、快速的运行速度到非常前沿的技术。

下面就是我们如何构建它以及如何使用它。

为什么简单的记忆会让情况更糟

市场对无状态智能体的回应是附加一个记忆即服务，存储一切，嵌入向量，按相似性检索。有些方法做得干净利落，有些则给你一个带命名空间的键值存储，剩下的就交给你自己了。

更复杂的选项构建了时间知识图谱，追踪事实何时改变，这些都是令人印象深刻的基础设施，但终究只是基础设施。

模式到处都一样：记忆被当作存储和检索问题。开发者负责决定什么值得记住，如何组织，何时检索结果足够可信可以采取行动，以及当两个记忆相互矛盾时该怎么办。你的智能体周一学了一件事，周五又学了一件与之矛盾的事。现在它两个都记住了。

而且它们都没有问那个真正重要的问题：检索结果是否足够可信可以采取行动？它们都返回结果，但没有一个会说“我不确定，让我再深入看看。”

这就是当你把记忆当作数据而非认知时，在规模上会发生的事情。

记忆是认知，不是存储

人类记忆不是通过存储一切并按相似性搜索来工作的。它选择性编码，决定什么重要以及它适合放在哪里；它巩固记忆，解决已知信息与新学信息之间的冲突；它适应性检索，有时瞬间完成，有时通过逐步梳理已知信息；它还会遗忘，不是偶然，而是因为遗忘是保持记忆有用的关键。

仔细想想，记忆本身就很像一个智能体系统，而这正是我们遵循的模型。CrewAI 的新认知记忆系统围绕五个认知操作构建：编码、巩固、回忆、提取和遗忘。每一个都是主动过程，而不是被动的读或写。所以当你存储一个记忆时，系统会分析其内容，分配重要性，检测矛盾，并将其放置在一个自组织的层次结构中。当你检索时，系统会评估自己的置信度，并决定是否要深入挖掘。

结果是五个方法。以下是完整的 API。

CrewAI 的认知记忆

CrewAI 的新认知记忆本身就是一个智能体系统，它在幕后使用 CrewAI Flows，完全是“梦中梦”。它可以在你的智能体系统中的任何地方使用：

• 你可以在单个智能体上使用它。
• 在 Crew 中开启它，其所有智能体会自动跨任务加载和持久化记忆，但它们也可以在上下文重要时主动使用记忆和回忆作为工具。
• 在 Flow 中使用它，你会得到一个补充状态的持久层，状态处理单次运行中的临时信息，而记忆处理跨运行应该累积的信息。

另一个很酷的实现细节是，你可以随身携带它，让不同的智能体访问相同的记忆，同时在如何回忆上设置不同的参数，比如为回忆的组成部分（如记忆的半衰期等）设置不同的权重。

原生实现采用了一个极其简单的 DSL，符合 CrewAI 一贯的风格，所以那五个认知操作映射到五个方法：

from crewai.memory import Memory

# 新的认知记忆类
memory = Memory()

# 直接添加新记忆
memory.remember("我们决定使用 PostgreSQL 作为用户数据库。")

# 直接回忆记忆
results = memory.recall("我们使用什么数据库？")

# 从字符串中提取可记忆的事实
facts = memory.extract_memories("包含许多可能事实的长文本")

# 获取记忆树
memory.tree()

# 遗忘某些记忆
from datetime import datetime, timedelta
memory.forget(scope="/", older_than=datetime.utcnow() - timedelta(days=30))

每个方法都会触发自己的认知管道。

remember() 不仅仅是存储，它会分析你保存的内容，检测与已知信息的矛盾，并解决它们。

recall() 不仅仅是搜索，它会评估自己的置信度，并在不确定时深入挖掘。

记忆系统本身是智能体化的，每个操作都是一个推理过程，而不是简单的读或写。

在 Crew 中，只需一行：

crew = Crew(
    agents=[researcher, analyst],
    tasks=[...],
    memory=True,
)

智能体在每个任务前加载相关上下文，并在学习后持久化所学内容。它们还可以将记忆和回忆作为工具使用，智能体自己决定什么时候值得存储，或者什么时候需要过去的上下文。系统默认处理持久化，当智能体更了解情况时，它会接管。

在 Flow 中：

class ResearchFlow(Flow):
    @start()
    def research(self):
        past = self.recall("关于这个主题的先前发现")
        self.remember(f"发现：{findings}", scope="/research")

    @listen(research)
    def analyze(self):
        context = self.recall("所有研究发现")

你不再需要为那些本应被记住的东西过度设计状态。

把状态看作是处理当前重要的事情，而记忆是处理下次重要的事情。

现在让我们看看幕后到底发生了什么。

记忆幕后：两个认知流

有两个主要的智能体系统为这个认知记忆提供动力：一个编码流和一个回忆流。

编码智能体系统

当你调用 remember() 时，CrewAI Flow 会运行一个编码管道，分析内容并产生一个 MemoryAnalysis：

class MemoryAnalysis(BaseModel):
    scope: str          # 这个记忆属于层次结构中的哪个位置
    categories: list    # 这是关于什么的
    importance: float   # 这有多重要 (0-1)

系统决定一个记忆属于哪里，它是关于什么的，以及它有多重要，所有这些都不需要你指定任何东西。没有预定义的模式，结构实际上是从系统本身中涌现出来的。当你想要控制时，可以覆盖范围、类别和重要性。

每次 remember() 调用也会触发对现有记忆的相似性搜索，就像人类学习新事物时，会找到方法将它们聚类在一起，甚至基于此推断新信息。

举个例子：

你上个月存储了“我们使用 PostgreSQL 作为用户数据库”。现在你正在存储“我们上周迁移到了 MySQL”。

在其他系统中，两者共存，检索结果就像抛硬币。在认知记忆中，巩固逻辑检测到相似性，识别出矛盾，并产生一个计划：更新旧记录的内容，保留迁移上下文，删除过时的事实，这样你得到的是一个连贯的记忆，而不是两个相互竞争的记忆。

在 CrewAI 的记忆中，编码流中的巩固步骤检测相似性，识别矛盾，并产生一个计划：更新旧记录的内容，保留迁移上下文，删除过时的事实，所以你最终得到一个连贯的记忆，而不是两个相互竞争的记忆。

回忆智能体系统

回忆流做了两件其他系统不做的事情：它根据真正重要的因素对结果进行评分，并且知道何时需要更深入搜索。

复合评分混合了三个信号，而不是仅仅一个：相似性、新近性和重要性，对每个应用特定的权重（你也可以在记忆的访问层完全自定义这些权重，而记忆本身保持不变）。

score = (相似性 × w_sim) + (新近性 × w_rec) + (重要性 × w_imp)

这就是为什么六个月前的一个关键架构决策会排在昨天提到“数据库”的一个琐碎笔记前面。纯向量搜索返回那个琐碎的笔记。但认知复合评分返回的是那个决策。

它分析查询，选择要搜索的范围，检索候选记忆，然后评估自己的置信度。如果需要，它会搜索得更深、更广，并尝试不同的策略，同时跟踪缺失的信息作为 evidence_gaps。

原子记忆

智能体不是以干净、独立的事实来思考的。比如一个研究智能体返回一份 500 字的摘要，同时一个分析智能体生成一份涵盖六个主题的报告。如果你把其中任何一个存储为一个记忆，你就回到了“信息块”问题，检索时在你需要一个事实时拉出所有内容，而巩固无法解决埋在一个段落里的矛盾。

作为我们新认知记忆的一部分，有能力从智能体执行和更大的文本块中提取记忆。extract_memories() 将原始输出分解为自包含的原子事实：

raw = """After reviewing the infrastructure options, the team 
recommends PostgreSQL for the user database due to its JSONB 
support. Estimated cost is $2,400/month on RDS. The compliance 
team flagged that all user data must stay in EU regions. 
DevOps prefers managed services over self-hosted to reduce 
on-call burden."""

facts = memory.extract_memories(raw)
# → "Team recommends PostgreSQL for user database due to JSONB support"
# → "Estimated database cost is $2,400/month on RDS"  
# → "Compliance requires all user data to remain in EU regions"
# → "DevOps prefers managed services over self-hosted"

在上面的例子中，每个提取的事实都独立地进入完整的认知管道。数据库建议以高重要性编码在 /infrastructure/database 下，而合规要求则有自己的范围在 /compliance 下。所以后来当你存储“我们正在切换到 MySQL”时，巩固会专门针对 PostgreSQL 建议进行解决，而不是针对一个还提到成本估算和团队偏好的信息块。

这也是 Crew 中自动记忆功能的动力。当一个智能体完成一个设置了 memory=True 的任务时，系统会对输出运行提取，将其分解为原子事实，并将每一个通过编码和巩固管道。你只需设置一个标志，系统就会为你处理一切。

这解锁了什么

真正的转变不是你的智能体记住了东西，而是你的智能体系统能够累积进化。

没有记忆，每次运行都是独立的，大致相同的成本、相同的延迟、相同的发现过程、相同的上限。但使用认知记忆，每次运行都让下一次变得更好。一个处理了一千个客户工单的智能体不仅仅有一千个记忆。它已经巩固了模式，解决了矛盾，构建了重要事项的层次结构，所以第 1001 次运行与第 1 次运行有根本的不同——它更快、更便宜、更可靠，因为系统已经学习并进化了。

这也极大地改变了你可以构建的东西：

从纠正中学习的人机协同系统。 一个带有 @human_feedback(learn=True) 的 Flow 不仅仅是收集批准，它将每次纠正提炼成一个可泛化的教训，并将其存储在记忆中。下次运行时，系统在人类甚至看到输出之前就回忆并应用这些教训。曾经需要重写每份草稿的审阅者现在只需批准，因为系统已经学会了他们在乎什么。

积累专业知识的研究系统。 一个每周运行的研究 Flow 不会每次都从头开始，它会回忆之前的发现，识别变化，并专注于增量。几次执行后，它不是在研究，而是在维护一个活的知识库，每次循环都变得更加精炼。

具有共享理解的多智能体团队。 智能体共享记忆，但回忆方式不同。一个规划智能体权重重要性，而一个执行智能体权重新近性，这样你就能拥有相同的知识，但能够通过不同的视角来利用它。就像一个团队，架构师记住原则，工程师记住上次冲刺交付了什么。

从执行转向探索的系统。 这可能是最大的解锁：无状态智能体只能执行，给定输入，产生输出。拥有认知记忆的智能体可以探索，尝试一种方法，记住什么有效，在下次运行时改进。它们制定策略。它们在“变得更好”这件事上变得更好。

本文描述的每一个认知操作——编码、巩固、适应性回忆——本身就是一个 CrewAI Flow。记忆系统是一个建立在与你构建自己系统相同平台上的智能体系统。我们能用我们自己的产品来构建我们的产品，这太棒了，证明了当问题足够困难需要它时，这个架构是站得住脚的。

自己试试看！

很简单：

pip install crewai

然后你可以在 Python shell 中快速尝试一个单独的智能体：

from crewai import Agent

agent = Agent(
    role="Technical Advisor",
    goal="Help the team make infrastructure decisions",
    backstory="Senior engineer with deep knowledge of agentic systems",
    memory=True
)

agent.kickoff("what are the benefits of using CrewAI to build agentic systems?")

之后，你可以在同一目录下导航所有生成的记忆：

crewai memory