1. 项目概述：从单兵作战到团队协作的智能体进化

如果你已经玩过一阵子CrewAI，搭建过几个简单的任务链，可能会发现一个问题：单个Agent（智能体）的能力终究是有限的。它就像一个精通某一领域的专家，但当面对一个需要多步骤、多领域知识协作的复杂项目时，单打独斗就显得力不从心了。这时，你就需要引入“Crew”这个概念。简单来说， Crew就是一个由多个Agent组成的、有明确分工和协作流程的智能体团队 。它不再是让一个Agent吭哧吭哧干完所有活，而是像组建一个项目组一样，让产品经理、工程师、设计师、测试等各司其职，通过高效的协作流程来共同完成一个宏大的目标。

但今天我们要聊的，远不止于“分工协作”这个基础概念。标题里点出的“记忆”功能，才是让Crew从“机械流水线”蜕变为“有经验、能成长的智能团队”的核心魔法。想象一下，如果你的项目团队每接一个新项目，都像失忆一样从头开始，不记得上次客户喜欢什么风格，不记得某个技术方案曾踩过什么坑，那效率得多低？传统的AI工作流往往就有这个问题，每次执行都是“一次性”的。而CrewAI引入的短期记忆、长期记忆和实体记忆，就是为了解决这个痛点。它让Agent们在协作过程中不仅能交流当前任务信息（短期记忆），还能积累个人经验（长期记忆），甚至记住关于特定人、事、物的关键事实（实体记忆）。这直接赋予了Crew学习和进化的能力，让它们越用越聪明，执行策略也越来越精准。

所以，这篇教程要解决的，就是如何利用Crew的记忆系统，来显著提升团队的执行力和决策质量。无论你是想构建一个能持续优化营销文案的创作团队，还是一个能记住用户偏好并提供个性化推荐的服务小组，理解并应用记忆功能都是关键一步。接下来，我会带你彻底拆解Crew的三种记忆机制，并通过一个完整的源码案例，展示如何将它们落地到实际项目中，让你打造的AI团队真正拥有“经验”和“学习”能力。

2. Crew与记忆系统深度解析：不止于任务传递

在深入代码之前，我们必须先建立起对Crew及其记忆系统的清晰认知。很多人把Crew简单理解为多个Agent的顺序调用，这其实低估了它的设计价值。一个设计良好的Crew，其核心在于 角色定义、协作流程与共享上下文 ，而记忆系统则是丰富这个上下文、让协作产生“化学反应”的关键。

2.1 Crew的构成：角色、任务与流程

一个Crew通常包含三个核心要素：

  1. Agents（智能体） ：团队的成员。每个Agent都有明确的角色（如“资深Python开发”、“挑剔的质量保证专家”）、一个清晰的目标（如“编写高效且可读的代码”、“找出所有潜在缺陷”）以及背后的LLM大模型驱动。角色的设定决定了Agent思考问题的视角和专长领域。
  2. Tasks（任务） ：团队要完成的具体工作项。每个任务会被分配给最合适的Agent，包含具体的描述、期望的输出以及所需的上下文信息。任务之间可以定义依赖关系，形成工作流。
  3. Process（流程） ：团队协作的章程。CrewAI支持几种预定义的流程，比如 SequentialProcess （顺序执行，一个接一个）、 HierarchicalProcess （分层执行，有管理者协调）等。流程决定了任务如何排序、Agent之间如何传递信息和结果。

当这三者结合，Crew就运转起来了。但基础的运转只是信息的线性传递：Task A完成，把结果传给Task B。记忆系统的引入，打破了这种线性的、一次性的信息流，引入了 状态持久化和经验复用 的维度。

2.2 记忆的三重境界：短期、长期与实体

CrewAI的记忆系统主要分为三类，它们服务于不同粒度、不同生命周期的信息存储与召回：

