🔶 Agent 记忆的四种类型

问三个团队“Agent 记忆”是什么意思，你会得到三张不同的架构图——但三张图中都会有同样的四个框：工作记忆、情景记忆、语义记忆、程序性记忆。这套分类法是这个领域最接近共同词汇的东西。使用它的大多数人，却说不清它从何而来、哪些部分能直接迁移到 LLM Agent，以及自己的系统悄悄缺少了哪一种。

这篇文章是一份实地指南：每一种类型究竟是什么、如今在 Agent 中实际上如何实现、各自特有的失败模式，以及——因为无法执行的分类法只是一张海报——用于存储每种记忆的命令。

四种类型从何而来

这种划分比 LLM 早了半个世纪。Endel Tulving 在 1972 年将情景记忆（能够定位到时间的经历）与语义记忆（脱离产生它的经历而存在的知识）区分开来。20 世纪 80 年代的符号认知架构——SOAR、ACT-R——又加入了用于技能的程序性记忆，以及用于当前决策周期的工作记忆。

2023 年，普林斯顿研究人员在 Cognitive Architectures for Language Agents——CoALA——中将这一完整框架迁移到 LLM Agent，领域几乎立刻采纳了它。LangChain 的 LangMem 文档直接引用 CoALA 来划分语义、情景和程序性记忆。Letta、Mem0、IBM 和 MongoDB 都推出了同样四个框的某个版本。

这条谱系值得牢记，因为它同时解释了这套分类法的优势与弱点。优势在于：这些区分经受了五十年的检验，因为它们是真实存在的。弱点在于：它们原本是为描述人类认知而建立的，而 LLM Agent 不是人。有些内容可以完全迁移，有些则迁移得很糟。在仅凭一张架构图就建立四个存储库之前，值得先知道哪些属于哪一种。

四种类型速览

类型	它回答的问题	典型存续时间	如今在 Agent 中实际存在的位置
工作记忆	我现在正在做什么？	一项任务	上下文窗口和循环的暂存区
情景记忆	之前发生了什么？	数天到数月	转录日志、对话存储、追踪后端
语义记忆	什么是真的？	数月到永久	知识库——如果有人真的建了的话
程序性记忆	在这里该如何做这件事？	直到方法改变	模型权重、工具定义、系统提示词、一个 Markdown 文件

读一遍最后一列，问题的轮廓已经显现。四种中有两种是免费得到的，一种是你大概已经拥有的日志，而最有价值的一种恰恰是默认情况下谁都没有的。

1. 工作记忆——你已经拥有的那一种

CoALA 将工作记忆描述为当前决策周期可用的活跃信息。对于 LLM Agent 来说，它几乎就是上下文窗口，加上循环在步骤间保留的任意暂存区。你不用构建它。模型在每一次调用时都会把它交给你。

两个特性定义了它。它是按 token 租用的，每一次调用都要付费。它会在循环结束时消失——这不是缺陷。会持续存在的工作记忆，只会成为卫生状况更差、没有策略的长期记忆。

它的失败模式是整个类别中最常见的错误：团队把工作记忆当作记忆发生的地方，于是“给 Agent 增加记忆”变成了“往提示词里塞更多内容”。你塞入的每个检索片段都要付出两次代价——一次是 token，另一次则是长上下文会对你租来推理能力造成的、可测量的性能退化。长期记忆的目的，是让工作记忆保持小。如果你的记忆系统让提示词变长，它就在与自身目标对着干。

Memanto 有意不将工作记忆建模为一种记忆类型。它建模的是其边界：session 是一个受时间限制的窗口——默认大约六小时，在服务端配置——它授权记忆操作，并标记一段工作从何处开始、何处结束。记忆则有意比它存续得更久。

bashmemanto session info      # the working-memory boundary: when it opened, when it lapses
memanto answer "Before this run: what is the fastest known path here, and what should I avoid?"

第二条命令将整套纪律浓缩在一行中。memanto answer 返回的是从整个记忆资产中综合出的、以事实为基础的简报，而不是把资产本身交出来。Agent 获得的是结论，不是档案库。

2. 情景记忆——发生过什么

Tulving 所说的情景记忆，是锚定于时间和地点的经历记忆。对于 Agent 来说：尝试过什么、说过什么、哪里出了问题，以及何时发生。它是大多数团队最先实现的类型，因为记录转录日志看起来就和情景记忆一模一样，而且一个下午就能完成。

