系列：AI Agent 工程实践
上一篇：第 24 篇《Tool Registry》
下一篇：第 26 篇《Prompt Management》

一、开场：重启一次，记忆全没

一个客服 Agent，记住了老客户的偏好和历史工单，聊得越来越顺。某天服务重启（部署、崩溃、扩容），记忆全在进程内存里，restart 后变成"失忆新人"，老客户一上来就炸毛："你昨天不是都知道吗？"

问题：Memory 被当成了 Agent 的"内部状态"，而不是"独立服务"。上篇（24）讲了工具收口，这篇讲记忆收口——Memory Service。

二、问题背景：内联记忆 vs 独立服务

内联版（Demo）：

class Agent:
    def __init__(self):
        self.memory = []   # 进程内存，重启即丢
    def chat(self, msg):
        self.memory.append(msg)
        return llm(self.memory)

独立版（生产）：

from memory.service import MemoryService
mem = MemoryService()            # 背后是 Redis/Qdrant/...
mem.remember(session_id, msg)    # 落外部存储
history = mem.recall(session_id) # 重启也不丢

差别：记忆活在"服务"里，不在"进程"里。Agent 挂了，记忆还在。

三、错误尝试：三种记忆翻车

错误 1：记忆存在进程内存

如开场。重启 / 扩容 / 崩溃 = 全员失忆，且每次扩容新实例都没有历史。

错误 2：记忆和 Agent 强耦合

# agent.py 里直接写 SQLite 连接
def chat(self, msg):
    self.db.execute("INSERT ...", msg)   # 换存储要改 agent

Agent 本该只管"推理"，却背上了"存储实现"。换 Qdrant 做语义检索，得改 Agent——违背（22）的依赖单向（下层反向被上层持有）。

错误 3：不分短期 / 长期

把"当前对话的临时草稿"和"用户三年的偏好"塞进同一个 list。短期要快、长期要检索，混在一起两头的优化都做不了。

四、关键观察：Memory 属于系统，不属于 Agent

抽象原则：

1. Memory 是独立服务：Agent 通过接口读写，不碰存储实现。换 backend 不动 Agent。
2. 分短期 / 长期：短期（会话内上下文）要低延迟；长期（跨会话偏好/知识）要可检索、可演进。
3. backend 可替换：根据规模与需求选 Redis / Qdrant / SQLite / Postgres。

记忆是"系统的记忆"，Agent 只是"记忆的使用者"。 这和（24）工具不属于调用方、而属于 Registry 是同一个思想——能力收口成服务，使用方只依赖接口。

五、最终方案：MemoryService 长什么样

memory/
├── service.py        # MemoryService：recall / remember 接口
├── backends/
│   ├── redis.py      # 短期：高速 KV
│   ├── qdrant.py     # 长期：向量语义检索
│   ├── sqlite.py     # 轻量本地持久化
│   └── postgres.py   # 事务 + 关系查询
└── types.py          # ShortTerm / LongTerm 区分

接口：

class MemoryService:
    def remember(self, session, msg, scope="short"|"long"): ...
    def recall(self, session, query=None, scope="short"|"long") -> list: ...

backend 选择表：

存储	适合	不适合
Redis	短期高速、会话上下文	语义检索、持久关系
Qdrant	长期语义检索（"类似过去的投诉"）	简单 KV、事务
SQLite	单机轻量、原型	高并发、分布式
Postgres	事务+关系+持久，企业标配	超大规模向量检索（需扩展）

依赖方向（Mermaid）：

六、设计权衡：怎么选 backend

场景	建议	理由
原型 / 单人	SQLite	零运维
高并发会话上下文	Redis（短期）+ Postgres（长期）	速度+持久
要"语义回忆"	Qdrant 做长期	向量检索是强项
企业事务一致	Postgres	ACID

反过度工程：不要一上来就 Qdrant 集群。先用 SQLite/Redis 跑通，真有语义检索需求再引向量库。

七、总结

• ✅ 记忆在进程内存 = 重启即失忆，真实客诉。
• ✅ 三种翻车：进程内存、与 Agent 耦合、不分短期/长期。
• ✅ 原则：Memory 是独立服务；分短期（低延迟）/长期（可检索）；backend 可替换。
• ✅ backend 选择：Redis 短期、Qdrant 语义长期、SQLite 原型、Postgres 企业。
• ✅ 反过度工程：先 SQLite/Redis 跑通，有语义需求再上向量库。

下一篇，钻进提示词治理 —— 为什么 Prompt 不是 prompt.txt，而是 version / template / variables / A-B Test。（26）

---

参考资料（带用途说明）

• 本系列（24）Tool Registry：本文与（24）同构——能力（工具/记忆）收口成服务，使用方只依赖接口。
• 本系列（22）AI Agent 项目应该如何分层：本文是 memory/ 层的展开。
• 本系列（10）Memory 不只是聊天记录——长期记忆架构设计：本文是（10）"长期记忆"的工程化落地（独立服务+backend 选择）。
• Qdrant 文档（qdrant.tech）：本文向量语义检索 backend 的官方参考。
• Redis 文档（redis.io）：本文短期高速存储 backend 的官方参考。

---

本文是 AI Agent 工程实践系列的第 25 篇（第四阶段第五篇）。

---

系列导航

上一篇：第 24 篇《Tool Registry》
下一篇：第 26 篇《Prompt Management》