Agent记忆体系

人脑的记忆分很多种：你记得早餐吃了什么（短期）、记得三年前同事姓什么（长期）、记得怎么骑自行车（程序性）。Agent 的记忆系统也是分类的，不同类型的记忆放在不同的技术载体里，PM 在设计 Agent 时必须想清楚每一类记忆该用什么方案。

四类记忆全景

记忆类型	类比	技术载体	存什么
Working Memory（工作记忆）	当前任务的临时记忆	Context Window	当前对话历史、System Prompt、工具调用中间结果
Episodic Memory（情景记忆）	"上次做过什么"的具体事件	数据库	跨任务的历史交互、上次帮用户做了什么、结果如何
Semantic Memory（语义记忆）	从经历中提炼的"通用知识"	RAG 知识库	概念、规律、文档化知识
Procedural Memory（程序记忆）	"记住怎么做"的固定操作	Skill / Workflows	一套固定的操作步骤，不需要每次重新想

1. Working Memory — 工作记忆

特征：当前任务的记忆，任务结束就消失。技术上就是 LLM 的 Context Window。

Manus 的双区设计（教科书级）

上半区：System Prompt（每次循环都在，固定不变）

你是 Manus，一个由 Manus 团队创建的 AI Agent。你擅长帮助用户
完成各种任务，包括信息调研、数据分析、内容创作和文件处理。

<environment_info>
你运行在一个 Ubuntu Linux 沙箱环境中。可用工具：Shell、Python
3.10、Node.js 20、Playwright 浏览器、文件系统。
</environment_info>

<tool_use_rules>
1. 每一步都必须是一个工具调用，不能直接用自然语言回复
2. 每轮只能执行一个工具动作，必须等待返回结果后再决定下一步
3. 不能只看搜索引擎摘要，必须点进原始网页阅读完整内容
4. 任何报告都要引用来源，不能编造信息
</tool_use_rules>

下半区：Event Stream（随着任务推进不断向后追加）

[Plan] 任务计划：
  1. 搜索招聘网站获取薪资数据
  2. 打开 5-8 个招聘页面，提取薪资范围
  3. 多来源交叉验证
  4. 生成调研报告

[Action] browser_search("AI 产品经理 薪资 2026 BOSS直聘")
[Observation] 返回 10 条结果：BOSS直聘-北京-25K-50K，猎聘-上海-40K-60K...

[Action] browser_open("https://zhipin.com/...")
[Observation] 北京 AI 产品经理：初级 18K-30K，中级 25K-45K，高级 35K-60K

[Action] write_file("notes_beijing.md", "北京：初级 18-30K，中级 25-45K...")
[Observation] 文件已保存

...（中间 20+ 轮 action/observation 循环）

[todo.md]
✓ 搜索招聘网站获取薪资数据
✓ 打开 5-8 个招聘页面，提取薪资范围
✓ 多来源交叉验证
▶ 生成调研报告

System Prompt 是"游戏规则"，每次循环都送给模型；Event Stream 是"任务历史"，越积越长。这种分区让 Agent 在每一轮决策时既不忘初心（规则）又掌握进展（事件）。

2. Episodic Memory — 情景记忆

Working Memory 是"当前任务的记忆"，任务结束就消失。Episodic Memory 则是跨任务的记忆——上次帮用户做了什么、结果如何。

典型产品形态：

ChatGPT 设置里的"记忆"功能（已启用）→ 记录用户跨会话的偏好
个性化推荐里的"参考保存的记忆"
客服 Agent 记得用户上次的问题和解决方案

PM 决策点：

哪些情景该记？（用户偏好、重复任务模式、上次的失败教训）
用户能不能管理这些记忆？（查看、删除、修改）
多久过期？

3. Semantic Memory — 语义记忆

Episodic Memory 是"上次做过什么"（具体事件），Semantic Memory 是"从这些经历中提炼出的规律和知识"（通用理解）。

典型实现：RAG 知识库——把文档/代码/手册向量化存入数据库，检索时按语义相似度找最相关的内容。

Cursor 的 Codebase Indexing 就是 Semantic Memory 的经典案例：

你的代码库              向量化              存入向量数据库       语义匹配
src/                    [0.21 -0.41 ... 0.73]                       问："这个项目的
  auth.ts          →    [-0.35 0.62 ... -0.11]    →    Codebase  →   认证逻辑在哪？"
  middleware/jwt.ts     [0.54 0.12 ... 0.88]            Semantic
  session.ts            [-0.22 -0.73 ... 0.31]          Index    →   返回 auth.ts、
  routes/user.ts                                                      middleware/jwt.ts、
                                                                      session.ts

详见 RAG 体系。

4. Procedural Memory — 程序记忆

前三种记忆是"记住信息和知识"，Procedural Memory 是"记住怎么做"——一套固定的操作步骤，不需要每次重新想。

最典型的例子是 CLAUDE.md：

# CLAUDE.md（项目根目录）

## 代码规范
- 使用 TypeScript strict mode
- 测试用 Vitest，不要用 Jest
- 提交信息用 Conventional Commits 格式

## 工作流程
- 修改代码后必须跑 `npm test`
- 不要直接修改 prisma/migrations 里的文件
- API 路由修改后要同步更新 OpenAPI schema

Claude Code 每次启动都读这个文件，不需要你每次重复说"跑测试""用 Vitest"。这就是程序记忆——固定的"怎么做"被外化成文件，Agent 自动应用。

PM 决策点：

哪些操作流程应该固化成 Procedural Memory？（重复发生 + 不需要个性化判断的）
用什么形式承载？（配置文件 / Skill 定义 / Workflows）
用户能不能自己写/改？

四类记忆的协同

一个完整的 Agent 通常四类都用到：

Working Memory 装"当前对话"
Episodic Memory 装"这个用户的历史"
Semantic Memory 装"这个领域的知识"
Procedural Memory 装"这个产品的操作规范"

例如客服 Agent 处理"退款"问题：

Procedural Memory：退款流程的固定步骤（CLAUDE.md 风格的指令）
Semantic Memory：退款政策的知识库（RAG）
Episodic Memory：这个用户上次的订单和投诉记录
Working Memory：当前这轮对话的上下文

记忆设计的常见误区

什么都塞进 Context Window：Token 暴涨、长 Context 会让模型"迷失中间"（lost in the middle）。Manus 哲学："把文件系统当作外挂记忆——重要信息存文件而非塞进上下文。"
混淆 Episodic 和 Semantic：用户的订单历史是 Episodic（具体事件），退款政策是 Semantic（通用知识）。前者存数据库、后者存 RAG，混在一起就乱了。
忽略 Procedural Memory：把每次都要重复的规范塞 System Prompt 会让 Token 浪费，更好的方式是外化成项目文件让 Agent 主动读。