MVP 交付范围
羽忆第一阶段追求的是“最小闭环”，不是“功能最全”。只要闭环成立，后续能力都可以在现有架构上继续增量演进。
MVP 的一句话定义
用户可以把记忆写入自己的云端服务，并在另一个 Agent 或客户端里成功召回和控制这些记忆。
服务端必须覆盖的能力
| 模块 | MVP 能力 |
|---|---|
| API Gateway | 统一入口、认证、统一响应、基础限流 |
| Identity & Namespace | 用户与项目作用域解析、基础权限校验 |
| Ingest Service | 稳定记忆和历史材料写入入口 |
| Memory Judge | 基础规则判断与分流 |
| Stable Memory Service | 基本 CRUD、状态管理、版本控制 |
| History Recall Service | 写入、最近记录查询、条件查询 |
| Recall Orchestrator | 混合候选召回、业务排序、结果块生成 |
| Memory Control Service | 列表、详情、删除、归档、失效、模式切换 |
| Search & Index | 词法检索、向量检索、混合排序、过滤 |
| Security | 管理员登录、API Token、敏感扫描、最小审计 |
接入层 MVP
当前阶段优先级最高的是：
- MCP Server
- CLI
- Web Console
原因很直接：
- MCP 能快速覆盖主流 Agent 生态
- CLI 最适合调试、脚本化和验证闭环
- Web Console 承载管理、调试和控制面
SDK、更多 Skill / Tool 适配器可以在 API 和调用模型稳定之后再推进。
部署 MVP
部署侧至少要交付：
memory-server- PostgreSQL / pgvector
- Docker Compose dev / prod 配置
.env.example- HTTPS 反向代理示例
- 快速启动说明
如果部署文档不能让用户在合理时间内拉起最小闭环，再好的对象模型和架构说明都很难形成真实价值。
文档 MVP
第一阶段文档至少需要覆盖：
- 项目简介
- 快速开始
- 核心概念
- 架构设计
- 部署说明
- 接入说明
- 自动生成的 API 参考
也就是说，文档本身就是 MVP 的一部分，而不是功能完成后的附属品。
验收场景
一套 MVP 是否真正成立，可以用以下场景检验：
- 通过 CLI 写入稳定记忆并可读取
- 通过另一个 Adapter 看到同一条记忆
- 写入历史材料后，能在任务召回中被返回
- 删除或切换临时模式后，系统行为与预期一致
- 管理后台可以查看、控制和审计关键对象
只要这些场景都跑通，系统就已经具备第一阶段的核心价值。