2.2.1 短期记忆（Short-Term Memory） 这可以理解为Agent的“工作记忆”或“会话缓存”。它主要存储 当前执行上下文中产生的重要信息 。例如，在一个代码评审Crew中，当“开发Agent”生成了一段代码后，这段代码以及相关的设计思路，可能会被存入短期记忆。紧接着，“测试Agent”在编写测试用例时，就可以直接从短期记忆中召回这段代码进行分析，而不需要重新生成或通过复杂的参数传递。

  • 特点 ：生命周期短，通常与一次Crew的执行周期绑定。速度快，访问延迟低。
  • 类比 ：就像团队开会时的白板，记录了当前讨论的要点，会议结束（任务完成）后，白板就会被擦掉。

2.2.2 长期记忆（Long-Term Memory） 这是Agent的“个人经验库”或“知识档案”。它用于存储Agent在 多次执行任务过程中学到的、有价值的经验、知识或模式 。例如，一个“文案优化Agent”在经历了数十次营销文案改写后，可能会总结出“在标题中使用数字能提升20%的点击率”这条经验，并将其存入长期记忆。当下次遇到类似的优化任务时，它就可以主动应用这条经验。

  • 特点 ：生命周期长，跨会话持久化。存储的信息更为抽象和概括，是提炼后的知识。
  • 类比 ：就像每个团队成员的个人笔记本，里面记录了他从业多年来总结的最佳实践、教训和心得，这些知识会伴随他参与每一个新项目。

2.2.3 实体记忆（Entity Memory） 这是一种 围绕特定实体（如人、项目、产品） 的事实性记忆。它专注于存储与某个实体相关的关键属性、关系和事件。例如，在一个客户服务Crew中，可以建立一个关于“客户A”的实体记忆，记录“客户A偏好简洁的沟通风格”、“上次投诉过物流问题”等。当Crew再次服务该客户时，所有Agent都能查询到这些信息，从而提供高度个性化的服务。

  • 特点 ：以实体为中心进行组织，信息结构化程度高。非常适合需要维护状态、实现个性化的场景。
  • 类比 ：就像公司的CRM（客户关系管理）系统，为每一个客户建立了一个档案，记录了所有与该客户的交互历史和相关细节。

核心理解 ：短期记忆关乎 本次任务 的上下文流畅性；长期记忆关乎Agent 个体能力 的持续成长；实体记忆关乎对 外部世界特定对象 的状态跟踪。三者结合，使得Crew不仅能处理单次任务，还能积累知识、理解对象，从而实现更智能的决策和更高效的执行。

3. 实战：构建一个带记忆的智能内容策划Crew

理论说得再多，不如一行代码。让我们来构建一个实际可用的Crew，它负责为一个科技博客策划每周的内容主题。这个Crew将包含三个Agent，并充分运用三种记忆。

场景设定 ：我们的目标是每周自动生成3个符合博客调性、避免重复、且能结合历史表现进行优化的内容主题建议。

3.1 环境准备与基础架构搭建

首先，确保你的环境已安装CrewAI。我们使用LangChain的ChatOpenAI作为LLM驱动，并使用CrewAI集成的记忆存储后端（这里为了演示方便，使用 MemoryStorage ，生产环境可考虑向量数据库）。

pip install crewai crewai-tools langchain-openai

接下来，我们搭建基础的项目结构，并初始化关键的组件：记忆存储、LLM和工具。

# main.py
import os
from crewai import Agent, Task, Crew, Process
from crewai.memory import MemoryStorage, ShortTermMemory, LongTermMemory, EntityMemory
from langchain_openai import ChatOpenAI
from datetime import datetime

# 1. 初始化记忆存储
# MemoryStorage 是CrewAI提供的统一存储接口，背后可以连接不同的数据库
memory_storage = MemoryStorage()

# 2. 初始化LLM
# 使用gpt-4o-mini以保证响应速度和成本，你也可以根据任务复杂度更换模型
llm = ChatOpenAI(
    model="gpt-4o-mini",
    temperature=0.7, # 保持一定的创造性
    openai_api_key=os.getenv("OPENAI_API_KEY")
)

# 3. 定义工具（可选）
# 例如，我们可以给研究员一个网络搜索工具，但本例中我们主要依赖记忆和LLM推理
# from crewai_tools import SerperDevTool
# search_tool = SerperDevTool()

3.2 创建具备记忆能力的Agents

