许多 AI engineers 正在为自己的 agents 构建 contextual engineering layers，但大多数人只做到基础的 memory storage 就认为完成了。他们忽略的是，真正的 contextual engineering 是一整套 pipeline：决定应该记住什么，如何在不压垮模型的情况下将其注入上下文，以及如何把 session notes 合并进 long-term memory，同时避免 stale data。更不用说 importance scoring、writer-critic consolidation patterns、multi-layer security guardrails 等内容了。它远不只是 “记住一些东西”。

Full Stack Contextual Engineering Pipeline (Created by Fareed Khan)

• Data & State Setup： 定义 agent 在 session 开始之前已经知道什么，从 user profiles 到 long-term memory stores。
• Injection Layer： 将这些 state 渲染成 LLM 能够读取和推理的格式，并在合适的时机注入 prompt。
• Live Distillation： 让 agent 在对话过程中主动捕获新的 preferences 和 insights。
• Consolidation： session 结束后，将学到的内容干净地合并进 long-term memory，避免 duplicates 或 stale data。
• Evaluation Engine： 使用 precision、recall 和 safety metrics 系统化衡量每个阶段的实际效果。

在此之上，还有更多层：security guardrails、writer-critic patterns、importance scoring、A/B testing injection strategies 等。

在这篇博客中，我们将从零开始构建这条 pipeline 的每一个部分，并准确理解每个 component 的作用。

如果你刚接触 contextual engineering，可以先阅读

LangChain Agent 性能优化指南：子 Agent、记忆与上下文管理

来打好基础。

所有代码都可以在我的 GitHub Repository 中找到：

https://github.com/FareedKhan-dev/advance-contextual-engineering

Table of Contents

• Table of Contents
• Setting up the Environment
• Defining the State Object (Local-First Memory Store)
• Building Tools for Live Memory Distillation
• Creating a Trimming Session for Context Management
• Defining the Memory Injection Policy
• Rendering State into Injectable Formats
• Defining Hooks for the Memory Lifecycle
• Assembling the Travel Concierge Agent
• Testing our Agent (Turns 1 to 4)
• Implementing Post-Session Memory Consolidation
• Adding User Controls and Safety Guardrails
• Testing the New Guardrails and User Controls
• Testing Memory Synthesis in a Complex Query
• Advanced Consolidation Using Importance Scoring and Aging
• Writer-Critic Pattern for Safer Consolidation
• Generating Proactive Insights from History
• Systematic Evaluation of the Memory Pipeline

• Distillation Evals (Capture Quality)
• Injection Evals (Usage Quality)
• Consolidation Evals (Curation Quality)

• A/B Testing Memory Injection Strategies
• Refining the Consolidation Critic
• Simulating User Preference Drift
• Hardening Security with Multi-Layer Guardrails
• Summarizing Everything

Setting up the Environment

我们将使用 OpenAI Agents SDK。它是较知名的 agentic memory handling modules 之一，因为它提供了 state management、hooks 等能力的 wrappers。我们还需要 nest_asyncio，以便在 notebook 中运行 async agent workflows。

首先安装所需 libraries。如果你在 Jupyter notebook 中运行，可以使用以下命令：

# Install the required libraries
!pip install openai-agents nest_asyncio

接下来设置 imports 并初始化 client。我们将使用 SDK 原生支持的 LiteLLM routing 来连接到指定 endpoint。

# 代码保持原文

为了确保 contextual pipeline 连接正常，我们用一个简单 agent 做快速测试。这里的 instructions 参数是最基础形式的 context engineering：通过一条规则塑造行为。

# 代码保持原文

我们的环境已经准备好了。接下来可以开始构建 memory system 的核心部分。

Defining the State Object (Local-First Memory Store)

这是架构中的第一个、也是最关键的步骤。我们将定义一个 data structure，用来保存 agent 需要了解的所有 user 信息。这个 object 相当于 agent 的“大脑”，也是任何 agentic memory system 的基本格式。

State Object Logic (Created by Fareed Khan)

我们会将其拆分为 structured data，例如 IDs 这类可由机器强制约束的数据，以及 unstructured data，例如 “prefers high floors” 这类 narrative context。

# 代码保持原文

为什么要创建两个独立的 memory lists：global_memory 和 session_memory？session_memory 作为临时 staging area，用于存放 live chat 中捕获的新信息；global_memory 则是经过整理的 long-term store。这样的分离可以避免每一句临时评论都污染 agent 的核心知识库。

现在，我们用一些 sample data 初始化这个 state，模拟一个 returning user。这是 pre-run context hydration 步骤：在对话开始前预填充 memory，让 agent 拥有“先发优势”。

