小节一：Long-term Memory 和 Working Memory 到底差在哪——“当前要记”与“以后还要记”不是一回事

先别急着往下看代码，咱们先把这三个容易混在一起的概念摆平。下面这张图把 Working Memory、Long-term Memory、Conversation History 放到了一起，对照着看会更直观。

你可以把它简单理解成三层：Working Memory 负责眼前这次任务，内容会跟着步骤不断刷新；Long-term Memory 负责把未来还会反复用到的信息沉淀下来；Conversation History 更像原始交互轨迹，保留“发生过什么”，但它本身并不等于长期记忆。把这条边界先守住，后面设计记忆系统时就不会越写越乱。

这一节最重要的第一组概念边界是，Working Memory ≠ Long-term Memory。

两者都叫 Memory，但生命周期完全不同。

Working Memory 服务当前任务

上一节我们设计：

{
    "goal": "",
    "plan": [],
    "completed": [],
    "errors": [],
    "important_files": [],
    "next_action": ""
}

例如：

Goal:
修复当前 pytest 失败

Errors:
ModuleNotFoundError: requests

Next Action:
检查 requirements.txt

这些信息在当前 Run 很重要。

但任务结束以后：

Next Action:
检查 requirements.txt

就没有长期价值了。

甚至：

ModuleNotFoundError: requests

如果已经修好，也不应该永久记住。

Long-term Memory 服务未来 Session

真正值得长期记的可能是：

用户偏好最小修改
项目固定 Python 3.9
项目使用 pytest
禁止修改 tests/
不允许新增第三方依赖
数据库继续使用 SQLite

这些信息明天、下周仍然可能影响 Agent。

所以它们更适合 Long-term Memory。

一个非常实用的判断问题

当你不知道某条信息要不要写入 Long-term Memory 时，可以问，“如果明天开启一个全新的 Session，这条信息仍然有可能改变 Agent 的行为吗？”

如果答案是：

是

那它很可能值得长期保存。

例如：

用户偏好最小修改

会影响明天的代码修改方式。

值得保存。

而：

刚才 read_file("config.py") 失败

通常只影响当前任务。

不值得永久保存。

Conversation History 也不是 Long-term Memory

Conversation History 是：

原始事实流

Long-term Memory 是：

从历史里提炼出的长期有效信息

比如 Conversation 里有：

User:
这次不要新增依赖。

User:
以后这个项目都别新增依赖，除非我明确同意。

真正值得写 Memory 的是第二句表达的长期规则：

项目默认不新增第三方依赖，除非用户明确批准。

不是把两句聊天原文都永久保存。

Session History 也不是 Long-term Memory

Session 可以保存：

messages
tool_history
runs

它主要为了恢复历史会话。

Long-term Memory 的作用是，即使不用恢复旧 Session，也可以在新 Session 中继续知道长期事实。

这就是关键区别。

一个生命周期对比

为什么长期记忆必须更“少”

Working Memory 可以有：

20 条 completed
10 条 errors
20 个 important_files

但 Long-term Memory 如果不断把所有东西写进去，很快就会变成另一个 Context 垃圾桶。

所以长期记忆要遵守，少而准。

真正长期价值高的信息，通常没有你想象中那么多。

例如一个项目也许只需要几十条稳定事实和关键决策，就足够显著改善 Agent 行为。

“少”也包含数据最小化。API Key、Cookie、访问令牌、身份证号、完整客户数据等敏感内容，即使未来可能有用，也不应该顺手写进 Memory。凭据交给专门的 Secret Store；业务数据只保存完成任务所需的最小范围，并给用户留出查看、纠正和删除入口。

一个判断矩阵

可以先用下面这个简单标准：

这个表非常值得记住。