其失败模式是容量。情景材料按设计会持续生成——每一轮、每一次工具调用、每一条追踪记录。它将是你拥有过的容量最大、信号最弱的存储，而对原始情景进行语义搜索，会返回四十个几乎一模一样的“同一个星期二”版本。我们在构建 Langfuse integration 时详细写过这一点：812 条原始观察结果正确地被压缩为 2 条记忆。需要牢记的是这个比例。

“一段情景只有在可区分时才值得存储——例如一次事故、一个决策点、一次具有明确特征的失败。不是因为它仅仅发生过。

在 Memanto 中，情景材料会以 event、observation 或 context 的形式落库。三者都具有情境性和时间边界，并且在每一种已发布的策略预设中都具有最短的保留窗口——因为情景本来就是如此。

bashmemanto remember "Prod incident 2026-08-22: connection pool exhausted at 500 rps, resolved by raising pool size to 50" --type event
memanto remember "Build times spike Friday afternoons, cause unknown" --type observation
memanto remember "Mid-migration from REST to GraphQL, 60% of endpoints converted" --type context

情景记忆的另一半，是能够询问何时。一个只能回答“你知道什么”的存储，无论你给它打什么标签，都不是情景记忆。Memanto 为召回提供三种时间模式：

bashmemanto recall --recent --limit 10                  # what did we learn most recently
memanto recall --changed-since "last week"          # what moved since then
memanto recall --as-of 2026-07-01                   # what we believed on that date

第三条命令是转录日志完全无法回答的查询。日志只有一种时态。

3. 语义记忆——什么是真的

语义记忆是脱离产生它的情景而存在的通用知识。你知道部署流水线要求类型检查通过。你早已忘记是哪一次失败的构建让你学到这一点。这个主张存续下来；那段情景不必如此。

Agent 记忆中几乎所有的持久价值都在这里，而这也是最常被宣称拥有、却最少被真正构建出来的类型。原因在于一种很容易犯、且代价高昂的类别错误：

“装满对话片段的向量存储不是语义记忆。它只是搜索能力更好的情景记忆。

语义记忆的区别性特征是，它不能被记录，只能被蒸馏。情景输入，主张输出，而必须有某种东西执行这种归约。在大多数技术栈中，并没有任何东西会这么做。Letta 为 Agent 提供了将召回中的观察提升为归档记忆的工具，这种形态是对的——但它把决策留给了 Agent，而在实践中，生产部署很少真正作出这一判断。存储库被情景填满，所有人却因为嵌入向量具有语义性而称它为语义记忆。

在 Memanto 中，这构成了 13 semantic types 的主要部分——fact、decision、learning、relationship、artifact、goal、commitment——而蒸馏步骤是一条命令，而非一种愿景：

bash# Episode in, typed claims out. --dry-run shows the candidates before anything is stored.
memanto remember --from-conversation ./session.json --dry-run
memanto remember --from-conversation ./session.json

# Or leave it running: nightly distill, merge duplicates, flag contradictions
memanto schedule enable

语义记忆还有第二个特性，认知分类法没有为它留下位置，但它在实践中极为重要：你是如何开始相信它的。Memanto 存储的每条记忆都携带一个来源值——explicit_statement、inferred、corrected、validated、observed 或 imported——以及一个置信度评分。

用户直接陈述、置信度为 0.95 的事实，与系统从行为中推断、置信度为 0.4 的事实，在存储中具有相同的形态，却绝不应该以相同方式被信任。来源信息让策略得以区分它们——已发布的 balanced 预设会在十四天后过期置信度低于 0.5 的推断型记忆，而让陈述型记忆永久保留。

bashmemanto remember "Acme requires idempotency keys on every payment write" --type fact --confidence 0.95 --provenance explicit_statement
memanto recall "payment constraints" --type fact --min-confidence 0.7

4. 程序性记忆——在这里如何做事

在人类中，程序性记忆就是技能：骑自行车、盲打。你无法把它作为一句陈述检索出来，只能把它作为一种能力执行出来。这是最难干净迁移到 LLM Agent 的类型，因为在 Agent 中，它分散在三个地方，而其中只有一个在任何有用的意义上属于记忆。

