来源
论文：Are We Ready For An Agent-Native Memory System?
代码与 Benchmark：OpenDataBox / MemoryData
一句话判断
RAG 让模型查资料，Memory 让 Agent 保持状态。
这篇论文最重要的价值，不是告诉我们哪个 Memory 系统排名更高，而是给了一个更大的产品判断：
Agent Memory 正在从向量检索插件，变成长期 Agent 的状态管理层。
如果说 RAG 面向的是静态知识库，解决“查到相关资料”的问题，那么 Agent Memory 面向的是动态执行过程，解决“事情进展到哪一步”的问题。
信号
长期 Agent 的核心能力，不是记住更多聊天记录，而是持续管理用户、项目、任务和决策状态。
它要回答的不是“用户以前说过什么”，而是：
- 当前项目推进到哪一步；
- 哪些任务已经完成；
- 哪些方案已经被否掉；
- 哪些偏好已经过期；
- 哪些新事实覆盖了旧事实；
- 哪些决策仍然有效。
这意味着 Memory 不应该被看成 NLP 组件，而应该被看成 Agent 产品的数据管理层。
产品架构启发
下一代 Agent 产品不应该只是：
LLM + RAG + Tool Calling + Workflow更合理的结构是：
LLM + Tool Calling + Workflow + Memory Layer + State ControllerMemory Layer 负责沉淀长期状态，State Controller 负责判断哪些状态在当前任务中有效。
对产品团队来说，至少要维护四类状态：
- User State：用户偏好、审美、表达习惯、长期目标；
- Project State：项目目标、架构、资源、当前版本；
- Task State：当前任务、已完成步骤、失败步骤、下一步；
- Decision State：决策理由、约束、被否方案、保留原则。
这四类状态，才是长期 Agent 的真正记忆。
技术路线启发
Memory 的难点不是“存下来”，而是“长期保持可用”。
生产级 Memory 系统必须处理旧记忆污染、新旧事实冲突、时间顺序、多证据组合和维护成本。
所以未来的 Agent Memory 不应该只有一个 search_memory()，而应该有一套 route_memory()：
- 查最近状态，走时间索引；
- 查项目约束，走项目空间；
- 查用户偏好，走用户状态；
- 查因果关系，走决策记录；
- 查多跳证据，走图关系和重排。
向量检索只是其中一路，不是整个 Memory System。
商业化启发
模型会趋同，工具会标准化，Workflow 会越来越普遍。
真正能形成迁移成本的，是产品沉淀下来的长期状态：用户偏好、项目背景、业务流程、历史决策、团队协作方式、失败记录和任务进度。
这也是 Agent 产品的复利来源。
未来 Agent 产品的壁垒，不是接入了哪个模型，而是谁能管理更可靠、更长期、更可更新、更可追溯的任务状态。
行动建议
如果你在做 Agent 产品，不要一上来就问“要不要加向量库”。
先问四个问题：
- 哪些状态必须长期保留？
- 哪些状态会过期、冲突或被覆盖？
- 当前任务需要哪些状态参与决策？
- Agent 如何解释这些状态来自哪里、为什么可信？
先定义状态，再设计 Memory。