我们将创建三个角色：趋势研究员、内容策划师和主编。

# 创建带有长期记忆的Agent
trend_researcher = Agent(
    role="资深科技趋势研究员",
    goal="识别并分析当前新兴的科技趋势与热点话题，确保内容的前沿性。",
    backstory="你是一位在科技行业有十年经验的分析师，对AI、区块链、云计算等领域的动态了如指掌，擅长从海量信息中提炼出真正有潜力的趋势。",
    llm=llm,
    memory=True, # 启用基础记忆功能
    long_term_memory=LongTermMemory(
        storage=memory_storage,
        # 设定长期记忆的“提炼”条件：当研究员成功识别出一个被主编采纳的趋势时，存储该经验。
        # `entity_type` 和 `entity_name` 用于关联实体记忆（可选）。
        config={
            "entity_type": "tech_trend",
            "entity_name": "weekly_topic"
        }
    ),
    verbose=True
)

# 创建带有短期和实体记忆的Agent
content_strategist = Agent(
    role="创意内容策划师",
    goal="将趋势转化为具体、有趣、适合目标读者（开发者）的博客主题。",
    backstory="你是一位极富创意的内容专家，擅长将枯燥的技术概念包装成引人入胜的故事和实操指南。你深知读者的痛点。",
    llm=llm,
    memory=True,
    short_term_memory=ShortTermMemory(
        storage=memory_storage,
        # 短期记忆主要缓存本次协作中研究员传递的趋势列表
        expiration=3600 # 设置过期时间为1小时（本次任务周期内有效）
    ),
    entity_memory=EntityMemory(
        storage=memory_storage,
        # 实体记忆将围绕“博客读者”和“历史主题”建立
        entities=["blog_reader_profile", "historical_topic"]
    ),
    verbose=True
)

# 创建主编，负责最终决策和质量把控，并利用所有记忆
chief_editor = Agent(
    role="主编",
    goal="从策划的主题中筛选出最优质的3个，确保主题的多样性、深度和与博客整体定位的一致性。",
    backstory="你是博客的掌舵人，对内容质量有严苛的要求。你不仅关注单篇文章的亮点，更关注内容矩阵的长期战略价值。",
    llm=llm,
    memory=True,
    # 主编需要访问所有类型的记忆来做综合决策
    long_term_memory=LongTermMemory(storage=memory_storage),
    short_term_memory=ShortTermMemory(storage=memory_storage, expiration=3600),
    entity_memory=EntityMemory(storage=memory_storage, entities=["historical_topic"]),
    verbose=True
)

关键点解析 ：

  • memory=True 是启用Agent基础记忆能力的开关。
  • 每个记忆类型都需要传入共享的 memory_storage ，这是Agent之间记忆互通的基础。
  • long_term_memory 的 config 参数可以用于精细化控制哪些经验值得存储。这里我们简单关联一个实体类型。
  • short_term_memory 的 expiration 参数很重要，它避免了无用信息无限期占用缓存。
  • entity_memory 的 entities 参数预定义了该Agent关心的实体类型，方便后续存储和查询。

3.3 设计串联记忆的任务链

任务的设计是触发记忆读写的关键。我们需要在任务描述中，明确指示Agent去使用或存储记忆。

# 任务1：趋势研究（研究员）
task_research = Task(
    description=(
        "现在是 {current_date}。请分析过去一周科技领域（重点：AI应用开发、云计算架构、开源工具）的主要动态。\n"
        "请执行以下操作：\n"
        "1. 列出3-5个你认为最值得关注的趋势或热点。\n"
        "2. **在开始分析前，查询你的长期记忆**，回顾历史上哪些类似的趋势最终产生了高价值内容。\n"
        "3. 将本次分析得出的核心趋势列表，存储到短期记忆中，以便策划师查阅。\n"
        "4. 如果发现某个趋势具有长期跟踪价值（例如‘AI Agent生态’），将其关键洞察存储到你的长期记忆中。\n"
        "输出格式：清晰的列表，每个趋势附简要说明和你的初步判断。"
    ),
    agent=trend_researcher,
    expected_output="一个包含3-5个科技趋势的列表，每个趋势有名称、简要说明和潜力分析。",
    # 注入当前日期作为上下文变量
    context={"current_date": datetime.now().strftime("%Y-%m-%d")}
)