• 权重——如何编写 Python、如何组织论证。它们确实是程序性的，也确实不属于你，并且不会从你的经验中更新。
• 工具定义和系统提示词——属于你，在效果上是程序性的，但它们只是由人编辑的文件。其中没有任何内容是习得的。
• 这个特定环境中积累的规则——“提交前运行 pnpm typecheck”、“绝不要在这个仓库中使用 require()，它会让打包器悄无声息地崩掉”。这是唯一来自经验的一种，也是通常无处可存的一种。

第三个要点才是真正的工作。LangMem 的答案——让 Agent 重写自己的系统指令——是该领域最诚实地将程序性知识视为可更新内容的尝试。它也继承了所有无管理存储的问题：一套自我重写的指令集没有过期机制、没有来源信息，也没有人在两次重写相互矛盾时负责。Agent 正在决定自身行为的文件中批改自己的作业。

Memanto 将习得的程序保存在三种类型中：instruction 用于流程，preference 用于风格，error 用于那些已经让某人损失过一天时间的反模式。

bashmemanto remember "Run pnpm lint && pnpm typecheck before every commit; CI rejects if either fails" --type instruction
memanto remember "Prefer explicit return types on all public functions" --type preference
memanto remember "Never use require() — pure ESM project, breaks the bundler with no clear stack trace" --type error

memanto recall "what should I avoid in this repo" --type error

最后一条查询让程序性记忆完成了其存在的唯一职责：在犯错之前抵达，而不是在犯错之后。

用一张表完成映射

认知类型	在 Memanto 中	其区别性特征
工作记忆	session——根本不是一种记忆类型	一个约 6 小时的授权窗口。记忆被设计为比它存续更久；简报使其保持精简。
情景记忆	event、observation、context	在每种预设中保留时间最短。以时间方式查询（--as-of、--changed-since、--recent）。
语义记忆	fact、decision、learning、relationship、artifact、goal、commitment	从情景中蒸馏，绝不直接记录。带有来源和置信度。
程序性记忆	instruction、preference、error	在任何预设中，preference 和 instruction 都不会按计时器过期。error 会过期——见下文。

这种映射在两个方向上都有信息损失，这是有意为之，而非草率造成的。commitment（“在六月审计前完成认证重构”）在形式上是语义性的，却像情景一样会过期。relationship 是一种行为方式类似程序性知识的语义知识——它告诉 Agent 应将事项路由到哪里。Memanto 的 13 种类型并不按记忆来自哪里分类；它们按记忆回答什么问题分类，因为这是检索能够据以行动的信号。来源是绘制架构图的好方法，却是筛选查询的糟糕方法。

让人意外的部分：生命周期并不遵循分类法

以下是 Memanto 已发布 balanced 预设中的保留策略部分，每种类型都标注了其认知类别：

yamlretention:
  context:     7d      # episodic
  event:       30d     # episodic
  error:       30d     # procedural
  observation: 60d     # episodic
  commitment:  90d     # semantic
  artifact:    180d    # semantic
  # fact, decision, goal, learning        (semantic)   -> never
  # preference, instruction, relationship (procedural)  -> never

从上到下阅读注释列，认知类别是被打乱的。error 是程序性知识，却会在三十天后老化；fact 是语义性的，却永不过期。commitment 和 artifact 都是语义性的，但保留期限相差一倍。

在你把它说出来之前，这看上去确实不对。六周前修复的一个 bug 已经不是活跃风险——它是历史，而仍不断绕开它的 Agent 正在被自己的记忆拖慢。风格偏好则永远是活跃风险。决定一条记忆能保持真实多久的维度，不是它来自哪里，而是其所处世界变化的速度——这是主题本身的属性，而非

Ask three teams what "agent memory" means and you will get three different architecture diagrams — but all three will have the same four boxes in them: working, episodic, semantic, procedural. That taxonomy is the closest thing this field has to a shared vocabulary. Most of the people using it could not tell you where it came from, which parts transfer cleanly to an LLM agent, or which of the four their own system is quietly missing.

This post is the field guide. What each type actually is, how it is really implemented in agents today, the failure mode specific to each, and — because a taxonomy you cannot execute is a poster — the command that stores each one.

Where the four types came from