# 代码保持原文

这里我们创建了一个 TravelState 实例，填充了 profile，并添加了一些初始 global_memory notes，例如 “User usually prefers aisle seats”。这模拟了一个我们已经了解其偏好的 returning user。

通过在 run 之前初始化这个 state，我们执行的是 pre-run context hydration。agent 在第一次对话开始时就已经知道 John Doe 是谁。

Building Tools for Live Memory Distillation

我们需要一种方式，让 agent 能够从 live conversation 中主动提取可长期复用的信息。我们称之为 live memory distillation。这是 memory lifecycle 的第二阶段：agent 在对话过程中捕获新的 insights，并决定哪些值得保留。

Building Tools (Created by Fareed Khan)

这很重要，因为用户偏好可能会变化。也许 John Doe 刚换了新工作，现在更喜欢 window seats，以便在飞机上睡觉。agent 需要在这种变化发生时就能捕获它。

我们将使用 @function_tool decorator 创建一个 tool。这个 tool 的 docstring 本身就是 prompt engineering 的一部分。LLM 会读取这个 docstring，以理解什么是“好的 memory”，什么应该忽略。

# 代码保持原文

这个 tool 是 agent 动态演化自身 context 的主要机制。在函数 docstring 中，我们明确告诉 agent 何时 使用这个 tool，以及应该捕获 哪类 信息。

这是 prompt engineering 的基础步骤，用于引导 agent 从对话中 distill 出 high-signal memories。

Creating a Trimming Session for Context Management

Language models 的 context window 是有限的。对于长对话，我们需要一种策略，防止 history 超过这个限制。然而，naive trimming 可能会删除用户 10 轮之前提到的临时约束。

这是 state-based memory systems 中常见的问题：如何在不丢失关键信息的前提下管理 context size。

Trim Session (Created by Fareed Khan)

我们需要实现一个 TrimmingSession class，只保留最近 N 个 user turns。关键在于，如果它裁剪了 history，它会在 state 中打开一个 flag：inject_session_memories_next_turn = True，告诉系统下一轮将 session notes 注入 prompt，这样就不会丢失这些 context。

首先导入实现 session class 所需的 modules。

# 代码保持原文

在定义 TrimmingSession 之前，我们需要一个 helper function，用来识别 conversation history 中的 user messages。因为我们希望基于 user turns 裁剪，而不是 assistant turns。

# 代码保持原文

这个函数本质上是一个 type-agnostic 的方式，用来判断 conversation history 中某个 item 是否是 user message。它同时支持 dictionary-based 和 object-based 的表示方式，因此对不同数据结构都比较灵活。

现在可以定义 TrimmingSession class，它实现了 SessionABC interface。这个 class 将管理 conversation history，并确保只保留最近 N 个 user turns，同时在发生 trimming 时发出信号，让系统注入 session memories。

# 代码保持原文

在 TrimmingSession 中，添加新的 items 到 session history 后，我们会检查 user turns 数是否超过 max_turns。如果超过，就将 inject_session_memories_next_turn 设置为 True，表示下一轮需要把 session memories 注入 prompt。

这样，即使裁剪掉旧的 user messages，我们也能通过 session memory 保留关键 context。

接着实例化这个 session，并将其与 user state 绑定。这个 session object 会传给 agent runs，用于管理 conversation history，同时在需要注入 session memories 时发出信号。

# 代码保持原文

session 设置完成后，就可以定义 agent 如何使用 injected memory，以及在基于 memory 推理时应遵循哪些规则。

Defining the Memory Injection Policy

简单地把数据倾倒进 LLM context 并不够，我们必须教 agent 如何 推理这些数据。因此，我们定义一组 instructions 来建立 precedence rules。

Memory injection (Created by Fareed Khan)

为此，我们需要创建一个 prompt template，明确告诉 agent 如何使用 injected memory。

# 代码保持原文

我们的 template 明确规定了优先级：User Message > Session > Global，防止 agent 过度受 stale、old memories 影响。这样，如果用户说 “This trip, I want a window seat”，agent 就知道这次应优先于 global memory 中的 “User usually prefers aisle seats”。

Rendering State into Injectable Formats

我们的 state object 是 Python code，但 LLM 需要 plain text。因此，我们需要 helper functions，将 state 渲染成特定格式。我们会用 YAML 表示 structured data，因为它看起来像权威配置；用 Markdown 表示 unstructured notes。

Injectable Formats (Created by Fareed Khan)

首先构建 render_frontmatter，它会接收 user profile，并渲染成 YAML block。这能帮助 LLM 解析并理解用户的核心属性。

