模型本身是无状态的。

这一次调用和下一次调用之间，模型不会自动记住你之前说过什么。它看起来“有记忆”，通常是因为 Agent 在每次调用模型前。把历史消息重新组织成上下文发给了模型。

图里的关键点是：Agent 一直在收集使用者消息、模型回复、工具结果，接下来把这些消息组成队列。模型每次回答时看到的是这次传进去的完整上下文，而不是它自己真的保存了记忆。

先记住一句话的观点是。Agent 的 Memory 本质上是消息管理，不是模型真的拥有记忆。不过，

为什么需要 Memory

如果你连续问两句话：

使用者：我叫张三。使用者这方面，我叫什么，

第二次调用模型时如果你只发送“我叫什么？按理说，”，模型并不知道“张三”这个信息。

要让模型回答出来就必须把前面的消息一起发过去：

HumanMessage
AIMessage
HumanMessage

Memory 要解决两个问题：

• 历史消息存在哪里。
• 每次调用模型时应该带上哪些历史消息。

最简单的消息历史

最基础的 Memory 就是一个列表。

from langchain_core.messages import AIMessage,HumanMessage。SystemMessage
messages =
def chat -> str:
# 把本轮使用者输入追加到消息列表
messages.append)
# 把完整 messages 发给模型
response = model.invoke
# 把模型回复也存下来供下一轮使用
messages.append
return str
chat
chat

这就是最小可用的短期记忆。

痛点提醒：如果不做持久化，你会发现程序重启后对话被清空；因为对话增多，记录会超出；所有历史都塞给模型会导致成本飙升。

优点与缺点

• 再看优点。实现简单，易于调试，
• 缺点的观点是，
  • 进程结束后就丢失。
  • 消息越来越多，迟早超过模型。
  • 所有历史都塞给模型，成本会越来越高。

持久化消息历史

如果希望重启程序后还能继续对话，就需要把消息保存到外部存储。

常见存储方案

• 文件程序：- 适合本地工具和单机应用，但在多实例部署下容易出现冲突与同步问题。
• Redis：- 适合临时会话和分布式服务。但需要额外部署 Redis 集群，而且不支持持久查询语义相似度。
• 数据库：- 能长期保存并支持复杂查询，但往往需要额外设计模式与索引来满足性能需求。
• 向量数据库：- 可以按语义检索相关历史。功能比较强，但成本较高且实现更复杂。

至于示例，将聊天记录写入 JSON 文件

import json
from pathlib import Path
from typing import Literal,TypedDict
from langchain_core.messages import AIMessage,HumanMessage,SystemMessage
history_file = Path
class StoredMessage:
至于role，Literal
content: str
def load_history -> list:
至于try，return json.loads)
except FileNotFoundError:
return
def save_history -> None:
history_file.write_text(
json.dumps。encoding="utf-8",)
def to_langchain_messages:
result =
for message in history:
if message == "human":
result.append)
再看else，result.append)
return result
def chat -> str:
# 加载历史消息
history = load_history
# 添加本轮人类输入
history.append
# 组装最终上下文
messages =
response = model.invoke
# 保存机器人的回复到历史
.history.append})
.save_history
.return str

为什么不能一直追加?说起来，

至于因为。

• "超过上下文长度": 模型一次只能处理有限数量的 token，一旦超出就会报错或截断关键信息；
• "token 成本越来越高": 每增加一条旧记录，就要为其 token 支付费用；
• "无关信息干扰当前回答": 长期对话中很多早期细节已不再关键。却仍占据宝贵位置，让答案偏离主题。

常见 Memory 策略

• 截断策略 : 只保留最近 N 条或最近 M 个 token 的信息。例如保留最近 10 条对话或最近 2000 tokens。这样能保证最新语境始终被考虑，同时控制成本。
• 关键性排序 : 给每条记录打分，只挑选分数最高的一部分进入当前上下文。这种方法更智能，却需要额外逻辑来评估“关键”。
• 主题聚合 : 将相似主题的多条记录压缩成一条摘要，再加入当前上下文。这既能减少 token 数，又能保持主题连贯性。是面向大型 LLM 的高级做法。

与行动建议

• 若你的项目刚起步先用文件持久化 + 简单截断即可满足需求；关注进程重启后的数据丢失和 token 成本提高两大痛点。怎么说呢，

以上方案可根据实际业务场景组合使用，以平衡性能、成本和可维护性。