Multi-tenant Agent Memory Service

多租户、多用户、多业务的 memory service 抽象，关注写入、更新、冲突、权限和业务适配。

Context#

我做过一些 Agent Memory Service 的设计和实现尝试。它面向多租户、多用户、多业务场景，不只是把聊天记录塞进向量库。

我更关心的是：memory 如何被写入、更新、检索、隔离、回收，以及如何和不同业务系统解耦。

Layered memory#

一个比较自然的分层是：

L0: Session Memory#

当前对话、当前任务、工具调用结果、临时状态。它生命周期短，主要保证当前任务上下文连续。

L1: User / Project Memory#

用户偏好、项目背景、历史任务摘要、常用路径、重要决策。它生命周期更长，需要可检索、可更新、可删除。

L2: Business / Domain Memory#

业务知识、组织级工具说明、产品规则、领域文档和可复用 skill。它强调权限、版本、审计和跨业务复用。

Design concerns#

Memory 服务最难的地方不是 search API，而是治理。

一些具体问题包括：

• 什么信息值得写入？
• 什么时候应该摘要？
• 新旧记忆冲突怎么办？
• 错误记忆如何避免污染后续决策？
• 不同租户和业务如何隔离？
• 用户是否能看到和编辑自己的记忆？
• memory 如何与工具、代码仓库和项目上下文结合？
• 如何评估 memory 真的帮到了 Agent？

Architecture idea#

我更倾向于把 Memory Service 拆成几层：

• Memory Core：负责统一写入、检索、更新、删除和摘要；
• Business Adapter：负责对接不同业务；
• Backend Adapter：负责接入不同 memory engine；
• API Layer：对外暴露简单的 search / write / update / delete 接口。

这样做的目标是让 memory 能服务不同产品，而不是绑定在某一个聊天场景里。

What I learned#

Memory 是 Agent 产品里非常容易被高估、也非常容易被低估的模块。

说它高估，是因为很多 demo 只是把历史记录召回，看起来就像有记忆。说它低估，是因为真正进入多租户、多业务、多轮任务后，记忆的治理问题会变得非常复杂。

我现在更愿意把 memory 看成一种需要长期治理的数据系统，而不是一个简单的 RAG 子模块。