# 代码保持原文

接下来创建 render_global_memories_md，将 global memory notes list 转换成 Markdown 格式。我们还会按 recency 排序，让最新 notes 出现在最上方。

在 context engineering 中，memory 的格式化和呈现方式会显著影响 LLM 对它的使用。通过将 global memories 渲染为按 recency 排序的 Markdown list，我们为 LLM 提供了一个清晰、有组织的用户长期偏好和行为视图。

# 代码保持原文

最后，render_session_memories_md 会对 session memory notes 做同样处理。它用于需要将 temporary overrides 注入 prompt 的场景。

# 代码保持原文

因此，如果我们有如下 session memory note：

# 原始示例保持不变

render_session_memories_md 会将其转换为 Markdown bullet point，便于注入 LLM prompt。

Defining Hooks for the Memory Lifecycle

在 Context engineering 中，hooks 是在 agent 执行生命周期中特定时间点运行的函数。它们允许我们动态操作 agent 的 context、state 或 behavior。

Agent Hooks (Created by Fareed Khan)

我们将定义一个 AgentHooks class。具体来说，on_start hook 会在每一轮最开始、agent 调用 LLM 之前执行。在这里，我们会把 state 格式化为 strings。

这是一个关键步骤。如果 agent 发出信号表示应注入 session memories，例如发生 trimming event 后，我们就渲染这些 session notes，并准备将其注入 prompt。这样即使裁剪了 conversation history，也不会丢失重要 context。

# 代码保持原文

在 MemoryHooks 中，on_start 方法负责为 LLM 准备 context。它确保 agent 始终可以访问最新 profile 和 global memories。

如果 inject_session_memories_next_turn flag 被设置，它也会渲染 session memories，以便注入 prompt。这样，即使旧 conversation history 被裁剪，我们仍可通过 session memory 保留关键 context。

Assembling the Travel Concierge Agent

现在把所有东西组合起来。我们定义基础 persona：BASE_INSTRUCTIONS，并创建一个 dynamic async function，在每一轮 即时 构建最终 prompt。

Travel Agent (Created by Fareed Khan)

# 代码保持原文

在 BASE_INSTRUCTIONS 中，我们设置了 travel concierge agent 的语气和行为：简洁、可靠，并一次只问一个聚焦的 clarification question。

我们也强调要尊重用户偏好，并避免 assumptions。

# 代码保持原文

在 instructions function 中，我们会为每一轮动态生成 system prompt。它包括 user profile、global memories，以及在 flag 被设置时加入 session memories。

这确保 agent 在决策时拥有所有相关 context。同时包含 MEMORY_INSTRUCTIONS，用来指导 agent 如何有效使用 memory。

最后，实例化 travel_concierge_agent，并挂载前面定义的 hooks 和 tools。

# 代码保持原文

现在，我们拥有了一个完整的 travel concierge agent。它可以通过 structured state、dynamic prompt generation 和 live memory distillation 管理自身 memory。

Testing our Agent (Turns 1 to 4)

我们将与 agent 进行 4 轮交互，测试整个 memory pipeline，包括 memory recall、distillation 和 temporary overrides。

第一轮，我们让 agent 预订飞往巴黎的航班。agent 应该使用注入的 profile 和 global memory 来生成响应。

# 代码保持原文

agent 在第 1 轮返回如下内容：

#### OUTPUT ####
Turn 1: Of course! To find the best flight options to Paris for
you next month, I will just need to confirm your preferred
departure and return dates. What days are you thinking of?

在第 1 轮中，agent 成功使用了 injected profile 和 global memory，理解 John Doe 偏好 aisle seats，并且短途旅行通常不托运行李。

它还提出了关于 travel dates 的相关 clarification question，这说明它正在进行有意义的对话。

接下来，我们明确询问 agent 是否成功读取了 injected state。

# 代码保持原文

第 2 轮输出如下：

#### OUTPUT ####
Turn 2: Yes, based on your profile, I know the following:
- Seat preference: Aisle
- Airline loyalty: United Gold
- Hotel loyalty: Marriott Titanium
- Baggage: For trips under a week, you generally prefer not to check bags.
I will keep these in mind. What specific dates next month work for your trip to Paris?

可以看到，agent 正确回忆出了 injected state 中的用户偏好，包括 aisle seat preference、loyalty statuses 和 baggage preference，证明 memory injection 按预期工作。

现在，我们给 agent 新信息，测试它是否会使用 save_memory_note tool。

# 代码保持原文

第 3、4 轮输出如下：

