项目背景与目标
羽忆要解决的不是某个单独产品“记忆不好用”的问题，而是整个 Agent 生态里长期存在的结构性断层：记忆能力被绑定在具体模型、具体宿主和具体会话里，用户无法真正拥有自己的长期上下文。
这类问题为什么必须单独做一层基础设施
当前主流模型和 Agent 工具几乎都有各自的会话上下文与记忆机制，但这些能力天然存在三个限制：
- 生态孤岛：不同模型厂商、不同宿主之间的记忆不能互通
- 上下文断裂：换工具、换模型、换会话后，过去沉淀的结论往往要重新解释
- 数据黑箱：用户通常无法完整审计、迁移或删除已经被“记住”的内容
如果记忆继续作为产品私有能力存在，用户的知识和偏好就会被锁定在围墙花园里。羽忆的定位恰恰相反：把记忆从产品特性中抽离出来，变成一个可以部署、迁移、审计和控制的独立基础设施层。
核心目标
第一阶段的设计目标可以概括为一句话：
让用户把“值得长期保留的信息”和“任务过程中的上下文材料”稳定地沉淀到自己的云端记忆层里，并让不同 Agent 可以共享这份记忆。
围绕这个目标，系统需要满足以下要求：
| 目标 | 说明 |
|---|---|
| 开源 | 设计与实现都应可审计、可演进 |
| 自托管 | 核心能力不依赖官方托管服务 |
| 多 Agent 兼容 | 不同客户端都面向同一套记忆 API |
| 模型无关 | 不绑定特定模型厂商原生 memory |
| 用户可控 | 用户可以查看、删除、归档、失效自己的记忆 |
| 部署简单 | Docker Compose 可以快速拉起最小闭环 |
| 安全可审计 | 从第一阶段起就纳入认证、隔离、审计与脱敏 |
非目标边界
为了保证第一阶段聚焦，羽忆明确不把自己定义成以下几类系统：
- 不替代模型厂商官方的产品级 memory
- 不做聊天记录归档系统
- 不做通用知识库或企业搜索平台
- 不做以文档问答为中心的 RAG 产品
- 不在第一阶段引入复杂审批流、多租户计费或全自动记忆治理
这类边界需要明确写出来，是为了避免系统在“什么都能做一点”的扩张里失去主线。羽忆第一阶段的任务不是把所有记忆相关问题一次做完，而是把最核心的“写入、召回、控制、跨 Agent 共享”闭环跑通。
典型使用场景
跨 Agent 共享项目约定
用户在一个 Agent 里沉淀了项目约定、接口风格或技术决策，之后切换到另一个 Agent 时，新的宿主仍然可以读取同一份记忆，而不需要重新讲一遍背景。
长期保存个人偏好
例如：
- 代码示例优先使用 Java
- 回答偏详细，先讲原理再给结论
- 项目接口统一返回
{code, message, data}
这类内容本来就具有跨会话、跨工具复用的价值，适合沉淀为稳定记忆。
延续任务过程中的工作上下文
有些信息不一定值得长期固化，但在短期内极其重要，例如：
- 某个需求已经完成到哪一步
- 某个方案为什么被否决
- 上次排查线上问题时确认了哪些原因
这类材料不适合和长期规则混在一起，但也不能直接丢失，所以需要单独进入历史层，供后续任务召回。
当前阶段的交付判断标准
如果一个用户能够：
- 部署羽忆服务端
- 通过某个 Adapter 写入稳定记忆
- 再写入一条历史材料
- 在另一个 Agent 里成功召回这些内容
- 并且可以手动删除或切换到临时模式
那就说明这套基础设施已经完成了第一阶段最重要的价值验证。