Knowledge、Memory 与 Context
三个最常被混淆的概念。
一句话理解：Knowledge 是组织审核过、对所有人成立的共享信息；Memory 是 Agent 从交互中学到、针对某个用户或任务的信息；Context 是模型此刻看到的工作台——前两者只有被放进 Context，才会影响这一次的判断。
在需求评审会上，经常能听到这样的对话：“让 Agent 记住我们的退款政策”“把用户偏好放进知识库”“上下文里要有客户的历史记录”。三个词被随意混用，结果是方案里职责不清：规则被存进了某个用户的记忆，所以换个用户就不知道；用户随口说的一句话被写进了共享知识库，所有人都受影响；业务系统里的订单状态被当成“记忆”存下来，第二天就过期了。
这一课把三个概念，以及经常与它们混淆的“业务状态”，彻底分开。
三个概念，外加第四个
一张对照表
| 维度 | Knowledge（知识） | Memory（记忆） | Context（上下文） |
|---|---|---|---|
| 是什么 | 组织的规则、流程、手册、FAQ、案例 | 从交互中学到的偏好、事实、经验、进度 | 本次调用模型能看到的全部 Token |
| 作用范围 | 所有用户（受权限约束） | 某个用户、某个团队或某个任务 | 仅本次调用 |
| 谁来写 | 业务专家、文档负责人 | Agent 自动写入，或用户要求写入 | Harness 每次组装 |
| 写入前是否审核 | 通常经过审核发布 | 通常没有审核 | 不涉及 |
| 生命周期 | 随文档版本管理 | 需要主动设计过期与遗忘 | 调用结束即消失 |
| 可信度 | 高（权威来源） | 中（可能记错、过期） | 取决于放进去的内容 |
| 典型存储 | 文档库 + 检索索引 | 记忆文件、数据库、向量库 | 无，每次重新构建 |
| 出错的后果 | 所有人得到错误答案 | 某个用户的体验被带偏 | 这一次判断出错 |
一个简单的记法：Knowledge 是公司的制度手册，Memory 是你的工作笔记本，Context 是你此刻摊在桌上的材料。 制度手册和笔记本里的内容，只有被你翻到、摆上桌面，才会影响你现在的判断。
第四个概念：业务状态
还有一类信息既不是知识，也不是记忆，却最容易被错放：业务状态，即业务系统中实时变化的数据。
| 信息 | 类别 | 应该放在哪里 |
|---|---|---|
| “签收超过 7 天的退款申请需人工审核” | Knowledge | 知识库，由业务部门维护 |
| “客户 A 偏好邮件而不是电话通知” | Memory（用户 / 客户级） | 记忆存储，可查看、可修改 |
| “这位客服专员习惯先看结论再看明细” | Memory（用户级） | 用户记忆或用户画像 |
| “本次排查已排除支付通道故障” | Memory（任务级）/ 任务状态 | 任务状态或工作笔记，任务结束后归档 |
| “订单 ORD-1024 当前状态为已完成” | 业务状态 | 订单系统，通过工具实时查询 |
| “客户 A 当前欠款 3.2 万元” | 业务状态 | 财务系统，通过工具实时查询 |
| “上次处理类似问题时，先查发票状态最快定位” | Memory（经验）→ 可能升级为 Knowledge | 先作为经验记忆，验证后沉淀进 SOP 或 Skill |
业务状态的原则只有一条：永远以业务系统为准，每次使用时实时查询。 把它写进记忆或知识库，等于制造了一份注定会过期的副本。状态的完整分类见 状态的五种类型。
按“谁共享”和“变化多快”两个维度，四类信息各有各的位置：
它们如何流动
三者之间的流动关系如下：
几条关键路径：
- 进入 Context：知识通过检索进入，记忆通过召回进入，业务状态通过工具进入。三者进入 Context 的方式和时机，都属于 上下文五问 要设计的内容。
- 写入 Memory：Agent 在交互中发现值得记住的信息，写入记忆；敏感或影响较大的记忆，应该让用户确认。
- 从 Memory 升级为 Knowledge：某条经验被多个用户、多次任务验证有效后，由负责人审核，沉淀为知识库文档或 Skill。这一步必须有人审核，不能让 Agent 自动把个人记忆发布为共享知识。
一个可参考的实现：Claude Code
Claude Code 的设计很清楚地体现了这种区分。根据其官方文档：
- 项目说明文件（
CLAUDE.md）：由人编写，包含构建命令、代码规范、项目约定等“每次都应遵守”的内容，可以随代码仓库与团队共享。它更接近 Knowledge / 指令。 - 自动记忆（auto memory）：由 Claude 在工作中自己记录，包括用户的偏好、用户给出的纠正、无法从代码中推导出的项目背景等，存放在本机、按项目隔离，用户可以随时查看、编辑、删除。它就是 Memory。
- 两者都会在会话开始时加载进上下文；自动记忆只加载索引文件的开头部分，具体的记忆条目在需要时再读取。这就是 Context 层面的管理。
文档还特别提到，这两类内容对模型来说是“上下文”，而不是强制执行的配置；需要确保某个动作一定被阻止时，应该使用 Hooks 等确定性机制。这一点同样适用于业务 Agent：重要规则不能只靠知识或记忆被“看到”，还要靠程序来保证。
混淆带来的典型问题
| 错误做法 | 后果 | 正确做法 |
|---|---|---|
| 把业务规则存在某个用户的记忆里 | 换一个用户，Agent 就不知道这条规则 | 规则进知识库或指令 |
| 把用户随口说的话自动写进共享知识库 | 一个人的误解变成所有人的“事实” | 先作为个人记忆，经审核后再沉淀 |
| 把订单状态、欠款金额写进记忆 | 第二天记忆已过期，Agent 却很自信 | 每次通过工具实时查询 |
| 把知识库当成记忆，不设版本和负责人 | 知识库越来越乱，没人敢删 | 知识按文档管理，记忆按用户与过期策略管理 |
| 以为“存进去了”就等于“用上了” | 知识和记忆没被检索或召回，模型根本没看到 | 检查 Trace，确认它们真的进入了 Context |
最后一条最常见。用户抱怨“我跟它说过好几次了，它还是不记得”，排查时往往发现：记忆确实写入了，但召回逻辑没有把它放进这一次的上下文。
常见误区
- “Memory 就是一个更小的知识库。” 两者的写入者、审核流程、作用范围和生命周期都不同，混在一起管理会同时破坏两者。
- “上下文窗口很大，把知识和记忆全放进去就行。” Context 是每次调用都要重新组装的工作台，放得越多，腐化越严重，成本越高。
- “Agent 记住的越多越好。” 记忆需要纠错、过期与遗忘机制，也需要用户可见可控。长期记忆的设计见 长期记忆。
产品经理检查清单
- 方案中每一类信息，是 Knowledge、Memory、业务状态还是任务状态？是否都标注清楚了？
- 知识库的负责人是谁？记忆的写入规则是什么？
- 哪些记忆需要用户确认后才能写入？用户能否查看、修改、删除？
- 是否存在把业务状态存为记忆或知识的情况？
- 个人经验沉淀为共享知识的流程是什么？谁审核？
- 出现“它不记得”时，能否在 Trace 中看到记忆是否被召回进了上下文？
练习
为订单售后诊断 Agent 分类以下 12 条信息，标注类别（Knowledge / 用户级 Memory / 任务级 Memory / 业务状态）和存放位置，并说明进入上下文的方式：
- 退款审核的处理时限为 5 个工作日
- 订单 ORD-1024 的签收时间
- 客服专员小王希望报告里先列金额最大的异常
- 本次排查已确认发票状态正常
- 华东区企业版客户的退款自 9 月 10 日起统一由售后二组审核
- 客户 B 上次投诉是因为通知太晚
- 错误码 E-4031 的含义
- 客户 B 当前的待退款金额
- 上个月处理同类问题时，先查发票状态最快
- 客户 B 合同约定的退款上限
- 今天 10 点已为 ORD-1031 创建人工退款工单
- 小王所属区域为华东
完成后，挑出你认为最容易被放错位置的两条，写出放错后会发生什么。
延伸阅读
- Claude Code 文档：How Claude remembers your project
- Claude 文档：Memory tool
下一步
知识库搭好了，怎么知道它答得好不好？本模块最后一课「RAG 效果评估」讲如何用召回率、准确率、忠实度与答案相关性，把“答不准”拆成可以改进的具体问题。