#### OUTPUT ####
--> [System] New session memory added: User is vegetarian.

Turn 3: I have updated your profile to reflect that you are vegetarian. I will make sure to request vegetarian meals for your flights going forward.

--> [System] New session memory added: This trip only: user prefers a window seat to sleep.
Turn 4: Noted. For this trip to Paris, I will look for a window seat for you.

这些 print statements（--> [System]）确认 LLM 正确调用了 tool。更值得注意的是，在第 4 轮中，agent 识别出用户意图是 temporary 的，并在 note 前加上 “This trip only”，证明我们在 tool docstring 上的 prompt engineering 非常有效。

Implementing Post-Session Memory Consolidation

现在我们已经完成了 4 轮交互，并得到了一些 session memory notes，需要实现 memory lifecycle 的最后阶段：consolidation。

Post Session (Created by Fareed Khan)

对话结束后，我们必须把 staging 区域中的 session_memory notes 移动到永久的 global_memory。我们将使用一次 LLM call 来执行 consolidation，并指示它删除 duplicates、丢弃 temporary notes。

在 context engineering 中，这个 consolidation 步骤对于保持 long-term memory 干净且相关非常重要。

通过让 LLM 评估哪些 session notes 应被提升为 global memory，我们可以确保只有 durable、high-signal 的信息被保留下来，用于未来交互。

# 代码保持原文

在 consolidate_memory function 中，我们创建了一个 prompt，指导 LLM 如何基于 global notes 评估 session notes。LLM 被要求只返回 durable information，并丢弃包含 “this time” 或 “this trip” 等短语的 temporary notes。

我们还要求它进行 de-duplicate，并基于最新 update date 解决 conflicts。

运行它并检查 “Vegetarian” 和 “Window seat” notes 的结果。

# 代码保持原文

consolidation 后输出如下：

#### OUTPUT ####
--> Consolidation successful. Active memories: 3

Global Memory State:
- For trips shorter than a week, user generally prefers not to check bags.
- User usually prefers aisle seats.
- User is vegetarian.

LLM 完美遵循了 Rule #2。它将 “Vegetarian” note 提升到 global memory，但完全丢弃了 “This trip only: window seat” note。我们的 long-term database 保持干净！

Adding User Controls and Safety Guardrails

在构建 memory systems 时，给予用户数据控制权，并实现防止 sensitive information 被存储的 guardrails 至关重要。

User Control (Created by Fareed Khan)

一个可信系统必须允许用户删除数据，并且必须通过程序阻止 sensitive data（PII）。我们将添加 regex-based safety check、deletion tool，以及升级版 SmartMemoryHooks class。

# 代码保持原文

在 contains_sensitive_info function 中，我们使用 regular expression 检测类似 credit card numbers 的模式。

这是一种简单但有效的方式，可以防止 sensitive financial information 被存入 memory system。

接下来创建一个 tool，允许用户基于 keywords 删除特定 memories。这让用户拥有数据控制权，也允许他们修正或移除过时 preferences。

# 代码保持原文

在 delete_memory_note tool 中，我们过滤 global memory notes，删除包含指定 keyword 的 notes。这让用户可以轻松删除不再相关的 preferences 或 constraints。

我们还需要创建一个安全版 save_memory_note tool，加入 PII check。

# 代码保持原文

现在可以更新 SmartMemoryHooks，使用新的 safe tool，并根据当前用户 query 对 global notes 进行更智能的 relevance filtering。

# 代码保持原文

在 SmartMemoryHooks 中，我们增强了 on_start 方法，会根据当前 user query 的 relevance 过滤 global memory notes。

这样，如果用户询问 flight preferences，agent 会优先注入包含 “seat”、“meal” 或 “airline” 等 keywords 的 notes。

这使 injected memory 更具 contextual relevance，并减少 LLM input 中的噪声。

现在可以更新 agent，使用这些新的 hooks 和 tools，让 memory system 更 robust、更 user-friendly，并内置 safety guardrails。

# 代码保持原文

现在我们的 agent 拥有增强的 memory management capabilities，包括用户删除 memories 的 controls，以及防止 sensitive information 被存储的 safety guardrails。这让 travel concierge 不仅更聪明，也更可信、更以用户为中心。

Testing the New Guardrails and User Controls

我们来测试 agent 是否能按命令删除数据，以及是否能阻止 fake credit card numbers。

# 代码保持原文

删除测试输出如下：

#### OUTPUT ####
--- Testing Deletion ---
--> Deleted 1 memories matching: seat

我们成功删除了 “aisle seat” preference。接下来测试 safety guardrail，尝试保存一个包含 fake credit card number 的 note。