The split is older than LLMs by half a century. Endel Tulving separated episodic memory (experiences you can place in time) from semantic memory (knowledge detached from the experience that produced it) in 1972. The symbolic cognitive architectures of the 1980s — SOAR, ACT-R — added procedural memory for skills and working memory for the current decision cycle.

In 2023, Princeton researchers ported the whole frame to LLM agents in Cognitive Architectures for Language Agents — CoALA — and the field adopted it almost immediately. LangChain’s LangMem documentation cites CoALA directly for its semantic/episodic/procedural split. Letta, Mem0, IBM, and MongoDB all ship a version of the same four boxes.

That lineage is worth keeping in mind, because it explains both the strength and the weakness of the taxonomy. The strength: these distinctions survived fifty years of scrutiny because they are real. The weakness: they were built to describe human cognition, and an LLM agent is not a person. Some of it transfers exactly. Some of it transfers badly. It is worth knowing which is which before you build four stores on the strength of a diagram.

The four types at a glance

Type	Question it answers	Typical lifetime	Where it actually lives in an agent today
Working	What am I doing right now?	One task	The context window and the loop’s scratchpad
Episodic	What happened before?	Days to months	Transcript logs, conversation stores, trace backends
Semantic	What is true?	Months to forever	A knowledge base — if anyone built one
Procedural	How do I do this here?	Until the method changes	Model weights, tool definitions, the system prompt, a markdown file

Read that last column and the shape of the problem is already visible. Two of the four are handed to you for free. One is a log you probably already have. The valuable one is the only one nobody gets by default.

1. Working memory — the one you already have

CoALA describes working memory as the active information available to the current decision cycle. In an LLM agent it is, almost exactly, the context window plus whatever scratchpad the loop keeps between steps. You do not build it. The model hands it to you on every call.

Two properties define it. It is rented by the token , repaid on every single call. And it vanishes when the loop ends — which is not a defect. A working memory that persisted would just be a long-term memory with worse hygiene and no policy.

The failure mode is the most common mistake in the entire category: teams treat working memory as the place where memory happens , so "adding memory to our agent" becomes "put more into the prompt." Every retrieved chunk you stuff in is paid for twice — once in tokens, once in the measurable degradation that long contexts inflict on the reasoning you rented them for. The purpose of long-term memory is to keep working memory small. If your memory system makes prompts longer, it is working against itself.

Memanto deliberately does not model working memory as a memory type. What it models is the boundary around one: a session is a time-bounded window — roughly six hours by default, configured server-side — that authorizes memory operations and marks where one stretch of work begins and ends. Memories outlive it on purpose.

bashmemanto session info      # the working-memory boundary: when it opened, when it lapses
memanto answer "Before this run: what is the fastest known path here, and what should I avoid?"

That second command is the whole discipline in one line. memanto answer returns a grounded briefing synthesized from the estate, not the estate itself. The agent gets the conclusion, not the archive.

2. Episodic memory — what happened

Tulving’s episodic memory is memory of experience, anchored to a time and a place. In an agent: what was attempted, what was said, what broke, and when. It is the type most teams implement first, because logging a transcript looks exactly like episodic memory and takes an afternoon.

The failure mode is volume. Episodic material is generated continuously by design — every turn, every tool call, every trace. It is the highest-volume and lowest-signal store you will ever own, and semantic search across raw episodes returns forty near-identical versions of the same Tuesday. We wrote about this in detail when building the Langfuse integration, where 812 raw observations correctly reduced to 2 memories. The number to internalize is the ratio.

“An episode earns storage when it is distinguishable — an incident, a decision point, a failure with a signature. Not when it merely occurred.

In Memanto, episodic material lands as event, observation, or context. All three are situational and time-bound, and all three carry the shortest retention windows in every shipped policy preset — because that is what episodes are.

bashmemanto remember "Prod incident 2026-08-22: connection pool exhausted at 500 rps, resolved by raising pool size to 50" --type event
memanto remember "Build times spike Friday afternoons, cause unknown" --type observation
memanto remember "Mid-migration from REST to GraphQL, 60% of endpoints converted" --type context

The other half of episodic memory is being able to ask when. A store that can only answer "what do you know" is not episodic, whatever you tag it. Memanto exposes three temporal modes on recall:

