本文件为 meX 产品的最终需求范围。所有标记 ❓ 的需求均已和用户讨论后确定状态（2026-08-05）。
在 2026 年当下，LLM 大模型的能力越来越强，AI 不止能帮助人 Coding，还能帮助人学习、决策、进步。
很多人希望能够在和 agent 的对话过程中形成对用户画像的记忆，并在对话需要时提供用户的个人画像上下文，从而实现 agent 为用户提供个性化的对话服务。
典型场景如情感聊天、理财建议、工作/学习建议、求职辅助、简历撰写、人生决策辅助、个人成长辅助等等方面。
这就要求在人和不同的 agent 之间，存在一套个人的上下文记忆。
meX 是一个记忆系统，存储并提供用户个人相关的记忆上下文，尤其是用户画像相关的条目，从而帮助用户实现个性化的 AI 服务。
| # |
需求 |
状态 |
说明 |
| A1 |
来源标记（用户亲口 / AI 推断） |
✅ 保留 |
每条记忆标记来源，便于人工审查 |
| A2 |
证据关联 |
✅ 保留（调整） |
LLM 生成来源证据摘要（非存储原文），作为可选字段，通过环境变量开关（bool）控制是否启用 |
| A3 |
置信度 |
✅ 保留 |
告诉 agent 有多大可能信任这条记忆 |
| A4 |
时间分层与近期动态 |
✅ 保留（v4 重构） |
三层（layer）语义由"画像槽位 + 画像外记录"承载；状态层/事件层语义以 profile"近期动态"小节回归（默认近 7 天×5 条画像外记录，可配） |
| A5 |
事件层不常驻上下文 |
✅ 保留 |
事件层仅在触发时查询，不固定占用上下文 |
| A6 |
Schema 固定字段 + 扩展字段 |
✅ 保留 |
固定 schema 覆盖用户画像；扩展机制要正规化，不是单个 extra dump（用户明确反对单字段 dump 作为"架构腐败的坏味道"） |
| A7 |
Schema 泛化到各类人群 |
⬇️ 推迟 |
初版先满足用户自身需求，后续扩展 |
| # |
需求 |
状态 |
说明 |
| B1 |
本地存储和管理 |
✅ 保留 |
增删改查 |
| B2 |
软删除（已遗忘字段可恢复） |
✅ 保留 |
删除标记而非物理删除，可恢复，是"后悔药" |
| B3 |
GitHub 备份 |
✅ 保留 |
纯 CLI 实现，无 UI |
| B4 |
磁盘快照导出 |
✅ 保留 |
纯 CLI 实现，无 UI |
| B5 |
文本/文件导入（冷启动迁移） |
✅ 保留 |
需支持用户从其他记忆系统、累积的上下文文档迁移过来的便利性（包括 v1 的 markdown 档案） |
| B6 |
备份文件恢复导入 |
✅ 保留 |
纯 CLI 实现，无 UI |
| B7 |
唯一事实原则 |
✅ 保留 |
同一事物唯一存储，不存在事实冲突 |
| B8 |
管理 UI |
⬇️ 推迟 |
先做 CLI，UI 后续迭代 |
| # |
需求 |
状态 |
说明 |
| C1 |
高召回查询 |
✅ 保留 |
尽可能多命中相关记忆条目 |
| C2 |
高性能查询 |
✅ 保留（软指标） |
性能上的软指标、牵引达成的指标，不作为硬约束 |
| # |
需求 |
状态 |
说明 |
| D1 |
agent 多形态对接 |
✅ 保留 |
文档/插件/skill+CLI 等常用形式 |
| D2 |
常驻自动注入模式 |
✅ 保留 |
常驻上下文 + 尽量少占 |
| D3 |
全手动注入模式 |
✅ 保留 |
CLI 命令实现，支持多筛选条件：领域分区（理财/健康/求职/感情/家庭）、稳定层/状态层、datetime、关键词等 |
| D4 |
尽量少占上下文 |
✅ 保留 |
自动模式下最小化上下文占用 |
| D5 |
画像入口（斜杠命令） |
✅ 保留 |
用户可快速调用画像 |
| D6 |
写路径不轻推断 |
✅ 保留 |
记忆生成有理可循，不轻易做低置信度推断 |
| D7 |
持续核对越用越准 |
✅ 保留 |
会话信息用于修正、删除、确认记忆条目 |
| # |
需求 |
状态 |
说明 |
| E1 |
向量检索 / embedding |
🟡 视底座而定 |
自建方案可不做；开源底座方案有则 OK |
| E2 |
账号体系 |
❌ 砍掉 |
先只在自己本地给自己用，不考虑多租户 |
/Users/wzm/workspace/个人助手
.
├── CLAUDE.md
├── finance
│ ├── buckets-v2.2.md
│ ├── gold-history.csv
│ ├── plan.md
│ ├── reviews
├── history.csv
├── insights
│ ├── frameworks.md
│ └── patterns.md
├── journal
│ ├── 2026
│ ├── INDEX.md
│ ├── decisions.md
│ └── milestones.md
├── me
│ └── profile.md
├── profile
│ ├── assets-dashboard.html
│ ├── assets.csv
│ ├── assets.md
│ ├── biography.md
│ └── relationships.md
├── prompt_history.md
├── sessions
├── skills-lock.json
├── vision
│ ├── goals.md
│ ├── north-star.md
│ └── principles.md
└── 小区.md
- 方案简单，易于扩展
- markdown 可人类直接编辑，不只是让 agent 维护
- 有索引机制、渐进式披露的机制，上下文占用有控制
- 记忆可以被不同的 agent 工具读取和编辑，而不借助任何插件或是 mcp
- 存储架构存在设计问题，同一事物可能存在两个位置（如
me/ 和 profile/ 都是用户基础信息），存在冲突可能
- 没有 schema 结构化数据，markdown 内容全靠 LLM 控制，不利长期架构整洁
- 没有溯源、时间戳、冲突管理等机制，agent 自动生成的记忆真实性和来源无法人工确认
- 没有向量检索机制，深度文档可能造成上下文浪费