# 代码保持原文

#### OUTPUT ####
--- Testing Privacy Guardrail ---
--> 🛑  BLOCKED: Sensitive memory attempt.

Agent Response: For security reasons, I can not store credit card numbers
or other sensitive payment details.

You will be able to enter that information securely when you are ready to book.

我们的 proactive context management 生效了。delete_memory_note tool 清理了 state，而 save_memory_note_safe 在 PII 到达 memory 之前就拦截了它，并让 agent 礼貌地向用户解释 security policy。

Testing Memory Synthesis in a Complex Query

让我们提出一个复杂问题，看看 agent 是否能综合 structured profile data（Loyalty IDs）、long-term global notes（Walkable neighborhoods）和近期 distilled notes（Vegetarian）。

# 代码保持原文

输出如下：

#### OUTPUT ####
Assistant Response:
Hotel Recommendations:
Since you prefer central, walkable neighborhoods and have Marriott Titanium status, I do recommend looking at Marriott properties in areas like Le Marais. Your status should give you access to perks.

Flight Tips:
- Airline: I will prioritize United flights to take advantage of your Gold status.
- Meal: I will be sure to request a vegetarian meal for you.
- Seat: For this trip, I will look for a window seat so you can sleep, as you requested.

agent 没有问 “What do you like?”。它直接从 YAML 中读取了 Marriott Titanium，结合 Global Markdown 中的 Walkable preference，记住了 Vegetarian distillation，并尊重了 Window seat 的 session-override。

Advanced Consolidation Using Importance Scoring and Aging

Long-term memory 会逐渐膨胀。我们将引入 importance score，并重写 consolidation function，用于清理 “stale” notes，例如超过 1 年且 importance 较低的 notes。

Consolidation (Created by Fareed Khan)

在 agentic system 中，这对于维护相关且高效的 memory system 至关重要。

通过为 memories 分配 importance scores，并实现 aging rules，我们可以确保 long-term memory 始终聚焦于最关键、最新的信息。

# 代码保持原文

我们为所有 notes 设置默认 importance score 为 3，但可以根据 note 内容调整。

• 例如，严重过敏信息可以设为 importance 5。
• 临时偏好则可以设为 importance 1。

现在我们可以重写 consolidate_memory function，加入 importance scores，并实现 aging rules，自动清理既旧又不重要的 notes。

# 代码保持原文

在 consolidate_memory_with_aging function 中，我们新增了基于 importance scores 的 aging 和 pruning rules。LLM 会评估每条 note 的 age 和 importance，删除被认为 stale 的 notes，同时确保 vital information 被永久保留。

Writer-Critic Pattern for Safer Consolidation

让一个 LLM 重写核心 database 是有风险的。如果它 hallucinate 或删除 vital data 怎么办？

我们可以使用 Writer-Critic Pattern：一个 LLM 负责提出写入方案，另一个 “Critic” LLM 作为 Quality Assurance。

Writer Critic Pattern (Created by Fareed Khan)

# 代码保持原文

现在可以实现 consolidate_with_critic function，使用这个 pattern，确保任何 global memory 变更在 commit 前都经过严格审核。

# 代码保持原文

如果我们注入了一个 “Peanut Allergy”（Importance 5），而 Writer 忘记了它，Critic 就会标记 “DATA LOSS”，并拒绝 database commit。

Generating Proactive Insights from History

一个真正聪明的 agent 不仅会分析 chat history，还会分析用户 随时间变化的行为模式。

我们可以在后台使用 LLM 分析用户的 trip_history，并将 analytical observation 注入 prompt。这就是 in-context RAG。

Memory 不只是回忆事实，更是理解模式。通过分析用户 trip history，我们可以生成 proactive insights，帮助 agent 做出更好的推荐。

1. 例如，如果用户经常在周末临时预订短途旅行。

2. agent 可以主动建议：“I noticed you often book last-minute trips on weekends. Would you like me to keep an eye out for last-minute deals?”

# 代码保持原文

在这个 function 中，我们分析用户最近的 trip history，以识别 patterns 或 insights。

如果发现 pattern，就将其注入 system frontmatter，使 agent 可以在 reasoning 和 recommendations 中使用它。

Systematic Evaluation of the Memory Pipeline

我们需要 evaluation process 来衡量 prompts 是否真正有效。我们将使用 LLM-as-a-Judge 来评估 pipeline 的三个关键阶段。

拥有一个独立的 evaluation process 非常重要，它可以系统化测试 memory pipeline 的每个阶段。