bashmemanto recall --recent --limit 10                  # what did we learn most recently
memanto recall --changed-since "last week"          # what moved since then
memanto recall --as-of 2026-07-01                   # what we believed on that date

That third one is the query a transcript log cannot answer at all. A log has one tense.

3. Semantic memory — what is true

Semantic memory is general knowledge, detached from the episode that produced it. You know your deploy pipeline requires a green typecheck. You have long since forgotten which broken build taught you that. The claim survived; the episode did not need to.

This is where nearly all the durable value in agent memory sits, and it is the type most often claimed and least often actually built. The reason is a category error that is easy to make and expensive to keep:

“A vector store full of conversation chunks is not semantic memory. It is episodic memory with better search.

The distinguishing property of semantic memory is that it cannot be logged — only distilled. The episode goes in, a claim comes out, and something has to perform that reduction. In most stacks, nothing does. Letta gives the agent tools to promote observations from recall into archival memory, which is the right shape — but it leaves the decision to the agent, and in practice production deployments rarely make the call at all. The store fills with episodes and everyone calls it semantic memory because the embeddings are semantic.

In Memanto this is the bulk of the 13 semantic types — fact, decision, learning, relationship, artifact, goal, commitment — and the distillation step is a command rather than an aspiration:

bash# Episode in, typed claims out. --dry-run shows the candidates before anything is stored.
memanto remember --from-conversation ./session.json --dry-run
memanto remember --from-conversation ./session.json

# Or leave it running: nightly distill, merge duplicates, flag contradictions
memanto schedule enable

There is a second property of semantic memory that the cognitive taxonomy has no room for and that matters enormously in practice: how you came to believe it. Every memory Memanto stores carries a provenance value — explicit_statement, inferred, corrected, validated, observed, or imported — alongside a confidence score.

A fact a user stated outright at 0.95 confidence and a fact the system inferred from behavior at 0.4 are the same shape in the store and should never be trusted the same way. Provenance is what lets a policy tell them apart — the shipped balanced preset expires inferred memories below 0.5 confidence after fourteen days, and leaves stated ones alone forever.

bashmemanto remember "Acme requires idempotency keys on every payment write" --type fact --confidence 0.95 --provenance explicit_statement
memanto recall "payment constraints" --type fact --min-confidence 0.7

4. Procedural memory — how to do it here

In humans, procedural memory is skill: riding a bike, touch-typing. You cannot retrieve it as a statement, only perform it as an ability. This is the type that transfers to LLM agents least cleanly, because in an agent it is scattered across three places and only one of them is memory in any useful sense.

• The weights — how to write Python, how to structure an argument. Genuinely procedural, genuinely not yours, and it does not update from your experience.
• Tool definitions and the system prompt — yours, and procedural in effect, but they are a file a human edits. Nothing about them is learned.
• The accumulated rules of this specific environment — "run pnpm typecheck before committing," "never use require() in this repo, it breaks the bundler silently." This is the only one that comes from experience, and it is the one that usually has nowhere to live.

The third bullet is the real work. LangMem’s answer — let the agent rewrite its own system instructions — is the most honest attempt in the field at treating procedural knowledge as something that updates. It also inherits every problem of an unmanaged store: a self-rewriting instruction set has no expiry, no provenance, and no owner for the moment two rewrites contradict each other. The agent is grading its own homework, in the file that determines its behavior.

Memanto keeps learned procedure in three types — instruction for procedures, preference for style, and error for the anti-patterns that already cost someone a day.

bashmemanto remember "Run pnpm lint && pnpm typecheck before every commit; CI rejects if either fails" --type instruction
memanto remember "Prefer explicit return types on all public functions" --type preference
memanto remember "Never use require() — pure ESM project, breaks the bundler with no clear stack trace" --type error

memanto recall "what should I avoid in this repo" --type error

That last query is procedural memory doing the one job procedural memory exists to do: arriving before the mistake, not after it.

The mapping, in one table

Cognitive type	In Memanto	What is distinctive about it
Working	The session — not a memory type at all	A ~6h authorized window. Memories outlive it by design; briefing keeps it small.
Episodic	event, observation, context	Shortest retention in every preset. Queried temporally (--as-of, --changed-since, --recent).
Semantic	fact, decision, learning, relationship, artifact, goal, commitment	Distilled from episodes, never logged. Carries provenance and confidence.
Procedural	instruction, preference, error	preference and instruction never expire on a timer in any preset. error does — see below.

