在前四篇文章里我们已经完成了基础骨架、操作程序、Token费用大幅降低还有双手装载。老实说，

但如果你的 Agent 每次都会忘记上一轮对话、三天前搜索过的知识又得重新搜集、每次都要重述使用者偏好与项目背景——这不是模型的问题。而是缺少一个健全的记忆程序。其实，

使用者痛点

• 上一轮对话里告诉它的信息下一轮立刻清零。
• 三天前搜索过的知识今天又要重新来一遍。
• 使用者偏好、项目背景每次都得从头解释。
• 像金鱼一样只有7秒记忆。

这些痛点往往导致：

• Token 成本飙升
• 响应速度下降
• 注意力稀释。主要信息被淹没

一、Agent 记忆的三个层次

人脑记忆不是单层，而是分层结构。Agent 的记忆一样需要分层，以避免一次性塞入大量信息导致 Token 与性能问题。

为什么需要分层？

1. Token 成本爆炸：10万条对话可能产生数百万 tokens，导致每轮对话费用高昂。
2. 速度急剧下降：上下文越大推理越慢，影响实时交互体验。
3. 注意力稀释：信息过多时模型抓不到主要。

主要思想的观点是。当前任务用上下文，近期对话缓存起来长期知识存向量库检索。

二、第一层：上下文记忆

This is most basic form—just push all conversation history into messages array.

# 最基本的内存形式——每次把历史全塞进去
class NaiveMemory:
def __init__:
self.messages =
self.max_tokens = max_tokens or None
def add:
self.messages.append
def get_context -> list:
# 简单截断。不超窗口
total = 0
result =
for msg in reversed:
cost = len // 4 # 粗略估算 token
if total + cost> self.max_tokens:
break
result.insert
total += cost
return result
def clear:
self.messages = 

This works but is too crude—no compression,no layering,no persistence.

三、第二层：短期记忆——带摘要的对话历史

设计思路

• 最近 N 层保留完整原文；更早的压缩为结构化摘要，
• 摘要定期更新——不是一次性压缩就不管了。

实现代码示例

import json
class ShortTermMemory:
def __init__:
self.recent = # 最近 N 层完整对话
self.summary = "" # 更早对话的摘要
self.decisions = # 关键决策记录
self.max_recent = max_recent
self.max_summary = max_summary_tokens
def add_turn:
self.recent.append({
至于"user"，user_msg。"assistant": assistant_msg
})
# 超过阈值时把最老的一轮并入摘要
if len> self.max_recent:
oldest = self.recent.pop
self._merge_to_summary
def record_decision:
self.decisions.append
def _merge_to_summary:
snippet = f"}... | Agent：{turn}...]"
new_sum =
self.summary = new_sum
def get_memory_context -> str:
parts =
if self.decisions:
parts.append)
if self.summary:
parts.append
if self.recent:
parts.append} 层对话
" +
"
".join(f"Q:{t}
A:{t}"
for t in reversed))
return "
".join

关键设计点回顾

• 决策记录："我们决定用 Redis 而不是 MySQL" 等关键信息需单独存档。
• 累积式摘要：Aggressive summarization each time LLM runs would consume Token; instead incrementally append snippets when message drops out.
• CUT OFF 防止膨胀：S滑动窗口限制最大长度，保证摘要不会无限增长。话说回来，
• User Preference 与 Project Background 在短期内可保留。但长久存储需归档至长期记忆。不过，
• User Pain Point即使短期记忆能保持半小时的信息。也无法解决几天前的讨论和长期偏好忘却的问题。
• Solution引入第三层长期向量检索，以解决“时间跨度长”的痛点。

痛点聚焦：如何让 Agent 在“七秒后”还能回想起“昨天讨论过的关键决策”？按理说，答案在于长期向量检索！

四、第三层：长期记忆——向量检索技术细节

什么该进长期记忆？筛选标准 & 示例代码实现

筛选准则

关键词检测： “偏好”“决定”“配置”“项目”“架构”“技术栈”等词出现即视为关键。

时间戳优先级： 对新旧冲突做优先级判断，用最新覆盖旧记录；如发现冲突则标注冲突日志。

TTL/衰减： 信息随时间衰减或到期自动失效，以防旧数据误导模型。

主动删除： 使用者说“别再提那个方案”，Agent 能主动删除对应条目。

向量检索实现代码示例

# 简易向量数据库演示。仅用于说明流程，不建议直接生产使用。import numpy as np
from openai import OpenAI
client=OpenAI
class LongTermMemory:
def __init__:
self.memories= # 用列表模拟向量 DB
self.embed_model="text-embedding-ada-002"
def embed->list:
resp=client.embeddings.create(
model=self.embed_model,input=text)
return resp.data.embedding
def cosine_sim->float:
a=np.array;b=np.array
return np.dot/*np.linalg.norm)
def store_if_important:
keywords=
if any:
vec=self.embed
mem={'content':text,'vector':vec,'timestamp':__import__.time}
self.memories.append
def search->list:
qvec=self.embed
scored=
scored.sort
return ]
# 用法示例：
lt_mem=LongTermMemory
lt_mem.store_if_important
results=lt_mem.search
print

典型检索场景举例

# 从长期记忆中检索相关条目
results=lt_memory.search

context=" ".join( {m}" for i。m in enumerate])

task_msg=f"""## 长期记忆 {context}

当前任务

请根据以上记忆中的技术栈和之前调整记录，为搜索接口性能提供改进建议。”"""，echo $task_msg\end{lstlisting}

User Pain Point Recap:

“Your previous decisions and preferences vanish after a few hours – frustrating!不过，”.

“The system spends huge tokens on repeated context each session.”.

Hello!🚀 Ready to build an Agent that actually remembers?怎么说呢，

The solution?Layered memory architecture – short‑term cache + long‑term vector store.

I’ll walk you through how to design this architecture step by step – from simple caching to full‑blown vector DB integration.

---