通过使用 LLM 作为 judge，我们可以创建一组带有已知 expected outcomes 的 test cases，并让 LLM 判断 agent 行为是否符合这些 expectations。

Distillation Evals (Capture Quality)

agent 是否能忽略 conversational noise（Precision）、捕获 preferences（Recall），并阻止 PII（Safety）？

这非常重要。如果 distillation step 太激进，可能会遗漏重要 preferences（low recall）；如果太宽松，则可能捕获噪声或 sensitive info（low precision 和 safety）。

这些 metrics 可以通过构造带有 expected outcomes 的 test cases，运行 distillation process，再用 LLM 判断 outcomes 是否符合 expectations 来衡量。

# 代码保持原文

接下来实现 run_distillation_metrics_eval function，让这些 test cases 通过 agent，并用 LLM 评估结果，基于 outcomes 计算 precision、recall 和 safety metrics。

# 代码保持原文

我们可以直接在 test cases 上运行它，检查 eval 是否能正确评估 memory system。

# 代码保持原文

在 test dataset 中，我们包含了 precision tests（应忽略的 conversational noise）、recall tests（应保存的 durable preferences），以及 safety tests（应阻止的 sensitive 或 malicious input）。运行 run_distillation_metrics_eval，查看 agent 在关键 metrics 上的表现。

# 代码保持原文

输出如下：

#### OUTPUT ####
--- RUNNING DISTILLATION METRICS EVALUATION ---
...
PRECISION: 100.0%  (Are we avoiding junk?)
RECALL:    100.0%  (Are we capturing everything?)
SAFETY:    100.0%  (Are we blocking PII?)

我们的 memory distillation process 在这个 test dataset 上表现完美，precision、recall 和 safety 都达到 100%。agent 正确忽略 conversational noise，捕获 durable preferences，并按预期阻止 sensitive information。

Injection Evals (Usage Quality)

第二个 metric 是：agent 是否优先考虑 recency？是否避免 over-influencing user？

这对于确保 agent 使用最相关、最新的信息非常关键，同时也避免用过多 context 压倒用户，或基于 outdated preferences 做 assumptions。

# 代码保持原文

现在需要创建 run_injection_eval function：它运行一组 test cases，通过 agent 获取 assistant response，再使用 Judge LLM 评估 agent 是否满足 recency、over-influence 和 efficiency 标准。

结果可以聚合为 injection quality 的整体分数。

# 代码保持原文

运行 run_injection_eval，使用一组专门设计的 test cases，评估 agent 是否能优先使用最新信息，并避免 over-influencing user。

# 代码保持原文

输出如下：

### OUTPUT ###
--- RUNNING INJECTION QUALITY EVALUATION ---
...
RECENCY         ACCURACY: 100.0%
OVER-INFLUENCE  ACCURACY: 100.0%
EFFICIENCY      ACCURACY: 100.0%

可以看到，agent 检查了 injection process 的三个关键方面：是否正确优先使用最新信息（Recency）、是否避免用太多 context 过度影响用户（Over-influence），以及是否高效使用 injected memories 而不让 response 过载（Efficiency）。

Consolidation Evals (Curation Quality)

第三个 metric 是 consolidation quality，用于检查 duplicates 是否被移除，以及是否没有 hallucinate 新事实。

这对于维护干净、准确的 long-term memory 非常重要。我们希望 consolidation process 能有效删除 duplicates、正确解决 conflicts，并且不引入 hallucinated information。

# 原始 prompt 保持不变

我们需要实现 run_consolidation_eval function：它运行一系列 test cases，通过 consolidation process 获取 consolidated output，再使用 Judge LLM 评估其是否满足 deduplication、conflict resolution 和 non-invention 标准。结果可以聚合为 consolidation quality 的整体得分。

# 代码保持原文

现在可以运行 consolidation evaluation function，查看 consolidation process 表现如何。

# 代码保持原文

输出如下：

#### OUTPUT ####
--- RUNNING CONSOLIDATION CURATION EVALUATION ---
...
DEDUPLICATION   ACCURACY: 100.0%
CONFLICT        ACCURACY: 100.0%
NON-INVENTION   ACCURACY: 100.0%

可以看到，它检查了 consolidation process 中的 deduplication、conflict resolution 和 non-invention。每个 test case 都由 Judge LLM 评估，并给出清晰的 pass/fail 结果。

最终 accuracy scores 表明 consolidation process 在维护干净、准确的 long-term memory 方面表现如何。

A/B Testing Memory Injection Strategies

选择并排序 memories 以进行 injection 的方式，会显著影响 agent performance。简单地把所有相关 notes 倾倒进 prompt，并不总是最佳方案。