The mapping is lossy in both directions, and that is deliberate rather than sloppy. commitment ("ship the auth refactor before the June audit") is semantic in form but expires like an episode. relationship is semantic knowledge that behaves procedurally — it tells an agent where to route things. Memanto’s 13 types do not classify a memory by where it came from ; they classify it by what question it answers , because that is the signal retrieval can act on. Origin is a fine way to draw an architecture diagram and a poor way to filter a query.

The part that surprises people: lifetime does not follow the taxonomy

Here is the retention half of Memanto’s shipped balanced preset, with each type annotated by its cognitive category:

yamlretention:
  context:     7d      # episodic
  event:       30d     # episodic
  error:       30d     # procedural
  observation: 60d     # episodic
  commitment:  90d     # semantic
  artifact:    180d    # semantic
  # fact, decision, goal, learning        (semantic)   -> never
  # preference, instruction, relationship (procedural)  -> never

Read the comment column top to bottom and the cognitive categories are shuffled. error is procedural knowledge and it ages out in thirty days, while fact is semantic and never does. commitment and artifact are both semantic and differ by a factor of two.

That looks wrong until you say it out loud. A bug you fixed six weeks ago is not a live hazard — it is history, and an agent that keeps routing around it is being slowed down by its own memory. A style preference is a live hazard forever. The axis that predicts how long a memory stays true is not where it came from. It is how fast the world underneath it changes — a property of the subject matter, not of the cognitive category.

Which is exactly why retention is a table you own and edit, not something a taxonomy hands you. Three presets ship as starting points, and applying one prints the full policy before it asks you to confirm:

bashmemanto policy list-preset                 # conservative | balanced | aggressive
memanto policy apply-preset balanced
memanto policy apply --dry-run             # every memory the sweep would stamp, before it stamps one

And expiring is not deleting. A memory that ages out keeps its content and gains two fields — expired_at and expired_by — so recall can tell you which rule retired it and when, and memanto memory restore puts it back:

text[ACTIVE]  Deploys go through the release bot
[EXPIRED] Deploys are manual via ssh
          Expired Aug 18, 2026 03:56 PM · policy: retention.context

Nothing expires on its own, either. A memory only moves to expired when a policy sweep runs, a conflict resolution retires it, or you expire it by hand. An agent with no policy set will keep everything forever — which is a decision, just rarely a considered one.

A checklist that works in any framework

None of this is Memanto-specific. You can build every piece of it on LangGraph’s store, on Mem0, on a Postgres table you own. The four types tell you what the boxes are; they do not tell you to do any of the following, which is why so few systems do it:

• Working: measure it. If your agent’s prompt grows with the length of the conversation, you do not have a memory system — you have a leak with a retrieval step attached.
• Episodic: store distinguishable episodes, not turns. If your episodic store grows linearly with traffic, it is a log, and it will drown recall long before it helps it.
• Semantic: name the process that converts episodes into claims. If you cannot name it, you do not have semantic memory yet, however semantic your embeddings are.
• Procedural: give learned rules a home outside the system prompt, and decide who owns the case where two of them disagree. "The agent will figure it out" is not an owner.
• All four: every memory needs a provenance and an expiry answer. "Forever, because nobody wrote a policy" is an answer — it is just the worst one available.

Mem0’s own State of AI Agent Memory 2026 report lists staleness among the open problems of the field. Three years into a shared vocabulary that every major framework cites, the question "is this still true?" is still open — largely because the vocabulary never had a word for it. Four nouns, no verbs.

Find the empty box in your own agent

The fastest way to see which of the four kinds your agent actually has is to look at what it has stored, grouped by type:

bashpip install memanto
memanto agent create my-agent
memanto agent bootstrap          # an intelligence snapshot: total memories, sampled and grouped by type

In our experience the empty box is almost always the semantic one. Plenty of episodes, because logging is easy. Plenty of procedure, because it lives in a system prompt someone wrote. And nothing in between that turned the first into durable, retrievable claims — which is the transition the whole taxonomy is quietly built around and the only one it never tells you to implement.

“Four types is a good map. It tells you what to store. It never tells you what to stop believing — and at month six, that is the question deciding whether your agent’s memory is an asset or a liability.

▘ ▝End of article