Agent Memory 越做越乱，本质上是 Runtime 问题
很多 Agent 项目做到第二个月，会开始加 memory。
一开始理由很正当：
用户不想每次重复偏好。
长任务需要知道前面做过什么。
coding agent 应该记得项目结构。
客服 agent 应该记得用户历史。
然后大家很自然地做了一件事：把对话、文档、工具结果、用户偏好、项目摘要丢进向量库。
前几天效果不错。模型'记得'更多东西了，回答也更贴心。
再过一阵子，味道开始不对：
- 用户新要求已经变了，Agent 还按旧偏好行动。
- 一个项目里的事实被检索到另一个项目里。
- 旧的错误总结反复影响新任务。
- 用户说'忘掉这件事'，系统只从 UI 隐藏，检索层还拿得到。
- 历史摘要写得很像事实，但找不到原始证据。
- Memory 里混进了模型自己的猜测，后面又被当作用户偏好。
这时候再调 embedding、调 topK、调 reranker，只能缓一缓。
根子不在那里。
Agent Memory 不是一个向量库功能。它是 Runtime 能力。
Memory 到底在改变什么
Memory 不是'多给模型一点背景'这么简单。
它会长期改变模型看到的上下文，也会改变模型的默认行为。一次错误写入可能影响后面很多 run。
比如 coding agent 记住：
这个项目不允许修改数据库 schema。
这是有用记忆。
但如果它又记住：
用户上次要求优先使用 Prisma migration。
下一次用户明确说'不要改 schema'，旧记忆就可能和新指令冲突。模型不一定会自然分清'长期偏好''上一轮任务策略''当前明确约束'的优先级。
Runtime 必须帮它分清。
我会把 Memory 分成几类：
Session summary：当前会话压缩摘要。
User preference：用户长期偏好。
Project memory：某个 workspace 或 repo 的事实。
Run note：某次任务的结果和未完成事项。
Skill memory：可复用操作流程或团队约定。
External memory：来自 CRM、工单、知识库等系统的上下文。
这些东西不能混在一个桶里。
Session memory 和 Long-term memory 不是一回事
OpenAI Agents SDK 里有 sessions，用来自动维护 conversation history。LangGraph 文档里也会把短期记忆放在 thread state，把长期记忆放在跨 thread 的 store，通常还会用 namespace 区分范围。
这条边界很关键。
短期记忆解决的是'这次任务进行到哪里了'。它应该跟 run、turn、step、checkpoint 绑定。
长期记忆解决的是'以后还能不能用'。它应该有来源、作用域、TTL、审批、删除和审计。
短期记忆可以比较详细，因为它只服务当前任务。长期记忆必须克制，因为它会跨任务复用。
如果你把两者混在一起，系统迟早会出现这种问题：
用户上周临时要求'为了调试先跳过测试'
↓
Agent 记成长期偏好
↓
下周真实上线任务里继续跳过测试
这不是模型笨。是 memory 写入策略太随便。
写入比检索更危险
很多团队把精力放在检索：embedding 模型、topK、rerank、hybrid search。
这些当然重要。但我更关心写入。
谁有资格把一条信息写进 memory？
用户明确说'以后都这样'时，可以候选写入。模型从一次任务里推断出的偏好，不应该直接写。工具返回的事实可以写，但要带来源。用户审批记录应该进 audit log，不要靠自然语言摘要保存。
一个 memory entry 至少要长这样：
type = {
: ;
: | | | | ;
: {
?: ;
?: ;
?: ;
?: ;
};
: ;
: {
: | | | | ;
: ;
};
: | | | | ;
: | | ;
: ;
?: ;
};