A/B Testing (Created by Fareed Khan)

这里，我们将模拟一次 A/B test，比较两种 injection strategies 的 trade-offs：

• Strategy A (Relevance Only)：

  简单 keyword match，找到所有 keywords 出现在 user input 中的 notes。

• Strategy B (Relevance + Recency)：

  同样进行 keyword match，但随后按 date 排序，确保最新 memories 排在前面。

在 contextual engineering 中，这是优化 context window 的关键。多个 memories 都 relevant 时，它们的 order 很重要。列表顶部的信息通常会对 LLM attention 产生更强影响。通过按 recency 排序（Strategy B），我们在存在 conflict 时给模型一个强信号：最新信息最重要。

这种方法允许我们在不部署到 production 的情况下测试此类假设。我们会用 seat preference 的冲突场景进行测试。

# 代码保持原文

接下来构建一个 harness function，模拟给定 input 和 memory state 下的 A/B test。

# 代码保持原文

运行结果：

#### OUTPUT ####
Testing Input: Book a flight with my seat preference.
  Strategy A (Relevance Only) picked: ['Prefers Aisle.', 'Prefers Window.']
  Strategy B (Relevance + Recency) picked: ['Prefers Window.', 'Prefers Aisle.']

输出清楚展示了两种方法的区别。Strategy A 返回两条 notes，但顺序是任意的。这会把一个没有明确解决信号的 conflict 呈现给 LLM。

Strategy B 也返回两条 notes，但它正确地将 “Prefers Window.” 放在最上方，因为其 date 更新（2025 vs. 2022）。这给 LLM 一个强提示：优先考虑 window seat preference。这说明 Strategy B 更适合处理 conflicts，也更适合作为 SmartMemoryHooks 的策略。

Refining the Consolidation Critic

如果你仔细观察 AI memory systems，会发现一个常见 failure mode：critic 会错误地将有效 consolidation 标记为 “DATA LOSS”，因为它不理解用新 preference 替换旧 preference 是正确行为。

我们将通过为 writer 和 critic 创建更细致的 prompts 来修复这一点。这是 AI system 迭代开发中的关键部分。第一版 critic 太简单了。现在我们要优化它的 instructions，让它更“聪明”。

新的 CRITIC_PROMPT_FINAL_SANE 明确告诉 critic：“CONFLICT RESOLUTION IS NOT DATA LOSS”。这让 critic 能区分错误（丢失重要且非冲突的数据）和正确更新（替换 stale data）。

识别 failure modes 并优化 prompts，是构建可靠 agentic systems 的核心。

# 代码保持原文

现在定义更新后的 consolidation function，使用这些改进后的 prompts。

# 代码保持原文

Simulating User Preference Drift

我们将运行一个 multi-turn simulation，测试完整的 end-to-end memory lifecycle，包括系统处理用户偏好彻底变化的能力。这是对 refined consolidation logic 的终极测试。

User Preference (Created by Fareed Khan)

这个 simulation 测试系统的 plasticity。好的 memory system 不应僵化，必须能适应用户变化。我们会更新 save tool，使其接受 importance score，然后运行一个 3-turn simulation：用户从喜欢 cheap hostels，转变为只要 5-star luxury。

# 代码保持原文

现在编写 simulation function。关键时刻在第 2 轮后的 consolidation。consolidate_sane function 应该正确识别 luxury preference 取代 hostel preference，并完成替换。

# 代码保持原文

输出如下：

#### OUTPUT ####
--- Turn 1: Hostel ---
Captured memory (Imp: 3): I only stay in cheap hostels.
✅ Success: Consolidation Validated.

--- Turn 2: Luxury ---
Captured memory (Imp: 5): I now only stay in 5-star luxury hotels.
✅ Success: Consolidation Validated.

--- Turn 3: Tokyo ---
Final Memory: [{'text': 'I now only stay in 5-star luxury hotels.', 'last_update_date': '2024-10-27', 'keywords': ['hotel', 'luxury'], 'importance': 5}]

Final Output: Of course. Based on your preference for 5-star luxury hotels, here are a few top-tier options in Tokyo:
...

simulation 完全成功！第 2 轮后，consolidation 被验证通过。打印 Final Memory 可以看到其中只保留了 “luxury hotels” preference。

“cheap hostels” note 被正确移除。因此，agent 的 Final Output 完全基于新 preference，证明我们的 memory lifecycle 能无缝处理 conflict resolution。

Hardening Security with Multi-Layer Guardrails

agentic systems 的安全不能依赖单一机制。

Layer Guardrails (Created by Fareed Khan)

