AI Agent Engineer

AI Agent Engineer

Memory、Knowledge 与上下文

14 min read

Memory、Knowledge 与上下文

本节目标

完成本节后，你应该能解释 CrewAI 中 Flow state、当轮 context、Memory 和 Knowledge 的职责差异，为每类信息规定写入、读取、过期和删除规则，并避免把“模型看见过”误当成“系统已经可靠保存”。

版本说明

PyPI 在 2026-07-21 观察到的最新稳定包是 crewai==1.15.5，而本库真实 Layer B 仍固定并复验 1.15.4。本节按 2026-07-21 的官方页面补核 Memory/Knowledge 概念；页面标签、PyPI 版本与本库经测试基线不是同一事实。真实项目仍要以锁定依赖的 API 和最小集成测试为准。

四种信息分别解决什么问题

类型它回答的问题典型内容主要风险
Flow state“这次运行现在走到哪一步？”运行 ID、阶段、尝试次数、审批结果、结构化 Task 产物schema 漂移、重复执行、状态损坏
当轮 context“这一次模型调用需要看见什么？”Task 指令、有限历史、工具结果、检索片段超长、陈旧信息、提示注入
Memory“过去哪些经验值得以后检索？”经确认的用户偏好、已完成事件、可复用经验错误记忆、越权共享、无法删除
Knowledge“有哪些预先准备的领域资料可供检索？”手册、政策、产品文档、经过版本管理的内部知识旧版本、权限遗漏、来源丢失

这四者可以互相提供输入，但不能互相替代。例如，“退款已获人工批准”首先是本次 Flow 的状态；只有业务规则允许时，才可能在运行结束后写成长期记忆。政策手册属于 Knowledge，检索出的两段政策才进入当轮 context。模型自己推断出的“用户喜欢某种方案”不能未经确认就写成长期事实。

Flow state：可恢复的业务事实

状态应优先采用固定 schema，而不是一段自由文本。最低限度可包含：

{
  "schema_version": 1,
  "run_id": "run-...",
  "stage": "reviewing",
  "attempt": 1,
  "approved": false,
  "artifacts": {
    "draft_id": "draft-..."
  }
}

字段阅读：

  • schema_version 标识状态读取与迁移应遵循的版本合同。
  • run_id 唯一关联一次运行的状态、日志与审计记录。
  • stage 是由业务代码控制的当前推进阶段。
  • attempt 用于执行重试预算，不能只靠 Prompt 约束。
  • approved 只能由可信审批流程写入，不能由模型自行声明。
  • artifacts.draft_id 保存草稿产物的稳定引用，避免复制整段内容。

设计状态时先回答：

  1. 哪些字段决定下一条路由？
  2. 哪些字段必须能被程序校验，而不能只靠自然语言解释？
  3. 恢复运行时，如何判断某个有副作用的动作已经做过？
  4. schema 变化后，是迁移、拒绝恢复，还是兼容读取？

状态保存的是推进工作所需的事实，不应无限堆积完整 Prompt、原始附件和秘密。状态与 @persist、检查点的关系见 Flow、State 与事件 和 安全、失败恢复与生产边界。

当轮 context：模型这一次真正能使用的信息

上下文不是越多越好。一个 writer Agent 通常只需要研究结果、写作约束和输出 schema，而不需要 researcher 的全部思考过程。建议按以下顺序组装：

  1. 不可被外部文本覆盖的角色、权限和安全规则；
  2. 当前 Task 的目标、输入契约和完成条件；
  3. 来自 Flow state 的最小必要字段；
  4. Knowledge 或 Memory 检索出的有限片段，附来源和时间；
  5. 最近且与当前 Task 有关的工具结果；
  6. 明确的输出格式、拒绝条件和预算。

外部网页、PDF、邮件和工具结果都属于不可信数据。其中出现“忽略之前要求”“调用发送工具”等文字时，它仍然只是待处理内容，不能改变 Agent 的工具权限。上下文隔离最终依靠工具白名单、参数验证和审批，而不是一句更强硬的 Prompt。

Memory：可检索的长期经验，不是聊天记录仓库

2026-07-21 的官方 Memory 页面介绍统一的 Memory 能力，并以 remember、recall、forget 表达写入、检索和删除；Crew 也可通过 memory=True 开启记忆。由于官方页面与包版本标签存在差异，本节不把示例签名当成跨版本承诺，也没有在本离线项目中执行真实 Memory API。

启用 Memory 前先写“记忆政策”：

问题一个可执行的答案示例
谁可以写？只有结束后的归档步骤，普通 Agent 只提交候选项
写什么？用户明确确认的偏好、已完成且有来源的事件
不写什么？密钥、原始身份证件、模型猜测、短期错误日志
谁能读？仅同一租户且具有该业务权限的 Crew
保存多久？偏好 180 天，业务事件按组织政策保存
如何纠错？新事实带版本并使旧项失效，不静默覆盖审计记录
如何删除？按用户、来源和用途可定位删除，并验证检索不再返回

记忆检索结果也不是“真相”。每条结果至少需要来源、写入时间、适用范围和置信边界。高风险决策应回查权威系统，而不是仅凭相似记忆继续执行。