# 任务2：主题策划（策划师）
task_brainstorm = Task(
    description=(
        "你已经从研究员那里获得了最新的趋势列表（请从短期记忆中读取）。\n"
        "你的工作是：\n"
        "1. 针对每一个趋势，构思2-3个具体的博客主题角度。主题要具体，例如不是‘AI编程’，而是‘使用CrewAI在30分钟内构建你的第一个智能体工作流’。\n"
        "2. **在构思前，查询实体记忆**：了解我们的‘博客读者画像’（他们是中级开发者，喜欢实战教程和深度解析），并回顾‘历史主题’实体，避免与过去三个月内的主题重复。\n"
        "3. 将本次生成的所有主题草稿存储到短期记忆中，供主编审阅。\n"
        "4. 根据本次策划，更新‘博客读者画像’实体记忆，例如记录‘近期读者对AI工具链集成类教程反馈热烈’。\n"
        "输出格式：按趋势分组，列出所有主题草稿。"
    ),
    agent=content_strategist,
    expected_output="一份结构化的主题脑暴清单，按趋势分组，每个主题有标题和一句话描述。",
    # 定义任务依赖，确保研究员先完成任务
    dependencies=[task_research]
)

# 任务3：最终评审与定稿（主编）
task_finalize = Task(
    description=(
        "策划师已经提供了丰富的主题草稿（请从短期记忆中读取）。\n"
        "你的职责是：\n"
        "1. 从所有草稿中，精选出3个最符合以下标准的主题：前沿性、实操性、受众匹配度、内容独特性。\n"
        "2. **综合运用你的所有记忆**：\n"
        "   a) 查询长期记忆：基于你作为主编的经验，哪些类型的内容长期表现（如阅读量、分享率）更好？\n"
        "   b) 查询实体记忆：再次核对‘历史主题’，确保绝对不重复，并思考新主题如何与历史内容形成系列或互补。\n"
        "   c) 审视短期记忆中的趋势分析，确保最终主题与核心趋势强相关。\n"
        "3. 将最终选定的3个主题，以及选择理由，清晰输出。\n"
        "4. **将本次最终确定的主题列表，作为新的‘历史主题’记录，更新到实体记忆中**，供未来参考。\n"
        "输出格式：最终3个主题的详细方案，每个包含：最终标题、目标读者、内容大纲（3-4点）、选择理由。"
    ),
    agent=chief_editor,
    expected_output="一份详细的最终内容计划，包含3个主题的标题、大纲和决策依据。",
    dependencies=[task_brainstorm]
)

设计精髓 ：

  • 显式指令 ：在 description 中直接使用“查询你的长期记忆”、“从短期记忆中读取”、“更新实体记忆”等指令，明确告诉Agent何时、如何使用记忆功能。这是目前最可靠的驱动方式。
  • 上下文传递 ：通过短期记忆（ ShortTermMemory ）替代硬编码的参数传递，让任务间的数据流动更灵活、更符合“团队讨论”的自然感。
  • 经验闭环 ：在任务链的末端（主编任务），明确要求将本次工作的最终成果（选定主题）写回实体记忆。这就形成了一个“执行->学习->应用”的完整闭环，下次执行时，Crew就会“记得”它之前做过什么、效果如何。

3.4 组装Crew并执行

将Agent和Task组装成Crew，并选择 SequentialProcess 流程。

# 组装Crew
content_planning_crew = Crew(
    agents=[trend_researcher, content_strategist, chief_editor],
    tasks=[task_research, task_brainstorm, task_finalize],
    process=Process.sequential, # 顺序执行，适合有强依赖关系的任务链
    memory_storage=memory_storage, # 为整个Crew注入共享的记忆存储
    verbose=2 # 显示详细执行日志，方便调试
)

# 执行Crew
print("开始执行智能内容策划Crew...")
result = content_planning_crew.kickoff()
print("\n" + "="*50)
print("最终内容策划方案：")
print("="*50)
print(result)

