# Reverse Engineering GPT, Claude, OpenClaw, Hermes Taught Me Most AI Products Shouldn't Ship Memory
**作者**: Manthan Gupta
**日期**: 2026-04-22T13:25:16.000Z
**来源**: [https://x.com/manthanguptaa/status/2046943418769981677](https://x.com/manthanguptaa/status/2046943418769981677)
---
The first time I asked ChatGPT what it remembered about me, it listed 33 facts. Name, career goals, fitness routine, names of side projects I had mentioned weeks earlier, a throwaway line about my sabbatical from a completely unrelated chat. I was impressed. I spent the next few weeks reverse-engineering how it actually works, then did the same for Claude, OpenClaw, and Hermes. Somewhere around the third system, I stopped noticing how clever the designs were and started noticing how often memory was degrading my own outputs.
Explicit state beats implicit memory, surprisingly often. Memory is not a default feature, it is a product and systems tax, and most AI products have not earned the right to pay it.
## What I Saw Inside Four Memory Systems
I want to start with the synthesis, because it is the part I could not have written without doing the reverse-engineering work.
Each of the four systems I mapped takes a fundamentally different approach:
- ChatGPT uses an injected profile. A long-term fact store (33 facts, in my case), plus pre-computed summaries of recent chats, plus session metadata. All glued into every prompt. Just a curated block that rides along on every turn.
- Claude uses on-demand retrieval. A small <userMemories> block is always present, but past conversations are not injected by default. The model can invoke conversation_search or recent_chats as tools when it decides context is relevant.
- OpenClaw uses a Markdown workspace. Everything is plain files on disk: MEMORY.md for durable knowledge, memory/YYYY-MM-DD.md for daily logs, indexed for hybrid semantic + keyword search. The agent searches its own notes on demand.
- Hermes uses a hot/cold split. A tiny frozen prompt memory — MEMORY.md capped at 2,200 characters and USER.md at 1,375 characters, about 1,300 tokens combined, plus a SQLite-backed session_search for episodic recall, plus a skills system for procedural memory, plus an optional user-modeling layer.
Four systems, four different answers. Put them next to each other and a pattern becomes obvious. The simplest approach, injected profile, is also the one with the worst failure mode, every old fact competes for attention on every future prompt, and you have no principled story for when to stop. It is also the one most product teams copy, because it is the easiest to demo and the easiest to ship. That is how most AI products ended up with memory that degrades their own outputs.
The most deliberate of the four is Hermes, and the design choice holding it together is a single sentence from the source: keep the prompt stable for caching, and push everything else to tools. Memory stops being ambient and becomes a choice the model has to make. That is the direction I think most teams should copy, and it is the opposite of what the easy path gives you.
## Storage is Easy, Retrieval Policy is Hard.
Once I had looked inside four of these systems, one observation would not go away. The storage side is actually not the hard part. Storing facts is easy. You can do it with a JSON blob, a Markdown file, a SQLite table, or a vector index. The interesting part is the part that decides whether memory helps or hurts the output, the retrieval policy, the heuristic that decides which remembered thing gets pulled into which future prompt.
Walk through the four systems through that lens and the picture gets clearer:
- ChatGPT’s retrieval policy is “always inject.” Every stored fact rides along on every prompt. Cheap, fast, and the reason old context keeps shaping new answers whether it is relevant or not.
- Claude’s retrieval policy is “model decides.” The model has to recognize when past conversations matter and call a tool. Cleaner prompts when it works, but dependent on the model getting the “do I need to search?” call right.
- OpenClaw’s retrieval policy is “agent issues semantic + keyword search.” Better than always-inject, but the more notes you accumulate, the harder the search has to work, and the more likely you are to pull stale or redundant material.
- Hermes’s retrieval policy is tiered and explicit. A tiny hot set for durable facts, a separate cold store for episodic history, a separate skills index for procedural knowledge, and clear rules about what belongs where. (“Save user preferences, environment facts, recurring corrections, stable conventions. Do not save task progress, session outcomes, temporary TODO state.”)
Every failure I saw, and most of the failures the rest of this post describes, comes from a weak retrieval policy and not a weak storage layer. ChatGPT’s failure is architectural: the policy is “always inject,” which is why stale context keeps bleeding through. A better storage scheme would not fix that. Only a better retrieval policy would.
This matters because most teams shipping memory are spending their complexity budget on the wrong half. They compare vector stores, they design embedding pipelines, they debate chunk sizes. The retrieval policy gets one sentence in the design doc: “we’ll retrieve the top-k relevant items and inject them.” That one sentence is where the product quality lives. Most teams are flying blind on it.
## The Best Case for Memory
I want to take the opposite view seriously before arguing against it.
The strongest case for default memory is friction reduction. Not having to re-enter preferences every session is genuinely nice, especially for casual users. “Remember I’m vegetarian” should not need to be said twice.
The next strongest case is continuity for inherently longitudinal products. Meeting tools like Granola, personal knowledge products like Reflect and Mem.ai, relationship products like Replika, therapy companions. For these, memory is not a feature, it is the product.
The third is the retention wedge. Mike Taylor’s piece notes that the “it knows me so well” feeling is exactly what locks ChatGPT users in. That is real. Users do not switch to Gemini or Claude partly because they do not want to rebuild the profile. Memory makes your product stickier whether or not it makes the outputs better.
The fourth is low-stakes drift. For casual tasks like recipe ideas, travel suggestions, chit-chat being slightly wrong because of stale memory does not really hurt the user.
Each of these has a counter. Friction reduction does not require implicit memory; a settings panel does it without the tax. The longitudinal case is exactly the one this post concedes for those products, ship memory. The retention wedge is a business case, not a quality case; you are trading output quality for stickiness, which is a legitimate choice but should be made consciously. And low-stakes drift assumes your product only serves casual tasks, which is rarely true the same ChatGPT user doing recipe lookups is also doing code reviews and performance reviews and therapy-adjacent venting, and stale memory does not know which of those it is in.
The strongest version of the pro-memory argument is real. It is just much narrower than the scope most products ship memory at.
## Where Memory Goes Wrong in Practice
Once you ship memory with a weak retrieval policy, it fails in predictable, documented ways.
Output quality degrades. Mike Taylor’s Why I Turned Off ChatGPT’s Memory is the best user-side documentation of this. He put a Kanye quote about “dopeness” into his custom instructions, and ChatGPT started claiming it had built a collapsible website section “as dope as possible”, applying the same quote to interior decor, marketing plans, and Python debugging. When he turned memory back on to write the piece, a request for barbecue rib advice came back as “Hoboken Dinner Upgrade Ideas” because the assistant knew he had just moved. OP-Bench shows the pattern at benchmark scale: memory-augmented agents retrieve user details even when unnecessary, then over-attend to them until the details overshadow the actual query.
Debugging gets dramatically harder. I have spent enough time inside agent codebases to know the signature of a memory bug: the live trace is clean. Prompt, retrieval, tool logs are all fine. The weird behavior still happens. The reason is architectural.
The thing shaping tomorrow's answer lives in a pipeline you are not logging.
The Unit 42 writeup on Amazon Bedrock Agents describes exactly this shape: memory is produced by a separate session summarization process that runs at session end and merges into the next session’s system prompt. Every memory system I reverse-engineered has some version of this split. With memory, you are not debugging a request, you are debugging a relationship, and the relationship is logged somewhere you are not looking.
Context rot. The context window is not free intelligence, it is scarce working memory. Chroma’s Context Rot research evaluates 18 leading models on deliberately controlled tasks, holding task difficulty constant and varying only input length. Performance degrades with input length across every model they test, and distractors hurt more as context grows. A Databricks study shows accuracy dropping well before the window is full, sometimes as early as 32k tokens. A Microsoft/Salesforce paper shows splitting a prompt into a multi-turn conversation instead of one shot drops performance by 39% on average. Most memory systems are context inflation mechanisms in disguise.
Privacy gets weird fast. I built BYOM because, once you look at a memory system clearly, it stops being a convenience feature and becomes a persistent user-profiling system. The CIMemories paper calls out the specific failure mode: memory-augmented LLMs often pick the right domain to talk about but cannot tell which details inside that domain are relevant. Right domain (life logistics), wrong granularity (a therapy schedule bleeding into a work email draft). Personalization and contextual integrity are not the same thing.
A brand new attack surface. The Unit 42 proof-of-concept against Bedrock Agents shows what “poisoned memory” actually looks like. An attacker hides a prompt injection in a webpage. The victim asks their travel agent to read the URL. Nothing goes wrong in the live session, the payload is crafted to target the session summarization prompt, not the orchestration prompt. When the session closes, the summarizer writes the attacker’s instructions into memory as a normal-looking topic. Days later, the user returns, books a trip, and the agent exfiltrates the booking to an attacker-controlled domain by calling its own scrape_url tool. Prompt injection against a stateless chat is transient. Prompt injection into memory is persistent. The MINJA paper shows the attacker does not even always need access to the memory store, user-style interaction alone can land the payload.
Personality drift. PersistBench reports median failure rates of 53% on cross-domain leakage and 97% on sycophancy samples in long-term-memory systems. The sycophancy number is the scary one. If what the assistant remembers about you nudges it toward agreement and accommodation instead of honest judgment, you do not have a memory problem, you have a judgment problem. And it will still feel personal to the user.
## The Hermes Pattern: Memory as a Tool, Not Ambient Context
If the previous section is the symptom list, Hermes is the design that treats the disease.
Three principles hold it together. First, it separates hot memory from cold recall. A tiny always-injected block for durable facts, a searchable cold store for episodic history, a skills index for procedural memory. Nothing in the “always-injected” tier is allowed to grow unbounded, because prompt memory is cache-sensitive working set, not a diary.
Second, it treats prompt stability as a first-class constraint. Memory is frozen into a snapshot at session start and not mutated mid-session. Writes go to disk immediately, but the prompt stays stable until a natural rebuild point (new session, post-compression). Every agent system ships memory without thinking about caching. Hermes does.
Third, it acknowledges that memory is plural. Facts, episodes, skills, and deeper user modeling are distinct retrieval problems with distinct policies. One store does not solve them all.
This is what memory done right looks like in practice. Not a bigger vector DB. Not smarter auto-promotion. Fewer things in the system prompt, more things in tools, explicit rules about what belongs where. Most AI products that ship memory could cut their memory surface by 80% and end up with better outputs.
## Before You Ship Memory, Answer These
The synthesis above turns into a checklist. Before shipping memory in your product, answer these honestly:
Is your product inherently longitudinal? Do users get less value from session one than from session ten? If no, you do not need memory.
Can you draw a clear line between your storage system and your retrieval policy? If no, you are about to ship the ChatGPT failure mode and call it personalization.
Will the stored state be visible to users and directly editable by them? If no, you are building implicit profiling, not memory.
Can you scope recall to a specific task, project, or explicit tool invocation? If no, ambient memory will bleed across contexts.
Is your team willing to own the privacy, security, and debugging tax for the next three years? If no, you are not shipping memory, you are shipping a liability.
If the honest answer to most of these is no, do not ship memory. Ship visible settings, scoped project state, and explicit task briefs instead. Cursor’s .cursorrules and AGENTS.md, Claude Projects, Zed’s .rules, ChatGPT Custom Instructions, Linear task context, all of these work because they are legible, editable, and scoped. None of them need a memory layer to do their job.
## Conclusion
Memory sounds like intelligence because humans associate memory with understanding. Product memory is not human memory. It is stored context with retrieval rules, summarization errors, privacy trade-offs, security exposure, and a constant tendency to turn old signals into future bias. That does not make it useless. It makes it expensive.
If your AI product still struggles with basic workflow design, explicit settings, clean state management, and reliable task execution, adding memory will not make it smarter. It will make it harder to understand when it fails, harder to debug when it drifts, and harder to trust when it confidently carries the wrong things forward.
The truth is that most AI products do not need better memory. They need better product design.
## References
- OpenAI Memory FAQ
- Why I Turned Off ChatGPT’s Memory - Mike Taylor, Every
- Context Rot: How Increasing Input Tokens Impacts LLM Performance - Chroma
- Long Context RAG Performance of LLMs - Databricks
- When AI Remembers Too Much: Persistent Behaviors in Agents’ Memory - Unit 42
- CIMemories: A Compositional Benchmark for Contextual Integrity of Persistent Memory in LLMs
- PersistBench: When Should Long-Term Memories Be Forgotten by LLMs?
- OP-Bench: Benchmarking Over-Personalization in Memory-Augmented Conversational Agents
- MINJA: Memory Injection Attacks on LLM Agents via Query-Only Interaction
If you found this interesting, I’d love to hear your thoughts. Share it on Twitter, LinkedIn, or reach out at guptaamanthan01[at]gmail[dot]com.
## 相关链接
- [Manthan Gupta](https://x.com/manthanguptaa)
- [@manthanguptaa](https://x.com/manthanguptaa)
- [10K](https://x.com/manthanguptaa/status/2046943418769981677/analytics)
- [reverse-engineering how it actually works](https://manthanguptaa.in/posts/chatgpt_memory)
- [Claude](https://manthanguptaa.in/posts/claude_memory)
- [OpenClaw](https://manthanguptaa.in/posts/clawdbot_memory)
- [Hermes](https://manthanguptaa.in/posts/hermes_memory)
- [Mem.ai](https://mem.ai/)
- [Why I Turned Off ChatGPT’s Memory](https://every.to/also-true-for-humans/why-i-turned-off-chatgpt-s-memory)
- [OP-Bench](https://arxiv.org/html/2601.13722v1)
- [Unit 42 writeup](https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons-ai-longterm-memory/)
- [Context Rot research](https://www.trychroma.com/research/context-rot)
- [Databricks study](https://www.databricks.com/blog/long-context-rag-performance-llms)
- [Microsoft/Salesforce paper](https://arxiv.org/pdf/2505.06120)
- [CIMemories](https://arxiv.org/abs/2511.14937)
- [MINJA paper](https://arxiv.org/abs/2503.03704)
- [PersistBench](https://arxiv.org/abs/2602.01146)
- [OpenAI Memory FAQ](https://help.openai.com/en/articles/8590148-memory-faq)
- [Why I Turned Off ChatGPT’s Memory - Mike Taylor, Every](https://every.to/also-true-for-humans/why-i-turned-off-chatgpt-s-memory)
- [Context Rot: How Increasing Input Tokens Impacts LLM Performance - Chroma](https://www.trychroma.com/research/context-rot)
- [Long Context RAG Performance of LLMs - Databricks](https://www.databricks.com/blog/long-context-rag-performance-llms)
- [When AI Remembers Too Much: Persistent Behaviors in Agents’ Memory - Unit 42](https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons-ai-longterm-memory/)
- [CIMemories: A Compositional Benchmark for Contextual Integrity of Persistent Memory in LLMs](https://arxiv.org/abs/2511.14937)
- [PersistBench: When Should Long-Term Memories Be Forgotten by LLMs?](https://arxiv.org/abs/2602.01146)
- [OP-Bench: Benchmarking Over-Personalization in Memory-Augmented Conversational Agents](https://arxiv.org/html/2601.13722v1)
- [MINJA: Memory Injection Attacks on LLM Agents via Query-Only Interaction](https://arxiv.org/abs/2503.03704)
- [Twitter](https://twitter.com/manthanguptaa)
- [LinkedIn](https://www.linkedin.com/in/manthanguptaa/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [9:25 PM · Apr 22, 2026](https://x.com/manthanguptaa/status/2046943418769981677)
- [10.8K Views](https://x.com/manthanguptaa/status/2046943418769981677/analytics)
- [View quotes](https://x.com/manthanguptaa/status/2046943418769981677/quotes)
---
*导出时间: 2026/4/23 15:09:29*
---
## 中文翻译
# 逆向工程 GPT、Claude、OpenClaw、Hermes 后，我明白了大多数 AI 产品不应该上线记忆功能
**作者**： Manthan Gupta
**日期**： 2026-04-22T13:25:16.000Z
**来源**： [https://x.com/manthanguptaa/status/2046943418769981677](https://x.com/manthanguptaa/status/2046943418769981677)
---
我第一次问 ChatGPT 它记住了关于我的什么信息时，它列出了 33 条事实。姓名、职业目标、健身计划、我几周前提过的副项目名称，还有一条来自完全不相关对话的、关于我休职期的随口一提。我当时很惊叹。接下来的几周里，我对它的实际工作原理进行了逆向工程，然后对 Claude、OpenClaw 和 Hermes 也做了同样的事。大约到第三个系统时，我不再注意到这些设计有多巧妙，而是开始注意到记忆是多么频繁地在损害我自己的输出质量。
显式状态胜过隐式记忆，而且这种情况出奇地常见。记忆不是默认功能，它是一种产品和系统层面的税，而大多数 AI 产品还没有资格支付这笔税。
## 我在四个记忆系统内部看到的
我想先从综合结论讲起，因为如果不做逆向工程的工作，这部分我是写不出来的。
我研究的这四个系统各自采用了根本不同的方法：
- ChatGPT 使用注入式档案。一个长期事实存储（就我而言是 33 条事实），加上预计算的近期聊天摘要，再加上会话元数据。所有这些都被拼接到每一个提示词中。就是一个精心整理的信息块，随每一轮对话一起附带。
- Claude 使用按需检索。一个很小的 <userMemories> 信息块始终存在，但过去的对话默认不会被注入。当模型判断上下文相关时，可以将 conversation_search 或 recent_chats 作为工具调用。
- OpenClaw 使用 Markdown 工作区。一切都是磁盘上的纯文本文件：MEMORY.md 存储持久知识，memory/YYYY-MM-DD.md 存储每日日志，并建立了索引支持语义+关键词混合搜索。智能体按需搜索自己的笔记。
- Hermes 使用热/冷分离。一个极小的冻结提示词记忆——MEMORY.md 上限为 2,200 字符，USER.md 上限为 1,375 字符，合计约 1,300 个 token——外加一个基于 SQLite 的 session_search 用于情节记忆，外加一个技能系统用于程序性记忆，再加一个可选的用户建模层。
四个系统，四种不同的答案。把它们放在一起对比，一个模式就变得很明显。最简单的方法——注入式档案——恰恰是失败模式最糟糕的一种：每一条旧事实都在每一个未来提示词中争夺注意力，而你没有任何原则性的说法来解释何时该停止。这也是大多数产品团队照搬的方法，因为它最容易演示、最容易上线。这就是为什么大多数 AI 产品最终都拥有损害自身输出质量的记忆功能。
四个系统中最深思熟虑的是 Hermes，而将其设计凝聚在一起的核心选择来自源码中的一句话：保持提示词稳定以便缓存，把其他一切都推到工具中去。记忆不再是无处不在的默认存在，而变成了模型必须做出的选择。我认为大多数团队应该效仿的正是这个方向，而这恰恰与那条简单的路径所给你的相反。
## 存储很容易，检索策略很难。
在我深入研究了这四个系统的内部之后，有一个观察始终挥之不去。存储这一侧其实并不是难点。存储事实很容易。你可以用一个 JSON 块、一个 Markdown 文件、一个 SQLite 表或一个向量索引来实现。有趣的部分是决定记忆究竟是有助于还是损害输出质量的那部分——检索策略，也就是决定把哪条被记住的信息拉入哪个未来提示词的启发式规则。
用这个视角审视这四个系统，图景就更清晰了：
- ChatGPT 的检索策略是“始终注入”。每一条存储的事实都随每一个提示词一起附带。成本低、速度快，但也是无论相关与否，旧上下文不断影响新答案的原因。
- Claude 的检索策略是“模型决定”。模型必须识别过去的对话何时相关，并调用一个工具。运作良好时提示词更干净，但依赖于模型能否正确做出“我需要搜索吗？”的判断。
- OpenClaw 的检索策略是“智能体发起语义+关键词搜索”。比始终注入更好，但积累的笔记越多，搜索的工作负担就越重，拉取到过时或冗余内容的可能性也越大。
- Hermes 的检索策略是分层且明确的。一个极小的热数据集存储持久事实，一个独立的冷存储存放情节历史，一个独立的技能索引存放程序性知识，还有关于什么内容属于哪里的明确规则。（“保存用户偏好、环境事实、反复出现的纠正、稳定的惯例。不要保存任务进度、会话结果、临时的 TODO 状态。”）
我看到的每一个失败案例，以及本文其余部分描述的大多数失败，都源于薄弱的检索策略，而不是薄弱的存储层。ChatGPT 的失败是架构性的：策略就是“始终注入”，这就是为什么过时的上下文不断渗透进来。更好的存储方案解决不了这个问题。只有更好的检索策略才行。
这一点很重要，因为大多数上线记忆功能的团队都把他们的复杂度预算花在了错误的那一半上。他们比较向量数据库，设计嵌入流水线，争论分块大小。而检索策略在设计文档中只有一句话：“我们会检索 top-k 相关条目并注入。”产品的质量恰恰就取决于这一句话。而大多数团队在这上面是在盲目飞行。
## 记忆功能的最佳论据
在提出反对意见之前，我想先认真对待相反的观点。
默认记忆功能最有力的论据是减少摩擦。不必每个会话都重新输入偏好，这确实很方便，尤其是对普通用户来说。“记住我是素食者”这种事不应该需要说两遍。
下一个最有力的理由是本质上具有长期性的产品需要连续性。像 Granola 这样的会议工具，像 Reflect 和 Mem.ai 这样的个人知识产品，像 Replika 这样的关系型产品，以及治疗陪伴类应用。对这些产品来说，记忆不是一个功能，记忆本身就是产品。
第三个是留存楔子。Mike Taylor 的文章指出，“它太懂我了”这种感觉正是留住 ChatGPT 用户的关键。这是真实存在的。用户不会转向 Gemini 或 Claude，部分原因就是不想重建自己的档案。无论记忆是否能让输出质量更好，它都会让你的产品更具粘性。
第四个是低风险漂移。对于诸如菜谱创意、旅行建议、闲聊等随意任务，因为过时记忆而产生的小偏差并不会真正伤害用户。
这些理由每一个都有反驳之处。减少摩擦并不需要隐性记忆；一个设置面板就能做到，而无需付出代价。长期性场景正是本文为那些产品所承认的例外——可以发布记忆功能。留存楔子是一个商业理由，而非质量理由；你是在用输出质量换取粘性，这是一个合理的选择，但应当是有意识做出的选择。而低风险漂移的前提是你的产品只服务于随意任务，但这很少成立——同一个在 ChatGPT 上查菜谱的用户，也在做代码审查、绩效评估，以及类似治疗的倾诉，而过时的记忆并不知道当前处于哪种场景。
支持记忆论点最强的版本是真实的。只是它比大多数产品发布记忆功能时的适用范围要窄得多。
## 记忆在实践中如何出错
一旦你在发布记忆功能时采用了薄弱的检索策略，它就会以可预测、有据可查的方式失败。
输出质量下降。Mike Taylor 的《为什么我关闭了 ChatGPT 的记忆》是对此最好的用户端记录。他在自定义指令中放入了一句 Kanye 关于“dopeness”（酷劲）的话，结果 ChatGPT 开始声称它把一个可折叠的网页版块做得“尽可能的酷”，并将同一句话应用到室内装饰、营销计划和 Python 调试中。当他为了写那篇文章重新开启记忆时，一个关于烤猪肋排建议的请求返回了“霍博肯晚餐升级创意”，因为助手知道他刚搬了家。OP-Bench 在基准测试规模上展示了这一模式：增强记忆的智能体即使在没必要的情况下也会检索用户细节，然后过度关注这些细节，直到细节淹没了实际的查询。
调试变得异常困难。我在智能体代码库中花了足够多的时间，深知记忆类 bug 的特征：实时追踪是干净的。提示词、检索、工具日志都没问题。但奇怪的行为依然发生。原因在于架构。
塑造明天答案的东西，存在于你没有记录日志的流水线中。
Unit 42 关于 Amazon Bedrock Agents 的文章描述的正是这种形态：记忆由一个独立的会话摘要过程生成，该过程在会话结束时运行，并合并到下一个会话的系统提示词中。我逆向工程过的每一个记忆系统都有这种拆分的某个版本。有了记忆，你调试的不是一个请求，而是一段关系，而这段关系被记录在你没有查看的地方。
上下文腐烂。上下文窗口不是免费的智能，它是稀缺的工作记忆。Chroma 的 Context Rot 研究在刻意控制的任务上评估了 18 个领先模型，保持任务难度不变，只改变输入长度。在他们测试的每一个模型中，性能都随输入长度增加而下降，而且随着上下文增长，干扰项造成的伤害更大。Databricks 的一项研究表明，准确率在窗口填满之前就会大幅下降，有时早在 32k token 时就出现了。微软/Salesforce 的一篇论文显示，将提示词拆分为多轮对话而非一次性提问，平均会导致性能下降 39%。大多数记忆系统都是伪装起来的上下文膨胀机制。
隐私很快变得奇怪。我构建 BYOM 是因为，一旦你清晰地审视一个记忆系统，它就不再是一个便利功能，而是变成了一个持久的用户画像系统。CIMemories 论文指出了具体的失效模式：增强记忆的 LLM 往往能选对要谈论的领域，但无法分辨该领域内哪些细节是相关的。领域对了（生活琐事），粒度错了（治疗日程渗透进工作邮件草稿）。个性化和上下文完整性不是一回事。
一个全新的攻击面。Unit 42 针对 Bedrock Agents 的概念验证展示了“被投毒的记忆”实际上是什么样子。攻击者在网页中隐藏了一个提示词注入。受害者让他们的旅行助手读取该 URL。实时会话中没有出任何问题——载荷是专门针对会话摘要提示词而非编排提示词设计的。当会话关闭时，摘要器将攻击者的指令作为一个看起来正常的话题写入记忆。几天后，用户回来预订行程，智能体通过调用自身的 scrape_url 工具将预订信息泄露到攻击者控制的域名。针对无状态聊天的提示词注入是暂时性的。注入到记忆中的提示词注入是持久性的。MINJA 论文表明，攻击者甚至并不总是需要访问记忆存储——仅凭用户式的交互就能将载荷植入。
人格漂移。PersistBench 报告称，长期记忆系统在跨领域泄露上的中位失败率为 53%，在谄媚样本上为 97%。谄媚这个数字才是可怕的。如果助手对你的记忆使它倾向于附和与迎合，而不是诚实的判断，那你面对的就不是记忆问题，而是判断问题。而且它在用户眼中依然会显得很有“个性”。
## Hermes 模式：将记忆作为工具，而非环境上下文
如果说上一节是症状清单，那么 Hermes 就是针对病根的治疗方案。
三个原则维系着这一架构。首先，它将热记忆与冷召回分离。一个极小的始终注入的块用于持久性事实，一个可搜索的冷存储用于情景历史，一个技能索引用于程序性记忆。“始终注入”层级中的任何内容都不允许无限制增长，因为提示词记忆是对缓存敏感的工作集，而不是日记。
其次，它将提示词稳定性视为一等约束。记忆在会话开始时被冻结为快照，并且不会在会话中途被修改。写入会立即落盘，但提示词保持稳定，直到自然的重建点（新会话、压缩后）。每个智能体系统都在部署记忆时从不考虑缓存。Hermes 考虑了。
第三，它承认记忆是多元的。事实、情景、技能以及更深层次的用户建模是不同的检索问题，需要不同的策略。单一的存储无法解决所有这些问题。
这就是把记忆做对之后在实践中应有的样子。不是更大的向量数据库。不是更聪明的自动晋升机制。系统提示词中的东西更少，工具中的东西更多，关于什么属于哪里的明确规则。大多数发布记忆功能的 AI 产品本可以削减 80% 的记忆面，最终获得更好的输出。
## 在发布记忆功能之前，先回答这些问题
上述综合分析可以转化为一份检查清单。在为你的产品发布记忆功能之前，请诚实地回答以下问题：
你的产品是否具有天然的纵向性？用户从第一次会话中获得的收益是否少于第十次会话？如果不是，你不需要记忆。
你能否在存储系统和检索策略之间划出清晰的界线？如果不能，你即将复制 ChatGPT 的失败模式，并将其称为个性化。
存储的状态是否对用户可见并可由其直接编辑？如果不是，你构建的是隐性画像，而不是记忆。
你能否将召回范围限定在特定任务、项目或显式的工具调用上？如果不能，环境记忆将会在上下文之间产生串扰。
你的团队是否愿意在接下来三年里承担隐私、安全和调试的负担？如果不愿意，你发布的不是记忆，而是一份负债。
如果对上述大多数问题的诚实回答是否定的，请不要发布记忆功能。转而发布可见的设置、限定范围的项目状态和明确的任务简报。Cursor 的 .cursorrules 和 AGENTS.md、Claude Projects、Zed 的 .rules、ChatGPT 自定义指令、Linear 的任务上下文——所有这些之所以有效，是因为它们清晰可读、可编辑且范围明确。它们都不需要记忆层就能完成工作。
## 结语
记忆听起来很智能，因为人类将记忆与理解联系在一起。产品记忆不是人类记忆。它是带有检索规则的存储上下文，伴随着摘要错误、隐私权衡、安全暴露，以及一种把旧信号变成未来偏见的持续倾向。这并不意味着它没用，而是意味着它代价高昂。
如果你的 AI 产品仍在基础工作流设计、明确的设置、干净的状态管理和可靠的任务执行方面挣扎，那么添加记忆功能并不会让它变得更聪明。它只会让它失败时更难理解，漂移时更难调试，以及当它自信地把错误的东西带向未来时更难被信任。
事实是，大多数 AI 产品不需要更好的记忆。它们需要更好的产品设计。
## 参考文献
- OpenAI Memory FAQ
- Why I Turned Off ChatGPT’s Memory - Mike Taylor, Every
- Context Rot: How Increasing Input Tokens Impacts LLM Performance - Chroma
- Long Context RAG Performance of LLMs - Databricks
- When AI Remembers Too Much: Persistent Behaviors in Agents’ Memory - Unit 42
- CIMemories: A Compositional Benchmark for Contextual Integrity of Persistent Memory in LLMs
- PersistBench: When Should Long-Term Memories Be Forgotten by LLMs?
- OP-Bench: Benchmarking Over-Personalization in Memory-Augmented Conversational Agents
- MINJA: Memory Injection Attacks on LLM Agents via Query-Only Interaction
如果你觉得这篇文章有趣，我很乐意听听你的想法。欢迎在 Twitter、LinkedIn 上分享，或通过 guptaamanthan01[at]gmail[dot]com 与我联系。
## 相关链接
- [Manthan Gupta](https://x.com/manthanguptaa)
- [@manthanguptaa](https://x.com/manthanguptaa)
- [1万](https://x.com/manthanguptaa/status/2046943418769981677/analytics)
- [逆向工程它的实际工作原理](https://manthanguptaa.in/posts/chatgpt_memory)
- [Claude](https://manthanguptaa.in/posts/claude_memory)
- [OpenClaw](https://manthanguptaa.in/posts/clawdbot_memory)
- [Hermes](https://manthanguptaa.in/posts/hermes_memory)
- [Mem.ai](https://mem.ai/)
- [为什么我关闭了 ChatGPT 的记忆功能](https://every.to/also-true-for-humans/why-i-turned-off-chatgpt-s-memory)
- [OP-Bench](https://arxiv.org/html/2601.13722v1)
- [Unit 42 分析报告](https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons-ai-longterm-memory/)
- [Context Rot 研究](https://www.trychroma.com/research/context-rot)
- [Databricks 研究](https://www.databricks.com/blog/long-context-rag-performance-llms)
- [微软/Salesforce 论文](https://arxiv.org/pdf/2505.06120)
- [CIMemories](https://arxiv.org/abs/2511.14937)
- [MINJA 论文](https://arxiv.org/abs/2503.03704)
- [PersistBench](https://arxiv.org/abs/2602.01146)
- [OpenAI 记忆功能常见问题](https://help.openai.com/en/articles/8590148-memory-faq)
- [为什么我关闭了 ChatGPT 的记忆功能 - Mike Taylor, Every](https://every.to/also-true-for-humans/why-i-turned-off-chatgpt-s-memory)
- [Context Rot：输入令牌增加如何影响 LLM 性能 - Chroma](https://www.trychroma.com/research/context-rot)
- [LLM 的长上下文 RAG 性能 - Databricks](https://www.databricks.com/blog/long-context-rag-performance-llms)
- [当 AI 记住得太多：智能体记忆中的持久行为 - Unit 42](https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons-ai-longterm-memory/)
- [CIMemories：LLM 持久记忆语境完整性的组合式基准测试](https://arxiv.org/abs/2511.14937)
- [PersistBench：LLM 应该何时遗忘长期记忆？](https://arxiv.org/abs/2602.01146)
- [OP-Bench：记忆增强对话智能体过度个性化的基准测试](https://arxiv.org/html/2601.13722v1)
- [MINJA：仅通过查询交互对 LLM 智能体发起的记忆注入攻击](https://arxiv.org/abs/2503.03704)
- [Twitter](https://twitter.com/manthanguptaa)
- [LinkedIn](https://www.linkedin.com/in/manthanguptaa/)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [2026年4月22日 下午9:25](https://x.com/manthanguptaa/status/2046943418769981677)
- [1.08万次浏览](https://x.com/manthanguptaa/status/2046943418769981677/analytics)
- [查看引用](https://x.com/manthanguptaa/status/2046943418769981677/quotes)
---
*导出时间: 2026/4/23 15:09:29*
