The following article originally appeared on Angie Jones’s LinkedIn page and is being republished here with the author’s permission.以下文章最初发表于 Angie Jones 的 LinkedIn 页面，经作者许可在此转载。
I’m fascinated by the concept of agent memory. LLMs are stateless by design, meaning they have no memory or awareness of past interactions. Each prompt you send to an LLM is treated as a completely isolated event.我对智能体记忆（agent memory）的概念非常着迷。大语言模型（LLM）在设计上是无状态的，这意味着它们没有记忆，也无法感知过去的交互。你发送给 LLM 的每一个提示词都被视为一个完全独立的事件。
When you have a continuous chat with an AI agent, it feels like the AI remembers previous messages. However, the interface itself is faking it. Behind the scenes, your agent takes the entire conversation history and resends all of it to the LLM as one giant, combined prompt.当你与 AI 智能体进行持续对话时，感觉就像 AI 记住了之前的消息。然而，这只是界面营造的假象。在后台，你的智能体获取了整个对话历史，并将所有内容作为一个巨大的组合提示词重新发送给 LLM。
Companies, researchers, and even indie devs are all trying to crack agent memory. Because once an agent can remember, the entire interaction changes. It can build on what it learned, adapt to the user, resume work after a restart, and develop a sense of continuity.企业、研究人员甚至独立开发者都在试图攻克智能体记忆这一难题。因为一旦智能体能够拥有记忆，整个交互方式就会发生改变。它可以基于已学到的知识进行构建、适应用户、在重启后恢复工作，并产生一种连续感。
Recently, I spent time with Richmond Alake, who has been in the trenches working on agent memory at Oracle.最近，我与一直在 Oracle 深入研究智能体记忆的 Richmond Alake 进行了一次交流。
We talked about the different kinds of memory, why memory is harder than it sounds, and what it takes to build a memory system that is actually useful in production.我们讨论了不同类型的记忆、为什么记忆比听起来更难，以及构建一个在生产环境中真正有用的记忆系统需要什么。
That conversation made something very clear to me. When people say, “agent memory,” they often mean very different things.那次谈话让我清楚地认识到一点：当人们谈论“智能体记忆”时，他们往往指的是完全不同的东西。
So let’s unpack the various types of memory.那么，让我们来拆解一下各种类型的记忆。
Conversational memory对话记忆
Conversational memory is the one most people think of first. It stores the messages exchanged between the user and the assistant.对话记忆是大多数人首先想到的。它存储用户与助手之间交换的消息。
This makes sense. If I ask, “What did I say was the ultimate goal of this task?” the agent needs access to the conversation in order to answer. Without that history, every turn starts from zero.这很有道理。如果我问：“我刚才说这个任务的最终目标是什么？”智能体需要访问对话记录才能回答。如果没有这段历史，每一次对话都将从零开始。
But this is also where many memory systems go wrong.但这恰恰也是许多记忆系统出错的地方。
The most common first attempt is to keep appending prior messages to the prompt. For example:最常见的初次尝试是不断将之前的消息附加到提示词中。例如：
User: I’m building a customer support agent.用户：我正在构建一个客户支持智能体。
Assistant: Great, what should it do?助手：太棒了，它应该做什么？
User: It should look up past tickets and draft replies.用户：它应该查找过去的工单并起草回复。
Assistant: Got it.助手：明白了。
User: Also, I prefer Python and FastAPI.用户：另外，我更喜欢 Python 和 FastAPI。
Then on the next call, we send all of that back to the model along with the new question.然后在下一次调用时，我们将所有这些内容连同新问题一起发回给模型。
This works for a short conversation, but the agent only “remembers” because we keep reminding it. This is not really memory engineering.这在短对话中有效，但智能体之所以能“记住”，仅仅是因为我们不断提醒它。这并不是真正的记忆工程。
Eventually, the conversation gets too long and the model receives a giant blob of context where some details are important, some are stale, and some are completely irrelevant. The agent may technically have the information, but that doesn’t mean it can use it well.最终，对话变得太长，模型接收到一大块上下文，其中一些细节很重要，一些已经过时，还有一些完全无关。智能体在技术上可能拥有这些信息，但这并不意味着它能很好地利用它们。
So yes, conversation history is a valid and important type of memory. But it shouldn’t be the whole memory strategy. Real agent memory requires deciding what should be stored, where it should be stored, how it should be retrieved, and when it should be summarized, forgotten, or compressed.所以，对话历史确实是一种有效且重要的记忆类型。但它不应是全部的记忆策略。真正的智能体记忆需要决定存储什么、存储在哪里、如何检索，以及何时进行总结、遗忘或压缩。
Semantic memory语义记忆
Semantic memory stores durable facts.语义记忆存储持久的事实。
These are things that should outlive the exact conversation where they were learned:这些事实的生命周期应该长于它们被学习时的那次具体对话：
- The user prefers Python over TypeScript for backend work.用户在后端开发中更喜欢 Python 而非 TypeScript。
- The customer support agent needs access to past tickets.客户支持智能体需要访问过去的工单。
- The production system handles 50,000 queries per day.生产系统每天处理 50,000 次查询。
This is different from conversational memory because the exact wording and sequence are less important. What matters is the meaning.这与对话记忆不同，因为确切的措辞和顺序并不重要。重要的是含义。
If the agent needs to recall what stack the user is using, it should retrieve the memory even if the user never says those exact words again.如果智能体需要回忆用户正在使用什么技术栈，即使用户不再说出完全相同的词，它也应该能够检索到该记忆。
Vector search is useful for this. The memory can be embedded and retrieved by semantic similarity.向量搜索对此非常有用。记忆可以被嵌入，并通过语义相似度进行检索。
The benefit is that the agent doesn’t need to replay the full conversation. It can retrieve the few durable facts that are relevant to the current request.其好处在于智能体不需要重放整个对话。它可以检索与当前请求相关的少数持久事实。
Episodic memory情景记忆
Episodic memory stores events.情景记忆存储事件。
This is the “what happened” layer of memory:这是记忆的“发生了什么”层：
- The agent searched the web for recent API gateway patterns.智能体搜索了网络以获取最新的 API 网关模式。
- The agent generated a draft response for ticket #4821.智能体为 #4821 号工单生成了回复草稿。
- The workflow failed at the compliance review step.工作流在合规审查步骤失败。
Episodic memory is especially useful for debugging, auditing, and long-running workflows.情景记忆对于调试、审计和长期运行的工作流特别有用。
For example, if an agent makes a decision, I may want to know what happened right before that decision (e.g., What tools did it call? What data did it retrieve?).例如，如果智能体做出了一个决定，我可能想知道在该决定之前发生了什么（例如：它调用了哪些工具？它检索了什么数据？）。
This type of memory often benefits from structured storage.这种类型的记忆通常受益于结构化存储。
For example:例如：
Find all failed tool calls from the mortgage approval workflow in the last 24 hours.查找过去 24 小时内抵押贷款审批工作流中所有失败的工具调用。
That is a database query problem, not just a vector search problem.这是一个数据库查询问题，而不仅仅是向量搜索问题。
Procedural memory程序性记忆
Procedural memory is about how to do things.程序性记忆是关于如何做事。
For example:
- When investigating a failed deployment, check logs first, then recent config changes, then dependency updates.在调查失败的部署时，先检查日志，然后检查最近的配置更改，最后检查依赖项更新。
- When drafting a customer support reply, include the ticket summary, likely cause, recommended fix, and next step.在起草客户支持回复时，包含工单摘要、可能的原因、建议的修复方法和下一步操作。
- When creating a database-aware agent, scan table comments, column comments, constraints, and recent workload patterns.在创建数据库感知型智能体时，扫描表注释、列注释、约束和最近的工作负载模式。
This is the kind of memory that helps an agent improve its process. That’s powerful because agents are often asked to operate in messy real-world environments. With procedural memory, it can reuse proven approaches.这种记忆可以帮助智能体改进其流程。这非常强大，因为智能体经常需要在混乱的现实环境中运行。有了程序性记忆，它可以重用经过验证的方法。
The value extends beyond just knowing things to actually knowing how to proceed.其价值不仅在于了解事物，还在于真正知道如何进行下一步。
Entity memory实体记忆
Entity memory stores facts about specific people, accounts, projects, systems, tickets, or objects.实体记忆存储关于特定人员、账户、项目、系统、工单或对象的各种事实。
For example:
- Angie prefers practical examples over abstract explanations.Angie 喜欢实际案例胜过抽象解释。
- Customer Acme Corp has strict data residency requirements.客户 Acme Corp 有严格的数据驻留要求。
- Ticket #4821 is related to a billing reconciliation issue.#4821 号工单与账单对账问题有关。
Entity memory matters because many agent tasks are scoped around a particular thing.实体记忆之所以重要，是因为许多智能体任务都是围绕特定事物展开的。
If I ask, “What do we know about Acme Corp?” I don’t want every memory in the system. I want memories attached to that customer.如果我问：“我们对 Acme Corp 有什么了解？”我不希望得到系统中所有的记忆。我只想要与该客户相关的记忆。
This is also where memory safety becomes important.这也是记忆安全性变得重要的地方。
Agents should not accidentally mix memories between users, customers, or projects. A memory system needs strong scoping so one user’s context does not leak into another user’s response.智能体不应意外地混合不同用户、客户或项目之间的记忆。记忆系统需要强大的作用域划分，以确保一个用户的上下文不会泄露到另一个用户的响应中。
Working memory工作记忆
Working memory is the short-term scratchpad for the current task.工作记忆是当前任务的短期草稿板。
This is where the agent keeps temporary information while reasoning through a problem.这是智能体在推理问题时保存临时信息的地方。
Working memory is usually not meant to last forever. It’s useful during the task, but it may not deserve to become durable memory.工作记忆通常不是为了永久保存。它在任务期间很有用，但可能不值得成为持久记忆。
If an agent stores every temporary thought as long-term memory, the memory store gets noisy very quickly. The agent may later retrieve half-baked assumptions as if they were facts, which is dangerous.如果智能体将每一个临时想法都存储为长期记忆，记忆库会很快变得混乱。智能体以后可能会将半生不熟的假设当作事实检索出来，这是很危险的。
Not everything the agent observes or thinks should be remembered permanently.并非智能体观察或思考的一切都应该被永久记住。
Summary memory总结记忆
Summary memory is one many agent users are familiar with. It deals with the problem of context windows being limited.总结记忆是许多智能体用户所熟悉的。它解决了上下文窗口有限的问题。
Even with large context models, you can’t keep appending forever. At some point, you need to compress.即使使用大上下文模型，你也不能永远附加内容。在某个时刻，你需要进行压缩。
Summary memory stores a compact version of a longer thread or context window. The original details can still live in the thread, but the prompt gets a smaller representation.总结记忆存储较长线程或上下文窗口的紧凑版本。原始细节仍然可以存在于线程中，但提示词会获得一个更小的表示。
For example, instead of sending 80 turns of conversation, the agent might send:例如，智能体可能不会发送 80 轮对话，而是发送：
The user is building a SaaS customer support agent. They prefer Python and FastAPI, deploy on OCI, and want the agent to retrieve past tickets before drafting replies. They are currently evaluating memory strategies for production usage.用户正在构建一个 SaaS 客户支持智能体。他们更喜欢 Python 和 FastAPI，部署在 OCI 上，并希望智能体在起草回复前检索过去的工单。他们目前正在评估用于生产环境的记忆策略。
Why memory is hard for agents为什么智能体记忆很难
At first, memory sounds straightforward: store things, retrieve them later.起初，记忆听起来很简单：存储东西，以后检索它们。
But the hard part is judgment, not storage.但难点在于判断，而不是存储。
What should be remembered? If the user says, “I usually prefer Python,” that’s probably worth remembering. If they say, “Let’s try Python for this one experiment,” maybe not. The agent needs to distinguish durable details from temporary context.应该记住什么？如果用户说“我通常更喜欢 Python”，这可能值得记住。如果他们说“让我们在这个实验中试试 Python”，那可能就不必了。智能体需要区分持久细节和临时上下文。
When should memory be updated? People change their minds, and systems and requirements change. If a user used to prefer FastAPI but now works mostly in Java, should the old memory be deleted, overwritten, or kept with a timestamp? A memory system needs a correction strategy.什么时候应该更新记忆？人们会改变主意，系统和需求也会变化。如果用户过去更喜欢 FastAPI，但现在主要使用 Java，那么旧的记忆应该被删除、覆盖，还是保留并加上时间戳？记忆系统需要一种纠正策略。
How much memory should be retrieved? Retrieving too little means the agent misses important context. Retrieving too much means the prompt becomes noisy. This balance matters as more context isn’t always better.应该检索多少记忆？检索太少意味着智能体错过了重要的上下文。检索太多意味着提示词变得混乱。这种平衡很重要，因为更多的上下文并不总是更好。
How do we prevent memory leaks? If memories are shared across users, agents, or tenants, scoping is critical. The agent should only retrieve memories it’s allowed to use. This is especially important in enterprise systems where agents may operate across many customers, teams, or workflows.我们如何防止内存泄漏？如果记忆在用户、智能体或租户之间共享，作用域划分至关重要。智能体只能检索它被允许使用的记忆。这在企业系统中尤为重要，因为智能体可能跨越许多客户、团队或工作流运行。
How do we know whether memory helped? Memory should improve the agent’s behavior. It should reduce repeated questions, improve continuity, lower token usage, and help the agent produce more relevant responses. If memory just adds complexity without improving outcomes, it isn’t doing its job.我们如何知道记忆是否有帮助？记忆应该改善智能体的行为。它应该减少重复提问、提高连续性、降低 Token 使用量，并帮助智能体产生更相关的响应。如果记忆只是增加了复杂性而没有改善结果，那它就没有完成任务。
How Oracle is approaching agent memoryOracle 如何处理智能体记忆
Richmond was gracious enough to share how Oracle is tackling this with the Oracle AI Agent Memory Package (OAMP), built on top of Oracle AI Database 26ai.Richmond 非常慷慨地分享了 Oracle 如何通过 Oracle AI Agent Memory Package (OAMP) 来解决这个问题，该包构建在 Oracle AI Database 26ai 之上。
Yes, an AI database! Think of it as a database that can store and query the kinds of data AI applications need, not just rows and columns. That includes embeddings and JSON documents along with text search and regular SQL. These live together in the database, so an agent does not have to bounce between separate systems just to gather context.是的，一个 AI 数据库！可以把它想象成一个不仅能存储行和列，还能存储和查询 AI 应用所需数据的数据库。这包括嵌入（embeddings）和 JSON 文档，以及文本搜索和常规 SQL。它们共存于数据库中，因此智能体无需在不同的系统之间切换即可收集上下文。
The idea is to make Oracle AI Database the memory core for agents. Instead of stitching together a vector database, a relational database, a document store, and custom thread management, OAMP provides agent-friendly memory primitives on top of a database that already supports multiple data access patterns.其理念是将 Oracle AI Database 作为智能体的记忆核心。OAMP 不再需要拼凑向量数据库、关系数据库、文档存储和自定义线程管理，而是在一个已经支持多种数据访问模式的数据库之上，提供了对智能体友好的记忆原语。
At a high level, OAMP gives you:从高层来看，OAMP 为你提供了：
- Users and agents to scope memory ownership用户和智能体，用于划分记忆所有权
- Memories for durable facts and extracted knowledge用于持久事实和提取知识的记忆
- Threads for conversation history and continuity用于对话历史和连续性的线程
- Context cards for compact, prompt-ready memory retrieval用于紧凑、即用型提示词记忆检索的上下文卡片
- Summaries for long-running conversations用于长期运行对话的总结
- Vector search for semantic recall用于语义回溯的向量搜索
- Database-backed persistence so memory survives restarts数据库支持的持久化，确保记忆在重启后依然存在
This matters because, again, agent memory is not only a vector search problem. Some memory needs semantic retrieval. Some need ordered reads or exact SQL filtering. A database-backed memory system gives you room to support all of those patterns.这一点很重要，因为再次强调，智能体记忆不仅仅是一个向量搜索问题。有些记忆需要语义检索。有些需要有序读取或精确的 SQL 过滤。数据库支持的记忆系统为你提供了支持所有这些模式的空间。
Here’s a small example of what that looks like in code:以下是代码中实现这一功能的一个小例子：
from oracleagentmemory.core import OracleAgentMemory
from oracleagentmemory.core.llms import Llm
client = OracleAgentMemory(
connection=connection,
embedder="text-embedding-3-small",
llm=Llm("gpt-5.5"),
extract_memories=True,
schema_policy="create_if_necessary",
)
client.add_user(
"angie",
"Developer exploring agent memory patterns."
)
client.add_agent(
"memory-demo-agent",
"Assistant that demonstrates Oracle AI Agent Memory."
)
client.add_memory(
"Angie is fascinated by agent memory and prefers practical examples over abstract explanations.",
user_id="angie",
agent_id="memory-demo-agent",
)
There are a few important ideas packed into this snippet.这段代码片段中包含了一些重要的思想。
The OracleAgentMemory client is the bridge between the agent application and Oracle AI Database. The database connection tells OAMP where memory lives. The embedder tells it how to turn memory text into vectors for semantic retrieval. The LLM enables automatic memory extraction and summary generation. And schema_policy="create_if_necessary" lets OAMP manage the underlying memory schema instead of making every application reinvent it.OracleAgentMemory 客户端是智能体应用程序与 Oracle AI Database 之间的桥梁。数据库连接告诉 OAMP 记忆存储在哪里。嵌入器（embedder）告诉它如何将记忆文本转换为向量以进行语义检索。LLM 实现了自动记忆提取和总结生成。而 schema_policy="create_if_necessary" 让 OAMP 可以管理底层的记忆模式，而不必让每个应用程序都重新发明它。
The user and agent registration may look like simple setup code, but it’s actually part of the memory model. Memories need ownership. In a real system, you don’t want one user’s preferences showing up in another user’s session, and you don’t want memories written by one agent casually mixed with another agent’s context. The user ID and agent ID give the memory layer a way to scope what gets stored and retrieved.用户和智能体注册看起来像是简单的设置代码，但它实际上是记忆模型的一部分。记忆需要所有权。在真实的系统中，你不希望一个用户的偏好出现在另一个用户的会话中，也不希望一个智能体写入的记忆随意与另一个智能体的上下文混合。用户 ID 和智能体 ID 为记忆层提供了一种划分存储和检索内容的方法。
The add_memory() call stores a durable fact. This is a piece of information the agent may need later, even if the exact conversation has moved on.add_memory() 调用存储了一个持久事实。这是一条智能体以后可能需要的信息，即使确切的对话已经过去。
Given this, we can now recall memories.鉴于此，我们现在可以回溯记忆。
results = client.search(
"how should I explain this topic to Angie?",
user_id="angie",
max_results=3,
)
This search() call shows the part that makes semantic memory useful. The query doesn’t have to match the stored sentence exactly. We stored that I prefer practical examples, but we searched for how to explain something to me. Those are different words but related in meaning. That’s the point.这个 search() 调用展示了使语义记忆变得有用的部分。查询不必与存储的句子完全匹配。我们存储了我更喜欢实际案例，但我们搜索的是如何向我解释某事。这些词不同，但含义相关。这就是重点。
Threads and context cards线程和上下文卡片
Durable memories are only part of the picture. Agents also need conversation continuity.持久记忆只是图景的一部分。智能体还需要对话的连续性。
With OAMP, a thread can represent a real work session, such as an agent helping investigate a production issue:使用 OAMP，一个线程可以代表一个真实的工作会话，例如智能体协助调查生产问题：
from oracleagentmemory.apis.thread import Message
thread = client.create_thread(
user_id="angie",
agent_id="support-triage-agent",
)
thread.add_messages([
Message(
role="user",
content="Customer Acme Corp is seeing intermittent checkout failures after the latest deployment.",
),
Message(
role="assistant",
content="I'll check recent deployment notes, related incidents, and payment service logs.",
),
Message(
role="user",
content="Focus on the payment gateway first. We saw similar timeout errors last quarter.",
),
])
This is much closer to how memory shows up in real agent applications. The useful context is not just that messages were exchanged. It’s that this thread is about Acme Corp, checkout failures, a recent deployment, the payment gateway, and a related incident from last quarter.这更接近于记忆在真实智能体应用中的表现方式。有用的上下文不仅仅是交换了消息。而是这个线程是关于 Acme Corp、结账失败、最近的部署、支付网关以及上个季度的相关事件。
When it’s time to call the model, instead of passing the entire raw thread, you can ask for a context card:当需要调用模型时，与其传递整个原始线程，不如请求一张上下文卡片：
card = thread.get_context_card()The context card gives the agent a compact block of relevant memory to use in the next prompt.上下文卡片为智能体提供了一个紧凑的相关记忆块，用于下一个提示词。
Conceptually, the prompt becomes:从概念上讲，提示词变成了：
System: You are a helpful assistant. Use the provided memory context.系统：你是一个乐于助人的助手。使用提供的记忆上下文。
Memory context: [context card]记忆上下文：[上下文卡片]
User: What did we decide earlier?用户：我们之前决定了什么？
This is a much cleaner pattern than appending every message forever.这比永远附加每一条消息要简洁得多。
Automatic memory extraction自动记忆提取
OAMP can also extract memories from conversation.OAMP 还可以从对话中提取记忆。
For example, if the user says:例如，如果用户说：
I prefer Python over TypeScript for backend work. I usually deploy FastAPI apps on OCI behind an API gateway.在后端开发中，我更喜欢 Python 而非 TypeScript。我通常将 FastAPI 应用部署在 OCI 上，并放在 API 网关后面。
The memory system can extract durable facts such as:记忆系统可以提取持久事实，例如：
The user prefers Python over TypeScript for backend work.
The user deploys FastAPI applications on Oracle Cloud Infrastructure behind an API gateway.用户将 FastAPI 应用程序部署在 Oracle Cloud Infrastructure 上，并位于 API 网关之后。
That means the application does not have to manually call add_memory() for every useful fact.这意味着应用程序不必为每一个有用的事实手动调用 add_memory()。
A smart thread can be configured like this:智能线程可以这样配置：
thread = client.create_thread(
user_id="angie",
agent_id="memory-demo-agent",
memory_extraction_frequency=2,
memory_extraction_window=4,
enable_context_summary=True,
context_summary_update_frequency=2,
)This tells the system to periodically inspect recent messages, extract durable memories, and maintain a running summary.这告诉系统定期检查最近的消息，提取持久记忆，并维护一个运行中的摘要。
Here is where agent memory starts to feel more like a living part of the agent architecture vs just a data structure.在这里，智能体记忆开始感觉更像是智能体架构中一个鲜活的部分，而不仅仅是一个数据结构。
Teaching an agent about a database教智能体了解数据库
One of the most interesting examples Richmond and I discussed was using memory to teach an agent about a database.Richmond 和我讨论的最有趣的例子之一是使用记忆来教智能体了解数据库。
Imagine an enterprise data agent that needs to answer questions about a schema it has never seen before. Instead of fine-tuning a model, the agent can scan the database catalog and store what it learns as memory.想象一个企业数据智能体，它需要回答关于它从未见过的模式的问题。智能体无需微调模型，而是可以扫描数据库目录并将所学内容存储为记忆。
It might inspect:它可能会检查：
- ALL_TABLES for table names and row countsALL_TABLES 以获取表名和行数
- ALL_TAB_COLUMNS for column names and typesALL_TAB_COLUMNS 以获取列名和类型
- ALL_TAB_COMMENTS for human-written table descriptionsALL_TAB_COMMENTS 以获取人工编写的表描述
- ALL_COL_COMMENTS for column descriptionsALL_COL_COMMENTS 以获取列描述
- ALL_CONSTRAINTS for primary keys and foreign keysALL_CONSTRAINTS 以获取主键和外键
- V$SQL for recent workload patternsV$SQL 以获取最近的工作负载模式
Then it can convert those technical details into natural-language memories.然后它可以将这些技术细节转换为自然语言记忆。
For example:
Table SUPPLYCHAIN.VESSELS stores individual ships owned or operated by carriers. It includes vessel identifiers, carrier relationships, and operational metadata.表 SUPPLYCHAIN.VESSELS 存储由承运人拥有或运营的单个船舶。它包括船舶标识符、承运人关系和操作元数据。
Now when a user asks:现在当用户问：
Where would I find information about ships and carriers?我在哪里可以找到关于船舶和承运人的信息？
The agent can retrieve the relevant schema memory by meaning.智能体可以按含义检索相关的模式记忆。
This is a beautiful pattern because it avoids one of the common traps with agents expecting the model to already know your private system.这是一个很棒的模式，因为它避免了智能体期望模型已经了解你的私有系统的常见陷阱。
It doesn’t. And that’s okay.它并不了解。这没关系。
You can teach it by turning your system’s metadata into memory.你可以通过将系统的元数据转化为记忆来教它。
The more I learn about agent memory, the more I believe this will be one of the defining pieces of agent architecture.我对智能体记忆了解得越多，就越相信这将是智能体架构的决定性部分之一。
Tool calling lets agents act. Planning lets agents decide what to do. Memory lets agents build continuity.工具调用让智能体采取行动。规划让智能体决定做什么。记忆让智能体建立连续性。
With memory, we can start designing agents that feel less like one-off prompt responders and more like persistent collaborators.有了记忆，我们就可以开始设计那些感觉不像一次性提示词响应者，而更像持久协作者的智能体。
Of course, this also raises the bar. Memory has to be scoped, auditable, correctable, and intentionally retrieved. Bad memory is worse than no memory. So the challenge is not simply giving agents memory but giving them the right memory architecture.当然，这也提高了门槛。记忆必须是受控的、可审计的、可纠正的，并且是有意检索的。糟糕的记忆比没有记忆更糟糕。因此，挑战不在于简单地给智能体记忆，而在于给它们正确的记忆架构。
Oracle’s OAMP approach is one way to make that system concrete: users, agents, memories, threads, context cards, summaries, and database-backed retrieval.Oracle 的 OAMP 方法是将该系统具体化的一种方式：用户、智能体、记忆、线程、上下文卡片、总结和数据库支持的检索。
And while the implementation details matter, the bigger idea is that if we want agents to be useful beyond a single prompt, they need a way to remember.虽然实现细节很重要，但更大的理念是，如果我们希望智能体在单个提示词之外发挥作用，它们就需要一种记忆方式。
Not everything. But enough to carry context forward.不是全部记住。但要记住足够多的内容以延续上下文。
