一、Agent 为什么需要记忆？

没有记忆的 Agent，很像一个“每次见面都重新认识你”的助手。你今天告诉它代码风格要简洁，明天再让它写脚本，它可能又回到默认风格。原因不是模型不聪明，而是它没有把关键偏好沉淀下来。

所以，Agent 记忆不是把所有聊天记录无限塞进 Prompt，而是把“当前任务状态”和“跨任务经验”分开管理：短期记忆负责当下任务不断片，长期记忆负责跨会话持续积累。

短期记忆与长期记忆的职责边界

二、一句话回答面试官

短期记忆通常存在当前会话的 messages、session 或 checkpoint 里，用来保存用户输入、模型输出、工具结果和任务中间状态；长期记忆通常存在持久化存储里，常见做法是“原文 + embedding + metadata”写入向量库，同时用 SQL/KV/图数据库保存权限、时间、版本、实体关系等结构化信息。

记忆粒度不能太细，也不能太粗。比较合理的是按“独立知识点”“关键事件”“一次完整交互摘要”来存。读取时也不能只拿向量 TopK，最好结合元数据过滤、时间衰减、重要度排序和重排。

三、短期记忆：LLM 当前任务的工作台

短期记忆最常见的形态，就是每次调用模型时传入的 messages 列表。它里面有用户的问题、模型刚才说了什么、调用工具得到了什么结果、当前任务进行到哪一步。

你可以把它理解成一张工作台：东西放在台面上，模型就看得见；台面太乱、太满，模型就容易被旧信息干扰，成本也会越来越高。

from dataclasses import dataclass, field

from typing import Literal

Role = Literal["system", "user", "assistant", "tool"]

@dataclass

class ShortTermMemory:

"""当前会话的工作台：只服务于当前任务。"""

messages: list[dict] = field(default_factory=list)

def add(self, role: Role, content: str):

self.messages.append({"role": role, "content": content})

def get_context(self) -> list[dict]:

return self.messages

def trim(self, max_turns: int = 12):

"""保留最近若干轮，避免上下文无限增长。"""

self.messages = self.messages[-max_turns:]

在生产环境里，短期记忆通常还会加上“断点恢复”。比如 Agent 调用工具失败了、任务暂停了、用户刷新页面了，下次还能从 checkpoint 恢复，而不是从头来一遍。

四、长期记忆：跨会话的档案库

长期记忆存的不是所有聊天流水，而是未来还可能有价值的信息。例如用户偏好、项目背景、历史决策、常用流程、失败经验、实体关系。

这类记忆必须能被检索、能被更新、能被删除、能被审计。只说“存在数据库里”是不够的，真正要回答的是：存什么字段？怎么召回？怎么过滤权限？怎么处理旧记忆和新记忆冲突？

生产级 Memory Service 架构

五、记忆存储的完整闭环

一条记忆从产生到被使用，大致会经历八步：捕获、提取、结构化、向量化、存储、检索、注入、更新/遗忘。

这里最容易出错的是“只写不管”。如果只要用户说一句话就写入长期记忆，记忆库会很快变成垃圾堆。正确做法是先判断这条信息是否值得长期保存，再决定写入粒度、类型和有效期。

记忆写入与读取闭环

六、长期记忆到底存在哪？

向量数据库很重要，但它不是全部。向量库解决的是“语义相似召回”，不是权限管理、事务一致性、版本管理、原始日志归档和实体关系推理。

工程里更常见的是多存储组合：Redis 存热会话，Postgres 存结构化元数据，Vector DB 存语义索引，Elasticsearch 做关键词和混合检索，Graph DB 存实体关系，对象存储保留原始材料。

不同存储在记忆系统中的位置

七、一条长期记忆应该怎么设计？

长期记忆的核心不是 content 字段，而是 content、embedding、metadata、namespace、version、score、status 的组合。

content 是真正给 LLM 看的内容；embedding 是语义索引；metadata 负责过滤；namespace 负责隔离；version 和 status 负责更新、失效和删除。

MemoryRecord 数据模型

from dataclasses import dataclass

from typing import Literal, Optional

from datetime import datetime

MemoryType = Literal["semantic", "episodic", "procedural"]

MemoryStatus = Literal["active", "expired", "deleted"]

@dataclass

class MemoryRecord:

id: str

namespace: tuple[str, ...] # 例：("user_123", "coding")

type: MemoryType # 语义 / 情节 / 程序记忆

content: str # 给 LLM 注入的短文本

metadata: dict # source、tags、scope、created_at

embedding: Optional[list[float]] = None

importance: float = 0.5

confidence: float = 0.8

status: MemoryStatus = "active"

created_at: datetime = datetime.utcnow()

updated_at: datetime = datetime.utcnow()

八、记忆粒度：不要一句话一条，也不要一整场对话一条

粒度太细，检索时容易只命中碎片，LLM 拿不到完整背景。粒度太粗，检索命中了也会带入大量无关内容，浪费上下文，还会干扰回答。

更推荐的粒度，是“一个独立知识点”或“一个关键事件”。比如“用户偏好 Python、代码简洁、变量英文、注释英文”应该合并成一条偏好记忆，而不是拆成四条。

九、长期记忆怎么写入？

写入长期记忆之前，先做一个判断：这条信息以后还会不会影响 Agent 的行为？如果不会，就不要存。

