凌晨两点，你让个人助理Agent查找三个月前会议中提到的技术方案，它却只记得最近三条对话。这不是Bug，而是大模型上下文窗口的物理极限——GPT-4的128K上下文看似庞大，但塞入全天工作日志后，旧信息会被新Token的注意力淹没，更别提昂贵的Token账单。
AWS在2025年发布的Agentic AI基础设施实践系列中明确指出，解决“遗忘”问题的关键是构建短期工作记忆与长期语义记忆的分层架构。2026年，记忆模块已从Agent的“选配”变成“标配”。我在开发一个“小度”型个人助理项目时，踩遍了记忆管理的坑，最终落地了一套可复用的方案。
短期工作记忆：用Redis扛住上下文窗口
短期记忆存储当前会话的热数据：对话历史、临时变量、未完成任务。核心要求是快——写入延迟<10ms，读取延迟<1ms，并且能自动将旧记录归档到长期记忆。
我选Redis作为存储引擎，设置TTL为30分钟的List，每次用户发消息就把对话（包括Agent内部思考链）push进去。当List长度超过50条时，触发归档：用LLM总结最旧的20条，写入向量库，然后从List移除。
import redis, json
r = redis.Redis(host='localhost', port=6379, db=0)
def store_short_term(session_id, message):
key = f"session:{session_id}"
r.lpush(key, json.dumps(message))
r.expire(key, 1800) # 30分钟
if r.llen(key) > 50:
archive_oldest(session_id)
实测连续2小时助手交互，单轮Prompt大小稳定在3K Token以内，而无记忆方案会膨胀到15K+。
长期语义记忆：向量数据库+时间戳
长期记忆存储跨会话信息：用户偏好、关键事实、项目里程碑。我选用Qdrant（2026年社区最活跃的向量库之一），每条记录除了原始文本和Embedding，必须带上时间戳、来源会话ID、衰减权重。
时间戳有两个角色：一是检索排序依据——当问“上个月的第二版方案”时，先按语义召回，再按时间戳取2026年6月的片段；二是实现衰减——超过30天的记忆标记为低优先级，检索时乘以0.5的权重因子，让系统更关注近期信息。53AI的一篇文章也指出，向量数据库处理对话记忆游刃有余，但在复杂任务状态追踪上会遇到稀疏性问题。因此我额外用PostgreSQL存任务结构化状态（如“报销审批进行到第二步”），通过会话ID关联。
from qdrant_client import QdrantClient, models
import time
client = QdrantClient("localhost", port=6333)
def store_memory(session_id, text, metadata):
embedding = embed(text) # text-embedding-3-small
point = models.PointStruct(
id=str(uuid.uuid4()),
vector=embedding,
payload={
"text": text,
"timestamp": int(time.time() * 1000), # 毫秒级
"session_id": session_id,
"decay_weight": 1.0,
**metadata
}
)
client.upsert("memories", [point])
记忆检索：相关性+时间衰减+重要性
检索分三步：
- 向量召回：用问题Embedding在Qdrant找top-20。
- 时间衰减重排序：
score = cosine_sim * (0.5 ** max(0, days_since_creation / 30)) * decay_weight。30天前衰减到0.25，180天前几乎归零。 - 重要性提权：用户标记“重要”的事件（decay_weight=2.0）或被多次引用的信息，排名更高。
最终取top-5送入LLM。这种策略让助理回答“我端午节在哪家餐厅请的客户”时，能精确命中6月10日的日志。
踩过的坑
第一个是Token预算。不加限制塞原始对话，一周300万Token。解决：先总结再存——用GPT-4o-mini把对话概括成50 Token，存储和检索都用这个，详细文本备选。成本下降80%，准确率反而提升。
第二个是时间戳精度。之前用秒级Unix时间戳，一天内多轮对话无法区分先后。改成毫秒级，确保唯一排序。
第三个是记忆漂移——Agent错误解读后写入错误信息。参考《Agent误操作导致资金损失》（内链）的人机确认机制，在所有写入前加“事实核查”钩子：用一个独立验证模型（如Qwen3-8B）判断与现有信息是否冲突，冲突则标记“存疑”并延迟写入。
持久运行的Token账本
《连续干跑7小时不崩》（内链）展示了冷热分层的收益。我的系统上线一周，Agent每天处理约200轮对话，短期记忆只在Redis保持30分钟，长期记忆日均新增150条（每条压缩后约100 Token），月累计写入不到500K Token。若不用记忆系统，单日累计上下文消耗超1M Token。按2026年主流API价格，月成本从$1500降到$400。
框架取舍
项目初期试过Mem0，开箱即用，但时间戳衰减硬编码，且所有记忆都走向量库，对短期数据延迟偏高。最终用Qdrant+Redis+PostgreSQL自建，配合LangGraph编排。想要省事可关注AWS Bedrock Agent Memory托管方案，但定制空间小。《拒绝重复造轮子》（内链）中提到的Dify最近加了记忆模块，但更偏对话日志回放，没有时间戳衰减。
选择哪种取决于场景：纯聊天托管足够；多任务规划自建仍是正解。《架构师发来警告》（内链）已经指出“Token不经济”时代已来，盲目堆上下文是死路。好的记忆系统，就是用廉价存储和巧妙检索，替代昂贵且有限的上下文窗口。你的Agent能记住多久，取决于你给它盖了多大、多智能的房子。