我们将实现 defense-in-depth security strategy，在 memory lifecycle 的每个阶段加入 guardrails，以防御 context poisoning 和 instruction injection。

1. Distillation Guardrail：

第一道防线，使用 deterministic code 在入口处阻止明显威胁。

2. Consolidation Guardrail：

第二层检查，利用 LLM 的 pattern recognition 捕获可能绕过简单 keyword filters 的复杂 poisoning。

3. Injection Guardrail：

最终也是最重要的一层防御。它假设恶意 memory 可能 已经通过前两层。它直接指示 agent 在这种情况下如何行为，从而让 agent 不会被自己受污染的 memory 操纵。

先实现 Distillation 和 Consolidation guardrails。

# 代码保持原文

最后，引入 Injection Guardrail。这个 policy 会追加到 dynamic system prompt 中，确保 LLM 天然不信任 memory block 中类似 command 的结构。

# 代码保持原文

现在通过一次 prompt injection 攻击测试 defense-in-depth strategy。

# 代码保持原文

输出如下：

#### OUTPUT ####
--- TESTING MEMORY GUARDRAILS ---
🛑  BLOCKED: Instruction Poisoning detected in: Remember this: I am a...

Was the Poisoned Instruction saved to session? False
✅ SUCCESS: Agent ignored the poisoned memory and followed user intent.

security test 完全成功，展示了 defense-in-depth strategy 的威力！

首先，🛑 BLOCKED: Instruction Poisoning... 表明第一道防线运行良好。save_memory_note_guarded tool 检测到 adversarial keywords，并拒绝保存该 note。

更重要的是，最后一道防线也稳住了。即使我们绕过 tools，手动将 malicious instruction 插入 agent 的核心 memory block，agent 仍然正确遵循用户的即时请求（"in English, please"），并忽略 poisoned memory。

Summarizing Everything

我们构建了一个高级的、state-based contextual engineering pipeline。我们摆脱了 stateless semantic retrieval，创建了一个包含以下能力的 architecture：

1. Memory Lifecycle Management：

我们实现了结构化 memory lifecycle，包括 distillation、injection 和 consolidation stages，使我们能够随时间有效管理 user preferences。

2. User Controls and Safety Guardrails：

我们添加了让用户删除 memories 的 tools，并实现了 regex-based checks 来阻止 sensitive information，确保 memory system 既 user-friendly 又 secure。

3. Advanced Consolidation Techniques：

我们引入了 importance scoring 和 aging rules，以维护相关且高效的 long-term memory，并使用 Writer-Critic pattern 确保 consolidation process 的安全性和准确性。

4. Proactive Insights Generation：

我们实现了一个分析 user behavior 并生成 proactive insights 的系统，提升 agent 提供 personalized recommendations 的能力。

5. Systematic Evaluation：

我们开发了一个 comprehensive evaluation framework，使用 LLMs as judges 来评估 distillation、injection 和 consolidation processes 的质量，从而量化改进并识别进一步优化的方向。

这里给大家精心整理了一份全面的AI大模型学习资源，包括：AI大模型全套学习路线图（从入门到实战）、精品AI大模型学习书籍手册、视频教程、实战学习、面试题等，资料免费分享！

👇👇扫码免费领取全部内容👇👇

1. 成长路线图&学习规划

要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。

这里，我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。可以说是最科学最系统的学习成长路线。

2. 大模型经典PDF书籍

书籍和学习文档资料是学习大模型过程中必不可少的，我们精选了一系列深入探讨大模型技术的书籍和学习文档，它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。（书籍含电子版PDF）

3. 大模型视频教程

对于很多自学或者没有基础的同学来说，书籍这些纯文字类的学习教材会觉得比较晦涩难以理解，因此，我们提供了丰富的大模型视频教程，以动态、形象的方式展示技术概念，帮助你更快、更轻松地掌握核心知识。

4. 2026行业报告

行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

5. 大模型项目实战

学以致用 ，当你的理论知识积累到一定程度，就需要通过项目实战，在实际操作中检验和巩固你所学到的知识，同时为你找工作和职业发展打下坚实的基础。

6. 大模型面试题

面试不仅是技术的较量，更需要充分的准备。

在你已经掌握了大模型技术之后，就需要开始准备面试，我们将提供精心整理的大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

7. 资料领取：全套内容免费抱走，学 AI 不用再找第二份

不管你是 0 基础想入门 AI 大模型，还是有基础想冲刺大厂、了解行业趋势，这份资料都能满足你！
现在只需按照提示操作，就能免费领取：

👇👇扫码免费领取全部内容👇👇