# A Framework for Agent Memory: Remember, Cite, Forget
**作者**: Vox
**日期**: 2026-05-22T16:31:59.000Z
**来源**: [https://x.com/Voxyz_ai/status/2057862044783628508](https://x.com/Voxyz_ai/status/2057862044783628508)
---
When people add memory to an agent, the first instinct is usually "what else can I store in there?" But more storage doesn't mean the agent will actually use it.
For example: I run X Manager, the kind of agent that fires lots of cron jobs throughout the day. After running it for a while, I'm convinced of one thing. Agent memory has to do three jobs at once to be reliable. Remember what should be remembered. Cite what should be trusted. Forget what should expire. Break these three apart and you have a framework you can apply to any agent.
## Remember: agent memory comes in layers
In practice, the memory an agent uses comes in roughly 6 layers.
Each one has a different lifespan, a different scope of authority, and a different way of failing.
Hot session (working memory for the current task)
Holds the in-progress context: what the user just said, the last tool output, intermediate conclusions from this round. Should be cleared at task end. Common failure: the user said "no emoji today" two turns ago, the agent compressed the context on turn three, dropped that line, and added emoji again.
To soften this kind of loss, look at how lossless-claw handles it: raw messages land in SQLite, summaries only do compression, and the agent can grep the originals when needed.
Day-state (today's operating whiteboard)
What the agent has done today, where it is in its sequence, what's next. A whiteboard is meant to be overwritten. One direct instruction with a newer timestamp should retire the previous state. Common failure: you said in the morning "work on article A first," then switched to B in the afternoon, but the cron agent is still pulling research for A.
Project memory (long-running lessons)
What this project has tripped over before, which patterns worked, which decisions have been settled. Longer-lived than the whiteboard, but still gets overwritten by newer lessons. Common failure: a three-month-old note that says "user prefers markdown" still shapes today's formatting choice, even though the user switched preferences last month.
To do this layer well, write lessons into a cross-session structured knowledge base like GBrain, or your own notes / wiki system.
Retrieval / Index (surfaces candidates, doesn't decide)
Vector stores, RAG, GBrain search, graph search all live here. Their job is to surface material that might be relevant. The index gives you candidates. The final call still depends on source, time, authority, and freshness. Common failure: a vector search pulls up an old plan from six months ago, and it gets treated as the current best answer.
Canonical policy (the long-term rule layer)
Project rule files (things like AGENTS.md, SOUL.md), team policy, product boundaries. These are more like the agent's "constitution": long-lived, stable, and you only change them by editing the file by hand.
Direct instruction (the immediate task command)
What the user just said. High priority for the current task, but not necessarily durable. It has to keep its original source attached. A summary paraphrase doesn't carry the same weight. Common failure: AGENTS.md says "public actions require manual confirmation," the hot-session summary says "user has authorized batch sending," and the agent quietly follows the summary. The only thing that can override canonical is a traceable original confirmation. "The user seemed to authorize this" from a summary doesn't count.
These 6 layers weren't invented in a vacuum. Mainstream frameworks like LangGraph and Mem0 also split memory into layers. Different names, same principle. This version is a builder's-eye take on the same idea.
Layering alone isn't enough. Every layer has to answer one question: what gives this memory the right to influence the decision? That's where the second job comes in.
## Cite: don't make the agent guess who's authoritative
In practice, memory work takes at least two steps.
Step 1: Figure out which source the current query should hit. GBrain's source resolver is a good reference: it uses a CLI flag, an env variable, a dotfile, longest-prefix path match, a default config, and a fallback to decide the current source. What this step prevents: querying the wrong source.
Step 2: When the lookup turns up conflicting facts, an authority order decides who wins. The application defines this part for itself. Here's an order you can copy:
1. Original direct instruction
2. Canonical policy
3. Most recent project decision
4. Long-term memory with source attribution
5. Retrieval summary
6. Compressed summary
Higher levels overrule lower ones.
What does this look like without that machinery in production? The 2024 Air Canada chatbot case is the classic source-authority example. The bot told a customer he could apply for a retroactive bereavement-fare refund, but the official policy page said the opposite. The tribunal ordered Air Canada to pay C$650.88 in fare difference plus interest. The judge's words: "It makes no difference whether the information comes from a static page or a chatbot."
What this case shows: once AI speaks for the company, it can't disagree with the canonical policy page. Users shouldn't have to guess which one is more accurate. The company has to define the authority chain itself.
Citations themselves go stale. Before the 2026 Scottish election, Demos tested AI tools on 75 election questions and found misinformation in 34% of the answers. ChatGPT's citations were "at least a year out of date" 44% of the time. For agents, judging a source means asking whether the link is still current.
Even the most authoritative fact has to step aside when it goes stale. On to the third job.
## Forget: expiring old memories is reliability engineering
The most underrated agent memory capability is letting old memories expire. Most teams treat forget as a GDPR compliance task, but for agents this is a reliability problem: a memory that's gone stale still looks usable, even though the agent doesn't know it's already quietly wrong. That's more dangerous than "no memory at all."
This risk has already shown up in real content systems. In 2026, the UK's Department for Business and Trade described a GOV.UK example: the main page was up to date, but the GenAI bot, on narrower queries, was pulling answers from an unmaintained old GOV.UK page. The DBT audit found 150 pages on the first pass that all met three criteria at once: not updated in 5 years, fewer than 11 visits in 5 years, and no owner.
The old information hasn't gone anywhere. It's just unread. Once the agent pulls it back, it sounds as confident as today's answer.
Three implementation routes are out there. They can coexist.
Hard expiry. valid_from / valid_until columns. When a new fact arrives, the old fact gets an expiry timestamp written to it. The old record is retained but flagged as no longer usable. Example: GBrain typed facts / trajectory. Use for policy, pricing, regulations.
Bitemporal. Four timestamps created_at / valid_at / invalid_at / expired_at distinguish "when it was true in reality" from "when the system learned it was no longer valid." Example: Zep. Use for facts that change over time.
Soft decay. Retrieval ranking demotes long-unused memories, down to a 0.3× floor. The docs say "Nothing gets deleted or hidden." It's a search-time recency rerank. Example: Mem0. Use for preferences, habits, background knowledge.
When you design agent memory, define the expiry mechanism alongside the storage mechanism.
## 3 questions to ask before any memory enters the decision loop
Now translate the three jobs into a quick audit. Before any memory enters the decision loop, ask:
1. What level of decision can this affect? Hint only? Citable evidence? Or can it make the final call?
2. Where did it come from? Which canonical file, which day's notes, which message? Or is it just a derivative of another memory?
3. Is it still valid? What kind of new information would make this memory step aside?
An example. The agent is about to reply to an email and pulls a three-month-old preference from project memory: the user once said "don't use markdown for replies, plain text is fine."
- Decision level: hint only, can't override an explicit instruction from today.
- Source: must be able to point to which message and who said it.
- Still valid: three months untouched, so confirm with the user once before using.
If all three questions are answerable, the memory can enter the decision path. If not, it can only stay as background context. Don't let a memory with no source, no validity window, and no authority boundary make calls for the agent.
## A pocket card you can save
Remember by layer. Cite by source. Forget by expiry. Stick this somewhere visible. Run through it before adding any new memory to your agent.
- Hot session. Carries the current task. Steps aside when the task ends.
- Day-state. Coordinates today. Steps aside when a newer direct decision arrives.
- Project memory. Long-running lessons. Steps aside when the lesson gets overwritten.
- Retrieval / Index. Surfaces candidates, doesn't decide. Steps aside when the source updates, the index rebuilds, or a candidate fact expires.
- Canonical policy. Long-term rules and boundaries. Steps aside when a new policy version is manually committed.
- Direct instruction. Immediate call for the current task. Steps aside when the task ends, or a new instruction arrives.
Drop it into your agent project's AGENTS.md or README, and run through it before any memory change review.
Designing agent memory is the same shape as company governance. Remember through layering. Cite through provenance. Forget through expiry. Bundle these three into one trust contract you write into the agent, and its calls start being reliable.
The point where an agent actually becomes trustworthy is when all three are working at once.
Everything I'm writing as I build: voxyz.ai/insights.
## Tools you can try
- GBrain: cross-session structured knowledge base, bitemporal facts, 6-tier source resolver. github.com/garrytan/gbrain
- lossless-claw: lossless session recording (OpenClaw plugin). github.com/Martian-Engineering/lossless-claw
- LangGraph: short-term + long-term layers (semantic / episodic / procedural). docs.langchain.com/oss/python/concepts/memory
- Mem0: conversation / session / user / org layers + soft decay. docs.mem0.ai
- Zep: bitemporal facts (four timestamps). help.getzep.com/facts
## 相关链接
- [Vox](https://x.com/Voxyz_ai)
- [@Voxyz_ai](https://x.com/Voxyz_ai)
- [16K](https://x.com/Voxyz_ai/status/2057862044783628508/analytics)
- [lossless-claw](https://github.com/Martian-Engineering/lossless-claw)
- [GBrain](https://github.com/garrytan/gbrain)
- [LangGraph](https://docs.langchain.com/oss/python/concepts/memory)
- [Mem0](https://docs.mem0.ai/core-concepts/memory-types)
- [GBrain](https://github.com/garrytan/gbrain)
- [Air Canada chatbot](https://www.theguardian.com/world/2024/feb/16/air-canada-chatbot-lawsuit)
- [Demos tested AI tools](https://www.theguardian.com/technology/2026/may/20/ai-chatbots-chatgpt-replika-grok-gemini-misinformation-scottish-election-demos)
- [Department for Business and Trade](https://digitaltrade.blog.gov.uk/2026/04/20/how-were-preventing-ai-misinformation-at-dbt/)
- [GOV.UK](https://gov.uk/)
- [GOV.UK](https://gov.uk/)
- [GBrain](https://github.com/garrytan/gbrain)
- [Zep](https://help.getzep.com/facts)
- [Mem0](https://mem0.ai/blog/introducing-memory-decay-in-mem0)
- [voxyz.ai/insights](https://voxyz.ai/insights)
- [github.com/garrytan/gbrain](https://github.com/garrytan/gbrain)
- [github.com/Martian-Engineering/lossless-claw](https://github.com/Martian-Engineering/lossless-claw)
- [docs.langchain.com/oss/python/concepts/memory](https://docs.langchain.com/oss/python/concepts/memory)
- [docs.mem0.ai](https://docs.mem0.ai/core-concepts/memory-types)
- [help.getzep.com/facts](https://help.getzep.com/facts)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:31 AM · May 23, 2026](https://x.com/Voxyz_ai/status/2057862044783628508)
- [16.7K Views](https://x.com/Voxyz_ai/status/2057862044783628508/analytics)
---
*导出时间: 2026/5/23 09:01:17*
---
## 中文翻译
# 智能体记忆框架：记住、引用、遗忘
**作者**: Vox
**日期**: 2026-05-22T16:31:59.000Z
**来源**: [https://x.com/Voxyz_ai/status/2057862044783628508](https://x.com/Voxyz_ai/status/2057862044783628508)
---
当人们给智能体添加记忆时，第一直觉通常是“我还能往里面存点什么？”。但更多的存储并不意味着智能体真的会去使用它。
举个例子：我运营 X Manager（一款全天候大量运行定时任务的智能体）。运行一段时间后，我确信了一件事：智能体记忆必须同时做好三项工作才能可靠。记住该记住的。引用该信任的。遗忘该过期的。把这三者拆分开，你就得到了一个可应用于任何智能体的框架。
## 记住：智能体记忆是分层的
在实践中，智能体使用的记忆大致分为 6 层。
每一层都有不同的寿命、不同的权限范围，以及不同的失败方式。
**热会话（当前任务的工作记忆）**
保存进行中的上下文：用户刚才说了什么、上一个工具的输出、这一轮的中间结论。应在任务结束时清除。常见失败：用户在两轮对话前说“今天不要用表情符号”，智能体在第三轮压缩了上下文，丢掉了那句话，结果又加上了表情符号。
为了缓解这种损失，可以看看 lossless-claw 是怎么处理的：原始消息存入 SQLite，仅对摘要进行压缩，智能体在需要时可以检索原始内容。
**每日状态（今天的操作白板）**
智能体今天做了什么，当前处于序列的什么位置，接下来是什么。白板本来就是用来覆盖重写的。一个带有更新时间戳的直接指令应该让旧的状态退役。常见失败：你早上说“先做文章 A”，下午转到了 B，但定时任务智能体还在为 A 拉取研究资料。
**项目记忆（长期经验教训）**
这个项目以前踩过什么坑、哪些模式有效、哪些决定已敲定。比白板存续期长，但仍会被新的经验覆盖。常见失败：一条三个月前的笔记写着“用户偏好 markdown”，仍然在影响今天的格式选择，尽管用户上个月已经改了偏好。
要做好这一层，可以把经验教训写入跨会话的结构化知识库，如 GBrain，或者你自己的笔记/ wiki 系统。
**检索 / 索引（展示候选项，不做决策）**
向量库、RAG、GBrain 搜索、图搜索都住在这里。它们的职责是把可能相关的材料“捞出来”。索引给你的是候选项。最终裁决仍取决于来源、时间、权威性和新鲜度。常见失败：一次向量搜索捞出了六个月前的旧方案，结果被当成了当前的最佳答案。
**权威策略（长期规则层）**
项目规则文件（如 AGENTS.md、SOUL.md）、团队策略、产品边界。它们更像是智能体的“宪法”：长期存在、稳定，只能通过手动编辑文件来修改。
**直接指令（当前任务的直接命令）**
用户刚才说的话。对当前任务优先级很高，但不一定持久。它必须保持附带原始来源。经过转述的摘要没有同样的分量。常见失败：AGENTS.md 写着“公开操作需人工确认”，热会话摘要写着“用户已授权批量发送”，结果智能体悄悄听信了摘要。唯一能覆盖权威策略的是可追溯的原始确认。摘要里写“用户似乎授权了”不算数。
这 6 层并非凭空捏造。像 LangGraph 和 Mem0 这样的主流框架也将记忆分层。名字不同，原理一样。这个版本是从构建者视角对同一理念的阐述。
仅靠分层是不够的。每一层都必须回答一个问题：是什么赋予了这条记忆影响决策的权利？这就引出了第二项工作。
## 引用：别让智能体去猜谁更权威
在实践中，记忆工作至少分两步走。
**第 1 步：弄清当前查询该打哪个源。** GBrain 的源解析器是个很好的参考：它利用 CLI 标志、环境变量、点文件、最长前缀路径匹配、默认配置和兜底选项来决定当前源。这一步防的是什么：查错源。
**第 2 步：当查找出现冲突事实时，由权威顺序决定谁赢。** 这部分由应用自己定义。下面是一套可直接复用的顺序：
1. 原始直接指令
2. 权威策略
3. 最近的项目决策
4. 带来源归属的长期记忆
5. 检索摘要
6. 压缩摘要
上层覆盖下层。
如果在生产中没有这套机制会怎样？2024 年加拿大航空聊天机器人案是经典的“来源—权威”案例。机器人告诉客户可以申请追溯性的丧亲票价退款，但官方政策页说的却相反。法庭裁定加拿大航空支付 650.88 加元的票价差及利息。法官的话是：“信息是来自静态页面还是聊天机器人，没有区别。”
这个案例表明：一旦 AI 代表公司发言，它就不能与权威策略页唱反调。用户不该去猜哪个更准确。公司必须自己定义权威链。
引用本身也会过时。在 2026 年苏格兰选举前，Demos 用 75 个选举问题测试 AI 工具，发现 34% 的回答包含错误信息。ChatGPT 的引用有 44% 的时间“至少过期了一年”。对智能体来说，判断一个来源意味着问：链接是否仍然有效。
即便是再权威的事实，一旦过期也得靠边站。接下来是第三项工作。
## 遗忘：让旧记忆过期是可靠性工程
最被低估的智能体记忆能力，就是让旧记忆过期。大多数团队把遗忘当作 GDPR 合规任务，但对智能体而言，这是个可靠性问题：一条过期的记忆看起来仍然可用，尽管智能体并不知道它其实已经悄悄出错了。这比“完全没有记忆”更危险。
这种风险已经出现在真实的内容系统中。2026 年，英国商业贸易部描述了一个 GOV.UK 的案例：主页是最新的，但 GenAI 机器人在处理更细化的查询时，却从无人维护的旧 GOV.UK 页面上拉取答案。DBT 审计在第一轮就发现 150 个页面同时满足三个条件：5 年未更新、5 年访问量不足 11 次、无负责人。
旧信息并没有消失。只是没人去读。一旦智能体把它拉回来，听起来和今天的答案一样自信。
市面上已有三种实现路径，它们可以共存。
**硬过期。** valid_from / valid_until 字段。当新事实到来时，旧事实会被写入一个过期时间戳。旧记录保留，但被标记为不再可用。例如：GBrain 的 typed facts（类型化事实）/ trajectory（轨迹）。适用于策略、定价、法规。
**双时态。** 四个时间戳 created_at / valid_at / invalid_at / expired_at，区分“它在现实中何时为真”与“系统何时得知它不再有效”。例如：Zep。适用于随时间变化的事实。
**软衰减。** 检索排名会把长期未使用的记忆降权，下至 0.3× 的下限。文档称“没有任何内容被删除或隐藏”。这是搜索时的“新鲜度重排”。例如：Mem0。适用于偏好、习惯、背景知识。
在设计智能体记忆时，应该把过期机制与存储机制一并定义。
## 在任何记忆进入决策循环前先问三个问题
现在把这三项工作转化成一个快速审计。在任意记忆进入决策循环前，问：
1. 这会影响哪一级决策？仅作为提示？可引用的证据？还是能做最终拍板？
2. 它从哪来？来自哪个权威文件、哪一天的笔记、哪条消息？还是只是另一条记忆的衍生？
3. 它仍然有效吗？什么样的新信息会让这条记忆靠边站？
举个例子。智能体即将回复一封邮件，并从项目记忆中拉出一条三个月前的偏好：用户曾经说“回复不要用 markdown，纯文本就好”。
- 决策级别：仅提示，不能覆盖今天的明确指令。
- 来源：必须能指出是哪条消息、谁说的。
- 仍然有效：三个月未动，因此在使用前向用户确认一次。
如果三个问题都能回答，记忆就可以进入决策路径。如果不能，它就只能作为背景上下文待着。别让一条没有来源、没有有效期、也没有权威边界的记忆替智能体做决定。
## 你可以保存的一张随身卡
按层级来记。按来源来引用。按过期来遗忘。把它贴在显眼的地方。在给智能体添加任何新记忆之前都过一遍。
- Hot session。承载当前任务。任务结束时靠边。
- Day-state。协调整天事务。当更新、更直接的决定到来时靠边。
- Project memory。长期经验。当经验被覆盖时靠边。
- Retrieval / Index。展示候选项，不做决策。当源更新、索引重建或候选项事实过期时靠边。
- Canonical policy。长期规则与边界。当手动提交新版本策略时靠边。
- Direct instruction。针对当前任务的直接命令。当任务结束或新指令到来时靠边。
把它扔进你智能体项目的 AGENTS.md 或 README 里，并在任何记忆变更审查前过一遍。
设计智能体记忆，与公司治理是同构的。通过分层来记住。通过溯源来引用。通过过期来遗忘。把这三者打包成一份写入智能体的“信任合约”，它的决策就开始变得可靠。
智能体真正值得信赖的那一点，就是这三者同时发挥作用的时候。
我在构建过程中的所写所得：voxyz.ai/insights。
## 你可以试一试的工具
- GBrain：跨会话结构化知识库，双时态事实，6 层源解析器。github.com/garrytan/gbrain
- lossless-claw：无损会话记录（OpenClaw 插件）。github.com/Martian-Engineering/lossless-claw
- LangGraph：短期 + 长期层（语义 / 情景 / 程序性）。docs.langchain.com/oss/python/concepts/memory
- Mem0：对话 / 会话 / 用户 / 组织层 + 软衰减。docs.mem0.ai
- Zep：双时态事实（四个时间戳）。help.getzep.com/facts
---
*导出时间: 2026/5/23 09:01:17*