真正可用的写入链路通常是：原始对话 -> 记忆候选 -> 重要性评分 -> 去重/冲突检测 -> 向量化 -> 写入存储 -> 记录审计日志。

def should_write_memory(candidate: dict) -> bool:

"""判断是否值得进入长期记忆。"""

if candidate["type"] not in {"semantic", "episodic", "procedural"}:

return False

if candidate.get("importance", 0) < 0.6:

return False

if candidate.get("contains_sensitive_data") and not candidate.get("user_allowed"):

return False

return True

async def save_memory(memory_store, embedder, record: MemoryRecord):

if not should_write_memory(record.metadata):

return None

# 1. 生成向量

record.embedding = await embedder.embed(record.content)

# 2. 用 namespace 做租户/用户/项目隔离

# 3. content 用于注入 Prompt，embedding 用于语义召回，metadata 用于过滤和审计

await memory_store.put(

namespace=record.namespace,

key=record.id,

value={

"content": record.content,

"type": record.type,

"metadata": record.metadata,

"importance": record.importance,

"confidence": record.confidence,

"status": record.status,

},

embedding=record.embedding,

)

return record.id

十、长期记忆怎么读取？

读取记忆时，千万不要简单地“向量 TopK 拿回来直接塞 Prompt”。这样很容易召回过期记忆、无权限记忆、低质量记忆。

更稳的方式是混合召回：先用 namespace 和 metadata 做过滤，再用向量检索找语义相似，再结合关键词检索补充精确匹配，最后按时间新鲜度、重要度、可信度做重排。

def rank_memory(semantic_score: float,

freshness: float,

importance: float,

confidence: float) -> float:

"""记忆排序公式：不要只看语义相似度。"""

return (

semantic_score * 0.55 +

freshness * 0.20 +

importance * 0.15 +

confidence * 0.10

)

async def retrieve_memories(memory_store, query: str, user_id: str, top_k: int = 5):

query_vec = await embedder.embed(query)

candidates = await memory_store.search(

namespace=(user_id, "global"),

embedding=query_vec,

filters={"status": "active"},

limit=30,

)

reranked = sorted(

candidates,

key=lambda m: rank_memory(

semantic_score=m.score,

freshness=m.metadata["freshness"],

importance=m.metadata["importance"],

confidence=m.metadata["confidence"],

),

reverse=True,

)

return reranked[:top_k]

十一、更新与遗忘：长期记忆不是越多越好

用户偏好会变，项目状态会变，业务规则会变。如果长期记忆只追加不更新，时间久了反而会误导 Agent。

比较好的做法是：原始日志 append-only 保留用于审计；当前有效画像做可更新记录；旧记忆可以降权、过期、合并或标记删除。这样既保留历史，又不让旧信息污染当前决策。

时间衰减、冲突检测与记忆合并

十二、安全治理：记忆越强，越要守边界

长期记忆会保存用户偏好、工作习惯、项目背景，甚至可能涉及敏感信息。只要跨会话保存，就必须设计用户可见、可改、可删的机制。

另外，检索出来的记忆不能直接当成最高优先级指令。记忆只是上下文，不应该覆盖系统安全策略，也不应该被用户通过 Prompt 注入污染。

十三、一个更完整的 Agent 记忆执行流程

把上面的设计串起来，一个任务开始时先读取长期记忆，压缩后注入 Prompt；任务执行中靠短期记忆维持状态；任务完成后，再把真正有价值的新结论写入长期记忆。

async def run_agent_with_memory(user_id: str, user_request: str):

# 1. 读取长期记忆：只拿当前用户、当前任务相关的内容

memories = await retrieve_memories(memory_store, user_request, user_id, top_k=5)

memory_context = "\n".join([m.content for m in memories])

# 2. 初始化短期记忆：把相关长期记忆作为背景，而不是把所有历史塞进去

stm = ShortTermMemory()

stm.add("system", f"以下是与本次任务相关的历史记忆：\n{memory_context}")

stm.add("user", user_request)

# 3. Agent 执行任务：过程中持续追加工具结果和中间状态

result = await agent.run(stm.get_context())

stm.add("assistant", result.answer)

# 4. 任务结束：抽取真正值得长期保存的信息

candidates = await memory_extractor.extract(stm.get_context())

for candidate in candidates:

record = MemoryRecord(**candidate)

await save_memory(memory_store, embedder, record)

return result.answer

十四、常见踩坑

把长期记忆理解成“SQL LIKE 查询”：关键词不重合时召回不到，必须引入 embedding 或混合检索。

把每句话都存成一条记忆：召回时拿到碎片，LLM 不知道完整偏好。

把整场对话存成一条记忆：内容太长，注入 Prompt 后噪音大。

只写入不更新：用户偏好变化后，旧记忆仍然被召回。

没有 namespace：不同用户、项目、组织之间的记忆可能串库。

没有审计和删除：用户不知道系统记住了什么，也无法撤回。

十五、总结

Agent 记忆系统，本质不是“多存点聊天记录”，而是一个可治理的数据系统。

短期记忆像工作台，服务当前任务；长期记忆像档案库，服务跨会话积累。短期记忆重点是压缩和恢复，长期记忆重点是粒度、检索、更新和权限。

真正能上线的方案，一定不是单一向量库，而是 Memory Service + 多存储组合：向量库负责语义召回，SQL/KV 负责结构化管理，搜索引擎补关键词，图数据库补实体关系，对象存储保留原始证据。