执行这段代码，你将看到Crew的完整运行日志。研究员会先查询长期记忆（首次运行可能为空），然后进行分析并将趋势存入短期记忆；策划师读取短期记忆，并查询关于读者和历史的实体记忆，进行创意构思；主编综合所有记忆做出最终决策，并将结果写回历史主题实体。

4. 记忆系统的进阶配置与最佳实践

上面的例子展示了基本用法，但在实际生产环境中，你需要更精细地控制记忆系统。

4.1 记忆存储后端的选型与配置

MemoryStorage 默认使用内存存储，重启即丢失。对于长期记忆和实体记忆，你必须使用持久化存储。

# 示例：使用SQLite进行持久化存储（CrewAI内置支持）
from crewai.memory.storage.sqlite import SQLiteStorage

# 指定数据库文件路径
sqlite_storage = SQLiteStorage(database_path="./crew_memory.db")
memory_storage_persistent = MemoryStorage(storage_backend=sqlite_storage)

# 然后在创建Agent的LongTermMemory和EntityMemory时，使用这个持久化的memory_storage_persistent

选型建议 ：

  • 开发/测试 ：使用 SQLiteStorage ，简单轻量。
  • 生产环境 ：考虑使用 向量数据库 （如Chroma, Weaviate, Pinecone）来存储长期记忆。因为经验知识通常是语义化的，向量检索可以让你实现“查找相似经验”而不仅仅是“精确匹配关键词”。CrewAI未来版本可能会更深度集成向量存储。
  • 实体记忆 ：由于其高度结构化（属性-值对），使用关系型数据库（如PostgreSQL via SQLAlchemy）或文档数据库（如MongoDB）可能更合适。

4.2 控制记忆的读写：精度与成本的平衡

无节制地读写记忆，尤其是调用LLM来总结和存储长期记忆，会产生大量Token消耗。你需要策略。

1. 长期记忆的“提炼”策略 ： 不要存储所有中间结果。只在关键时刻触发。

# 在Task的description中，通过条件判断来引导存储
description="...如果本次代码评审发现了一个影响深远的架构设计模式，且该模式在未来项目中很可能复用，请将其核心思想存储到你的长期记忆中。"

2. 实体记忆的“结构化”存储 ： 尽量存储明确的事实，而非模糊的描述。这能提高查询准确性。

# 好的实体记忆更新
"更新‘客户A’实体：偏好风格=‘简洁’，上次投诉时间=‘2023-10-27’，投诉问题=‘物流延迟’"
# 差的实体记忆更新
"客户A好像不喜欢太啰嗦，上次有点不高兴因为送货问题。" # 过于模糊，不利于后续LLM理解。

3. 短期记忆的“清理”机制 ： 合理设置 expiration 时间。对于多阶段复杂任务，可以分阶段设置不同的短期记忆，或在任务结束时通过指令明确清除无用缓存。

4.3 调试与监控记忆内容

记忆系统是个黑盒？不，你可以查看它。

# 在执行Crew后，或在任何地方，通过storage后端查询记忆
# 假设我们想查看所有关于‘historical_topic’实体的记忆
from crewai.memory import EntityMemory

# 需要获取存储后端实例
storage = memory_storage.storage_backend # 这里根据你实际使用的backend调整

# 模拟查询：这是一个概念性示例，实际API可能因存储后端而异
# 通常你需要自己实现或使用后端提供的查询方法
# 例如，对于SQLiteStorage，你可能直接查询数据库
import sqlite3
conn = sqlite3.connect('./crew_memory.db')
cursor = conn.cursor()
cursor.execute("SELECT * FROM entity_memory WHERE entity_type = ?", ('historical_topic',))
print(cursor.fetchall())
conn.close()

更佳实践是在创建Crew时，设置 verbose=2 ，这样在日志中你会看到类似 [Memory] Storing to ShortTerm... 或 [Memory] Querying Entity... 的提示，了解记忆的读写时机。

5. 常见问题与避坑指南

在实际使用中，你肯定会遇到一些挑战。以下是我踩过坑后总结的经验。