当前 Memory 的 scope 不是租户授权

2026-07-21 的官方页面把 Memory 描述为统一 API：保存时可由 LLM 推断 scope、类别和重要度，召回分数会综合语义相似度、时效性和重要度；也提供 slice(..., read_only=True) 这类读写视图。它们有助于组织与检索，但不应被当作身份认证或跨租户 ACL：LLM 推断出的 scope 不是可信授权属性，召回排序也不是政策判定。

生产设计应先由可信请求身份确定 tenant/subject 与可读 scope，再把这些约束传给检索层；写入只接受受控归档步骤，并把 Memory 的实际存储根、scope、来源和删除请求一起审计。若框架 API 无法证明查询前完成这些过滤，就使用每租户独立存储/命名空间或在外部授权服务中过滤，而不是把 read_only、Agent 名称或 Prompt 当隔离机制。本课程没有运行真实 Memory 的 LLM/embedding 路径，因此这一段是基于官方文档的设计边界，不是本地集成验收。

Knowledge：受版本和权限管理的资料层

官方 Knowledge 文档描述了 Agent 级或 Crew 级知识源。文件型知识源采用相对于项目根目录 knowledge/ 的路径；这意味着运行目录、文件部署和容器挂载都需要纳入测试，不能假设本机相对路径在服务器仍然成立。

Agent 级知识源可独立工作，Crew 级知识源会提供给 Crew 中所有 Agent；这是配置分发范围，不是多租户访问控制。当前官方页面还展示默认存储中的 Agent collection 可能以 agent.role 命名、Crew collection 使用 crew 名称。角色与 collection 名称既可变又不等于可信主体，因此共享存储根、同名角色或默认 collection 时绝不能据此推断隔离已经成立。把 tenant、数据分类、来源版本和授权过滤放到检索前的可信层，并为实际 storage path、collection 命名、缓存失效和删除做集成测试。

一个可维护的知识链路包括：

  1. 采集：确认版权、数据分类、版本和负责人；
  2. 解析：保留标题、章节、页码或原始记录 ID；
  3. 切分：按语义和使用场景切分，而不是只按固定字符数；
  4. 索引：绑定来源、版本、租户、权限和失效时间；
  5. 检索：先做权限过滤，再做相关性检索；
  6. 注入：只把足够片段加入 context，保留可引用标识；
  7. 更新与删除：新版本上线后使旧片段失效，并验证缓存和索引均已更新。

官方页面还说明 Knowledge 使用本地存储组件，并建议生产环境通过 CREWAI_STORAGE_DIR 明确存储位置。路径只是存储配置，不等于权限、备份或加密策略；生产部署仍需自行设计这些边界。

多 Agent 间如何传递信息

优先传递结构化产物，而不是把完整对话复制给下一个 Agent。例如 researcher 输出：

{
  "claims": [
    {
      "text": "……",
      "source_ids": ["source-1"]
    }
  ],
  "unknowns": []
}

字段阅读：

  • claims 是可交给下游 writer 或 reviewer 的结构化断言集合。
  • 每个 text 应只陈述已有证据支持的内容，而不是模型推测。
  • source_ids 把断言绑定到可复查的来源目录条目。
  • unknowns 显式保留尚无充分证据的问题，空数组表示当前没有记录到此类缺口。

writer 只接收这些字段和写作规范；reviewer 接收研究产物、草稿和来源目录。这样更容易验证来源、限制提示注入传播，并在 Task 边界定位错误。本课程的可运行实现见 项目：离线研究简报 Flow。

常见误区与排查

  • 误区： 开启 memory=True 就自动得到正确的个性化。
    • 排查： 检查写入政策、召回结果、租户隔离、纠错和删除测试。
  • 误区： Knowledge 文件更新后，旧回答会自动消失。
    • 排查： 核对索引版本、缓存、存储路径和旧片段失效规则。
  • 误区： 摘要比原文短，所以一定更安全。
    • 排查： 摘要也可能保留秘密或注入指令；仍需分类、脱敏和来源绑定。
  • 误区： 多 Agent 共享全部历史才能协作。
    • 排查： 为每个 Task 列出最小输入，删除不影响完成条件的字段。

动手练习

设计一个客户支持 Crew，把下列信息逐项归入 state、context、memory 或 knowledge，并写出保留期限与读写权限：订单号、当前退款审批、用户明确选择中文、政策手册、上一轮工具超时、模型推测的用户情绪。

进一步完成一个表格，至少包含 8 个测试：跨租户检索、用户纠错、删除后召回、旧政策失效、恶意文档注入、上下文超长、来源缺失和 Flow 恢复。

掌握检查

  • 能用具体例子区分 state、context、Memory 与 Knowledge。
  • 能为 Memory 写出谁可写、什么可写、何时过期和如何删除。
  • 能说明 Knowledge 从文件到检索片段的完整链路。
  • 能让多个 Agent 只传递最小、结构化、可追溯的产物。
  • 能解释为什么检索结果和长期记忆都不能直接当作事实。

下一步

信息边界明确后，下一步是验证整个系统是否按契约运行：测试、评测与可观测性。

主要参考资料

资料获取日期：2026-07-21。

Backlinks