# Context vs. Memory Engineering in Agentic AI Systems
**作者**: beamnxw ./
**日期**: 2026-08-04T14:28:23.000Z
**来源**: [https://x.com/beamnxw/status/2084647643314102600](https://x.com/beamnxw/status/2084647643314102600)
---
In this article, you will learn how context engineering and memory engineering solve different problems in agentic AI systems, and how the two disciplines meet at the point where retrieved memory enters the context window
# Introduction
As AI agents move into longer workflows and multi-session use cases, a familiar pattern emerges. Constraints get dropped mid-task, retrieved information resurfaces when it shouldn’t, and context from an earlier step bleeds into the current one. The failures are hard to pinpoint because no single component is obviously at fault
Most of the time, the problem lies in two areas that get built together, conflated, or skipped: context engineering and memory engineering. They are related but distinct, fail in different ways, and require different systems to get right
This article covers the core decisions behind each discipline and where they interact:
- What context engineering involves and the specific decisions that determine whether an agent reasons well within a single call
- What memory engineering involves and how write policy, storage, retrieval, and maintenance each affect long-term reliability
- How the two disciplines share a boundary at retrieval time and what it takes to manage that boundary well
Understanding both, separately and together, is what determines whether an agent holds up across real workloads
# An Overview of Context and Memory Engineering
Context engineering covers the design of a single inference call: what to include, what to compress, where to place things, and what to discard. Everything in scope is ephemeral. When the call ends, the window clears
Memory engineering focuses on what survives beyond a single interaction with a model. It encompasses the systems and policies responsible for writing, storing, retrieving, updating, and governing information so that future interactions can make use of it. When an agent recalls information from a previous session, coordinates with another agent, or applies a user preference learned days or weeks earlier, it is relying on memory engineering
While context engineering determines what information is available to the model during a specific request, memory engineering determines what information persists across requests and how that information is maintained, retrieved, and trusted over time. Here’s an overview:
# Context Engineering: Assembling the Optimal Context Window
For an agent running a multi-step workflow, every inference call assembles a context window from multiple sources: system prompt, task description, conversation history, tool outputs, retrieved documents, subagent summaries. Context engineering is the set of decisions that determine what each component contributes, in what form, and in what position
## Selective Inclusion
Not everything available should enter the context. A database query returning hundreds of rows, a web search returning five complete articles, a code executor logging verbose output ➜ all of these bloat the window and reduce reasoning quality before the token limit is reached. The decision about what gets included verbatim, what gets compressed to key facts, and what gets dropped is a design choice, not a default
## Structural Placement
Where information sits in the window affects how reliably the model uses it. Models attend more strongly to content at the beginning and end of long contexts, with material in the middle receiving significantly less weight. This is known as the "lost in the middle" effect
Hard constraints and task-critical instructions belong at the top of the window. Retrieved information that is most relevant to the current task should be placed near the end of the context window
The current user query or task should typically follow the retrieved information, positioning both the relevant context and the immediate objective as close as possible to the generation point. This arrangement increases the likelihood that the model will effectively use the retrieved information when producing its response
Context Engineering Overview
## Compression on Arrival
Tool outputs should be compressed after a call returns, not after the window fills. A raw API response carrying 3,000 tokens, of which the agent needs only 150, should be summarized before it enters context for the next step. Waiting until the window is full and then scrambling to truncate is reactive management of a problem that compression at the source prevents
## Conversation History Management
Conversation history grows faster than any other context component. For long-running agents, carrying the full history into every call makes every subsequent inference more expensive and less reliable. A compression strategy ➜ rolling window, hierarchical summarization, or structured state extraction ➜ should be applied at defined intervals, not when the window overflows
# Memory Engineering: Designing Persistent AI Memory Systems
Once an inference call completes, memory engineering determines what deserves to persist and under what conditions it gets used again. This covers four distinct concerns: what to write, where to store it, how to retrieve it, and how to keep it accurate over time
## Write Policy Design
Write policy design is one of the most overlooked aspects of memory engineering, yet it has a disproportionate impact on memory quality over time. While retrieval systems often receive the most attention, retrieval quality is ultimately constrained by what enters the memory store in the first place
A well-defined write policy specifies:
1. What events trigger a write to memory
2. Which information is eligible for storage
3. The format in which information is stored, such as raw text, structured records, extracted facts, or summaries
4. The confidence or validation requirements for accepting new entries
5. Which agents, tools, or system components are permitted to write to specific memory namespaces
6. How updates, corrections, and conflicting information are handled
7. Retention rules, expiration policies, and time-to-live (TTL) requirements for different memory types
> Without explicit write policies, systems often default to storing too much information, assigning equal trust to all entries, and retaining data indefinitely. Over time, low-value and outdated memories accumulate, signal-to-noise ratios decline, and retrieval quality degrades. The result is a memory system that grows continuously while becoming progressively less useful
## Storage Layer Selection
Different memory types serve different purposes and require different storage backends. The choice of backend also constrains which retrieval strategies are available
OpenAI’s context personalization cookbook makes a useful distinction between retrieval-based memory and state-based memory for use cases requiring continuity. Retrieval-based memory treats past interactions as loosely related documents and is brittle to phrasing variation and conflicting updates. Structured state extraction ➜ writing typed, validated facts rather than embedding raw conversation ➜ produces more consistent results for facts that need to be applied reliably across sessions
Memory Engineering Overview
## Retrieval Strategy
> Reading from memory is not a single operation
A well-designed retrieval layer checks working memory first (fast, cheap, exact key lookup) ➜ falls back to semantic search in episodic or semantic memory when nothing relevant surfaces ➜ applies metadata filters for recency and trust level before returning results ➜ and injects only what the current step needs
## Memory Maintenance
A store with no maintenance policy degrades over time. The entries accumulate, stale facts compete with current ones, and retrieval quality falls as signal-to-noise ratio drops. The following maintenance routines matter in practice: confidence decay on volatile facts, deduplication of semantically similar entries, TTL-based expiry on working memory and time-sensitive data, and periodic compression of old episodic records into session-level summaries
> A MemoryEntry schema that encodes these concerns directly makes write and maintenance logic easier to reason about:
```
class MemoryEntry(BaseModel):
content: str
memory_type: str # working | episodic | semantic | procedural
importance: float # 0.0–1.0, gates long-term storage
confidence: float # decays over time for volatile facts
trust_level: float # 1.0 internal system, 0.5 user input, 0.0 external
created_at: datetime
expires_at: datetime | None
provenance: dict # agent_id, tool_name, session_id, input_hash
def should_write_to_long_term(entry: MemoryEntry) -> bool:
return (
entry.importance >= 0.6
and entry.confidence >= 0.7
and entry.trust_level >= 0.5
)
```
# The Retrieval Boundary: Connecting Memory and Context Engineering
Memory engineering and context engineering are often discussed as separate disciplines, but in practice they are deeply interconnected. Both exist to solve the same core problem: ensuring that a model has access to the right information at the right time
At a high level:
- Memory engineering focuses on persistence: what information should be stored, updated, retained, or forgotten over time
- Context engineering focuses on utilization: what information should enter the active context window for a specific task and how it should be organized
- Retrieval is the boundary where these two disciplines meet
Memory systems produce candidate information. Context assembly then decides:
- Whether that information should enter the prompt
- How much of it should be included
- Where it should be placed within the context window
Managing this boundary well is what transforms a collection of memory components into a coherent agent system
# Failure Mode #1: Retrieval Without a Context Budget
One of the most common failures occurs when retrieval is treated independently from context assembly
A memory search returns a set of relevant entries, and the context assembler injects all of them into the prompt. As more memories are added, the context window gradually fills with retrieved content, leaving less room for instructions, tool outputs, reasoning traces, and task-specific information
The resulting symptoms are often misleading:
- Retrieval quality appears high
- Relevant memories are successfully found
- System performance still degrades
In many cases, the memory system has done its job correctly. The failure occurs because context assembly lacks a budgeting mechanism
A better approach is retrieval-aware context assembly. Instead of retrieving first and budgeting later, the context layer allocates a token budget before retrieval begins. The retrieval layer then returns only the highest-value memories that fit within that budget
```
async def retrieve_for_step(
self,
step: AgentStep,
max_tokens: int
) -> str:
candidates = await self.memory.search(
query=step.retrieval_query,
max_results=10,
filters={
"trust_level": {"gte": 0.5},
"expires_at": {"gt": datetime.now()}
}
)
selected = []
used = 0
for entry in sorted(
candidates,
key=lambda e: e.relevance_score,
reverse=True
):
cost = self.token_count(entry.content)
if used + cost > max_tokens:
break
selected.append(entry.content)
used += cost
return "\n\n".join(selected)
```
> Retrieval must operate within context constraints, not assume unlimited space downstream
# Failure Mode #2: Poor Placement of Retrieved Information
Retrieval quality alone is not sufficient. Even highly relevant memories can fail if they are placed incorrectly inside the context window
A common issue is treating retrieval purely as a search problem while ignoring placement. Retrieved memories are appended wherever they arrive, without considering their role in the current reasoning step
This becomes more impactful in long contexts. Attention is not uniformly distributed across the prompt. Information placed deep inside a long context can receive significantly less influence than information positioned near the beginning or end. This leads to a subtle failure mode:
- The correct information is retrieved
- The information is inserted into context
- The model behaves as if it is missing
The retrieval succeeded but the placement failed. Context assembly should therefore optimize both:
- Selection: what enters the context window
- Placement: where it appears within the context window
Retrieved information that must influence the current step should be positioned near the active reasoning region rather than appended arbitrarily
## Summary
Context and memory engineering are two layers of a single system that controls what the model knows, when it knows it, and how that knowledge is used
> Context engineering operates at inference time, shaping the active information window. Memory engineering operates across time, shaping what information persists and how it can be retrieved later
To sum up, an agentic system only works when both layers are aligned: memory determines what is available, and context determines what becomes actionable
Save this so you don't lose it
Follow @beamnxw for more technical posts :)
my telegram channel
## 相关链接
- [beamnxw ./](https://x.com/beamnxw)
- [@beamnxw](https://x.com/beamnxw)
- [18K](https://x.com/beamnxw/status/2084647643314102600/analytics)
- [AI agents](https://cloud.google.com/discover/what-are-ai-agents)
- [context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [memory engineering](https://www.mongodb.com/company/blog/technical/why-multi-agent-systems-need-memory-engineering)
- [Context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [Memory engineering](https://www.mongodb.com/company/blog/technical/why-multi-agent-systems-need-memory-engineering)
- [For an agent running a multi-step workflow, every inference call assembles a context window from multiple sources](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents#the-anatomy-of-effective-context#why-context-engineering-is-important-to-building-capable-agents)
- [Where information sits in the window affects how reliably the model uses it](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents#the-anatomy-of-effective-context)
- [lost in the middle" effect](https://arxiv.org/abs/2307.03172)
- [OpenAI’s context personalization cookbook](https://developers.openai.com/cookbook/examples/agents_sdk/context_personalization)
- [@beamnxw](https://x.com/@beamnxw)
- [my telegram channel](https://t.me/beamnxw11)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:28 PM · Aug 4, 2026](https://x.com/beamnxw/status/2084647643314102600)
- [18.1K Views](https://x.com/beamnxw/status/2084647643314102600/analytics)
- [View quotes](https://x.com/beamnxw/status/2084647643314102600/quotes)
---
*导出时间: 2026/8/5 09:54:51*
---
## 中文翻译
# 代理式 AI 系统中的上下文工程与记忆工程
**作者**: beamnxw ./
**日期**: 2026-08-04T14:28:23.000Z
**来源**: [https://x.com/beamnxw/status/2084647643314102600](https://x.com/beamnxw/status/2084647643314102600)
---
在本文中，你将了解上下文工程和记忆工程如何解决代理式 AI 系统中的不同问题，以及这两个学科如何在检索到的记忆进入上下文窗口这一节点上交汇。
# 简介
随着 AI 代理进入更长的工作流程和多会话场景，一种熟悉的模式开始浮现。约束条件在任务中途被丢弃，检索到的信息在不该出现时重新浮出水面，而先前步骤的上下文渗入到了当前步骤中。这些故障很难定位，因为没有哪个单一组件明显是罪魁祸首。
大多数时候，问题出在两个经常被一起构建、混淆或跳过的领域：上下文工程和记忆工程。它们相关但截然不同，失败方式也不同，需要不同的系统来做好。
本文涵盖了每个学科背后的核心决策以及它们的交互点：
- 上下文工程涉及什么，以及哪些具体决策决定了代理在单次调用中是否能良好推理。
- 记忆工程涉及什么，以及写入策略、存储、检索和维护如何各自影响长期可靠性。
- 这两个学科如何在检索时共享边界，以及管理好该边界需要什么。
单独或共同理解这两者，决定了代理能否在真实工作负载中经受住考验。
# 上下文与记忆工程概览
上下文工程涵盖单次推理调用的设计：包括什么、压缩什么、将内容放在哪里以及丢弃什么。范围内的所有内容都是暂时的。当调用结束时，窗口会被清空。
记忆工程专注于在单次模型交互之外留存的内容。它 encompass（包含）负责写入、存储、检索、更新和管理信息的系统与策略，以便未来的交互可以利用这些信息。当代理回忆起先前会话的信息、与另一个代理协调，或应用几天或几周前学到的用户偏好时，它依赖的就是记忆工程。
虽然上下文工程决定了在特定请求期间模型可用的信息，但记忆工程决定了跨请求持久存在的信息，以及这些信息如何随时间被维护、检索和信任。以下是一个概览：
# 上下文工程：组装最佳的上下文窗口
对于运行多步工作流程的代理来说，每次推理调用都会从多个来源组装上下文窗口：系统提示词、任务描述、对话历史、工具输出、检索到的文档、子代理摘要。上下文工程是一系列决策，决定了每个组件贡献什么、以何种形式以及处于什么位置。
## 选择性包含
并非所有可用的信息都应进入上下文。返回数百行的数据库查询、返回五篇完整文章的网络搜索、输出冗余日志的代码执行器 ➜ 所有这些都会使窗口膨胀，并在达到 token 限制之前降低推理质量。关于什么逐字包含、什么压缩为关键事实以及什么丢弃的决定，是一种设计选择，而非默认行为。
## 结构化放置
信息在窗口中的位置会影响模型使用它的可靠性。模型对长上下文开头和结尾的内容给予更多关注，而中间的材料获得的权重明显较低。这被称为“迷失在中间”效应。
硬性约束和关键任务指令应位于窗口顶部。与当前任务最相关的检索信息应放置在上下文窗口的末尾附近。
当前用户查询或任务通常应紧跟在检索信息之后，将相关上下文和即时目标尽可能靠近生成点定位。这种安排增加了模型在生成响应时有效利用检索信息的可能性。
上下文工程概览
## 到达即压缩
工具输出应在调用返回后立即压缩，而不是在窗口填满之后。一个携带 3,000 个 token 的原始 API 响应，而代理只需要其中的 150 个，应在进入下一步的上下文之前进行总结。等到窗口满了再匆忙截断，是对问题的被动管理，而源头压缩可以预防这个问题。
## 对话历史管理
对话历史的增长速度超过任何其他上下文组件。对于长时间运行的代理，将完整历史带入每次调用会使每次后续推理变得更昂贵且更不可靠。压缩策略 ➜ 滚动窗口、分层摘要或结构化状态提取 ➜ 应在定义的时间间隔内应用，而不是在窗口溢出时才应用。
# 记忆工程：设计持久化的 AI 记忆系统
一旦推理调用完成，记忆工程就决定了什么值得持久化以及在什么条件下再次使用它。这涵盖了四个不同的关注点：写入什么、存储在哪里、如何检索以及如何保持其长期准确性。
## 写入策略设计
写入策略设计是记忆工程中最容易被忽视的方面之一，但它对随时间变化的记忆质量有着不成比例的影响。虽然检索系统通常受到最多的关注，但检索质量最终受到最初进入记忆存储的内容的限制。
一个定义明确的写入策略指定：
1. 什么事件触发写入记忆。
2. 哪些信息符合存储条件。
3. 信息存储的格式，例如原始文本、结构化记录、提取的事实或摘要。
4. 接受新条目的置信度或验证要求。
5. 哪些代理、工具或系统组件被允许写入特定的记忆命名空间。
6. 如何处理更新、更正和冲突信息。
7. 不同记忆类型的保留规则、过期策略和生存时间（TTL）要求。
> 如果没有明确的写入策略，系统通常默认存储过多信息，对所有条目赋予同等信任，并无限期保留数据。随着时间的推移，低价值和过时的记忆会累积，信噪比下降，检索质量恶化。结果就是一个记忆系统不断增长，却变得越来越无用。
## 存储层选择
不同的记忆类型服务于不同的目的，需要不同的存储后端。后端的选择也限制了可用的检索策略。
OpenAI 的上下文个性化手册在需要连续性的用例中，对基于检索的记忆和基于状态的记忆做出了有用的区分。基于检索的记忆将过去的交互视为松散相关的文档，对措辞变化和冲突更新很脆弱。结构化状态提取 ➜ 编写入经过类型验证的事实而不是嵌入原始对话 ➜ 对于需要在会话之间可靠应用的事实会产生更一致的结果。
记忆工程概览
## 检索策略
> 从记忆读取不是单一的操作。
设计良好的检索层首先检查工作记忆（快速、廉价、精确的键查找）➜ 当没有找到相关内容时回退到情景记忆或语义记忆的语义搜索 ➜ 在返回结果之前应用最近时间和信任级别的元数据过滤器 ➜ 并且仅注入当前步骤需要的内容。
## 记忆维护
没有维护策略的存储会随时间推移而退化。条目累积，陈旧的事实与当前的事实竞争，随着信噪比下降，检索质量下降。以下维护程序在实践中很重要：易变事实的置信度衰减、语义相似条目的去重、基于 TTL 的工作记忆和时敏数据过期，以及定期将旧的情景记录压缩为会话级摘要。
> 一个直接编码了这些关注点的 `MemoryEntry` 模式使写入和维护逻辑更易于推理：
```
class MemoryEntry(BaseModel):
content: str
memory_type: str # working | episodic | semantic | procedural
importance: float # 0.0–1.0, gates long-term storage
confidence: float # decays over time for volatile facts
trust_level: float # 1.0 internal system, 0.5 user input, 0.0 external
created_at: datetime
expires_at: datetime | None
provenance: dict # agent_id, tool_name, session_id, input_hash
def should_write_to_long_term(entry: MemoryEntry) -> bool:
return (
entry.importance >= 0.6
and entry.confidence >= 0.7
and entry.trust_level >= 0.5
)
```
# 检索边界：连接记忆与上下文工程
记忆工程和上下文工程通常被讨论为独立的学科，但在实践中它们是深度交织的。两者的存在都是为了解决同一个核心问题：确保模型在正确的时间访问正确的信息。
从高层次来看：
- 记忆工程专注于持久性：什么信息应该被存储、更新、保留或随时间遗忘。
- 上下文工程专注于利用：什么信息应该进入特定任务的活跃上下文窗口以及应该如何组织它。
- 检索是这两个学科相遇的边界。
记忆系统生成候选信息。上下文组装然后决定：
- 该信息是否应该进入提示词。
- 应该包含多少。
- 它应该放置在上下文窗口内的什么位置。
管理好这个边界是将一组记忆组件转化为连贯代理系统的关键。
# 失败模式 #1：没有上下文预算的检索
最常见的失败之一发生在检索被独立于上下文组装处理时。
记忆搜索返回一组相关条目，上下文组装器将它们全部注入提示词。随着添加更多记忆，上下文窗口逐渐被检索内容填满，留给指令、工具输出、推理轨迹和特定任务信息的空间变少。
产生的症状往往具有误导性：
- 检索质量看起来很高。
- 成功找到了相关的记忆。
- 系统性能仍然下降。
在许多情况下，记忆系统正确地完成了它的工作。失败的发生是因为上下文组装缺乏预算机制。
更好的方法是检索感知的上下文组装。与其先检索后预算，上下文层在检索开始之前就分配一个 token 预算。然后，检索层仅返回适合该预算内的最高价值记忆。
```
async def retrieve_for_step(
self,
step: AgentStep,
max_tokens: int
) -> str:
candidates = await self.memory.search(
query=step.retrieval_query,
max_results=10,
filters={
"trust_level": {"gte": 0.5},
"expires_at": {"gt": datetime.now()}
}
)
selected = []
used = 0
for entry in sorted(
candidates,
key=lambda e: e.relevance_score,
reverse=True
):
cost = self.token_count(entry.content)
if used + cost > max_tokens:
break
selected.append(entry.content)
used += cost
return "\n\n".join(selected)
```
> 检索必须在上下文约束内运行，而不是假设下游有无限的空间。
# 失败模式 #2：检索信息的放置不当
仅靠检索质量是不够的。即使高度相关的记忆，如果放置在上下文窗口内的位置不当，也可能失效。
一个常见问题是将检索纯粹视为搜索问题而忽略放置。检索到的记忆被附加到它们到达的任何位置，而不考虑它们在当前推理步骤中的作用。
这在长上下文中变得更具影响力。注意力在提示词中不是均匀分布的。放置在长上下文深处的信息可能比定位在开头或结尾附近的信息受到的影响明显更小。这导致一种微妙的失败模式：
- 检索到了正确的信息。
- 信息被插入到了上下文中。
- 模型的行为就好像缺少了该信息一样。
检索成功了，但放置失败了。因此，上下文组装应该优化两者：
- 选择：进入上下文窗口的内容。
- 放置：它在上下文窗口内出现的位置。
必须影响当前步骤的检索信息应定位在活跃推理区域附近，而不是任意附加。
## 总结
上下文和记忆工程是单一系统的两层，控制着模型知道什么、何时知道以及如何使用这些知识。
> 上下文工程在推理时操作，塑造活跃的信息窗口。记忆工程跨越时间操作，塑造哪些信息持久存在以及以后如何检索。
总而言之，只有当这两层保持一致时，代理系统才能工作：记忆决定了可用什么，上下文决定了什么变得可执行。
保存这篇文章以免丢失。
关注 @beamnxw 获取更多技术文章 :)
我的 Telegram 频道
## 相关链接
- [beamnxw ./](https://x.com/beamnxw)
- [@beamnxw](https://x.com/beamnxw)
- [18K](https://x.com/beamnxw/status/2084647643314102600/analytics)
- [AI agents](https://cloud.google.com/discover/what-are-ai-agents)
- [context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [memory engineering](https://www.mongodb.com/company/blog/technical/why-multi-agent-systems-need-memory-engineering)
- [Context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [Memory engineering](https://www.mongodb.com/company/blog/technical/why-multi-agent-systems-need-memory-engineering)
- [For an agent running a multi-step workflow, every inference call assembles a context window from multiple sources](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents#the-anatomy-of-effective-context#why-context-engineering-is-important-to-building-capable-agents)
- [Where information sits in the window affects how reliably the model uses it](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents#the-anatomy-of-effective-context)
- [lost in the middle" effect](https://arxiv.org/abs/2307.03172)
- [OpenAI’s context personalization cookbook](https://developers.openai.com/cookbook/examples/agents_sdk/context_personalization)
- [@beamnxw](https://x.com/@beamnxw)
- [my telegram channel](https://t.me/beamnxw11)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:28 PM · Aug 4, 2026](https://x.com/beamnxw/status/2084647643314102600)
- [18.1K Views](https://x.com/beamnxw/status/2084647643314102600/analytics)
- [View quotes](https://x.com/beamnxw/status/2084647643314102600/quotes)
---
*导出时间: 2026/8/5 09:54:51* 
