Agent Memory 可能被想复杂了：不提炼记忆，6组测试拿第一

Agent Memory 可能被想复杂了。

最近一篇论文《Is Complex Agentic Memory Always Needed?》做了一个很直接的实验：不做 Memory Extraction，不建复杂知识图谱，也不让 LLM 在写入时反复总结、更新记忆。只保留原始对话历史，在需要的时候检索出来，交给 LLM 自己推理。

这套方案叫 RAW-RAG。它在 LoCoMo、LongMemEval 等四个 benchmark 的 7 组测试设置里拿下 6 组第一，最多领先对比的最强 Agentic Memory 系统 5.53 分。benchmark 可以理解成公开测试集，7 组设置则是不同任务和条件下的测试。这个结果至少说明一件事：先把记忆提炼成摘要，再让 Agent 去用，未必是更优解。

项目作者 Yuu 在推文里提到，这也是他们开发 Obelisk 时坚持的思路。Agent 不该只看到别人替它总结好的记忆。一次代码修改背后的原因、一次失败的尝试、几个决策之间的依赖关系，都可能在总结和信息提取时丢失。与其猜未来什么信息值得记住，不如保留完整历史，让 Agent 在真正需要的时候自己去找。

Obelisk 是一个开源的 Coding Agent Session 检索系统。它可以直接查询 Claude Code、Codex、Hermes、Pi、Opencode 等 Agent 的历史 Session，包括对话、工具调用、Subagent 和工作流。它不依赖 Embedding，也不需要预先从历史中提取 Memory。底层用 SQLite FTS5 和 Agent 主动查询，让 Agent 能重新找到过去的原始证据。FTS5 可以理解为 SQLite 自带的全文搜索能力，不靠向量检索。

它想回答的问题很具体：

• 为什么当初要这样设计这段代码？
• 上一个 Agent 的任务进行到哪里了？
• 我们之前尝试过哪些方案，为什么失败？
• 这个项目的架构是如何一步步演变的？

项目作者更愿意把 Memory 看成一段随时可以追溯的历史，一份不断被改写的摘要很难承担这个角色。对普通用户来说，这有点像保留完整聊天记录和操作日志，而不是只留一份会议纪要。会议纪要读起来快，但它已经替你决定了什么重要。

评论区里，有网友说 AI 到现在这个程度真是大道至简，harness 和记忆都一样。也有人开玩笑，说 git 才是最好的记忆系统。这个说法不一定能直接套到所有 Agent Memory 场景，但它抓住了同一个点：原始记录本身很有价值。

质疑也很实在。有网友提醒，个人项目怎么搞都无所谓，企业项目记忆内容太多，直接用原生记忆扛不住，一次检索出来几十 M 相关记忆，需要结合自己的场景取舍。作者回复说，agent 可以自己限定检索范围。另一个常见担心是，方案中途推翻过，检索会把旧决定和新决定一起翻出来。作者回复，记录有时间戳，agentic search 不会在这种问题下犯错。

还有网友把摘要称作有损压缩，在不知道未来需要什么之前，先决定丢弃什么。保留原始历史，等于把难点从提前总结转到检索质量。这个判断很关键。RAW-RAG 赢了 6 组测试，不代表检索本身没有成本。有人问速度，有人提到上下文有限才是天花板。也有网友提 optmem，作者区分说，optmem 是 agent 主动写入，Obelisk 查询的是原始 session log，两者不是一回事。

论文标题问的是，复杂的 Agentic Memory 总是必要的吗。至少从这组实验和 Obelisk 的实现看，答案值得打一个问号。先把原始历史留住，再让 Agent 自己查，可能比反复改写一份摘要更接近记忆本来的用途。

Obelisk 完全开源：https://github.com/tommy0103/obelisk

论文：https://arxiv.org/abs/2610.30755