问题1：Agent“忘记”使用记忆，或错误地使用了记忆。

  • 现象 ：在任务输出中，看不到记忆查询或存储的痕迹。
  • 排查 ：
    1. 首先检查Agent创建时是否设置了 memory=True 以及相应的记忆对象（ LongTermMemory(...) 等）。
    2. 最关键的一步 ：检查任务描述（ Task.description ）。LLM只会执行你明确指令它做的事。你必须用清晰、直接的语言告诉它“请查询你的长期记忆，看看我们之前关于XX有什么经验”或“请将本次讨论的结论Y存储到实体Z的记忆中”。指令越模糊，执行越随机。
    3. 设置 verbose=2 查看详细日志，确认记忆操作是否被触发。
  • 解决 ：重写任务描述，将记忆操作作为明确的步骤（如“第一步：查询...；第二步：基于查询结果，执行...”）。

问题2：记忆内容混乱或无关信息过多。

  • 现象 ：Agent查询记忆时返回了大量无关内容，干扰了当前任务的判断。
  • 原因 ：记忆的存储缺乏“质量控制”，或者查询条件太宽泛。
  • 解决 ：
    • 存储侧 ：在指令中限定存储条件。例如，“仅当这个解决方案被验证为最优时，才将其存入长期记忆”。
    • 查询侧 ：在查询指令中提供更具体的上下文。例如，“查询我们在过去一个月内，关于‘Python异步编程’性能优化方面的长期记忆”，而不是简单地“查询你的长期记忆”。
    • 技术侧 ：如果使用向量存储，确保嵌入模型合适，并且查询时使用高质量的查询语句进行语义搜索。

问题3：多Agent记忆冲突或污染。

  • 现象 ：Agent A 写入了某个实体记忆，Agent B 读取时得到了意外结果，或者覆盖了A写入的数据。
  • 原因 ：多个Agent对同一实体进行并发或顺序读写，缺乏锁或版本管理机制。
  • 解决 ：
    • 设计流程 ：在任务设计中，明确某个实体的记忆“负责人”。例如，规定只有“主编”Agent可以写入和更新“历史主题”实体，其他Agent只读。
    • 使用更细粒度实体 ：不要用一个“项目”实体记录所有事。可以拆分为“项目_需求”、“项目_进度”、“项目_问题”等多个实体，由不同Agent负责维护。
    • 注意 ：CrewAI当前的记忆系统更偏向于共享知识库，对于需要强一致性的“状态”管理，可能不是最佳选择，需要考虑外部的状态管理机制。

问题4：Token消耗激增。

  • 现象 ：每次执行成本显著上升。
  • 原因 ：记忆的存储（尤其是长期记忆的总结）和读取（将大段记忆作为上下文喂给LLM）都会消耗Token。
  • 优化 ：
    • 存储时总结提炼 ：指示Agent用最精炼的语言（如bullet points）存储记忆，而非存储原始长篇大论。
    • 查询时限制长度 ：目前CrewAI可能默认返回所有相关记忆。你需要关注其未来是否提供参数来限制返回的记忆片段数量或长度。
    • 定期归档与清理 ：为长期记忆和实体记忆设计归档策略。例如，将三个月前的“历史主题”移动到“归档主题”实体，减少主实体的信息密度。

记忆功能是CrewAI从“自动化工具”迈向“智能协作系统”的关键一步。它引入的状态持久化能力，使得构建能够持续学习、适应环境、提供个性化服务的复杂AI应用成为可能。虽然目前该功能在易用性和精细控制上还有提升空间，但理解其原理并按照上述模式进行实践，已经能极大提升你构建的Crew的智能水平和实用价值。记住，好的记忆设计，就像是给AI团队配备了一位永不疲倦的档案管理员和一位洞察深刻的战略顾问。

Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

【花雕动手做】行空板 K10 系列实验之人工智能调用语音合成（TTS）模块

avatar AI Agent技术社区
cover

苏州企业AI Agent智能体从概念到落地：2026年开发者必须关注的技术范式与工程实践

avatar AI Agent技术社区
cover

GitHub 狂揽 4万+ Star！这个项目直接让你省下 60–95% 的 Token

avatar AI Agent技术社区